Apakah normal bagi pengembang untuk menyarankan ide fitur kepada pemilik produk? [Tutup]


16

Saya mulai bekerja sebagai pengembang baru-baru ini, setelah bekerja sebagai administrator sistem sebelumnya.

Pemahaman saya tentang bagaimana tim pengembangan perangkat lunak menggunakan fungsi Agile adalah bahwa komunikasi "apa yang perlu kita laksanakan" sebagian besar terjadi dalam satu arah, dari pemilik produk ke pengembang. Pengembang dapat mengungkapkan keprihatinan mereka kepada pemilik produk tentang utang teknis, tetapi memunculkan ide fitur tidak boleh menjadi salah satu tanggung jawab utama mereka.

Perusahaan tempat saya bekerja memiliki pandangan yang berbeda. Bagi mereka, pengembang tidak hanya harus pergi ke pemilik produk dari tim mereka sendiri untuk menyarankan ide fitur, tetapi juga kepada pemilik produk dari tim lain jika mereka berpikir mereka memiliki sesuatu untuk berkontribusi pada produk tim itu. Idenya adalah kita semua adalah satu tim besar <nama perusahaan>, dan semua pengembang harus menggunakan keahlian mereka untuk mendorong fitur yang mereka pikir akan berguna.

Apakah pendekatan semacam itu "normal", karena tidak ada kata yang lebih baik? Apakah saya terlalu pasif, haruskah saya mengambil inisiatif dan mulai mendorong ide kepada pemilik produk? Sebaliknya, apakah perusahaan salah sepenuhnya dan saya harus mencari pekerjaan di tempat lain?


15
Tentu, programmer sering tahu banyak hal yang pemilik produk tidak pernah dengar. Ambil pengembangan web, ada layanan, apis, sejumlah perpustakaan dan plugin serta item antarmuka pengguna. Kami sering bekerja dengan pelanggan yang tidak memiliki lebih dari sekadar gagasan kasar tentang apa yang ingin mereka lakukan, tetapi tidak memiliki pengetahuan apa cara umum untuk mengimplementasikannya atau fitur tambahan apa yang mungkin dilakukan.
thorsten müller

1
Apakah Anda merasakan dendam atau konsekuensi negatif karena tidak menyarankan fitur? Sepertinya perusahaan Anda ingin mendorong praktik dan tidak menghukum mereka yang tidak.
JeffO

Ini adalah proses normal di dua perusahaan tempat saya bekerja. Saya menyadari bahwa para pebisnis tidak memiliki petunjuk tentang betapa berharganya pengembang kami dalam keterampilan solusi / pemecahan masalah. Melompati kapal Anda kemungkinan akan mengalami masalah yang sama. Menyarankan fitur-fitur baru kepada orang-orang produk seolah-olah ada solusi, disebut mengelola manajer dan berfungsi dengan baik. Satu-satunya masalah adalah itu berarti Anda tidak mendapatkan kredit untuk ide-ide Anda tetapi setidaknya fitur Anda diimplementasikan.
Jason

IMO ini adalah hal yang sangat baik dan sangat sehat. Pemilik produk mungkin ahli dalam domain bisnis tetapi kemungkinan tidak mengetahui setiap teknologi baru atau pendekatan teknis yang tersedia. Selain itu, pengembang mungkin memiliki wawasan tentang sistem yang berasal dari perspektif berbeda dalam bekerja langsung dengan kode. Anda pasti ingin tetap bersama perusahaan yang menerima ide dari semua orang, apa pun perannya. Itu tidak berarti bahwa pemilik tidak tahu apa-apa, itu berarti bahwa mereka terbuka untuk ide semua orang.
Ken Liu

Jawaban:


2

Itu tergantung apa yang Anda maksud dengan ide-ide fitur.

Dalam permainan perencanaan, tidak jarang bagi pengembang untuk memberikan masukan tentang cerita yang mungkin berakhir dalam iterasi. Namun, ini sangat berbeda dari pengembang yang datang dengan cerita sendiri.

Dalam sistem yang matang, pengembang mungkin menyarankan cara mengitari masalah yang diketahui yang bisa membuatnya menjadi iterasi.

