Bisakah laporan harian menurunkan produktivitas pengembang? [Tutup]

Dalam pertanyaan lain , saya bertanya tentang mengapa pengembang mungkin tidak menyukai scrum harian . Kami berbicara dengan pengembang dan kami memutuskan untuk tidak memegang scrum harian untuk sementara waktu (untuk memberikan scrum coba dan kustomisasi dalam upaya pertama kami). Ini adalah hasil konsultasi dengan pengembang secara langsung.

Di sisi lain, kami tidak ingin kehilangan bagian scrum harian yang baik, seperti mendapatkan kesempatan untuk mengoordinasikan pengembang setiap hari, atau menonton kemajuan pekerjaan seperti Indikator Kinerja Utama, untuk mengambil tindakan lebih awal.

Sebagai alternatif untuk scrum harian, kami berpikir untuk meminta pengembang memberikan laporan harian dengan ketentuan berikut:

1. Tidak perlu mengikuti format spesifik apa pun. Setiap format diterima.
2. Bahkan jika pekerjaan itu belum selesai, kami ingin mendengar jumlah kemajuan.
3. Tidak perlu menyebutkan waktu yang dihabiskan untuk setiap tugas.
4. Hambatan pembangunan dan persyaratan koordinasi harus disebutkan.
5. Tidak perlu terobsesi dengan laporan harian. Tidak terlalu ketat.

Apakah Anda pikir ini dapat menurunkan produktivitas mereka? Sudahkah Anda memiliki pengalaman laporan harian? Apakah Anda memiliki saran untuk kami, sehingga kami dapat memastikan bahwa kami tidak mengelola mikro ?

Sebagai alternatif untuk scrum harian, kami berpikir untuk meminta pengembang memberikan laporan harian dengan ketentuan berikut:

Gagasan yang mengerikan.

Apakah Anda pikir ini dapat menurunkan produktivitas mereka?

Iya.

Mengapa? Sebuah presentasi lisan pada menggabungkan pertemuan menulis dan n orang "membaca" laporan menjadi satu kegiatan bersamaan. Berbicara plus Mendengarkan. Lebih dan selesai dengan. Pertanyaan langsung dijawab.

Menulis laporan adalah buang-buang waktu karena akan ada pertanyaan dan Anda harus meninjau laporan dengan orang-orang yang (a) memiliki pertanyaan dan (b) tidak benar-benar membacanya.

Laporan harian, tidak akan dibaca. Mereka dengan cepat berpindah ke in-box-noise.

"Tidak perlu terobsesi dengan laporan harian". Dalam hal ini, mengapa mereka melakukannya?

Apakah Anda memiliki saran untuk kami, sehingga kami dapat memastikan bahwa kami tidak mengelola mikro?

Iya. Miliki stand-up harian. Butuh beberapa menit dan Anda selesai.

Jika pengaktifan harian Anda membutuhkan lebih dari beberapa (15?) Menit, Anda membagikan terlalu banyak detail dan perlu menjadwalkan pertemuan terpisah untuk detail tersebut. Stand-up harian mudah dilakukan. Setelah ringkasan 2 menit, yang lainnya mungkin detail, bukan untuk seluruh tim, dan perlu didorong ke pertemuan lanjutan. Rapat beralih ke fokus orang berikutnya untuk hari itu.

Saya sudah melakukan ini di masa lalu, tetapi di pagi hari yang bertentangan dengan akhir hari. Untuk mengisi, biasanya kurang dari lima menit, jadi tidak, saya tidak bisa melihat bagaimana akan ada penurunan produktivitas pengembang. Hal yang menyenangkan tentang melakukannya di pagi hari adalah membuat Anda berpikir tentang apa yang akan Anda lakukan untuk sisa hari itu.

Setelah mengatakan itu ...

