Jika Anda berjanji untuk memberikan fitur yang Anda tidak yakin apakah itu dapat diterapkan?


13

Dalam sebuah artikel dari HN , saya menemukan saran berikut:

Selalu beri tahu pelanggan / pengguna Anda "ya", bahkan jika Anda tidak yakin. 90% dari waktu, Anda akan menemukan cara untuk melakukannya. 10% dari waktu, Anda akan kembali dan meminta maaf. Harga kecil untuk membayar pertumbuhan pribadi utama

Tapi saya selalu berpikir bahwa seseorang harus melakukan analisis kelayakan sebelum membuat segala jenis janji kepada pelanggan / pengguna, sehingga mereka tidak disesatkan pada titik apa pun. Pada keadaan apa, maka, apakah nasihat di atas berlaku?


20
Dalam pemrograman, segala sesuatu mungkin terjadi. Ingat saja bahwa "Ya" bukan jawaban untuk "Berapa lama?"
Steven Evers

9
@SnOrfus: Beberapa masalah tidak dapat diselesaikan. Jika Anda berpikir sebaliknya, programkan ramalan cuaca rutin yang akan memberi tahu Anda jika kita akan merayakan Natal putih.
Loren Pechtel

5
@ Elarlz: itu dengan asumsi bahwa alam semesta adalah deterministik, yang belum tentu benar.
whatsisname

4
Maaf, tidak mungkin. Cuaca menjadi kacau setelah tujuh hingga sepuluh hari. Ada sebuah makalah yang sangat terkenal tentang topik ini, “Prediktabilitas: Apakah Tutup Sayap Kupu-kupu di Brasil Memicu Tornado di Texas? oleh Edward Lorenz.
David Hammen

26
Jika para programmer akan membuat janji-janji yang tidak bisa mereka penuhi, apa yang akan dilakukan oleh para sales?
JeffO

Jawaban:


20

Ini adalah pertanyaan kedua berturut-turut yang dipicu oleh artikel itu.

  • Pemrogram yang baik: Saya mengoptimalkan kode. Programmer yang lebih baik: Saya menyusun data. Programmer terbaik: Apa bedanya?
    Ada nama lain untuk ini: optimasi prematur.

  • Jangan pernah gunakan pintu keluar awal.
    Itulah aturan "titik masuk tunggal / titik keluar tunggal". Ini adalah tambalan atas masalah nyata, yaitu bahwa keluar lebih awal mungkin meninggalkan kekacauan. Aturan yang tepat adalah "bersihkan kekacauan Anda". Aturan yang lebih baik lagi adalah dengan menggunakan konstruksi data yang membersihkan diri mereka sendiri sehingga programmer tidak perlu khawatir tentang membersihkan kekacauan mereka.

  • Dan sekarang, Selalu beri tahu pelanggan / pengguna Anda "ya", bahkan jika Anda tidak yakin. 90% dari waktu, Anda akan menemukan cara untuk melakukannya.
    Ini juga saran yang sangat buruk.

Terkadang pelanggan Anda perlu diberi tahu tidak, atau "di milenium mana Anda menginginkan ini?" Jangan menjanjikan sesuatu yang akan menghancurkan arsitektur Anda, yang akan menelan biaya jauh lebih banyak daripada yang ingin dibelanjakan pelanggan, atau bahwa Anda tidak memiliki petunjuk tentang bagaimana mencapainya. Anda tahu teknologinya, bukan pelanggan. Jika Anda tidak tahu cara melakukannya, jangan katakan Anda bisa melakukannya. Jika Anda tidak yakin, katakan Anda perlu waktu untuk meneliti apakah itu mungkin. Lebih baik jujur, dan itu akan membuat Anda keluar dari masalah.