Peningkatan bisa OK saja misalnya menambahkan grafik untuk laporan, tetapi bel alarm akan berdering bagi saya jika pengembang datang dengan cerita baru yang bonafid. Jika ada nilai nyata dalam hal ini, saya akan mempertanyakan mengapa tidak ada cerita yang belum diimplementasikan untuk ini atau mengapa itu tidak pernah muncul dalam retrospektif.


1
Saya tidak menafsirkan filosofi perusahaan saya sebagai meminta pengembang untuk membuat cerita, dan saya tidak ingat melihat itu terjadi. Apa yang saya pikir mereka inginkan adalah, begitu sebuah ide telah dipancarkan dan pengembang telah mengambil kepemilikan atas pelaksanaannya, adalah tanggung jawab pengembang untuk memperjuangkan gagasan itu sampai akhir.
louniks

1
Jadi Anda mengatakan bahwa alarm berbunyi ketika pengembang memikirkan sebuah ide yang tidak dipikirkan oleh pemilik produk? Mengapa itu menjadi hal yang buruk?
Stefan Billiet

1
Melempar ide-ide baik-baik saja - itu adalah bagian dari permainan perencanaan. Jika itu adalah cerita baru, saya akan mempertanyakan ini. Cerita memberikan nilai pelanggan yang menjadi pengembang jujur ​​biasanya tidak ditempatkan untuk menilai (kecuali mereka ahli domain). Apakah sesuatu muncul dalam iterasi ditentukan oleh nilai cerita dan upaya pengembang dalam game perencanaan. Keterlibatan pengembang dalam membuat cerita dapat menyebabkan potensi konflik kepentingan di sini. Ini bukan untuk mengatakan itu tidak bisa terjadi - hanya saja pemilik produk kemudian perlu memperjuangkannya, kalau tidak itu adalah ekor yang mengibas-ngibaskan anjing.
Robbie Dee

47

Alasan mengapa banyak pengembang "pasif," seperti yang Anda katakan, adalah karena dibutuhkan sejumlah pengetahuan dan pengalaman domain sebelum ide-ide produk yang bagus datang kepada Anda. Tetapi jika mereka datang, tidak ada alasan untuk tidak menyarankan mereka dan memperjuangkan mereka.

Ingat - pengembang, pemilik produk, tenaga penjualan, dll., Semuanya berada di tim yang sama, dengan tujuan yang sama: membangun produk yang sukses. Berusahalah untuk mencapai tujuan itu sebisa Anda.


Saya pikir Anda telah berhasil - saya telah mendarat di sebuah tim yang bekerja dengan teknologi yang hanya memiliki sedikit pengalaman, oleh karena itu sulit bagi saya untuk menjadi proaktif. Harus ada periode belajar di mana saya tetap pasif. Setelah itu, begitu saya mulai merasa nyaman dengan teknologi, saya bisa mulai bersikap proaktif.
louniks

1
@louniks tidak, Anda tidak mengerti intinya. Teknologi bukan yang penting. Bisnislah yang penting. Seberapa transparan pelaku bisnis? Apakah Anda sadar bagaimana bisnis ini ingin menghasilkan uang? Apakah Anda mengetahui bagaimana produk yang Anda kerjakan cocok dengan produk lain di perusahaan? Jika tidak, maka majikan Anda tidak adil terhadap Anda. Anda tidak dapat menyarankan fitur jika Anda tidak tahu rencana bisnisnya.
RibaldEddie

3
@RibaldEddie saya tidak setuju dengan bagian terakhir. Siapa pun harus bebas untuk menyarankan fitur. Manajemen dan pemilik produk masih bebas menentukan apakah fitur tersebut dapat digunakan di mana saja. Jangan mengabaikan kemungkinan bahwa pengembang dengan domain dan pengetahuan teknis yang memadai dapat memunculkan fitur besar yang menghasilkan uang yang sepenuhnya di luar rencana bisnis asli. Pemilik produk mungkin tidak akan pernah memiliki ide yang sama karena pengetahuan teknis yang terbatas.
Dan Lyons

