Manajemen Proyek, Kategori 30+

Hentikan, hentikan, bersihkan segera! Untuk menutup proyek yang gagal, Anda perlu dua hal: Anda perlu memahami bahwa proyek itu gagal, dan Anda harus menutupnya. Tapi tidak sesederhana itu.



Artikel ini didasarkan pada laporan oleh Maria Belkina dari SEMrush, dari OKR-mitap di St. Petersburg : "Pengalaman Beralih dari OKR ke Spotify Rhythm". Meskipun judul laporan menunjukkan demonstrasi kekurangan OKR, keunggulan Rhythm dan cara untuk mengganti satu sama lain, topik utamanya adalah pertanyaan: "Apa yang harus dilakukan dengan proyek yang gagal?". Ini adalah topik akut dan menyakitkan yang menarik untuk dipahami.

Budaya startup berkomitmen untuk sukses. Jika Anda dapat mencapai tujuan, Anda harus melanjutkan dalam semangat yang sama. Tetapi tidak semua proyek berhasil, dalam banyak kasus hanya hasil biasa-biasa saja yang dapat dicapai, atau lebih buruk. Apa yang terjadi pada proyek semacam itu? - Mereka melanjutkan. Untuk semua orang: baik untuk manajemen dan untuk pemain, jauh lebih mudah untuk terus berinvestasi dalam proyek yang gagal daripada mengakui kegagalannya. Meningkatnya masalah dapat menyebabkan konflik dalam tim, sehingga dapat merusak hubungan dengan rekan kerja. Tidak ada yang membutuhkan ini. Tetapi jika Anda tidak melakukan apa-apa, pengembangan akan terperosok dalam proyek yang tidak menjanjikan, dan produk tersebut akan berubah menjadi hash yang tidak didukung oleh fitur yang tidak berguna. Ini juga tidak baik.

Uang selalu penting, tetapi orang adalah sumber utama pengembangan. Untuk satu bulan kerja, sekelompok seratus orang akan membakar jumlah uang yang sama, terlepas dari hasilnya. Tentu saja, mengatur hasil terbaik adalah hal utama dalam manajemen pengembangan. Tetapi ketika sebuah ide baru muncul, "ini adalah apa yang perlu kita lakukan!", Sering kali ternyata tidak ada orang yang menanganinya. Semua pengembang sibuk dengan tugas saat ini, dan bukan yang paling penting, tetapi Anda tidak dapat meninggalkannya. Ini adalah khas dari produk dewasa.

Semakin tua produk perangkat lunak, semakin besar proporsi sumber daya yang dihabiskan untuk dukungannya, dan semakin lambat pengembangan baru. Bahkan jika fitur tersebut digunakan oleh dua ratus pengguna dari seratus ribu, bug di dalamnya tetap harus diperbaiki. Pengenalan teknologi baru akan membutuhkan memperbaiki semua kode, terlepas dari apakah metode ini disebut setiap milidetik atau sebulan sekali. Proyek yang dimulai lebih baik untuk diselesaikan daripada meninggalkan yang belum selesai. Setiap perubahan global akan membutuhkan pengujian penuh dan sebagainya. Semua ini agak serius dan membuat Anda berpikir kritis tentang prospek.

Tidak semua proyek akan berhasil, ini adalah kenyataan. Anda dapat hidup dengan ini, tetapi pada titik tertentu, manajemen harus memiliki pemahaman bahwa Anda tidak bisa terus menyebarkan mainan di lantai. Secara berkala, mereka perlu dikumpulkan kembali ke dalam kotak, jika tidak akan berantakan. Ya, merapikan itu membosankan. Ya, itu butuh waktu. Ya, seseorang mungkin kesal karena mainan kesukaannya dimasukkan kembali ke dalam kotak. Tapi kami orang dewasa.

Apa artinya menutup proyek yang gagal? Bukan hanya menghapuskan sepuluh tahun kerja orang yang hilang. Semua fungsionalitas yang dikembangkan juga perlu dihapus dari produk, dan ini adalah pekerjaan tambahan dan biaya tambahan. Akan ada juga pengguna yang tidak puas yang karena suatu alasan menyukai fungsi proyek. Jangan lupa tentang peluang yang terlewat. Waktu dan upaya yang dihabiskan untuk menutup proyek, tampaknya, dapat digunakan dengan manfaat yang lebih besar. Tutup proyek - mahal. Untuk mengambil langkah seperti itu, Anda membutuhkan kemauan, tekad, dan pemahaman bahwa kesehatan produk jangka panjang lebih penting daripada penghematan taktis. Tetapi bahkan jika ada kemauan untuk menerapkan langkah-langkah drastis seperti itu, pemicunya masih diperlukan, cara diperlukan untuk memahami bahwa proyek telah gagal.

Kriteria kegagalan proyek. Biasanya, sudah lazim untuk menentukan kriteria keberhasilan. Tampaknya jika kriteria kesuksesan ditentukan dan proyek tidak mencapainya, maka gagal. Benar-benar tidak. Antara keberhasilan dan kegagalan terletak area abu-abu yang besar. Tidak mencapai nilai-nilai indikator yang menentukan keberhasilan, selalu ada perasaan bahwa "kita belum cukup melakukan," "hanya sedikit lebih dan kemudian semuanya akan berhasil." Mungkin memang begitu. Tetapi mengevaluasi proyek sesuai dengan kriteria keberhasilan hanya menimbulkan pertanyaan "terus atau tidak?", Dan pertanyaan seperti itu tidak menyiratkan jawaban "tutup dan hancurkan!".

Kriteria untuk kegagalan proyek adalah bahwa batas bawah indikator, jatuh di bawah proyek yang harus dihancurkan. Seperti kapal yang berlubang di bawah permukaan air, kapal itu harus turun. Dengan segala kemungkinan kebanggaan, kemegahan, dan profesionalisme.

Sama seperti kesuksesan seharusnya tidak mengarah pada kecemburuan, kegagalan seharusnya tidak menghasut kebencian dalam sebuah tim. Dalam jangka panjang, semua ini adalah rutinitas dari proses kerja. Agar kegagalan proyek tidak mengarah pada konflik, kriteria kegagalan harus ditentukan dan disepakati terlebih dahulu, serta kriteria keberhasilan. Juga, rencana pemutusan proyek perlu dipersiapkan sebelumnya, bahkan lebih awal dari rencana proyek itu sendiri. Kemudian, setelah menentukan bahwa proyek telah gagal, tidak akan ada keraguan apa yang harus dilakukan dalam situasi ini. Anda dapat segera melanjutkan ke tindakan tegas. Semua dengan cara dewasa.

Adalah masuk akal untuk berargumen bahwa otak kita diatur sedemikian rupa sehingga, memikirkan kegagalan sebelumnya, kita mengatur diri kita sendiri untuk gagal. Mungkin. Tetapi kemampuan untuk memikirkan konsekuensinya adalah tanda pemikiran yang matang. Dan kesulitan yang terkait dengan ini, sepertinya, dapat diatasi.

---

Dmitry Mamonov,
Wrike

PS Sebagai kelanjutan dari topik tentang bagaimana, mengapa dan kapan untuk menghapus fitur dari produk, saya dapat merekomendasikan laporan dari rekan saya, Yuri Andreikovich.