Pelanggan dengan cepat menjadi mantan pelanggan jika Anda tidak dapat memenuhi janji Anda. Tingkat kegagalan 10% mungkin terdengar kecil, tetapi 10% pelanggan Anda akan fokus. Terkadang mereka menuntut ketika Anda gagal memenuhi apa yang Anda janjikan. Anda benar-benar tidak menginginkan itu. Di lain waktu, memastikan Anda melakukan yang baik dengan janji dapat membuat Anda bangkrut, menjadi gila, atau kehilangan pasangan Anda karena Anda bekerja 18 jam sehari. Anda juga tidak menginginkan itu.

Pikirkan seperti ini: Menurut Anda apa yang akan terjadi pada industri penerbangan jika 90% dari semua pendaratan pesawat berhasil? Apakah Anda pikir akan kembali dan meminta maaf atas 10% yang macet akan memperbaiki apa pun?


2
+1 Saya tidak melihat daftar yang ditautkan sebelumnya, pekerjaan yang bagus untuk menunjukkan ada beberapa saran yang sangat buruk di sana. Orang itu mungkin pengembang yang baik, saya tidak tahu, tapi dia yakin dia adalah yang pada umumnya bukan pertanda baik dan saran ini berbunyi seperti itu berasal dari beberapa IT bulanan untuk manajer kain.
Jimmy Hoffa

+1 - Saya tidak pernah mengatakan "Tidak" kepada pelanggan (kecuali jika saya tidak ingin melihatnya lagi) - Selalu seperti "Ini akan memakan biaya X dolar", "Tumpukan teknologi Anda tidak mendukung itu" dll. "Tidak" menutup masalah itu. gunakan tanggapan yang membukanya untuk diskusi lebih lanjut. misalnya "... tapi saya bisa memberi Anda 90% dari apa yang Anda inginkan dengan biaya 10%" atau ".... Tapi saya bisa menerapkannya dengan cara ini dan memberi Anda solusi yang bekerja dengan cara ini ...."
mattnz

1
@ mattnz - Sulit untuk mengatakan "Tidak", tetapi kadang-kadang diperlukan. "Bisakah kamu menyelesaikan perubahan itu besok?" Ya tidak. Tapi saya bisa mendapatkannya pada akhir minggu. "Bisakah Anda melakukan analisis Monte Carlo dengan masing-masing beberapa ratus variabel kontrol ini bervariasi secara acak per run?" Itulah yang mengumpulkan respons "di mana milenium yang Anda inginkan hasilnya". Saya membahas kutukan dimensi dan menyarankan agar kami membagi daftar itu ke sesuatu yang masuk akal. Bagaimana Anda mengatakan tidak itu penting, tetapi terkadang Anda harus mengatakan tidak. Secara diplomatis, tentu saja.
David Hammen

Tingkat kegagalan 10% akan menjadi peningkatan BESAR dari tingkat keberhasilan pengiriman perangkat lunak rata-rata saat ini.
Graham

Mengenai analogi pendaratan pesawat - Pesawat mendarat dengan aman setiap hari. Jika saya seorang pilot dan saya menjawab "biarkan saya kembali kepada Anda tentang hal itu" untuk pertanyaan apakah saya dapat mendaratkan pesawat saya dengan aman, itu tidak akan membelikan saya karma apa pun dengan para penumpang. Bahkan jika saya tahu ada kemungkinan kecil kecelakaan pendaratan, ini adalah contoh yang baik di mana menunjukkan kepercayaan pada kemampuan saya sebagai pilot lebih penting daripada berfokus pada kemungkinan kecil kegagalan.
Cliff

24

Akan lebih baik untuk mengatakan "Saya pikir itu bisa dilakukan". atau "Aku akan memeriksa dan kembali padamu". Saya pernah mengalami saat saya mengatakan tidak atau menentang sesuatu. Jika pelanggan menginginkan "aplikasi berbasis browser yang berfungsi tanpa pernah terhubung ke internet dan menggunakan umpan balik taktil", itu mungkin. Tetapi itu mahal dan akan lebih bermanfaat untuk mendiskusikan apa kebutuhan sebenarnya.