1
Kedengarannya seperti situasi berbahaya: itu artinya orang-orang bisnis tempat Anda bekerja tidak tahu apa yang mereka lakukan. MEREKA PEKERJAAN untuk menjadi ahli di bidang ini. Kalau tidak, mengapa mereka ada di sana? Serius. Jika pengembang memberikan wawasan seperti ini maka pengembang mungkin juga menjalankan perusahaan. Yang lainnya adalah pemborosan.
RibaldEddie

Anda tidak selalu membutuhkan pengetahuan domain terperinci untuk menyarankan peningkatan teknis ...
Robbie Dee

5

Dengan pembicaraan Anda tentang pengembang dan pemilik produk, menurut saya Anda tidak memiliki orang tengah yang bertanggung jawab atas fitur-fitur dalam organisasi Anda.

Nah, di organisasi saya, saya adalah orang itu. Saya adalah insinyur kebutuhan, orang yang belajar bagaimana membuat spesifikasi yang baik dan memilih fitur yang menghasilkan perangkat lunak berkualitas tinggi dengan desain interaksi yang ramah pengguna. (Di organisasi lain orang UX yang mendapatkan pekerjaan yang sama, Anda mungkin lebih akrab dengan istilah itu).

Dan saya dapat memberi tahu Anda: Mendapatkan spesifikasi yang baik itu sulit. Tentu saja, pengembang benci melakukannya. Ini merupakan beban bagi mereka - mereka ada di sana untuk membangun perangkat lunak, bukan untuk memikirkan permainan kekuasaan di antara para pemangku kepentingan dan model mental pengguna yang malas. Tapi tahukah Anda? Ini juga menjadi beban bagi pemilik produk. Mereka tidak tahu lebih baik fitur apa yang harus dimiliki oleh perangkat lunak mereka daripada para pengembang atau pengguna. Membuat spesifikasi yang layak adalah keterampilan yang dipelajari, dan jika Anda tidak pernah mempelajarinya, Anda tidak bisa menjadi ahli dalam hal itu. Tentu, ada banyak pengembang dan pemilik produk yang dapat melakukannya, karena mereka harus melakukannya di proyek sebelumnya. Tetapi rata-rata pemilik atau pengembang produk berjuang dengan hal itu, karena tentu saja bukan pekerjaan mereka untuk melakukannya. Tidak semua orang yang bisa mengendarai mobil dapat merancang mobil; demikian pula,

Bisakah Anda mengembangkan perangkat lunak tanpa insinyur persyaratan? Tentu kamu bisa. Tetapi meletakkan seluruh berat spesifikasi itu di pundak pemilik produk itu tidak adil, dan tidak baik untuk hasil proyek. Terutama karena dia dihadapkan dengan tugas yang sangat sulit baginya, mendapatkan masukan dan dukungan dari orang lain sangat membantu. Jika Anda berada dalam situasi seperti itu, jangan lihat pemilik produk Anda yang buruk dan katakan "katakan padaku apa yang harus dibuat untuk Anda dan saya akan membuat Anda", dia benar-benar tidak tahu apa yang dia butuhkan. Tetapi diskusi dengan Anda akan membantunya mengartikulasikan pemikirannya dan mengeksplorasi ide-idenya.

Ketika tidak ada insinyur persyaratan dalam struktur proyek, ada masalah lain: tidak ada moderator. Semua pengembang ada di sisi teknis, semua pemilik produk ada di sisi bisnis. Ketika kedua budaya berbenturan, konflik dapat muncul, dengan masing-masing pihak menilai yang lain bodoh dan tidak masuk akal (karena menggunakan sistem nilainya sendiri untuk menilai). Jadi, jangan bicara dengan pemilik produk Anda tentang fitur yang mungkin, tetapi tetap sopan dan sabar bahkan ketika Anda berpikir dia tidak layak mendapatkannya; keberhasilan proyek tergantung pada seberapa baik Anda berdua dapat rukun, dan kadang-kadang mengambil keputusan yang kurang optimal lebih baik daripada tidak mengambil keputusan sama sekali karena konflik. Mungkin bermanfaat untuk membangun hierarki dan memberikan salah satu dari kalian kata terakhir, karena ini mencegah konflik yang menemui jalan buntu. Jika dia mendapatkan kata terakhir, tunda bahkan jika Anda merasa itu tidak adil.

