Atasan Pengisap Darah Keluar dari Konteks atau Mengapa Mereka Selalu Gagal

Menurut pendapat saya, artikel "Atasan Pengisap Darah dalam Konteks ..." tidak mengungkapkan alasan kegagalan tim yang mengatur diri sendiri, tetapi alasannya adalah rendahnya kecepatan distribusi persyaratan produk, dan kurangnya pemahaman bahwa pemimpin selalu menjadi bagian dari tim.

Dengan mengubah pendekatan perencanaan departemen desain selama pengembangan produk baru, Anda dapat meningkatkan kecepatan penyebaran informasi, yang jauh lebih penting bagi proyek daripada hanya memiliki informasi.

Desain klasik

Dalam skema klasik, proses perencanaan kerja dan proses pengembangan memiliki jadwal yang jelas. Biasanya, proses perencanaan terjadi sebelum pengembangan. Pada akhir perencanaan untuk setiap bulan, "jadwal kerja jaringan" muncul, yang dengannya proses pengembangan produk oleh departemen desain dimulai. Tidak banyak jenis grafik jaringan - ini terutama PERT dan GANTT . Persyaratan dalam jadwal jaringan biasanya bersifat deklaratif dan tidak didukung oleh apa pun, yang menciptakan beberapa lingkup imajiner saat melakukan pekerjaan dalam proses pengembangan oleh departemen desain dan pengembangan. Bahkan, syarat-syarat dalam jadwal jaringan disepakati dengan pelanggan dan kontraktor dipaksa untuk mematuhinya, jika tidak, tenggat waktu pengembangan utama dapat mengancam penutupan proyek secara keseluruhan. Tidak ada yang meminta pengembang dalam skema klasik, dan manajer proyek hanya menurunkan tenggat waktu untuk setiap pekerjaan kepada pengembang.

Dari samping tampak seolah-olah manajer proyek memberi setiap orang semacam pancing (alat) dan berkata: Pada akhir bulan, saya akan datang dan memeriksa berapa banyak yang telah ditangkap. Kami perlu menangkap 2 ton. " Selama bulan itu, manajer proyek mengadakan pertemuan di mana ia melaporkan siapa, berapa ton dan jenis ikan apa yang ia tangkap. Pada akhir bulan, manajer proyek merilis jadwal jaringan baru "diperbarui", di mana pelanggan ingin menangkap bukan ikan gurame, tetapi misalnya "zucchini" . "Manajer proyek yang bijaksana" memiliki kesempatan untuk mendapatkan bonus untuk membeli plasma baru atau SUV modern baru. Jika dia beruntung dan setidaknya akan ada satu yang menangkap "ikan zucchini", maka dia akan membayar bonus untuk dirinya sendiri dan nelayan yang beruntung, dan akan mengenakan denda pada orang lain.

Mode operasi ini memaksa manajer proyek untuk mengambil sendiri beberapa tugas pengembangan untuk dirinya sendiri, dan pengembang proyek semacam itu selalu terlambat bekerja, dan kadang-kadang mereka harus pergi di akhir pekan untuk dapat mengembangkan antarmuka interaksi pengguna baru dengan produk tepat waktu. Semua ini, seperti yang saya sebutkan di atas, semakin diperburuk oleh fakta bahwa persyaratan untuk produk akhir dapat berubah, dan kemudian jadwal jaringan disesuaikan, dan penyesuaian dibuat sedemikian rupa sehingga tidak mempengaruhi tanggal-tanggal penting dalam proyek.
Dalam skema semacam itu, semua pekerjaan tergantung pada faktor manusia, yang memainkan peran kunci. Faktor manusia dapat diminimalkan dengan memperkenalkan sistem perencanaan dan pengembangan otomatis, yang, pada dasarnya, banyak orang lakukan dengan menerapkan CAD , CAM , CAE , PDM , ERP , CRM , PLM , dll di perusahaan mereka.

Namun, dasar dalam bentuk skema klasik, ketika perencanaan dan pengembangan memiliki batas waktu yang jelas, tetap tidak berubah. Akibatnya, pengembang harus terus memperbarui sejumlah edisi produk perangkat lunak dan dokumentasi di setiap sistem otomatis, serta terus-menerus mendukung integrasi sistem, yang sangat bermasalah dalam kondisi persaingan saat ini di pasar TI. Pelanggan pada akhirnya hanya membutuhkan satu hal - adalah produk jadi atau produksi yang disederhanakan. Dalam skema klasik, daftar dokumentasi yang dikembangkan oleh kontraktor akan selalu berlebihan, karena baik pelanggan maupun kontraktor tidak memiliki keyakinan penuh bahwa tujuan akan tercapai, yang berarti bahwa perlu untuk mendokumentasikan proses secara maksimal untuk mengidentifikasi siapa yang harus “disalahkan” karena gagal memenuhi tenggat waktu. Bahkan jika tujuan akhir awalnya dirumuskan sebagai spesifik (Spesifik), Terukur, Dapat Dicapai, Realistis dan Berbasis Waktu, sebagai hasilnya, setelah persyaratan tambahan pertama, artis dapat kehilangan kepercayaan diri pencapaian tujuan akhir, dan oleh karena itu akan ada rincian tenggat waktu dan penutupan proyek.

Lalu bagaimana memastikan bahwa pelanggan tidak terlalu sering mengubah persyaratan, dan kontraktor memenuhi semua persyaratan pelanggan tepat waktu?