Pelanggan akan menghormati Anda jika Anda jujur. Dalam saran dalam pertanyaan, orang itu salah 10% dari waktu. Jika saya bekerja dengan seseorang yang secara rutin salah satu dari setiap sepuluh kali, saya tidak akan mempercayainya sama sekali. Itu adalah rekam jejak yang mengerikan.


17
Sering kali lebih baik memastikan klien memberi tahu Anda masalah apa yang ingin mereka selesaikan .. daripada meminta mereka untuk membahas solusi yang mereka inginkan . Dapatkan masalahnya .. dan beri tahu mereka solusinya.
Simon Whitehead

+1 dan lebih banyak - dua poin bagus yang Anda buat - Jangan pernah mengatakan "Tidak", dan jangan kehilangan kredibilitas dengan pelanggan Anda.
mattnz

+1 "Pelanggan akan menghormati Anda jika Anda jujur". Pernyataan itu sangat benar dan bernilai emas. Saat menyajikan opsi kepada pelanggan, jujurlah. Cukup beri tahu mereka bahwa apa yang mereka minta bukanlah widget yang sudah dibangun yang bisa Anda beli dan pasang. Biarkan mereka tahu bahwa mereka meminta solusi yang dibuat khusus dan perangkat lunak khusus sangat mahal. Ini biasanya menyebabkan satu dari dua hal terjadi. 1.) Mereka menginginkan alternatif yang hemat biaya. 2.) Mereka bersedia membayar untuk solusi kustom. Bagaimanapun itu adalah win / win.
Michael Riley - AKA Gunny

6

Menjanjikan bulan dan mengirimkan batu adalah semacam pendekatan sales-man yang tidak bisa ditoleransi. Jika Anda tidak tahu apakah itu mungkin, lakukan penelitian. Atau, beri mereka penawaran tentang jumlah waktu yang harus Anda ambil untuk melihatnya. Dengan cara ini Anda tidak menjanjikan apa pun yang tidak dapat Anda hasilkan, namun Anda dibayar untuk waktu yang dibutuhkan untuk melihatnya.


6

Pertanyaan ini telah dipelajari secara formal dan ditangani oleh IEEE Computer Society / ACM Code of Ethics yang diproduksi bersama .

2.01. Memberikan layanan dalam bidang kompetensi mereka, jujur ​​dan terus terang tentang segala keterbatasan pengalaman dan pendidikan mereka.

3.04. Pastikan bahwa mereka memenuhi syarat untuk proyek apa pun di mana mereka bekerja atau mengusulkan untuk bekerja dengan kombinasi pendidikan dan pelatihan yang sesuai, dan pengalaman.

3.09. Pastikan estimasi kuantitatif realistis mengenai biaya, penjadwalan, personel, kualitas, dan hasil pada setiap proyek tempat mereka bekerja atau melamar pekerjaan dan memberikan penilaian ketidakpastian estimasi ini.

5.0. Pastikan estimasi kuantitatif realistis mengenai biaya, penjadwalan, personel, kualitas dan hasil pada setiap proyek tempat mereka bekerja atau melamar, dan memberikan penilaian ketidakpastian estimasi ini.

Tentu saja ada implikasi bisnis dan hukum tentang menjanjikan sesuatu yang tidak dapat Anda berikan. Biasanya ini datang dari pelanggan yang pergi ke tempat lain, menolak untuk membayar, atau menuntut perusahaan Anda. Jika Anda bermitra dengan orang lain, mereka dapat menuntut ganti rugi jika bagian Anda tidak dikirimkan. Gugatan bahkan dapat datang dari pesaing.

