Satu tanda silang (+) berarti bahwa kurir dapat pergi ke tujuan dalam langkah-langkah, dua salib (++) berarti lynx, tiga salib (+++) - sebuah gallop langsung. Oleh karena itu, derap pasukan secara tidak resmi disebut daya tarik dari tiga salib , dan kemudian ungkapan ini memasuki bahasa Rusia, yang berarti eksekusi perintah yang paling cepat dari pihak berwenang. [Wikipedia]
Tar pit (bahasa Inggris, secara harfiah pit tar ) - 1) masalah yang tak terpecahkan, 2) danau bitumen (tempat bitumen bawah tanah muncul ke permukaan, menciptakan bagian aspal alami). [Kamus Inggris-Rusia] Hewan yang ditangkap dalam bitumen tidak bisa keluar, jadi danau ini adalah tempat yang bagus untuk menggali kerangka prasejarah [Wikipedia].
“Imajinasi mewakili dinosaurus, mammoth, dan harimau bertaring tajam yang berusaha membebaskan diri dari resin. Tidak peduli seberapa kuat atau gesit binatang itu, pada akhirnya ia akan ditakdirkan untuk mati. Dalam dekade terakhir lubang pemrograman seperti itu adalah pemrograman sistem besar ... ” [1, p.16] Dengan gambar yang mencolok ini, buku klasik oleh Frederick Brooks dimulai, yang pertama kali melihat cahaya di kejauhan tahun 1975. Buku klasik lain, yang diterbitkan pada tahun 1987 kuno yang sama, dimulai tidak lebih baik: "Dan pada saat itu proyek sedang sekarat di suatu tempat" [2, hal.23]. Tahun demi tahun berlalu, umat manusia memasuki milenium baru, tetapi pada tahun 2014 buku terlaris lainnya dimulai dengan kisah abadi yang sama: “Pada 3 Maret 2010, Biro Investigasi Federal memutuskan untuk menangguhkan rencana berskala besar dan menjanjikan untuk memodernisasi manajemen informasi ... Biro mencoba memperbarui sistem komputernya selama lebih dari sepuluh tahun, dan tampaknya bencana telah menimpa mereka ” [3, hal.14].
44 tahun setelah Brooks, kami dapat, dengan hati nurani yang jelas, mengulangi: sekarang, ketika Anda membaca baris-baris ini, proyek berikutnya, seperti pendahulunya, tenggelam di lubang tar yang sama. Peluang keberhasilan dalam manajemen proyek kurang dari ketika melempar koin, dan itu tampaknya tidak tumbuh banyak:
Menurut Studi CHAOS dari Standish-Group [4]
Mengapa kemajuan dalam ilmu manajemen (diwujudkan dalam 6 edisi PMBoK dan beberapa lusin buku tebal lainnya) selama 40 tahun (!) Tidak pernah mengarah pada peningkatan kualitas manajemen itu sendiri (kecuali, tentu saja, dengan kualitas manajemen dipahami probabilitas tiba pada titik tertentu)? Untuk mengatasi masalah ini, kita mulai dengan masalah utama dari setiap proyek, yang diidentifikasi di seluruh buku Brooks yang terkenal.
Masalah pertama: kompleksitas produk yang sedang dibuat
Jika Anda bertanya pada spesialis IT pertama yang menemukan - "Apa hal utama dalam bulan Mythical?" - jawabannya mungkin: "Bahwa semua bulan kerja berbeda, pekerja baru sama sekali tidak sama dengan yang lama." Bahkan Brooks menyebut "undang-undang" ketentuan yang dirumuskan pada awal buku ("Jika proyek tidak memenuhi tenggat waktu, maka menambahkan lebih banyak tenaga kerja akan menunda lebih banyak lagi"). Tapi ini hanya pengamatan empiris, diketahui oleh semua orang bahwa setidaknya sekali "mengubah kuda di persimpangan"; pertanyaannya adalah bagaimana merencanakan proyek ketika semua bulan kerja berbeda?
"Mythical man-month" karenanya menjadi buku terlaris, yang memberikan jawaban untuk pertanyaan ini. Inilah cara Brooks merumuskan pemahamannya tentang masalah desain dasar:
"... kesulitan klasik pengembangan perangkat lunak berasal dari kompleksitas entitas dan pertumbuhan non-liniernya dengan ukuran yang semakin besar. Kompleksitas menyebabkan kesulitan dalam proses komunikasi antara anggota tim pengembangan, yang mengarah pada kesalahan dalam produk, melebihi biaya pengembangan, menunda pelaksanaan jadwal kerja. Kompleksitas adalah alasannya kesulitan pencacahan, dan bahkan lebih dari itu pemahaman semua kemungkinan keadaan program, dan karenanya tidak dapat diandalkan muncul ... Kompleksitas struktur menyebabkan kesulitan selama pengembangan program dan penambahan fungsi baru sehingga tidak ada efek samping ... " [1, hal. 167]
Perbedaan mendasar antara proyek dan produksi lainnya adalah bahwa proyek yang dibuat di dalamnya diproduksi untuk pertama kalinya [kami sadar bahwa banyak tugas seperti "mengacaukan kunjungan ke situs" juga disebut "proyek", tetapi kami berbicara tentang proyek nyata]. Seperti hal yang nyata, produk baru ini (tidak masalah apakah itu perangkat lunak atau "perangkat keras") terdiri dari sejumlah besar komponen yang mampu berinteraksi paling tak terduga (baik negatif - thalidomide dan positif - viagra). Sangat sulit untuk meramalkan bagaimana semua ini akan bekerja bersama, dan ini secara harfiah membutuhkan "pikiran yang lebih baik," dan bukan "bulan-bulan" yang tak berkesudahan:
“Proyek-proyek yang luar biasa diciptakan oleh para desainer terkemuka. Membuat program adalah proses kreatif. Metodologi yang kuat dapat memberdayakan dan membebaskan pikiran kreatif, tetapi itu tidak dapat menyalakan atau menginspirasi seseorang yang sibuk dengan pekerjaan yang membosankan ... Oleh karena itu ... Saya percaya bahwa satu-satunya dan upaya terpenting yang dapat kita lakukan adalah mengembangkan cara untuk mendidik desainer yang luar biasa ” [1 , hal. 185-186]
Dari posisi dasar Brooks (mendesain adalah kreativitas , dan proses kreatif tidak dapat dilakukan oleh orang banyak), seluruh konten nyata dari "Mythical Man-Month" secara langsung mengikuti: persyaratan "kediktatoran arsitek", dan "efek dari proyek kedua", dan rekomendasi "rencana untuk membuang versi pertama" . Tetapi ini juga mengikuti tesis Brooks yang paling terlupakan - bahwa dalam manajemen proyek "tidak ada peluru perak ! " Kompleksitas proyek adalah objektif, tidak dapat diatasi baik dengan bantuan bahasa pemrograman baru (bahkan yang grafis), atau dengan menghubungkan kecerdasan buatan. Penting untuk mengatasi kompleksitas setiap kali baru, dan jika bakat desainer tidak cukup untuk ini, proyek tidak akan berhasil.
Musuh utama proyek Brooks adalah kompleksitas produk yang sedang dibuat . Dengan setiap baris kode baru, dengan setiap halaman dokumentasi teknologi, kompleksitas ini tumbuh, dan tumbuh secara nonlinier. Dan pada saat yang sama, manajer memiliki sumber daya yang lebih sedikit - baik waktu yang tersisa sampai akhir proyek dan uang tersisa sampai akhir anggaran:
Pada titik persimpangan, atau sesaat sebelum itu, menjadi jelas bahwa proyek sebenarnya membutuhkan lebih banyak uang dan waktu daripada yang dimaksudkan:
Proyek berikutnya, yang disebut "Sentinel," FBI segera dimulai, pada tahun 2005. Harga masalah ini adalah $ 451 juta, dan sistem Sentinel akan beroperasi penuh pada tahun 2009 ... Pada bulan Maret 2010, Lockheed Martin, kontraktor, terlambat untuk tahun ini dengan menyelesaikan hanya setengah dari proyek dan menghabiskan 405 juta. Untuk menyelesaikannya, menurut para ahli independen, dibutuhkan enam hingga delapan tahun lagi, dan tambahan $ 350 juta. [3, p.17-18].
Tapi biarkan aku! Jika, sejak 1975, kita tahu bahwa kompleksitas proyek tumbuh, misalnya, secara kuadrat, - apa yang mencegah anggaran dan tim meningkat secara kuadratik ? Mengapa semua generasi manajer baru terus memimpin proyek dengan keberhasilan yang diperkirakan sebesar 30%, ketika Anda hanya dapat menambah uang ?
Sekarang, saatnya untuk beralih ke buku berikutnya.
Masalah kedua: kompleksitas kolaborasi
Seperti yang telah kita ketahui, buku terlaris di dunia yang terkenal, Peopleware ("kepegawaian" diterjemahkan ke dalam bahasa Rusia sebagai "Faktor Manusia"), yang muncul dua belas tahun setelah Mythical Man-Month, dimulai dengan pernyataan tingginya tingkat kematian proyek. "Sekitar lima belas persen dari proyek berakhir dengan tidak ada ... Dalam kasus proyek besar, gambarannya bahkan lebih buruk, keruntuhan itu mencapai dua puluh lima persen dari proyek, durasinya berkisar dari dua puluh lima orang-tahun" [2, p.24] Ini ditulis pada tahun 1987 (USSR masih hidup !), dengan merujuk pada penelitian tahun 1981 (Brezhnev masih hidup); dan apa yang kita miliki hari ini?
Menurut Laporan CHAOS 2015 [5]
Rata-rata pengembang saat ini biaya $ 100K per tahun, menambahkan overhead, kami mendapatkan bahwa 25 orang-tahun adalah sekitar 3-6 juta dolar. Seperti yang Anda lihat, situasinya tidak berubah sejak tahun-tahun yang panjang itu: 26% dari proyek berukuran sedang dan 43% dari proyek besar mengharapkan kegagalan, dan tidak ada yang bisa kita lakukan untuk itu. Tetapi mengapa ini terjadi? Demarco dan Lister bertanya kepada pengembang tentang alasan kegagalan tersebut, dan inilah jawaban mereka:
“Dalam sebagian besar kasus, tidak ada alasan tunggal untuk kegagalan dari bidang teknologi. Paling sering, para peserta dalam jajak pendapat kami menyebut "politik" sebagai penyebab kecelakaan itu
Sama sekali tidak kompleksitas produk yang dikembangkan, dan bukan kekurangan sumber daya, seperti yang mungkin diharapkan ketika melihat Brooks Cross! "Politik", hubungan antara orang-orang di dalam dan di luar tim (apa yang Demarco dan Lister lebih suka menyebutnya "sosiologi") - inilah yang, menurut para pengembang, mencegah kesuksesan.
Pikirkan fakta ini: orang-orang yang sama (pengembang, bos dan pelanggan) yang pada pandangan pertama paling tertarik pada kesuksesan, bersatu demi proyek, mengatur "politik" di dalamnya, yang membuat proyek runtuh! “Kami bertemu musuh, dan dia adalah kita” [6]; proyek ini mengungkapkan musuh terburuk kedua - timnya sendiri.
Secara intuitif jelas bahwa semakin banyak orang terlibat dalam suatu proyek, semakin banyak waktu yang harus mereka habiskan untuk mengorganisir kerja bersama, dan semakin sedikit - pada pengembangan produk yang sebenarnya. Pertanyaannya adalah seberapa jauh lebih sedikit:
Fig. 2 dari artikel Putnam, Myers [7]
Setelah mengumpulkan karakteristik numerik dari 491 proyek pengembangan perangkat lunak dari 35 hingga 95 ribu baris kode, Putnam dan Myers memberikan hasil yang hampir tidak mungkin dipercaya. Proyek-proyek dengan ukuran yang sebanding diselesaikan oleh tim-tim dengan jumlah yang berbeda hampir pada waktu yang bersamaan, dan tim-tim dengan jumlah yang lebih besar membutuhkan tidak sedikit, tetapi lebih banyak waktu. Hukum Brooks ("tambahkan pengembang - memperlambat proyek") ternyata bekerja tidak hanya dengan ancaman gangguan terhadap proyek, tetapi dari awal , dimulai dengan penambahan programmer kesembilan. Jika Anda menyajikan hasil yang sama dalam hal bulan-bulan yang terkenal kejam, Anda mendapatkan jadwal yang lebih ekspresif. Berapa banyak uang (dalam gaji bulanan) yang diperlukan untuk menyelesaikan masalah yang sama oleh tim-tim dari nomor yang berbeda:
Fig. 3 dari artikel Putnam, Myers [7]
Data yang diperoleh kira-kira cocok dengan pola yang benar-benar fantastis: produktivitas pengembang dalam tim berbanding terbalik dengan ukurannya. Dalam hal ini, periode pengembangan akan sama untuk tim mana pun, yang kira-kira seperti yang ditunjukkan oleh data Putnem dan Myers. Percaya atau tidak, urusan pribadi semua orang; tetapi bahkan jika Anda tidak percaya, Anda harus mengakui bahwa waktu yang dihabiskan untuk politik tumbuh secara non-linear dengan ukuran tim - dan oleh karena itu, jauh lebih sedikit waktu yang tersisa untuk benar-benar bekerja dalam tim besar.
Buku karya Demarco dan Lister berisi banyak contoh "sosiologi", yang menggantikan pekerjaan pada proyek dengan pekerjaan mempertahankan "ketertiban" dalam tim. Kantor ruang terbuka, di mana bos dapat melihat siapa yang berayun dari pekerjaan (dan karyawan terus-menerus mengganggu satu sama lain); perencanaan terperinci dan persyaratan konstan untuk memenuhi tenggat waktu (cepat dan mengarah pada peningkatan jumlah kesalahan); peraturan kecil (yang membuat Anda menghabiskan banyak waktu untuk melaporkan pekerjaan yang dilakukan dan mengubah motivasi karyawan dari kode menjadi "selembar kertas"). Semua langkah ini tampaknya perlu untuk organisasi kerja bersama - tetapi, ketika diterapkan sepenuhnya, mereka tidak lagi menyisakan waktu untuk pekerjaan itu sendiri.
Sekarang kita dapat memahami mengapa metode “cukup tambahkan uang” tidak berfungsi. Peningkatan ukuran proyek dengan organisasi kerja modern (ruang terbuka, tenggat waktu yang ketat, pelaporan terperinci) tidak mengarah pada peningkatan produktivitas yang signifikan. Sebaliknya, semakin besar tim proyek, semakin tinggi risiko bahwa itu akan sepenuhnya berkubang dalam pekerjaan kertas dengan menyetujui siapa yang melakukan apa dan di pihak siapa masalahnya. Palang Demarco mengakhiri upaya untuk meningkatkan efektivitas proyek dengan cara "luas".
Tetapi bagaimana jika kita mengubah prinsip-prinsip mengatur kegiatan bersama? Demarco dan Lister merekomendasikan hal ini kembali pada tahun 1987: Agar dapat secara efektif mengelola orang di bidang pekerjaan intelektual, perlu untuk mengambil langkah-langkah yang berlawanan dengan yang tercantum di atas. [mis. regulasi, standardisasi, bekerja di bawah tekanan pemecatan dan larangan inisiatif]. Diasumsikan bahwa dalam Peopleware ditulis dengan sangat jelas seperti apa ukuran “berlawanan” seharusnya [pada kenyataannya, tidak]. Mari kita lihat kembali grafik keberhasilan proyek. Dan di mana hasil dari buku yang masih termasuk dalam harus dibaca dari manajer mana pun? Sesuatu yang tidak terlihat.
Jadi mengapa? Apakah benar-benar ada jalan lain menuju manajemen proyek yang efektif?
Masalah ketiga: kesulitan merencanakan yang baru
Pada pandangan pertama, hambatan ketiga untuk menyempurnakan manajemen proyek adalah sifat yang tidak biasa dari cara yang benar untuk memandu proses kreatif. Salah satu metode tersebut, sekarang dikenal sebagai Scrum, dijelaskan dalam sebuah artikel [8] pada tahun 1986, bahkan sebelum rilis Peopleware. Dalam beberapa tahun, pada tahun 1993, Jeff Sutherland pertama kali menggunakan elemen individu Scrum dalam proyeknya, dan senang dengan hasilnya:
Kami mengirimkan produk perangkat lunak ke Easel tepat waktu, dalam waktu enam bulan, tanpa melebihi anggaran dan dengan jumlah kesalahan minimum - tidak ada yang bisa melakukan ini sebelumnya.
Namun, deskripsi rinci tentang ide-ide utama Scrum diterbitkan hanya dua puluh tahun kemudian , hanya beberapa hari, pada tahun 2014 [3]. Selama ini, Scrum ada sebagai metodologi semi-sektarian, ditransmisikan secara harfiah dari guru ke siswa, dan mendapatkan popularitas secara eksklusif melalui mulut ke mulut. Masalahnya adalah bahwa konsep utama Scrum, yang secara langsung mengikuti dari filosofinya, tidak cocok dengan logika kontrol yang masuk akal:
Inilah yang saya ulangi terus-menerus pada kepemimpinan: “Saya hanya bisa menyebutkan tenggat waktu ketika saya melihat seberapa efektif tim akan bertindak” [3, hlm. 28).
Jika yang kami maksud dengan “manajemen proyek” memastikan penciptaan produk dengan properti yang ditentukan tepat waktu sesuai anggaran, ternyata Scrum sama sekali bukan “manajemen”! Pusat filsafat Scrum adalah penolakan kategoris untuk datang dengan "batas waktu yang ditentukan" dari langit-langit (dalam isolasi dari tim nyata dan kinerjanya), dan konsekuensi pertama dari penolakan semacam itu adalah pendekatan yang sama sekali tidak konvensional dalam perencanaan proyek:
Saya pergi ke kepala perusahaan dan menyatakan bahwa kami meninggalkan grafik Gantt. Marah dengan apa yang didengarnya, dia menuntut penjelasan.
- Berapa banyak grafik Gantt yang Anda temui untuk karier profesional Anda? Saya bertanya.
"Dengan ratusan," katanya.
- Berapa banyak dari mereka yang benar?
"Tidak ada," jawabnya, berpikir sejenak.
Lalu saya menjelaskan bahwa alih-alih grafik dan tabel yang tidak perlu, pada akhir bulan kami akan memberinya bagian dari sistem yang berfungsi penuh, yang dia sendiri akan dapat menguji dan melihat sendiri apakah pengembangan berada di arah yang benar " [3, p.50]
Dalam sebuah kisah yang diceritakan oleh Sutherland, bos setuju untuk mencoba. Tapi kita tahu apa "kesalahan para penyintas" itu, dan kami sangat sadar bahwa ada sepuluh bos yang akan mengirim "manajer proyek" seperti itu. Omong kosong macam apa, membayar uang dengan jujur, bahwa "kami akan bekerja dan akan menunjukkan sesuatu dalam sebulan"? Idiot apa yang melakukan itu?
Dari buku Sutherland, kita tahu dengan tepat yang mana: orang yang sudah mencoba membuat proyek dengan cara klasik , dan telah mengalami kegagalan besar. Hanya seorang pemimpin yang didorong ke sudut, yang tidak kehilangan apa-apa, berani meninggalkan prinsip dasar "sumber daya - manajemen hanya di bawah rencana penggunaannya." Tentu saja, setelah dua puluh tahun menggunakan Scrum, sikap terhadapnya telah agak berubah, tetapi bahkan hari ini sebagian besar percakapan "Saya akan menyebutkan istilah dan jumlah ketika saya mengumpulkan tim dan mulai bekerja" menanggung risiko ini.
Ideologi Scrum sangat bertentangan dengan ide yang diterima secara umum tentang proyek ("Pelanggan setuju untuk membayar, dan Kontraktor melakukan pekerjaan berikut ...") sehingga tiba saatnya untuk mengajukan pertanyaan: mengapa Sutherland dipaksa untuk mengambil langkah revolusioner seperti itu? Benarkah mustahil untuk meninggalkan tangga lagu Gantt “hanya untuk tanda centang” dan fokus mengorganisir pekerjaan tim (misalnya, pada rapat harian, di mana banyak orang melihat hal terpenting di Scrum)?
Dilihat dari kegigihan serangan Sutherland dalam bukunya "Gantt Charts", orang tidak bisa:
Saat mengelola proyek, dua hal secara tradisional diperlukan - akuntabilitas dan prediktabilitas. Pendekatan semacam itu pasti akan mengarah pada munculnya sejumlah besar dokumentasi, tabel dan diagram ... Bulan kerja dihabiskan untuk menyediakan segala sesuatu dengan detail terkecil, mencegah satu kegagalan fungsi, tidak membanjiri sumber daya keuangan dan bergerak maju sesuai jadwal. [3, hal.23] Satu- satunya masalah adalah bahwa segera setelah rencana yang diasah sempurna ini dihadapkan dengan kenyataan, ia segera hancur menjadi debu. Tetapi alih-alih melemparkan rencana itu sendiri dan pendekatannya ke tempat sampah, para manajer berpura-pura bahwa rencana itu berhasil ... Bahkan, mereka membayar orang karena berbohong kepada mereka . [3, p.20]
Mereka membayar untuk berbohong kepada mereka - itu masalahnya! ( « ») , . , , (« !»). :
, , , , [3, .23]
: ( ) ( ), . «», , :
( , ), , « », . : «, , , ».
— ! [9]
, « » . , , . « - » , . (« ») . , - .
? ? — . () — . — .
. , «» . , ( «»). , . , — , . , .
- [1] . « - », , -, 2007
- [2] Demarco T., Lister T. "Faktor Manusia: Proyek dan Tim yang Sukses", St. Petersburg, Symbol-Plus, 2005
- [3] Sutherland, Jeff. "Scrum. Metode revolusioner manajemen proyek ”, M., Mann, Ivanov dan Ferber, 2016
- [4] de.wikipedia.org/wiki/Chaos-Studie
- [5] LAPORAN CHAOS 2015
- [6] Kami telah bertemu musuh
- [7] Putnam, Myers "Manajemen Metrik Akrab - Kecil itu Indah-Sekali Lagi", 1998
- [8] Takeuchi, Nonaka "Pengembangan Produk Baru: Aturan Game Baru" (1986), terjemahan Rusia
- [9] Makovetsky P.V. "Lihatlah akarnya!", M., 1966