Tentang bagian "pasif": jika Anda tidak memiliki ide, jangan mencoba untuk membuat sesuatu hanya untuk menunjukkan aktivitas. Jika pemilik produk sudah merasa tidak aman dan tidak mengetahui kriteria yang baik untuk mengevaluasi ide-idenya, ide-ide aneh "hanya untuk memiliki sesuatu" akan membuat situasi yang sudah sulit menjadi semakin sulit. Menghadirkan ide-ide fitur yang bagus bukanlah sihir, tetapi itu membutuhkan pengetahuan. Jika Anda tidak mempelajarinya dari buku teks, Anda mungkin perlu beberapa tahun pengalaman pengembang, terutama dalam proyek-proyek di mana Anda terpapar dengan pengguna atau data kegunaan yang dihasilkan pengguna (analitik, pengukuran kepuasan) sebelum otak Anda memilah pola untuk dirinya sendiri dan Anda mulai memperhatikan: ada masalah di sini yang bisa kita pecahkan. Pengguna tampaknya kehilangan sesuatu di halaman ini, apa itu? Maka Anda akan memiliki ide bagus untuk dibagikan.

Kesimpulan 1: Dalam proyek tanpa insinyur persyaratan, ada baiknya untuk membuat saran saat Anda memilikinya. Lakukan dengan kepekaan dan kebijaksanaan - sangat penting untuk menghindari konflik bahkan jika itu berarti ide bagus Anda gagal.

Dan jika Anda berada di tim dengan insinyur persyaratan?

Saya suka mendengar ide fitur dari semua orang! Ya, kadang-kadang ide pengembang sangat buruk (ketika mereka ingin membuat antarmuka pengguna mengikuti logika pemrograman). Ide pemilik produk juga sering kali mengerikan (ketika mereka menginginkan matahari dan bulan dengan anggaran yang ketat - oh, dan pengguna seharusnya memasukkan halaman informasi pribadi dalam kualitas data tertinggi, tanpa mendapatkan imbalan apa pun). Tapi itu tugas saya untuk membuat spesifikasi yang bagus untuk semua orang di tim. Dan bahkan jika ide Anda tidak akan berhasil, mendengarnya membuat saya sadar bahwa Anda memiliki masalah. Anda mungkin telah memilih solusi yang salah untuk disarankan, tetapi ini tidak membuat kekhawatiran Anda kurang valid. Jika Anda melihatnya, mungkin perlu ditangani (atau saya perlu mencari alasan mengapa itu bukan ancaman). Jika Anda memiliki insinyur persyaratan yang bertanggung jawab untuk spesifikasi, jangan pernah ragu untuk pergi ke mereka dengan saran. Jika mereka tidak mendengarkan Anda, mereka melakukan kesalahan (perhatikan bahwa "mempertimbangkan" tidak berarti "menerima").

Seorang insinyur persyaratan harus melihat proyek dari sudut pandang masing-masing pemangku kepentingan secara terpisah (dan kadang-kadang pada saat yang sama). Kita hanya manusia, dan kita sering gagal dalam hal itu. Jika Anda berada di sana untuk memberikan sudut pandang Anda yang sebenarnya, alih-alih dari sudut pandang yang kami pikir Anda miliki, maka masukan Anda sangat berharga.

Anda bisa lebih bebas dalam perilaku Anda di sini. Adalah tugas saya untuk melakukan tarian sensitivitas. Jangan agresif secara terbuka, ini menghalangi pekerjaan saya, tetapi Anda perlu lebih sedikit kontrol diri dan kesadaran budaya / komunikasi, karena saya bisa mengambil kendur. Anda juga tidak mengambang, dalam situasi di mana ada dua ide yang saling bertentangan dan tidak ada yang bisa menilai mana yang lebih baik. Saya seharusnya tahu itu, dan jika itu tidak berhasil, itu adalah kepalaku.

Kesimpulan 2: Jika ada insinyur persyaratan di tim, kunjungi mereka dengan saran fitur produk. Anda tidak perlu sarung tangan beludru saat ini.

