Flazzo memiliki fokus utama untuk menambah nilai bisnis Anda.

Blog

Dua Wajah Perencanaan Perangkat Lunak

soroush-karimi-ZcczBXrkXgA-unsplash.jpg
Blog

Dua Wajah Perencanaan Perangkat Lunak


Jika Anda bekerja dengan orang lain untuk membuat perangkat lunak, Anda akan terbiasa dengan istilah tersebut perencanaan. Anda pernah mendengar istilah yang digunakan dalam frasa seperti “minggu depan adalah minggu perencanaan”, “kita harus lebih baik dalam merencanakan kuartal berikutnya”. Heck, Anda bahkan mungkin telah berpartisipasi dalam ritual ini. Tetapi jika Anda seperti saya, setiap kali Anda keluar dari perencanaan, selalu ada suara di kepala Anda yang berkata, apakah kita sudah cukup?

Setelah banyak pengulangan perencanaan pada skala waktu yang berbeda, dari harian hingga tahunan, saya akhirnya memahami sumber keraguan saya yang masih ada.

Sebagai orang yang bertanggung jawab atas hasil perencanaan tim, saya menyadari bahwa saya selalu harus melayani dua audiens yang berbeda: pemangku kepentingandan tim dari pembangun. Mereka memiliki tujuan yang berbeda dalam hal perencanaan, tetapi tanpa menyatakannya secara eksplisit, karena saya secara tidak sadar terombang-ambing antara memuaskan a Atau yang lainnya adalah di mana keraguan akan ketidakcukupan merayap masuk.

Agar efektif dalam memuaskan kedua audiens, kita perlu membenamkan diri dalam apa yang mereka inginkan.

Stakeholder

Stakeholder tipikal dalam tim pembuat perangkat lunak termasuk manajer tingkat atas, tim lain, manajer mereka, dan mungkin eksekutif. Jika mereka adalah bagian dari perencanaan tim, kemungkinan mereka ada di sana untuk menemukan, dan mungkin bernegosiasi, apa yang akan dilakukan kapan.

Bagi manajer senior dan eksekutif, hal ini penting karena, sebagai pengalokasi sumber daya utama, mereka perlu mengawasi pengembalian investasi, dalam bentuk orang dan waktu. Misalnya, mengetahui berapa minggu rekayasa yang diperlukan untuk bergabung dengan penyedia layanan eksternal dapat menjadi faktor yang sangat penting dalam memutuskan apakah akan melakukan pembelian.

Untuk tim lain, berpartisipasi dalam perencanaan penting untuk mengoordinasikan proyek yang bergantung pada mereka, serta untuk mengevaluasi pelaksanaan proyek mereka sendiri. Ini bisa berupa tim yang berhubungan dengan pelanggan yang tertarik dengan tanggal rilis alat internal versi berikutnya, atau tim saudara yang akan memulai migrasi serupa dan tertarik dengan upaya untuk menyediakan.

Pada akhirnya, tujuan pemangku kepentingan dari perencanaan adalah untuk mengumpulkan informasi sehingga mereka dapat melakukannya membuat keputusan masa depan. Oleh karena itu, perspektif yang kami sajikan kepada pemangku kepentingan selama perencanaan harus fokus hasil yang diharapkanapa yang akan dilakukan, dalam urutan apa, oleh siapa, kapan, dengan nilai apa dan dengan resiko apa.

Pembangun

Di sisi lain, bagi orang-orang yang benar-benar membangun perangkat lunak, mereka kebanyakan datang ke perencanaan hanya untuk mendapatkan pekerjaan berikutnya.

Permainan untuk mereka sederhana. Semakin detail dan pasti, semakin dapat diprediksi dan mulus pelaksanaannya. Dalam kasus yang paling ekstrim, jika setiap elemen persyaratan dan spesifikasi disajikan, dengan semua kasus ekstrim diperhitungkan dan jaminan bahwa tidak ada yang akan diubah, sebagian besar tim teknik dapat memberikan persis apa yang diminta dengan sangat presisi. Di sisi lain, jika ada banyak ambiguitas tentang bagaimana suatu sistem harus berperilaku, terutama dalam situasi yang tidak terduga, ruang untuk desain dan eksekusi yang buruk menjadi semakin besar, sedemikian rupa sehingga seluruh sistem mungkin harus didesain ulang dan dibangun kembali dari awal. bawah ke atas.

Oleh karena itu, insinyur yang berpengalaman akan mencari ambiguitas saat merencanakan dan akan mencoba mengklarifikasi sebanyak mungkin titik pertentangan untuk menghindari jalan yang salah.

Oleh karena itu, visi yang kami sajikan kepada pembangun harus fokus cakupan (yaitu perilaku konkret apa yang harus ditunjukkan oleh sistem, idealnya dengan prioritas kepentingan) dan desain (yaitu komponen atau struktur teknis apa yang perlu ada untuk mengaktifkan perilaku tersebut), sehingga mereka dapat dipercaya untuk menyelesaikan pekerjaan mereka.

Datang bersama

Singkatnya, pemangku kepentingan menginginkan hasil yang dapat diprediksi, sementara pembangun menginginkan detail yang cukup untuk memulai pekerjaan mereka. Tapi…bagaimana tim bisa berkomitmen pada hasil tanpa detail yang cukup, dan bagaimana bisa ada dampak nyata jika keputusan penting tentang proyek belum diselesaikan?

Itu benar. Ini tidak mungkin.

Itu tidak mungkin karena saya mungkin telah menipu Anda untuk berpikir bahwa perencanaan adalah pertemuan sehari penuh, atau paling banyak beberapa hari, tanpa henti di mana semua keputusan dibuat dengan cepat dan semua rencana diselesaikan dengan mudah selama seperempat atau bahkan satu tahun.

Namun pada kenyataannya, rencana yang dipikirkan dengan matang Ke menjadi proses berulang. Tim produk membutuhkan waktu bersama pelanggan untuk mengembangkan dan memvalidasi ide. Produk dan teknik membutuhkan waktu bersama untuk mencapai kompromi antara fungsionalitas dan kelayakan. Tim teknis harus mengevaluasi opsi desain dan trade-off. Analis perlu menarik angka untuk menilai dampak dan risiko. Manajer harus bernegosiasi di antara mereka sendiri tentang personel. Kepala departemen perlu menyelaraskan dengan prioritas yang lebih luas.

Semua percakapan ini membutuhkan waktu dan bolak-balik untuk sampai pada suatu kesimpulan. Di sinilah nyata perencanaan tiba.

Jika Anda telah meluangkan waktu untuk melakukan percakapan ini, saya harap Anda tidak akan merasa tidak mampu saat semester baru dimulai.

Buat survei pengguna Anda sendiri