4 Pertanyaan yang Harus Diajukan Saat Developer Mengatakan "No"

• Saat developer mengatakan No, menanggapi hal itu dapat membantu Anda sebagai manajer produk menegaskan otoritas dan mencapai tujuan
• Ketika mereka mengatakan sebuah fitur tidak bisa diimplementasikan dalam waktu yang diberikan karena alasan teknis, Anda dapat membuka jalan keluar dengan mengajukan pertanyaan yang tepat

1. Apakah ada solusi teknis lain untuk membangun fitur ini?

• Ada banyak cara untuk membangun sebuah fitur, dan cara pertama yang dicoba tidak selalu yang paling optimal
• Developer ingin membangun fitur yang keren dengan menggunakan teknologi terbaru, tetapi hal ini bisa berujung pada overengineering alih-alih optimalisasi untuk kesederhanaan
• Developer dengan set keterampilan tertentu mungkin tidak menyadari adanya solusi yang lebih sederhana di luar cakupan pengetahuan mereka
• Karena itu, ada baiknya mendorong engineer untuk berpikir lebih kreatif tentang solusi teknis
• Beberapa manajer produk terbaik yang pernah bekerja dengan saya memiliki wawasan dan pengetahuan teknis yang cukup tentang lanskap teknologi sehingga mereka bisa mengajukan pertanyaan tajam yang membantu engineer berpikir di luar kebiasaan

2. Jika Anda harus mengusulkan solusi dengan kendala seperti ini, apa yang akan Anda lakukan?

• Jika developer mengajukan keberatan terhadap solusi yang Anda usulkan, mintalah mereka menawarkan solusi versi mereka
• Developer adalah sumber kreativitas dan inovasi, dan dengan menanyakan apakah ada versi fitur yang lebih sederhana, Anda memberi mereka kesempatan untuk berpikir kreatif
• Ketika mereka memahami inti masalahnya, developer akan berpikir kreatif dan menemukan solusi yang tetap bisa berjalan dalam batasan proyek

3. Bisakah kita mempertimbangkan pendekatan bertahap untuk fitur ini?

• Ketika mereka mengatakan implementasi fitur tidak memungkinkan karena kompleksitas teknis, tanyakan apakah proyek bisa dibagi menjadi beberapa tahap dan dijadwalkan ke tanggal rilis yang berbeda
• Memang menggoda untuk menghadirkan visi besar sekaligus, tetapi pendekatan bertahap lebih iteratif dan memberikan hasil nyata lebih cepat
• Prioritas bisa berubah, dan pendekatan bertahap memungkinkan Anda menyesuaikan fitur apa yang perlu ditambahkan berikutnya bersama developer

4. Hambatan apa yang bisa kami hilangkan atau selesaikan agar pekerjaan ini memungkinkan?

• Ini adalah pertanyaan untuk keberatan yang berbasis sumber daya; ketika developer menyebut sumber daya yang terbatas (misalnya waktu atau jumlah developer yang tersedia), singkirkan pekerjaan lain secara proaktif untuk membebaskan waktu mereka
• Cara yang mungkin dilakukan: menghapus pekerjaan sepenuhnya, mengerjakan sendiri tugas yang tidak membutuhkan developer, mengambil alih komunikasi dengan tim lain dan/atau pihak ketiga, atau mempermudah pekerjaan dengan memiliki prosesnya dan menghentikan fitur lama

Kesimpulan

• Mungkin terasa tidak nyaman untuk "mendorong" balik saat developer mengatakan "tidak bisa", tetapi hal itu justru bisa membuat Anda lebih dihormati
• Anda perlu menggali sedikit lebih dalam untuk memahami mengapa engineer menolak, lalu menghapus keberatan tersebut satu per satu
• Semua pertanyaan ini bagus karena mengakui kesulitan dan batasan unik yang dapat dihadapi engineer saat mengimplementasikan fitur tertentu
• Ini juga menunjukkan dengan jelas bahwa Anda bersedia ikut turun tangan untuk membantu tim dan proyek, termasuk mengerjakan hal-hal yang tidak menyenangkan atau menyesuaikan diri dengan kebutuhan dan jadwal

