Apakah "Tim Bedah" Fred Brooks efektif menangani faktor bus?


10

Tim saya yang terdiri dari 4 pengembang berpengalaman bekerja pada aplikasi Windows modular yang besar (sekitar 200 KLoC). Saya telah fokus pada basis kode inti sejak awal proyek (3 tahun yang lalu) dan secara bertahap telah bergeser ke posisi pengembang semi-lead, meskipun saya bukan manajer tim.

Iterasi kami saat ini adalah refresh UI prioritas tinggi yang diminta oleh manajemen atas, yang melibatkan sekitar 15 perubahan pada basis kode inti. Ketika ditanya oleh manajer, saya memperkirakan bahwa masing-masing dari 15 perubahan akan memakan waktu kurang dari empat jam untuk saya selesaikan , totalnya kurang dari 7 hari kerja. Saya kemudian mengajukan diri untuk melakukan pekerjaan itu. Sebagai gantinya, manajer memutuskan untuk membagi 15 tugas secara merata ke keempat pengembang.

Dalam tiga hari sejak kami mulai bekerja, saya telah mengamati dua hal:

  1. Anggota tim yang tidak berpengalaman lainnya menyelesaikan masing-masing sekitar 1 atau kurang tugas.

  2. Hukum Brook dalam tindakan: Saya menghabiskan sekitar setengah dari waktu saya untuk memberikan bantuan (berusaha melatih mereka dalam menggunakan komponen). Akibatnya, saya hanya menyelesaikan 2 tugas sendiri, daripada yang diharapkan 5 atau 6.

Saya mendekati manajer saya dengan kekhawatiran bahwa kami terlambat dan sekali lagi menyarankan agar saya menyelesaikan tugas yang tersisa. Permintaan saya ditolak, dan alasan yang disebutkan untuk membagi beban secara merata ada dua:

  1. Batasi faktor truk / bus - tingkatkan pengembang lain pada keterampilan ini sekarang, sehingga di masa depan pekerjaan apa pun dapat diberikan kepada siapa pun, bukan hanya saya.
  2. Untuk menghilangkan "bottleneck" (saya) dan menyelesaikan pekerjaan lebih cepat.

Supaya jelas, saya tidak punya masalah dengan: a) menginvestasikan waktu mengajar, b) orang menyentuh kode saya, atau c) keamanan pekerjaan. Bahkan, saya secara teratur menyarankan kepada ketua tim agar saya melatih para dev lain tentang aspek-aspek tertentu dari basis kode inti untuk mengurangi risiko.

Dalam iterasi ini kami juga memiliki banyak koleksi perbaikan bug berprioritas tinggi yang ditargetkan, sehingga tampaknya akan ada lebih banyak kemajuan yang dapat dilakukan jika beban kerja didistribusikan kembali.

Dalam Mythical-Man-Month, Brooks 'menyarankan " Tim Bedah " di mana setiap tim terdiri dari pemimpin + sub-pemimpin (manajer dan saya), dan beberapa peran kecil. Saya merasa seolah-olah kita secara alami jatuh ke dalam organisasi ini, tetapi manajer saya berusaha menentangnya. Saya merasa bahwa faktor bus sudah diurus (manajer pandai dalam kode inti), dan bahwa bottleneck sebenarnya tidak ada (melibatkan lebih banyak pengembang tidak akan membuat pekerjaan berjalan lebih cepat). Saya pikir dalam hal ini, Tim Bedah adalah Hal yang Baik.

Ini adalah perasaan saya, tetapi saya bukan manajer yang berpengalaman, kami juga tidak harus berurusan dengan faktor bus (mengetuk kayu). Apakah Brooks benar? Pernahkah Anda bekerja di "Tim Bedah" di mana faktor bus ikut bermain? Apakah ada teknik yang lebih baik untuk mengelola keahlian mendistribusikan?

Pertanyaan serupa:


1
Anggap itu sebagai pelatihan dalam mengkomunikasikan keterampilan Anda kepada tim.

Jawaban:


5

Sebenarnya, saya berpendapat bahwa Anda mengikuti model "tim bedah". Beruntung!

Bagian dari titik model tersebut adalah bahwa anggota tim yang lebih rendah memiliki peran asisten. Ketika tim tidak melakukan operasi jantung, maka boleh saja untuk bergerak lebih lambat dan memberi mereka kesempatan untuk mempraktikkan beberapa keterampilan mereka, atau untuk menyeberang melatih dalam tanggung jawab.

Adalah tugas dokter bedah untuk memeriksa dan mengelola tim mereka dengan mencari titik-titik lemah dan menyelesaikannya, serta menjadi pengembang teratas. Anda tidak dapat meminta non ahli bedah (manajer bisnis) melakukan ini, karena mereka tidak memahami keterampilan yang diperlukan, seperti magang bagi pengrajin ahli.

