Perselisihan antara manajer produk dan teknisi adalah salah satu masalah yang paling mudah diprediksi dalam tim perangkat lunak, dan salah satu masalah yang paling sering salah ditangani.
PM merasa seperti para insinyur menolak segala sesuatunya tanpa menawarkan alternatif. Insinyur merasa seperti PM yang berkomitmen pada tenggat waktu dan ruang lingkup tanpa memahami kompleksitas teknis. Kedua belah pihak biasanya benar mengenai titik buta pihak lain, dan keduanya biasanya salah mengenai niat pihak lain.
Retrospektif sprint standar jarang menyelesaikan masalah ini karena cenderung tetap berada dalam batas-batas tim. Insinyur retro dengan insinyur. Diskusi PM dengan PM. Ketegangan lintas fungsi hanya terakumulasi hingga meletus dalam rapat perencanaan atau tenggat waktu yang terlewat.
Retrospektif rekayasa produk khusus menempatkan kedua perspektif dalam satu ruangan dengan struktur yang menjadikan percakapan produktif, bukan agresif.
Empat Titik Gesekan Berulang
Sebelum merancang retrospektif, ada baiknya menyebutkan ketegangan dengan jujur. Di sebagian besar tim, mereka dikelompokkan ke dalam empat kategori.
1. Persyaratan yang Tampak Jelas tetapi Tidak
Seorang PM menulis spesifikasi yang mereka anggap menyeluruh. Seorang insinyur membacanya dan mempunyai lima belas pertanyaan. PM merasa seperti insinyurnya yang rewel. Insinyur tersebut merasa PM belum memikirkan kasus-kasus yang rumit.
Akar masalahnya jarang sekali adalah kemalasan di kedua sisi. PM dan teknisi mempunyai pemikiran yang berbeda tentang produk. PM memikirkan perjalanan pengguna dan hasil bisnis. Insinyur berpikir dalam aliran data, manajemen keadaan, dan mode kegagalan. Spesifikasi yang lengkap dari satu perspektif penuh dengan kesenjangan dari perspektif lainnya.
2. Kecepatan vs. Kualitas
PM bertanggung jawab atas pengiriman tepat waktu. Insinyur bertanggung jawab ketika terjadi kerusakan dalam produksi. Insentif ini mempunyai arah yang berlawanan, dan tidak ada yang salah.
Konflik ini muncul sebagai perdebatan mengenai pemotongan cakupan, cakupan pengujian, ketelitian peninjauan kode, dan apakah akan mengambil jalan pintas teknis. Tanpa perbincangan eksplisit mengenai trade-off ini, masing-masing pihak berasumsi pihak lain tidak peduli terhadap hal yang penting.
3. Hutang Teknis
Para insinyur melihat utang tersebut semakin menumpuk dan membutuhkan waktu untuk mengatasinya. PM melihat tumpukan fitur yang dihadapi pengguna dan kesulitan untuk membenarkan pekerjaan yang tidak terlihat oleh pelanggan. Hasilnya: utang ditangguhkan hingga mulai menimbulkan insiden, yang pada akhirnya semua orang setuju bahwa utang tersebut seharusnya ditangani lebih awal.
4. Estimasi dan Prediktabilitas
PM perlu mengomunikasikan jadwal kepada pemangku kepentingan. Para insinyur menolak memberikan perkiraan karena mereka tahu seberapa besar ketidakpastian yang ada. PM mendengar "Saya tidak ingin berkomitmen" dan insinyur mendengar "beri tahu saja apa yang ingin saya dengar". Tidak ada interpretasi yang akurat.
Menyiapkan Retrospektif
Jalankan ini setiap triwulan atau setelah rilis besar. Menstruasi terlalu sering terjadi -- polanya memerlukan waktu untuk berkembang.
Yang hadir: Manajer produk, pemimpin teknologi, dan teknisi senior. Pertahankan grup menjadi 6-10 orang. Jika kelompoknya lebih besar, percakapan menjadi performatif.
Durasi: 90 menit. Retrospektif lintas fungsi membutuhkan waktu lebih lama dibandingkan retrospektif tim yang sama karena Anda memerlukan waktu untuk membangun pemahaman bersama, bukan hanya memunculkan masalah.
Fasilitasi: Gunakan fasilitator yang netral, idealnya seseorang yang bukan PM atau teknisi dalam tim. Seorang manajer teknik, master scrum, atau seseorang dari tim lain bekerja dengan baik. Tugas fasilitator adalah mencegah percakapan menjadi perdebatan dan memastikan kedua belah pihak merasa didengarkan.
Struktur yang Berfungsi
Bagian 1: Koleksi Perspektif Ganda (20 menit)
Mintalah PM dan teknisi secara mandiri menulis kartu untuk menjawab tiga pertanyaan yang sama:
- Apa yang berhasil dalam kolaborasi kita pada kuartal ini?
- Di manakah gesekan memperlambat kita?
- Apa yang Anda harap pihak lain dapat memahaminya dengan lebih baik?
Permintaan ketiga adalah yang penting. Hal ini memunculkan asumsi dan rasa frustrasi yang biasanya tidak terucapkan.
Kumpulkan semua kartu secara anonim. Hal ini penting -- orang menulis lebih jujur ketika nama mereka tidak dicantumkan, terutama tentang ketegangan lintas fungsi.
Bagian 2: Diskusi Tema (40 menit)
Kelompokkan kartu berdasarkan tema. Yang umum meliputi: kejelasan persyaratan, proses estimasi, keputusan penentuan prioritas, kesenjangan komunikasi, dan penanganan utang teknis.
Untuk setiap tema, hindari godaan untuk berdebat siapa yang benar. Sebaliknya, tanyakan:
- Apa yang masing-masing pihak optimalkan? (Biasanya kedua belah pihak memiliki tujuan yang sah dan berada dalam ketegangan.)
- Di manakah kegagalan handoff? (Sebagian besar gesekan terjadi pada batasan antar peran, bukan di dalam peran tersebut.)
- Informasi apa yang kurang dari masing-masing pihak? (Banyak konflik sebenarnya merupakan asimetri informasi yang terselubung.)
Bagian 3: Perjanjian Khusus (30 menit)
Jangan pergi dengan niat yang tidak jelas. Tinggalkan dengan perjanjian kerja khusus yang menjadi komitmen kedua belah pihak.
Perjanjian kerja yang baik adalah:
- Dapat Diamati -- Anda dapat mengetahui apakah hal tersebut sedang terjadi atau tidak.
- Bilateral -- Kedua belah pihak mengubah sesuatu, bukan hanya satu pihak yang menuntut pihak lain.
- Keterbatasan waktu -- Cobalah selama seperempat dan evaluasi.
Berikut adalah contoh perjanjian yang cenderung berhasil:
Untuk kejelasan persyaratan: "PM dan pimpinan teknologi akan menghabiskan waktu 30 menit bersama sebelum spesifikasi fitur apa pun dibagikan kepada tim yang lebih luas, khususnya untuk mengidentifikasi kasus-kasus sulit dan kendala teknis."
Untuk estimasi: "Insinyur akan memberikan perkiraan rentang (kasus terbaik / kemungkinan / kasus terburuk) dan bukan hanya perkiraan satu titik, dan PM akan mengomunikasikan rentang tersebut kepada pemangku kepentingan, bukan hanya kasus terbaik."
Untuk utang teknis: "20% dari kapasitas setiap sprint dicadangkan untuk pekerjaan yang diprioritaskan teknik. PM tidak mengalokasikan kapasitas ini dan teknisi tidak perlu memberi alasan pada masing-masing item, namun teknisi membagikan ringkasan triwulanan mengenai waktu yang dihabiskan."
Untuk diskusi cakupan: "Ketika cakupan perlu dikurangi, PM mengusulkan apa yang harus dikurangi dan insinyur mengusulkan cara menyederhanakannya. Kedua opsi tersebut dibahas sebelum mengambil keputusan."
Menangani Percakapan yang Sulit
Beberapa topik secara konsisten menggagalkan retrospektif lintas fungsi. Berikut cara mengatasinya.
"Kita tidak pernah punya waktu untuk utang teknis." Jangan memperdebatkan apakah utang teknis itu penting. Sebaliknya, tanyakan: berapa biaya utang saat ini? Jika para insinyur dapat menunjukkan insiden tertentu, perlambatan, atau masalah yang dialami pengembang yang disebabkan oleh utang, percakapan akan beralih dari abstrak ke konkrit. PM merespons data dampak, bukan permintaan abstrak terhadap kualitas kode.
"Persyaratan terus berubah." Persyaratan berubah karena perubahan pasar, masukan pengguna yang masuk, dan pemangku kepentingan mengubah prioritas. Pertanyaannya bukan apakah persyaratan akan berubah, namun bagaimana perubahan dikomunikasikan dan seberapa terlambat perubahan tersebut terjadi. Fokus pada proses: pada titik mana dalam pengembangan ruang lingkup harus dianggap dibekukan? Apa jalur eskalasi perubahan setelah titik tersebut?
"Teknik selalu meremehkan." Balikkan hal ini: apakah tim melacak keakuratan perkiraan dari waktu ke waktu? Jika tidak, mulailah. Setelah beberapa kali mengumpulkan data, percakapan beralih dari tuduhan ke pola. Mungkin tim secara konsisten meremehkan jenis pekerjaan tertentu (integrasi, migrasi) dan akurat dalam hal lainnya. Hal ini dapat ditindaklanjuti.
"PM tidak memahami betapa rumitnya hal ini." Seringkali hal ini benar, dan merupakan tugas teknisi untuk membuat kompleksitas terlihat. Jika seorang insinyur mengatakan "ini sulit" dan PM mendengar "ini sulit", tidak ada perubahan. Jika teknisi mengatakan "hal ini memerlukan perubahan pada tiga layanan, migrasi database, dan memiliki risiko waktu henti jika migrasi gagal", PM sebenarnya dapat mempertimbangkan trade-off tersebut.
Seperti Apa Kelihatannya Seiring Waktu
Setelah tiga atau empat retrospektif ini, Anda akan melihat perubahan nyata:
- Lebih sedikit kejutan dalam perencanaan sprint karena PM dan pemimpin teknologi sudah melakukan koordinasi lebih awal
- Percakapan yang lebih jujur tentang pengorbanan dibandingkan pertikaian pasif-agresif
- Mengurangi pengerjaan ulang karena persyaratan dieksplorasi dari kedua perspektif sebelum pengembangan dimulai
- Utang teknis ditangani secara bertahap, bukan ditunda hingga menyebabkan krisis
- Perkiraan menjadi lebih akurat karena tim melakukan kalibrasi terhadap kinerja sebelumnya
Tujuannya bukan untuk menghilangkan ketegangan antara produk dan teknik. Ketegangan yang terjadi adalah hal yang sehat -- artinya kedua belah pihak mendukung hal-hal yang penting. Tujuannya adalah menjadikan ketegangan itu produktif, bukan korosif.
Coba NextRetro gratis -- Fasilitasi retrospektif lintas fungsi dengan pengumpulan kartu anonim dan alur kerja diskusi terstruktur.
Terakhir Diperbarui: Februari 2026
Waktu Membaca: 7 menit