Kami menemukan bahwa itu lebih sering daripada tidak, itu bukan metode paling efektif untuk mengkomunikasikan apa yang telah kami lakukan pada hari sebelumnya dan apa yang akan kami kerjakan pada hari itu. Mengapa? Orang pada umumnya tidak membacanya. Itu adalah tugas Outlook yang dijadwalkan, jadi semua orang mengirim mereka keluar setiap hari, tetapi entah itu disingkirkan atau hanya terlewatkan sama sekali (selain oleh lead atau manajemen).

Kami menemukan bahwa memiliki stand-up harian jauh lebih berharga karena orang-orang cenderung saling mendengarkan. Juga, jika ada kesalahpahaman, itu akan hilang di sana-sini, yang lebih cenderung terjadi daripada seseorang membalas email status harian untuk mengajukan pertanyaan lebih lanjut.

Dalam semua kejujuran, membiarkan siapa pun untuk melapor tanpa kendala tampaknya agak terlalu jauh ke sisi liberal dari persamaan. Di tempat saya bekerja, kami berputar-putar dan setiap pengembang memberikan yang berikut:

1. Apa yang dilakukan pada hari sebelumnya. Tidak semua detail kecil, tapi secara keseluruhan.
   • Jika hal di atas belum selesai, jika tidak, apa yang dibutuhkan untuk menyelesaikan dan berapa lama.
   • Jika hal di atas selesai, apa tugas selanjutnya, apa yang diperlukan, dan waktu yang dibutuhkan.
2. Blocker. Jika Anda bekerja di Foo, yang tergantung pada Bar, dan Bar belum selesai, ini harus diperjelas.

Menyiapkan skema umum untuk diikuti semua orang dapat membuat melalui laporan yang diberikan menjadi mudah. Anda dapat dengan mudah mengatur beberapa metode bagi semua orang untuk mendapatkan email dengan laporan harian, dan karenanya memungkinkan siapa pun untuk mengetahui apa yang sedang terjadi.

IMO semua jenis rapat / laporan harian mengurangi produktivitas karena, sejujurnya, bau manajemen mikro. Ya, saya mengetahui Scrum dan sejenisnya dan itu tidak terlalu buruk asalkan mereka pembaruan status singkat ("Hei bagaimana Proyek X datang?") Tapi saya sangat percaya bahwa itu menghina pengembang profesional untuk mengawasi kita pada level rendah itu; itu mirip dengan menggunakan kartu waktu untuk memastikan kita berada di kantor 8 jam sehari, atau memastikan tidak ada dinding sehingga Anda dapat memata-matai komputer orang untuk melihat jendela apa yang telah mereka buka pada waktu tertentu.

Jika Anda harus mengawasi semua orang untuk memastikan mereka berfungsi, itu artinya Anda tidak mempercayai mereka. Jika Anda tidak mempercayai mereka, ada masalah yang lebih besar di tempat kerja daripada yang Anda khawatirkan.

Tim saya telah melakukan scrum selama sekitar satu tahun sekarang. Sebelum itu kami mengadakan dua pertemuan seminggu, di mana setiap anggota tim melaporkan tentang kegiatannya dalam 2, 3 hari sebelumnya. Setiap pertemuan berlangsung antara 30 menit dan 1 jam. Jika kami perlu bertukar informasi dan mengoordinasikan pekerjaan kami, kami hanya naik ke rekan-rekan kami dan berbicara kepada mereka (yang masih kami lakukan, tentu saja).

Sekarang kami melakukan scrum, kami sering mendapat kesan bahwa satu pertemuan sehari (meskipun hanya berlangsung 15 menit) terlalu banyak. Seringkali laporan dari beberapa anggota bermuara pada: "Tidak ada yang baru sejak kemarin". Kami sering memiliki kesan bahwa skema 2-pertemuan-per-minggu lebih efektif.

Kelemahan lain adalah bahwa pertemuan harian adalah gangguan yang terencana (lihat misalnya artikel Paul Graham , poin 1. Hindari gangguan): karena Anda tahu gangguan akan datang, Anda tidak akan memulai sesuatu yang sulit sebelum pertemuan (pertemuan harian mungkin berlangsung satu hingga satu setengah jam setelah seseorang mulai bekerja).

