Bisakah laporan harian menurunkan produktivitas pengembang? [Tutup]


18

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 ?


20
Jika rapat scrum Anda membutuhkan waktu lebih dari 5-10 menit, Anda tidak melakukannya dengan benar. Rapat scrum bukan tempat untuk memperbaiki atau mendiskusikan. Yang Anda lakukan hanyalah mengatakan: apa yang saya lakukan, apa yang saya lakukan, dan apa yang menghalangi saya. Butuh 60 detik dan tidak perlu stres sama sekali. Setiap diskusi lebih lanjut harus terjadi di luar scrum.
Chris Eberle

3
Bisakah Anda mengatakan lebih banyak tentang manfaat apa yang akan Anda dapatkan (atau harapan / harapkan dapatkan) dari pelaporan harian?
poolie

9
Saya benci poin # 2: itu tidak menyelesaikan masalah dari sisi pengembang, hanya dari manajer. Ditambah lagi itu menunjukkan bahwa bos tidak mempercayai saya dalam pekerjaan saya. Saya lebih suka apa yang dikatakan Chris: apa yang saya lakukan, apa yang saya lakukan, apa yang menghalangi saya.
mouviciel

5
Pastikan laporan TPS memiliki sampul yang benar.
Simon Richter

2
Apakah ada alasan untuk berbicara dengan lifeforms berbasis karbon lainnya yang diberikan kontrol sumber terintegrasi dengan pelacak bug dan server CI?
Wyatt Barnett

Jawaban:


37

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.


6
+1 "Jika pengaktifan harian Anda membutuhkan lebih dari beberapa (15?) Menit, Anda membagikan terlalu banyak detail ..." dalam pertemuan mingguan kami (di mana kami menghubungi pengembang yang berada di negara bagian lain) kami benar-benar cobalah untuk memperkuat jenis aturan ini. Kami telah mengadakan pertemuan yang telah berjalan terlalu lama dan sejak kami menjadwalkannya sebelum makan siang, ... yah, Anda mendapatkan gambarannya.
James Khoury

Posisi terlama yang saya lakukan adalah 20 menit, dan itu karena masuknya orang. Kami tidak hanya memiliki tim pengembangan, tetapi magang, koperasi, dan satu atau dua kontraktor. Tidak semua orang selalu berbicara, tetapi jika banyak orang memiliki pembaruan yang relevan, itu mendorong batas. Pada 20 menit, perhatian mulai mengembara, sehingga menjadi penutup, sampai jumlahnya berkurang dan kami kembali ke pertemuan 15 menit. Namun, biasanya, 15 menit adalah waktu yang tepat untuk memotret.
Thomas Owens

Apakah Anda pikir ini dapat menurunkan produktivitas mereka? Iya. lol sangat benar. Kenapa kamu tidak coding ?? karena saya sedang menulis laporan tentang pengkodean.
Jenis Anonim

+1: "Saya sedang menulis laporan tentang pengkodean". Status Mikro adalah "Saya memberikan laporan status makro".
S.Lott

11

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.


2
+1: "mereka disorot". Saya telah bekerja untuk pelanggan yang menginginkan status sehari-hari, tetapi masih bersikeras rapat untuk membahasnya. Jika kita akan mengadakan pertemuan itu, mengapa harus menuliskannya terlebih dahulu?
S.Lott

@ S.Lott - mungkin karena tetap ditulis - pada dasarnya daftar pekerjaan yang akan digunakan banyak orang untuk melacak kemajuan mereka sendiri. Mengingat (dari pertanyaan) "tidak perlu mengikuti format tertentu", saya akan dengan senang hati menyalin dan menempel daftar tugas yang harus saya lakukan lengkap dengan item yang lengkap - saya biasanya melakukannya setiap hari untuk memulai to daftar hari berikutnya pula. Laporan lisan saya akan fokus pada apa yang saya ingat dan apa yang saya pikir orang lain harus dengar - jadi itu akan ketinggalan dibandingkan dengan yang tertulis, tetapi juga berspekulasi tentang masalah yang akan datang yang mungkin mempengaruhi orang lain.
Steve314

@ Steve314: "Laporan lisan saya ..." Itu adalah upaya mulia untuk memanfaatkan situasi yang buruk. Lebih mendasar lagi, mengapa duplikat? Jika laporan tertulis tidak digunakan untuk apa pun, mengapa orang memintanya?
S.Lott

@ S.Lott - jika tidak digunakan untuk apa pun, itu benar. Tetapi saya telah mendengar banyak tentang programmer berpikir semuanya berjalan baik-baik saja dengan banyak kemajuan yang dibuat, sementara para manajer panik karena mereka tidak mendengar apa-apa selama berabad-abad dan jadi anggap orang tetap diam berusaha menyembunyikan kekurangan total. kemajuan atau bencana yang akan datang. Biarkan manajer melihat beberapa item tugas yang sudah ditandai dan mungkin itu bisa dihindari. Adapun duplikasi, komunikasi manusia membutuhkan redundansi - semua orang yang terlibat hanya manusia.
Steve314

@ Steve314: "programmer berpikir semuanya berjalan baik-baik saja ..., sementara para manajer panik". Bukan itu intinya sama sekali. Laporan tertulis yang hanya mengarah ke pertemuan untuk membahas kemajuan tidak dibaca . Jika tidak dibaca, mengapa menulisnya? Anda dapat melakukan upaya mulia untuk mengubah situasi yang buruk menjadi baik. Tetapi laporan tertulis yang hanya mengarah pada pertemuan lanjutan adalah pemborosan laporan tertulis. Lakukan saja pertemuan lanjutan. Lakukan saja pertemuan lanjutan setiap hari. Sambil berdiri. Dan dilakukan dengan itu.
S.Lott

6

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.


+1: kami melakukan hal yang sama. Tidak setiap hari, tetapi setiap minggu pada hari Senin sepanjang minggu (jadi cara Anda, hanya pada jangka waktu yang lebih besar). Kami tidak melakukannya setiap hari karena sebagian besar karyawan adalah mahasiswa dan tidak ada di sana setiap hari, sebagian besar komunikasi dilakukan melalui IM atau serupa, sehingga pertemuan mingguan antara seluruh tim (sekitar 10) sudah cukup.
Femaref

6

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.


4

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.


2

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".


1
Jika Anda tidak mengatakan dengan tepat apa yang Anda maksud dengan email status harian singkat, setidaknya beberapa orang akan menghabiskan berjam-jam setiap hari mengkhawatirkan jika mereka melakukannya dengan benar.
Steve314

@ Steve314, lol benar, berpotensi cara yang baik untuk secara proaktif melihat putaran berikutnya penghematan ahem .
Jenis Anonim

2

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.


2

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.


2

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.


2

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.


2

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.