[sirotan]

Pada akhirnya semuanya bergantung pada bagaimana menyesuaikannya
Terima kasih, isinya bagus
Kalau ditanya dengan poin-poin di atas, orang yang sebenarnya cuma tidak mau mengerjakannya lalu bilang "No" sepertinya bakal cepat ketahuan

[ddaemiri]

Sebagai PM/PO, ada 2 metodologi yang membantu saya saat berperan mengoordinasikan antara divisi bisnis dan divisi IT dalam sebuah proyek.
Tentu saja, prasyaratnya adalah baik divisi bisnis maupun divisi IT sama-sama bisa saling memahami.
Yang pertama, lakukan secara bertahap.
Yang kedua, perkecil cakupannya.
Itu dua hal tersebut.
Kesulitan terbesar dalam menjalankan proyek, baik di divisi bisnis maupun divisi IT, adalah soal 'waktu'.
Jadwalnya sudah ditentukan, tetapi sering kali volumenya terlihat tidak akan selesai dalam waktu tersebut.
Dalam situasi seperti ini, kerjakan secara 'bertahap'. Dengan jadwal berurutan seperti phase 1, 2, 3.. misalnya. Fitur yang paling penting dimasukkan ke phase 1, yang kurang penting ke phase 2.. seperti itu.
Tetapi untuk proyek yang tidak bisa dibuat bertahap seperti ini, yaitu yang harus dibuka sekaligus dalam satu kali rilis,
cakupannya harus dikurangi agar sesuai dengan 'waktu'. Dari hal-hal yang tadinya akan masuk ke phase 1, 2, 3, selain 'fitur yang benar-benar diperlukan' harus dibuang.
Dengan dua metodologi ini, sebagian besar divisi bisnis/divisi IT yang 'bisa diajak memahami' biasanya setuju.
Daripada proyeknya gagal total lalu masing-masing dimarahi atasannya, ini jauh lebih baik..
Hmm.
Semangat semuanya^^

PS:
Ada satu bumbu terakhir.
Bahkan kalau memakai dua cara di atas, sering kali para developer tetap menunjukkan keberatan.
Kalau begitu,
"Mari kita cek sekali di pertengahan periode proyek. Kalau sepertinya butuh waktu tambahan, saya yang akan bertanggung jawab untuk memperpanjang jadwalnya"
kalau dikatakan begitu, sering kali ekspresi para developer langsung lebih tenang.
Dan ketika benar-benar dicek di pertengahan, 95% kasusnya ternyata tidak perlu tambahan waktu.
Selain itu, begitu developer mulai ngoding, sering kali mereka menyelesaikannya dengan cepat.

[exit55]

Sebagai orang yang berperan untuk berkoordinasi dengan developer, saya ingin bekerja dengan developer yang bisa diajak berdiskusi seperti ini. Selama ini saya hanya bertemu developer yang langsung bilang tidak bisa, jadi rasanya sedih. Soalnya, setelah dibujuk dan ditanya macam-macam, kebanyakan ternyata memang ada cara yang mereka sendiri belum tahu..

[abhidhamma]

Wkwkwkwkwk, sakit di hati ya..

[bbulbum]

Pertanyaan yang perlu diajukan insinyur kepada diri sendiri sebelum mengatakan "TIDAK".

[neidn]

Menurut saya, ini juga tampak seperti pertanyaan-pertanyaan yang sangat bagus untuk diajukan kepada diri sendiri.

[evenn33111]

Bagaimanapun, sebelum menjadi engineer, mereka tetap manusia. Saya setuju bahwa kebiasaan refleks mengatakan No sebagai engineer memang bermasalah, tetapi kalau pihak PM/PO membawa pertanyaan-pertanyaan seperti itu, rasanya itu akan sangat membantu.