Jadi, manajer mengambil keuntungan dari kesempatan ini untuk mengerjakan salah satu tujuan lainnya. Jika selama itu, beberapa cacat terungkap dalam tim, dia bisa mengatasinya sebelum itu menjadi masalah. Katakanlah, dengan mempekerjakan pengembang lain.

Atau, junior mungkin membuat kesalahan. Ini adalah waktu yang tepat bagi mereka untuk melakukannya, karena ada seseorang yang mengawasi dari belakang. Oscar Wilde berkata

Pengalaman hanyalah nama yang kita berikan kesalahan kita.

Jika junior ini tidak pernah memiliki kesempatan untuk melakukan kesalahan, maka mereka tidak akan pernah membaik. Ini tidak hanya akan merampok tim Anda dari pengembang masa depan yang berpengalaman, tetapi dalam arti tertentu, merampas peluang yang seharusnya mereka miliki.


Terima kasih atas jawabannya. Sudah, pengalaman ini jelas mengungkapkan dua kelemahan dari tim kami: 1) basis kode inti kami terlalu besar, dan membutuhkan lebih banyak modularisasi, dan 2) ketika kami melakukan modularisasi lebih banyak, pengembang lain perlu memimpin komponen baru, alih-alih saya. Masalah yang lebih besar, yang tidak selalu menjadi bagian dari pertanyaan awal saya, adalah bahwa saya memiliki pengetahuan yang jauh lebih besar tentang kode daripada manajer (yang merupakan ahli bedah "resmi"), jadi ia tidak mendelegasikan secara efektif karena ia dapat melakukannya. .
Kevin McCormick

@KevinMcCormick - Sepertinya Anda harus membiarkan manajer Anda khawatir tentang hal-hal ini. Sesuaikan perkiraan Anda sekarang termasuk membantu anggota tim Anda dengan tugas-tugas mereka. Anda perlu pembenaran untuk melakukannya.
Ramhound

@Ramhound, pasti benar, dan saya bahkan sudah mendiskusikannya dengan manajer dan dia menyetujuinya di masa depan. Beberapa ketidakseimbangan dalam keterampilan yang tidak dia sadari, dan dia menawarkan bantuan. Dia tahu bahwa proyek itu sangat membebani saya, yang kami berdua berusaha selesaikan.
Kevin McCormick

7

Perusahaan kami dulu bekerja seperti yang Anda sarankan. Kami hanya memiliki dua orang yang memahami bagian penting dari kode. Setiap kali sebuah tugas muncul di bagian kode itu, daripada menghabiskan beberapa minggu untuk mempercepat orang lain, tugas itu akan diberikan kepada mereka karena mereka dapat menyelesaikannya dalam beberapa hari. Ini sebenarnya bekerja cukup baik untuk sementara waktu.

Apa yang terjadi pada akhirnya piring mereka menjadi begitu penuh sehingga meskipun mereka mungkin dapat menyelesaikan tugas dalam 2 hari, itu akan memakan waktu berminggu-minggu untuk pindah ke puncak daftar mereka. Manajer akan memiliki pertempuran verbal yang sengit mengenai tugas siapa yang lebih mendesak. Tugas yang tergantung mendesak akan dibatalkan.

Akhirnya manajer bosan menunggu dan mulai melatih tim mereka sendiri. Ya, itu jauh lebih lambat untuk sementara waktu, tetapi sekarang throughput kami jauh lebih baik.

Anda mungkin berada di fase pertama sekarang di mana Anda dapat menangani pekerjaan, tetapi Anda tidak memiliki cara untuk memprediksi kapan Anda akan pindah ke fase kedua. Ini sebuah petunjuk: itu selalu terjadi pada waktu yang paling tidak nyaman. Manajer Anda benar untuk menerima pukulan ketika Anda masih memiliki ruang bernapas.

Ya, sangat frustasi menyaksikan seseorang bergumul dengan sesuatu yang bisa Anda lakukan dengan lebih cepat dan mudah. Cobalah mengasuh anak yang berusia dua tahun kapan-kapan. Anda melakukannya karena membantu seluruh tim meningkat. Adalah tugas manajer Anda untuk mengkhawatirkan jadwal. Jika Anda khawatir tentang bug prioritas tinggi yang dibatalkan, tantang diri Anda untuk melihat seberapa cepat Anda dapat memperbaikinya.


Terima kasih atas jawabannya! Saya pasti dapat mengatakan bahwa "fase 2" adalah ketakutan yang nyata, mengingat bahwa kami memiliki karyawan lain dari proyek lain yang merupakan hambatan yang sangat terlihat, dan itu menyebabkan masalah besar di masa lalu. Saya tidak yakin apakah proyek kami memiliki masalah yang sama, jadi saya kira ada sedikit gangguan di sini. Bagaimanapun, saya menganggap ini sebagai kesempatan untuk berbagi pengetahuan dan mungkin mengungkapkan beberapa kelemahan dalam dokumentasi, modularitas kode, dll. Dan ya, ini sangat membuat frustrasi! Sangat menyenangkan untuk mendengar orang lain yang merasakan hal yang sama.
Kevin McCormick