Ada sebuah kisah dari masa-masa awal superkomputer di mana Seymour Cray dan sebuah tim di Control Data Corporation hampir meluncurkan produk, dan perusahaan komputer besar lainnya memberi tahu para pelanggannya bahwa mereka juga akan segera diluncurkan. Kebohongan itu menghabiskan banyak urusan dengan CDC dan berubah menjadi gugatan di mana perusahaan besar itu tidak dapat menunjukkan bukti yang kredibel atas klaim mereka. Hasilnya adalah apa yang pada saat itu penyelesaian besar senilai $ 80 juta dolar tahun 1970 (sekitar $ 223 juta pada tahun 2012, disesuaikan dengan inflasi). Anda dapat membacanya di sini:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing


+1 untuk merujuk kode etik untuk menjawab pertanyaan tentang etika.
Jay Elston

5

Dengan waktu yang cukup, sumber daya dan fleksibilitas di sekitar definisi kesuksesan apa pun mungkin terjadi. Contoh x-mass putih mudah jika Anda hanya menginginkan akurasi lebih dari 50% dan Anda memiliki lokasi geografis pengguna dan sedikit data statistik.

Pertanyaan pertama yang sebenarnya dalam sebagian besar proyek bukanlah apakah sesuatu itu mungkin, tetapi apakah itu wajar mengingat serangkaian keadaan tertentu.

Apakah fitur menambah nilai yang cukup untuk menjamin biaya upaya?

Sekalipun idenya akan sangat luar biasa, jika itu memerlukan periode pengembangan yang panjang atau akuisisi beberapa perangkat keras yang lebih eksotis, akan lebih baik bagi klien untuk mengetahui hal itu terlebih dahulu dan kemudian mengarahkan percakapan kembali ke tujuan yang lebih masuk akal dalam banyak kasus.

Jika seseorang cukup gila untuk memberi Anda cek kosong dan tidak ada tenggat waktu maka dengan segala cara memberi tahu mereka bahwa semuanya mungkin, beri tahu mereka bahwa Anda harus menemukan & mendistribusikan beberapa teknologi yang terlibat dalam mencapai tujuan di sepanjang jalan.

Di sisi lain, ketika berhadapan dengan klien yang masuk akal dengan sumber daya yang masuk akal kadang-kadang tidak ada yang lebih buruk daripada memberi tahu klien beberapa fitur harus dipotong setelah Anda menyetujuinya karena mereka mungkin sudah melarikan diri dan menghabiskan waktu / uang / sumber daya mempromosikan atau mendokumentasikannya dan bahwa 10% mungkin adalah hal yang membuat proyek mendapatkan penerangan sejak awal. Masuk ke dalam situasi itu dan Anda baru saja kehilangan pelanggan, dan kemungkinan besar mendapatkan referensi yang sangat buruk secara verbal di seluruh pasar.


4

Bermain sebagai penasihat iblis

Menjadi pola pikir analitis, orang-orang teknis dapat cenderung menganggap bahwa kinerja mereka terutama akan dinilai berdasarkan scorecard dari permintaan yang sudah selesai vs yang dilakukan, tetapi dalam praktiknya, itu tidak memotong dan mengering.

Bahkan sebelum pengembangan dimulai, pelanggan mulai membentuk opini tentang kinerja tim berdasarkan tingkat kepercayaan dan kemauan untuk berkomitmen.

Sebagian alasan untuk ini adalah bahwa pelanggan dapat mengalami kesulitan menilai apakah keraguan kontraktor untuk berkomitmen disebabkan oleh sulitnya permintaan atau kurangnya kemampuan kontraktor.

Karena tidak ada kriteria absolut untuk mengukur kesulitan permintaan, seringkali yang lebih penting bagi pelanggan adalah kepercayaan bahwa kontraktor memberikan upaya 100%, daripada apakah 90% atau 100% dari permintaan dipenuhi.

Misalkan pelanggan harus memilih antara dua skenario:

