Manajer Berada di Posisi Terbaik Untuk Menyebabkan Kesengsaraan
Sebagai manajer, kami berada dalam posisi terbaik untuk menyebabkan kesedihan di tim kami. Jika Anda bercita-cita untuk benar-benar hebat dalam menimbulkan rasa sakit pada tim Anda, perhatikan! Kami akan membahas tiga cara yang paling populer.
Perhatikan bahwa ini difokuskan pada “anti-pola” manajemen proyek. Ada banyak cara lain untuk membuat orang-orang di tim Anda menderita.
Teknik-teknik ini menyebabkan pengiriman lambat dan dapat membuat perusahaan Anda kurang efektif. Dengan partisipasi yang cukup, Anda dapat menyebabkan rekayasa gagal total dalam misinya. Teknik ini tidak hanya membuat tim Anda tidak bahagia, tetapi juga dapat menghancurkan perusahaan Anda!
Tiga Yang Disebut “Anti-Pola”
Manajer sadis telah lama meniru teknik ini, menyebarkannya dari orang ke orang. Hari ini, saya akan membagikannya kepada Anda sehingga Anda dapat mengetahui kapan harus menggunakannya.
Tiga rahasia anti-pola adalah:
- Treadmill tugas
- Sejuta pertemuan Agile
- Gantt-aholik
Saya telah melakukan ketiga pendekatan ini, dan semuanya memiliki manfaat dan risiko. Saya dapat melaporkan bahwa mereka semua menyebabkan penderitaan yang wajar.
1. Treadmill Tugas
Ini adalah teknik penyebab rasa sakit paling umum yang saya lihat di perusahaan rintisan saat ini. Manajer jahat beralih ke itu karena sangat efektif untuk mematikan pikiran.
Berikut cara kerjanya:
- Gunakan Jira untuk menyimpan segala sesuatu yang orang pikirkan tentang pekerjaan yang terkait dengan pekerjaan tim.
- Pecah proyek menjadi satu ton tugas teknis. Bonus jika tugas tidak memiliki deskripsi dan memiliki judul yang sangat teknis yang hanya dapat dipahami oleh satu insinyur.
- Tim bekerja melawan tugas-tugas itu.
- Setiap minggu Anda membawa hal-hal yang tidak selesai.
- Idealnya, pada akhirnya, Anda memiliki pekerjaan yang benar-benar selesai.
Keuntungan Treadmill Tugas
- Bekerja dengan cara ini adalah pekerjaan lini perakitan alih-alih pekerjaan pemecahan masalah. Hal ini menyebabkan para insinyur melepaskan diri dari masalah pelanggan yang harus mereka pecahkan. Ini menghasilkan solusi yang dangkal dan tidak lengkap. Anda menyelesaikan tugas, bukan menyelesaikan masalah.
- Bekerja dari tiket dapat membuat orang enggan untuk menentang pendekatan tersebut, atau memikirkan pekerjaan yang sedang mereka lakukan. Ini menghambat inovasi dan pemikiran segar.
- Jika Anda memiliki pekerjaan penemuan sebagai bagian dari proyek, atau proyek dapat berubah (yaitu, sebagian besar pekerjaan pengembangan produk), rincian rinci Anda baru saja menjadi kewajiban: Anda telah mengumpulkan tumpukan besar tiket yang perlu dikerjakan ulang. Buang-buang waktu!
- Seringkali, pendekatan ini dilakukan tanpa disiplin di balik proses breakdown, sehingga Anda akhirnya membuat tiket saat Anda pergi. Hal ini mengakibatkan tidak tahu berapa lama semuanya akan berlangsung, atau seberapa baik Anda melakukannya. Anda terkutuk jika Anda melakukan kerusakan, dan terkutuk jika tidak! Jenius!
- Pendekatan ini juga cenderung mendorong manajer proyek untuk fokus pada “poin selesai” dan perkiraan mekanis berdasarkan cerita di Jira. Ini berfungsi dengan baik jika pekerjaan benar-benar dirinci, tetapi sering kali ada area risiko atau ketidakpastian yang tidak diperhitungkan. Oleh karena itu sering menyebabkan terlalu percaya diri berdasarkan pengukuran yang salah.
- Kegagalan umum lainnya adalah bahwa tim tidak benar-benar merencanakan pekerjaan mereka. Mereka tidak memikirkan apa yang bisa salah. Mereka tidak berencana untuk belajar. Mereka tidak memikirkan kontur proyek; sangat banyak bekerja melawan kesibukan tiket di Jira.
Seperti yang Anda lihat, ini adalah cara yang sangat efektif untuk menurunkan motivasi tim Anda.
Kekurangan Treadmill Tugas
Anda harus menyadari bahwa teknik ini tidak anti gagal. Atau lebih tepatnya, itu bisa berhasil.
- Jika Anda menggunakan pendekatan ini dengan seseorang yang sangat berorientasi pada detail, dan Anda merinci pekerjaan Anda sepenuhnya, itu bisa berhasil. Biasanya saya melihatnya bekerja hanya jika orang teknis senior menguraikan semua cerita sepenuhnya, dan proyek benar-benar dipikirkan.
2. Sejuta Pertemuan Agile
Jika Anda seorang manajer bengkok, Anda pasti ingin tahu semua variannya. Cara kedua dalam mengelola proyek ini pasti akan membuat tim Anda marah! Pendekatan ini mengikuti bentuk Agile tetapi membuatnya menjadi kelas berat. Saya menyebut pendekatan ini “sejuta pertemuan Agile”.
Pendekatannya adalah:
- Adakan pertemuan untuk backlog grooming (dengan seluruh tim). Periksa setiap item dengan seluruh kelompok.
- Tahan standup harian. Telusuri setiap item dalam Sprint, dan minta setiap orang berbicara melalui naskah. Biasanya, ini berbicara tentang pekerjaan yang telah Anda lakukan dan rencanakan, serta hambatan. Idealnya, ini akan memakan waktu satu jam setiap hari.
- Adakan pertemuan perencanaan Sprint (dengan seluruh tim). Rencanakan pekerjaan untuk Sprint. Periksa setiap item dan pastikan semua orang memahaminya. Jika Anda melakukan ini dengan benar, itu akan memakan waktu setengah hari seminggu sekali.
- Memiliki pertemuan estimasi proyek. Biasanya ini melibatkan penggunaan poker Agile untuk memperkirakan setiap cerita, dan mendiskusikan setiap poin ketidaksepakatan. Bonus jika Anda memperkirakan hal-hal yang mungkin tidak Anda kerjakan!
- Adakan rapat demo. Setiap orang mendemonstrasikan karyanya. Meskipun ini mungkin demo yang bagus, ini adalah pertemuan lain.
- Lakukan retrospektif Sprint setelah setiap Sprint. Latihan yang bagus, tapi OMG, pertemuan lagi?!
Keuntungan Tangkas Sejuta Pertemuan
- Salah satu keuntungan terbesar dari pendekatan ini adalah tampaknya egaliter. Semua orang tahu tentang segalanya! Semua orang setuju dalam segala hal! Ini adalah penutup yang bagus untuk perfidy Anda!
- Hampir semua yang dilakukan tim adalah berurutan. Ini akhirnya memakan banyak waktu. Argumen untuk melakukannya dengan cara ini adalah bahwa ia membangun konteks sebagai sebuah kelompok. Konteks bersama semacam itu sangat berharga (dan dapat membantu tim merasakan kepuasan dari pekerjaan mereka)! Untungnya, pertemuannya sangat membosankan sehingga tidak ada yang benar-benar membangun konteks.
- Ini bekerja sangat baik jika Anda menggunakan cerita kecil. Dengan begitu, overhead untuk proses Anda berlipat ganda. Untungnya, sebagian besar tim menggunakan perincian yang bagus dalam cerita dan tiket mereka, membuat mereka sangat cocok untuk pendekatan ini. Ini berarti tim pada dasarnya mengarungi antrian besar sampah untuk menentukan apa yang harus dikerjakan setiap minggu, dan mereka membangun konteks pada hal-hal yang sebenarnya tidak terlalu penting.
- Ini harus sinkron, yang dapat menjadi tantangan dalam organisasi terdistribusi jarak jauh atau zona waktu.
Ketidakefisienan cara kerja ini dapat menyebabkan pelepasan. Anggota tim akan merasa seperti mereka pergi ke sejuta pertemuan tetapi tidak bisa menyelesaikan masalah apa pun. Ini juga akan membuat mereka merasa rapat tidak berguna, jadi bahkan berkolaborasi dengan rekan satu tim mereka dalam suatu masalah akan terasa seperti siksaan!
Kerugian Agile Sejuta Pertemuan
Praktek-praktek ini sendiri tidak mengerikan. Banyak dari mereka memiliki alasan yang baik di belakang mereka. Jadi Anda dapat mencoba menyebabkan kesengsaraan besar tetapi sebenarnya melakukan pekerjaan yang baik jika Anda tidak hati-hati.
- Tim yang bekerja dengan cerita tingkat tinggi akan cenderung menghindari banyak kesulitan dari pendekatan ini. Pastikan untuk membuat cerita yang cukup kecil, atau tim Anda akan menghindari banyak rasa sakit. Jika tim meninjau beberapa cerita seminggu, mereka mungkin baik-baik saja dengan pendekatan ini.
- Pendekatan ini melakukan pekerjaan yang baik dalam membangun konteks bersama.
3. Manajemen Proyek Gantt-aholic
Terakhir dan tentu saja paling tidak adalah manajemen proyek Gantt-aholic. Ini adalah pendekatan yang biasanya diambil oleh seseorang yang baru mengenal manajemen proyek. Mereka banyak membaca tentang teknik manajemen proyek dan menerapkannya pada pengembangan perangkat lunak. Itu bisa menyebabkan banyak rasa sakit!
Jika Anda ingin membuat dunia menjadi tempat yang lebih buruk, saya akan mulai dengan dua pola lainnya, tetapi ini juga dapat melakukan bagiannya.
-
Manajer proyek membuat bagan Gantt atau bagan PERT dan menggunakan perangkat lunak manajemen proyek atau spreadsheet yang rumit untuk mengelola berbagai hal.
-
Mereka menghabiskan banyak waktu setiap minggu untuk mengelola proyek dan memelihara model mereka.
- Mereka meminta tim untuk memperkirakan segalanya, untuk membangun informasi yang mereka butuhkan untuk model mereka. (Ini sering kali sejalan dengan perkiraan beban berat, seperti merencanakan poker.)
- Mereka sering menyimpan daftar risiko. . . dan log keputusan.
Keuntungan Manajemen Proyek Gantt-aholic
Meskipun ini tidak seburuk beberapa pendekatan lain, ini efektif untuk membuat orang ragu mengapa mereka memasuki dunia teknologi yang mengerikan ini:
- Sebagian besar proyek dalam pengembangan produk memiliki jumlah perubahan atau ketidakpastian yang tinggi. Perencanaan Gantt-aholic tidak memetakan dengan baik untuk berubah. Ini tepat, tetapi tidak akurat. Penemuan atau perubahan dalam proyek sulit untuk dipertanggungjawabkan karena tidak diperkirakan dengan cara yang sama.
- Karena rencananya sangat rumit, diperlukan upaya yang cukup besar untuk menangani perubahan yang tak terhindarkan. Hal ini dapat membuat rencana menjadi lebih kaku dari yang seharusnya karena biaya untuk melakukan perubahan sangat tinggi. Ketidakfleksibelan ini secara tidak wajar dapat mengubah hasil proyek Anda, dan juga menghasilkan pekerjaan yang tersembunyi dari model atau tidak diperhitungkan. Perubahan dapat memakan waktu untuk memperkirakan karena waktu siklus untuk membangun negara baru bisa mahal. Biasanya sulit untuk bereksperimen dengan variasi rencana, dan karena manajer proyek adalah ketergantungan untuk setiap perubahan pada rencana, dan rencana tersebut memerlukan waktu siklus yang tinggi untuk diperbarui, kelincahan perencanaan Anda dikompromikan.
- Karena didasarkan pada model, perkiraan biasanya dihitung. Ini menghasilkan perkiraan yang berayun ke mana-mana.
- Manajer proyek harus menghabiskan banyak waktu untuk mengelola model (kadang-kadang bahkan mengambil alih manajemen proyek itu sendiri).
- Biasanya, manajer proyek adalah satu-satunya orang yang dapat memperbarui model, karena terlalu rumit untuk dipahami orang lain. Artinya, mereka tidak bisa pergi berlibur tanpa kehilangan kemampuan mengelola proyek.
- Tingkat detail yang dibutuhkan berarti tim harus menghabiskan banyak waktu untuk memperkirakan cerita.
Kerugian Manajemen Proyek Gantt-aholic
- Terkadang manajer proyek yang berpengalaman dapat menggunakan pendekatan ini dengan sukses karena mereka menyadari mode kegagalan. Berhati-hatilah jika Anda bekerja dengan orang seperti itu. Mereka mungkin membuat segalanya lebih baik daripada yang Anda inginkan.
Apa Itu “Lebih Baik”?
Kadang-kadang, Anda mungkin merasa perlu untuk berbelas kasih kepada tim yang Anda layani. Dalam hal ini, Anda mungkin ingin membaca tentang alternatif tanpa rasa sakit untuk gaya manajemen proyek ini, yang disebut pengembangan berbasis demo .
Terima kasih
Banyak pemimpin teknik yang berpengalaman memberikan umpan balik yang bermanfaat tentang konsep awal posting ini. Terima kasih kepada Seth Falcon , Bjorn Freeman-Benson , dan Kenichi Nakamura atas banyak saran struktural dan konten yang membuat posting ini lebih kuat dan lebih fokus. Juga, terima kasih kepada Brent Miller , Davy Stevenson , dan Darin Swanson atas perbaikan mereka!
https://dzone.com/articles/make-your-team-miserable-with-these-popular-projec?fromrel=true