6

Anda mungkin tidak menjadi hambatan sekarang, tetapi pada akhirnya Anda akan menjadi jika Anda terus melakukan semua pekerjaan sendiri. Manajer Anda menyadari bahwa cukup penting bagi Anda untuk belajar mendelegasikan risiko bahwa proyek Anda terlambat - percayalah padanya. Setelah Anda belajar untuk melepaskan, junior Anda akan mulai belajar dan memproduksi lebih banyak di bawah bimbingan Anda.


Terima kasih atas jawabannya, saya sangat setuju bahwa satu orang yang melakukan semua pekerjaan adalah risiko tinggi dan manajer menyadari hal itu. Namun dalam hal ini, saya tidak melakukan semua pekerjaan. Anggota tim lainnya sangat produktif ketika mengerjakan tugas-tugas lain, seperti memperbaiki bug dan mengerjakan subkomponen - bukan arsitektur sistem inti. Akan agak mirip dengan menyarankan kepada seseorang di tim Windows Media Player di MS untuk membuat perubahan pada kernel Windows.
Kevin McCormick

@KevinMcCormick - Bagaimana jika Media Player ditambahkan ke Windows Kernel, alasan yang sah, untuk melakukannya. Sepertinya Anda tidak ingin anggota tim menjadi lebih akrab dengan arsitektur sistem inti, dan saya tidak bisa melihat alasan untuk melakukannya, itu hanya akan membantu Anda dalam jangka panjang.
Ramhound

@Ramhound, ya tentu saja dalam kasus itu pasti akan benar. Saya memang ingin orang lain mengambil kepemilikan atas apa yang saya tulis, membuat perubahan, dan memahaminya (saya secara teratur memberikan pelatihan dan dokumentasi). Saya hanya tidak berpikir bahwa pendekatan "semua orang mengerjakan segalanya dengan tingkat yang sama" adalah efektif vs beberapa tingkat penugasan peran, karena kita semua memiliki keahlian dan keahlian yang berbeda.
Kevin McCormick

3

Anda menerapkan batasan yang mungkin tidak ada atau sepenting apa yang Anda pikirkan. Khususnya, Anda khawatir tentang waktu sampai selesai. Manajer Anda, di sisi lain, tidak tampak khawatir dengan batasan waktu yang dirasakan.

Jika Anda mengambil waktu pengiriman dari pertanyaan Anda, Anda akan segera mulai bertanya-tanya mengapa Anda mengajukan pertanyaan di tempat pertama.

Itu bukan untuk mengatakan bahwa waktu selalu tersedia, dan Anda menyatakan ini adalah permintaan prioritas tinggi dari manajemen atas. Tapi Anda tidak tahu semua percakapan bos Anda dengan mereka. Dia mungkin telah bernegosiasi untuk lebih banyak waktu agar Anda menghabiskan waktu itu untuk melatih anggota tim yang lain.

Dan sementara Anda merasa faktor bus telah diatasi, atasan Anda mungkin mencari permintaan berikutnya yang tidak akan masuk dalam 7 hari kerja oleh salah satu pengembang bintangnya. Jauh lebih aman untuk melatih tim pada iterasi yang lebih kecil di mana besarnya objektif risiko jauh lebih kecil.

Saya telah menjadi hambatan kritis sebelumnya; dan jujur, itu bukan tempat yang menyenangkan. Dalam kasus saya, Wakil Presiden IT dan saya berbicara dan kami membuat rencana untuk memperbaiki masalah secara permanen. Rasanya sakit, tapi sakitnya jauh lebih sedikit daripada aku diangkut truk.

Sangat mudah untuk masuk ke dalam pola pikir segala sesuatu yang perlu dihilangkan secepat mungkin. Seorang manajer yang baik melihat peluang langka di mana sedikit keterlambatan (untuk pelatihan silang / pendidikan) dapat membayar dividen yang signifikan di kemudian hari.


Terima kasih atas jawabannya! Saya berharap saya bisa menerima semuanya. Batasan waktu sangat nyata dalam kasus ini, tetapi seperti yang dikatakan orang lain, tidak pernah ada waktu yang tepat untuk melakukan investasi waktu semacam ini. Akan tertarik mendengar bagaimana Anda menyelesaikan situasi Anda.
Kevin McCormick

3
+1 Beberapa bos mungkin idiot, tetapi sering kali bos Anda memiliki perspektif yang lebih luas dan Anda hanya perlu mempercayainya.
Phil

@ Phil - Jujur kedengarannya seperti dalam kasus ini bos sebenarnya mungkin memiliki perspektif yang baik. Biarkan dia khawatir tentang timeline, khawatir terlambat, dia memberikan estimasi. Kasus terburuk, waktu krisis terjadi, dan Anda menyelesaikan semuanya sendiri.
Ramhound
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.