Kontraktor A :

  • Percaya diri mereka dapat memenuhi semua permintaan
  • Hasil: 90% dari permintaan dikirimkan
  • Pelanggan senang bahwa kontraktor memberikan upaya 100%
  • Pelanggan merasa bahwa permintaan yang tidak selesai disebabkan oleh masalah yang tidak terduga, yang mungkin di luar kendali kontraktor

Kontraktor B :

  • Berkomitmen untuk memenuhi 90% permintaan. Tidak percaya diri mereka dapat memberikan sisa 10%
  • Hasil: 90% dari permintaan dikirimkan
  • Pelanggan kecewa karena kontraktor tidak mencoba untuk menyelesaikan 10% dari permintaannya
  • Pelanggan berasumsi bahwa 10% permintaan yang tidak diselesaikan disebabkan oleh kurangnya upaya atau kemampuan kontraktor

Dalam kedua skenario, jumlah permintaan yang sama dikirimkan; namun, pelanggan merasa bahwa Kontraktor A yang "terlalu berkomitmen" memberikan upaya 100% dan menggunakannya untuk memvalidasi bahwa permintaan yang tersisa benar-benar sulit, untuk kredit Kontraktor A.

Di sisi lain, pelanggan merasa bahwa Kontraktor B tidak memberikan upaya 100% dan ketidakmampuannya untuk menyelesaikan semua permintaan itu karena kurangnya upaya atau kemampuan Kontraktor B.

Penafian: Saya tidak menganjurkan komitmen berlebihan sebagai strategi; ini hanya sebuah pengamatan dari kemungkinan situasi dunia nyata di mana komitmen berlebihan mungkin memiliki hasil positif.


3

Anda harus memberi tahu mereka untuk memberi Anda waktu untuk membuat "solusi spike" .

Solusi spike adalah program kecil yang, dalam mengkodekannya, memungkinkan Anda untuk mengetahui bagaimana melakukannya, atau bahkan apakah itu mungkin, sesuatu yang menciptakan ketidakpastian dalam suatu proyek.

Misalnya, Anda tidak pernah mengirim SMS secara terprogram, tetapi entah bagaimana Anda tahu itu mungkin. Solusi spike adalah membuat program kecil yang mengirim SMS. Dengan begitu, ini bukan lagi ketidakpastian dan Anda dapat membuat estimasi lebih lanjut tentang kelayakan.

Inilah yang dikatakan dokumentasi Pemrograman eXtreme di atasnya:

Buat solusi spike untuk mencari tahu jawaban atas masalah teknis atau desain yang sulit. Solusi spike adalah program yang sangat sederhana untuk mengeksplorasi solusi potensial. Buat lonjakan hanya untuk mengatasi masalah yang sedang diperiksa dan abaikan semua masalah lainnya. Kebanyakan paku tidak cukup bagus untuk disimpan, jadi harap dibuang. Tujuannya adalah mengurangi risiko masalah teknis atau meningkatkan keandalan perkiraan cerita pengguna. Ketika kesulitan teknis mengancam untuk menahan pengembangan sistem menempatkan sepasang pengembang pada masalah selama satu atau dua minggu dan mengurangi risiko potensial.


1

Menurut pengalaman saya, ketika pengguna meminta sesuatu, Anda harus meminta mereka untuk spesifikasi rinci tentang apa yang benar-benar diinginkan atau dibutuhkan pengguna. Lebih sering daripada tidak, Anda tidak akan pernah mendengar tentang permintaan itu lagi.


1
itulah cara terbaik untuk ... membuat pengguna tidak senang. Lebih sering daripada tidak, ini akan menyebabkan penyusutan laba
agn

3
Jujur saja, untuk beberapa pengembang In-House, ini bukan ide yang buruk. Pekerjaan in-House biasanya tidak ditagih secara langsung (IT hanya bagian dari anggaran umum) dan Anda dapat kewalahan dengan permintaan omong kosong karena para pemohon tidak mengeluarkan uang dengan mengirim spam kepada Anda dengan pekerjaan.
Graham
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.