Dan terakhir, bagaimana jika tidak ada insinyur persyaratan, pemilik produk kewalahan dan berjuang untuk ide-ide, bos dengan tajam menatap Anda, dan Anda tidak punya ide untuk ditawarkan?

Anda punya beberapa pilihan. Yang satu, seperti yang Anda sebutkan, berhenti. Tidak semua organisasi bekerja seperti itu, dan jika lingkungan ini tidak cocok untuk Anda, temukan yang lebih baik. Ini akan baik untuk Anda dalam jangka panjang.

Anda juga dapat menunggu dan melihat apakah ada perubahan. Proyek selanjutnya dapat memiliki pemilik produk yang lebih berpengalaman (atau yang memiliki lebih banyak kepemimpinan). Tapi kamu tidak bisa berhenti selamanya.

Pilihan ketiga adalah untuk benar-benar mempelajari beberapa persyaratan rekayasa sendiri. Ini adalah keterampilan yang sangat dicari hari ini. Bahkan jika Anda tidak pernah berencana untuk mengambil posisi di mana Anda adalah insinyur persyaratan penuh waktu, memiliki keterampilan ini meningkatkan nilai Anda sebagai pengembang, karena memungkinkan Anda memahami anggota lain yang lebih baik di tim Anda (dan pengguna Anda) dan membuat proses pengembangan berjalan lebih lancar. Dan Anda tidak harus masuk ke dalamnya. Buku teks tingkat entri yang menjelaskan tugas, alur kerja, model mental, dan model data yang berpusat pada pengguna sudah memungkinkan Anda melihat banyak peluang peningkatan dalam perangkat lunak yang dirancang oleh tim pengusaha dan pengembang. Mengenakan' untuk mencari buku-buku paling tebal yang dimaksudkan sebagai referensi bagi akademisi (seperti terjemahan Pohl baru-baru ini ke Bahasa Inggris) - buku-buku itu lebih merupakan daftar semua metode yang mungkin untuk setiap langkah kecil, tanpa penjelasan bagaimana cara melakukannya. Pilih sesuatu yang berorientasi pada praktik.

Jika Anda mencobanya dan ternyata Anda tidak memiliki minat pribadi di area tersebut, itu tetap baik-baik saja. Jangan memaksakan diri untuk melakukan sesuatu yang tidak Anda sukai. Tetapi Anda mungkin harus mencari pekerjaan di organisasi dengan struktur tim yang berbeda.

Kesimpulan 3: Alih-alih menunggu bertahun-tahun untuk mendapatkan pemahaman intuitif, baca satu atau dua buku dan Anda sudah memiliki ide-ide bagus untuk memasok


+1 Itulah jawaban yang sangat komprehensif. "Kesimpulan" berfungsi sebagai baik TL;DR.
James Khoury

4

Ya, itu sangat normal.

Ada 80% karya terkenal - 20% model inovasi di google, di mana orang 20% ​​dari waktu mereka mencurahkan untuk sesuatu yang mereka sukai. Dengan cara ini, tidak hanya mereka mendapatkan fitur baru, tetapi juga produk dan layanan yang sama sekali baru.

Apakah saya terlalu pasif, haruskah saya mengambil inisiatif dan mulai mendorong ide kepada pemilik produk?

Itu tergantung kepribadian Anda. Saya telah bekerja dengan orang-orang yang benar-benar bersemangat, tetapi juga dengan orang-orang tanpa emosi yang melakukan shift 8 jam dan pulang ke rumah.


Sepertinya di Google para pengembang menghabiskan sebagian waktu mereka sebagai pemilik produk.
JeffO

Karyawan Google yang mengerjakan proyek mereka sendiri tidak sama kecuali Anda berbicara tentang inisiatif lain?
Robbie Dee

@RobbieDee Ya, benar. Mereka mengerjakan proyek mereka, tetapi Google menjual layanan yang keluar dari proyek.
BЈовић

Yang saya maksudkan adalah bahwa proyek semacam itu tidak harus berada dalam lingkup proyek tangkas yang ada. Mereka mungkin sepenuhnya otonom.
Robbie Dee
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.