Terakhir tetapi tidak kalah pentingnya, sementara umpan balik awal memang memiliki kelebihan ("Oh, Anda sedang mengerjakan masalah itu, kita harus membahasnya!"), Kadang-kadang lebih efektif untuk memulai diskusi hanya ketika Anda sudah mengatur ide-ide Anda di pikiran Anda. , Anda memiliki pertanyaan spesifik, dan Anda siap untuk berdiskusi. Sebaliknya, laporan harian dapat dengan cepat menyebabkan banyak brainstorming yang tidak perlu dan tidak terstruktur. Jadi, waspadalah terhadap umpan balik yang terlalu dini : itu dapat membingungkan Anda dan memperlambat Anda.

Jadi: dalam beberapa kasus, laporan harian memang menurunkan produktivitas kami. Rata-rata, saya tidak merasa mereka membuat pekerjaan kami lebih efektif.

MEMPERBARUI

Saya menulis jawaban asli saya beberapa tahun yang lalu, dan sementara itu saya telah berganti tim. Di tim saya saat ini, kami melakukan pertemuan harian sesuai permintaan, yaitu ketika kami merasa kami perlu pembaruan status singkat. Jadi, setiap hari ada kemungkinan untuk mengadakan pertemuan seperti itu tetapi kami tidak melakukannya jika tidak ada yang memintanya. Kami memiliki pertemuan retrospektif mingguan. Ini pada dasarnya sangat mirip dengan pendekatan yang awalnya kami gunakan di tim saya yang sebelumnya tidak gesit: pertemuan mingguan tetap ditambah pertemuan berdasarkan permintaan tambahan selama sisa minggu itu.

Jika yang Anda inginkan adalah status kasar dan mencatat hambatan apa pun, cara terbaik adalah meminta mereka untuk "email status harian" pendek. Jika Anda terlalu menekankan pada hal itu, atau membuat daftar apa yang seharusnya / tidak boleh berisi maka setidaknya beberapa devs Anda akan menghabiskan waktu ekstra untuk membuatnya memenuhi persyaratan. Alih-alih itu, tanyakan saja surel sederhana. Ketika hal-hal muncul sepanjang hari mengatakan hal-hal seperti "oh, tuliskan itu di email akhir hari Anda" dan jika Anda mendapatkan email akhir hari yang sangat panjang, sebutkan dengan santai "Anda tidak perlu detail seperti itu setiap hari".

Sangat membantu untuk memperjelas tujuan rapat atau laporan, terutama yang dilakukan oleh semua orang setiap hari. Anda mengatakan alasannya adalah:

kami tidak ingin kehilangan bagian scrum harian yang baik, seperti mendapatkan kesempatan untuk mengoordinasikan pengembang setiap hari,

Apa yang Anda maksud dengan mengoordinasikan pengembang ? Jenis pekerjaan apa yang perlu dikoordinasikan dan belum ad-hoc dikoordinasikan oleh pengembang dan manajer mereka saat dibutuhkan? Apakah mungkin ada beberapa cara Anda bisa mengidentifikasi tugas yang akan membutuhkan koordinasi, dan berkomunikasi hanya dalam kasus-kasus itu?

atau menonton kemajuan pekerjaan seperti Indikator Kinerja Utama, untuk mengambil tindakan lebih awal.

Banyak KPI yang baik (seperti waktu respons situs, atau jumlah bug kritis) akan dapat diukur secara mekanis, dan Anda tidak perlu membebankan biaya pada pengembang untuk melakukannya.

Saya harus membuat laporan harian dalam beberapa format berbeda di tempat kerja. Secara umum, saya pikir laporan harian cenderung hanya menambah nilai bagi manajer, bukan untuk pengembang itu sendiri. Sementara manajer mendapat manfaat dari laporan harian dengan mengetahui status keseluruhan dari setiap proyek dan beban tugas masing-masing karyawan dalam waktu singkat, menurut pengalaman saya sebagian besar pengembang tidak repot membaca laporan status masing-masing.