Dalam skema klasik, seorang ahli yang berpengalaman dalam bidang perencanaan proyek berurusan dengan proses perencanaan, yang, berdasarkan pengalamannya, menentukan daftar tugas dan persyaratannya. Saya percaya bahwa semua ini tidak mungkin dilakukan oleh seorang ahli yang berpengalaman, karena tim itu sendiri dapat menentukan jadwal untuk menyelesaikan tugas, serta daftar tugas yang diperlukan untuk eksekusi. Untuk ini, ahli di pihak pelanggan perlu menjelaskan produk sedetail mungkin dalam TK- nya dan batas waktu penggunaan produk, dan hanya itu! Tim, di bawah bimbingan manajer proyek, dapat dengan sendirinya melaksanakan perencanaan kerja, mengidentifikasi perangkap, menguraikan tugas, singkatnya semua pekerjaan yang dilakukan oleh seorang ahli yang berpengalaman.

"Masalahnya" adalah bahwa dalam hal ini setiap anggota tim mengetahui tujuan akhir, itu transparan dan pada setiap saat waktu diketahui sejauh mana tim dari itu. "Manajer proyek yang bijak" tidak akan dapat memasukkan mega-tujuannya dalam tujuan ini: "membeli SUV modern". Agar dia 100% berhasil mencapai mega-tujuannya, dia perlu memisahkan proses perencanaan dan pengembangan, dan memberikan daftar tugas dalam batch ketika “masalah” muncul. Dalam hal ini, tugas manajer proyek untuk mengalihkan perhatian tim ke tujuan akhir proyek sebanyak mungkin, dan memusatkan perhatian mereka pada solusi tepat pada waktunya untuk pekerjaan spesifik dari jadwal jaringan. Dengan kata lain: "isi tim dengan pekerjaan rutin".

Skema kerja yang berbeda secara fundamental adalah skema kerja menggunakan metodologi pengembangan yang fleksibel, di mana prinsip utamanya adalah:
pengiriman terus menerus dari produk yang bernilai kepada pelanggan.

Untuk mencapai hal ini, pertama-tama, transparansi proses perencanaan memungkinkan, ketika setiap anggota tim mengetahui tujuan akhir dan berpartisipasi dalam pembentukan kumpulan tugas untuk 1-4 minggu ke depan, setelah itu pelanggan akan melihat versi pertama produk dengan fungsionalitas baru. Tanggung jawab manajer proyek untuk mendapatkan persetujuan dari pelanggan atau hanya untuk memberi tahu dia tentang versi produk dengan fungsionalitas baru, yang akan siap setelah penyelesaian iterasi. Semua persyaratan tambahan yang berasal dari pelanggan harus diperhitungkan saat merencanakan tim kumpulan tugas dalam iterasi berikut.

Agar tidak menyimpang dari jalan untuk mencapai tujuan akhir, tim mengumpulkan setiap hari selama 15 menit demonstrasi, di mana setiap anggota tim menjawab tiga pertanyaan:

1. Apa yang telah dilakukan sejak pertemuan sebelumnya?
2. Apa yang akan dilakukan untuk reli berikutnya?
3. Apa masalahnya?

Dalam kasus ketika perencanaan dilakukan secara terpisah dari pengembangan, jawaban untuk pertanyaan kedua diberikan oleh manajer proyek, seperti halnya jawaban untuk yang ketiga.

Pada akhir setiap iterasi (sprint), tim mendemonstrasikan produk dengan fungsionalitas baru kepada pelanggan. Setelah setiap demonstrasi, tim berkumpul secara terpisah dari pelanggan untuk melakukan retrospektif. Ada banyak metode untuk melakukan retrospektif, saya ingin mencatat retrospektif dalam gaya "PLUS / DELTA", di mana setiap anggota tim mengekspresikan 10 poin positif (PLUS) dan sepuluh poin yang membuat tim menyimpang (DELTA) dari mencapai tujuan yang dimaksud.

Dalam skema kerja menggunakan teknik pengembangan yang fleksibel, sistem otomatis memainkan peran kunci, memungkinkan Anda untuk mendapatkan produk dengan fungsi baru yang paling canggih di akhir iterasi. Setelah setiap iterasi, produk dapat dikirim untuk pengembangan teknologi dalam sistem ERP atau CRM untuk lebih lanjut memulai produksi produk prototipe untuk pengujian dalam kondisi sedekat mungkin dengan yang nyata. Jadi, setelah setiap iterasi, produk perangkat lunak disempurnakan dan persyaratan fungsional baru dibangun. Klien sendiri sudah pada tahap pengembangan teknologi atau proyek percontohan melalui umpan balik dalam sistem CRM- akan mengungkapkan persyaratan yang bahkan tidak akan Anda pikirkan. Hal utama adalah menyampaikan persyaratan ini kepada pengembang tepat waktu, dan tidak menyembunyikannya di ruang alasan mereka, seperti yang kadang-kadang dilakukan oleh "Manajer Proyek Bijaksana".

Buat kesimpulan

Upaya untuk membangun proses pengembangan sesuai dengan skema klasik menggunakan metodologi yang fleksibel biasanya gagal, dan melihat ini banyak manajer proyek demi "megacels" mereka atau secara otomatis mengikuti prinsip dasar "divide and conquer" menolak untuk menerapkan pengetahuan manajemen proyek modern dalam praktiknya.