Namun, sepertinya dengan tidak menegakkan format untuk laporan harian Anda, Anda membuat laporan lebih sulit untuk dibaca dan diproses untuk kedua manajer dan sesama pengembang, sehingga memperburuk masalah hilangnya waktu pengembang.

Jika Anda memutuskan untuk maju dengan laporan harian untuk pengembang Anda, bolehkah saya menyarankan menggunakan wiki internal alih-alih laporan email? Dengan begitu Anda tidak mengirim spam ke kotak masuk orang, sambil mempertahankan riwayat status harian setiap orang.

Ini adalah ide bagus untuk menyesuaikan metode Agile Anda untuk membuatnya cocok untuk Anda - jadi pujian untuk itu.

Jadi, laporan harian sebagai gantinya, saya akan mengatakan ini tidak jauh lebih baik daripada pertemuan harian, itu masih sama "katakan padaku apa yang Anda lakukan" pendekatan, Anda baru saja membuat semua orang menuliskannya daripada berbicara itu.

Inilah pendekatan alternatif: alih-alih menggunakan teknik 'polling' ini di mana Anda meminta status masing-masing pengembang, Anda malah menggunakan teknik 'push'. Jika dev tidak memiliki banyak hal untuk dilaporkan, mereka tidak, mereka harus melaporkan setiap dan semua masalah dan kemajuan saat mereka terjadi. Jadi ketika mereka menyelesaikan modul, mereka harus mengirim email ke semua tim yang sudah selesai, bahwa itu di SCM, di mana dokumentasi dapat ditemukan, dan ringkasan singkat tentang apa itu, cara kerjanya, dan / atau bagaimana cara menggunakan Itu. Jika mereka memiliki masalah, mereka harus mengirim email kepada tim untuk meminta saran, bantuan atau tip. (Ya, sama seperti masa lalu di mana tim berkomunikasi dengan baik tanpa manajemen mikro yang kita derita hari ini)

Anda akan menemukan bahwa ini jauh lebih produktif, dan konstruktif. Anda tidak akan mendapatkan laporan yang tidak berarti demi mereka dan Anda akan mendapatkan tim yang lebih termotivasi karena semua orang suka memberi tahu rekan kerja mereka tentang pekerjaan mereka.

Saya juga setuju bahwa itu adalah ide yang buruk untuk mengganti stand-up harian dengan laporan. Stand-up harian adalah tempat yang tepat untuk menyuarakan ide dan masalah. Ini adalah salah satu alasan saya suka papan tulis tua yang bagus (yang kami gunakan bersama Jira + Greenhopper). Papan tulis adalah tempat di mana kelompok 'berkerumun' dan berbagi informasi, semuanya ada di sana, semuanya terlihat, semua orang bergerak dan mengubah perekat yang mereka kerjakan, itu juga sangat menyenangkan.

Tidak bisakah Anda mengekstrak informasi ini dari alat Anda yang lain?

• Apa yang sedang Anda kerjakan? Tiket yang saya tetapkan.
• Apa kemajuan Anda? Untuk tiket yang saya miliki lebih dari 1 hari, lihat komentar di tiket atau komit pesan dari cabang. Tiket yang saya miliki lebih pendek: mungkin dilakukan besok (Anda tidak menghasilkan tiket 5+ hari besar, ya?)
• Apa kemajuan umumnya? lihat rasio tiket terbuka / tertutup
• Apa yang perlu diatur? tiket yang Anda dapatkan ditugaskan kembali, dengan umpan balik status yang diperlukan , dan semua yang dibahas di IRC tim Anda, Ruang Api unggun, apa pun.

Ketika Anda memiliki pertanyaan yang lebih spesifik untuk dijawab, saya akan melihat perlunya laporan spesifik, tetapi tanpa itu laporan Anda terlihat seperti akhir saja.