Berurusan dengan ketidakcocokan budaya pelanggan / pengembang pada proyek tangkas

11

Salah satu prinsip lincah adalah ...

Kolaborasi pelanggan atas negosiasi kontrak

... yang lain adalah ...

Individu dan interaksi atas proses dan alat

Tapi cara saya melihatnya, paling tidak ketika berinteraksi dengan pelanggan, ada masalah mendasar:

Bagaimana menurut pelanggan berbeda dengan cara berpikir insinyur perangkat lunak

Itu mungkin sedikit generalisasi, ya. Diperdebatkan, ada yang domain bisnis di mana hal ini tidak selalu benar --- ini sedikit dan jauh antara sekalipun. Namun di banyak domain, pelanggan tipikal adalah:

Tertarik dengan masalah operasional harian - taktik jarak pendek ... belum tentu strategi;
Maklum, hanya mementingkan solusi langsung;
Pemikir praktis, bukan pemikir abstrak;
Jauh lebih tertarik untuk "menyelesaikan pekerjaan" daripada mempertimbangkan bagaimana solusi akan mendukung masalah di masa depan.

Di sisi lain, dalam ideal , insinyur perangkat lunak yang berlatih gesit adalah:

Orang yang berpikir banyak tentang kualitas;
Individu yang menghargai bagaimana sedikit pekerjaan dimuka dapat menghemat satu ton upaya di telepon;
Pemikir analitis yang berpengalaman.

Jadi sepertinya ada perbedaan budaya yang cenderung menghambat "kolaborasi pelanggan".

Apa cara terbaik untuk mengatasi ini?

agile

— Eric Smith
sumber

1

Operant conditioning shaping - en.wikipedia.org/wiki/Shaping_%28psychology%29 - Petunjuk: terlalu jelas jika Anda menggunakan clicker sebelum memberi mereka donat.

— jfrankcarr

3

Saya ingin memilih ini. Tapi kemudian saya membaca stereotip yang Anda coba pakai ini. Ada programmer buruk melakukan pelanggan tangkas dan baik. Mungkin Anda bisa mengerjakan ulang pertanyaan Anda dengan memasukkan kesulitan yang Anda miliki alih-alih stereotip bias yang Anda miliki di sini .. Lalu saya akan menjawab pertanyaan itu dengan jelas.

— SoylentGray

3

stereotip Anda mengkhianati pendapat narsis Anda yang fanatik, saya tidak berpikir siapa pun yang berpikir seperti Anda akan berhasil dalam berurusan dengan pelanggan mana pun , Anda telah mengambil keputusan dan memiliki sistem kepercayaan yang kuat untuk memperkuat bias Anda. Hanya berpikir semacam sikap chauvinistik yang memberi bekerja dengan insinyur nama buruk. Semoga beruntung dengan itu.

1

@Chad Ini bisa menjadi sudut pandang yang berguna untuk sebuah pertanyaan, terlepas dari apakah itu berasal dari prakonsepsi si penanya, atau tidak. Berpikir tentang bagaimana insinyur yang baik berinteraksi dengan klien yang buruk adalah kasus yang relevan dan menarik: bisa dikatakan bahwa kita tidak peduli tentang bagaimana insinyur yang buruk menangani ini, karena produk mereka akan lebih rendah pula, dan klien yang baik meniadakan kebutuhan untuk pertanyaan ini. Itu membuat kami memiliki masalah tentang bagaimana pengembang yang baik harus berurusan dengan klien yang buruk. Mungkin kata-kata itu keluar dengan kuat, tetapi pertanyaannya masih berguna,

— Chris Bye

@ Slothsberry - Saya mengerti pertanyaan ini dapat dicakup untuk himpunan bagian tersebut. Itu bukan bagaimana itu bertahap. Saya membacanya karena semua pengembang yang berlatih gesit baik dan sebagian besar pelanggan buruk.

— SoylentGray

27

Namun di banyak domain, pelanggan tipikal adalah:

Tertarik dengan masalah operasional harian - taktik jarak pendek ... bukan strategi;

Hanya peduli dengan solusi langsung;

Umumnya pemikir satu dimensi, non-abstrak;

Terutama tertarik pada "menyelesaikan pekerjaan" sebagai lawan datang dengan solusi yang tahan lama dan berkualitas.

Dan jujur saja, mereka biasanya punya alasan bagus untuk berpikir seperti ini. Pertama-tama, mereka menjalankan bisnis, yang seharusnya menghasilkan pendapatan hari ini dan besok, bukan di masa depan yang jauh. Kedua, mereka bukan ahli teknis - mereka tidak tahu apa yang mungkin dan apa yang tidak, dan apa konsekuensi dari pilihan arsitektur / desain / implementasi tertentu. Ini yang kita tahu.

Jadi jawabannya adalah - tidak mengejutkan - komunikasi .

Anda perlu banyak berkomunikasi, untuk saling mendidik, untuk membuat satu sama lain memahami sudut pandang pihak lain setidaknya ke tingkat dasar. Anda perlu menjelaskan konsekuensi jangka pendek dan jangka panjang dari alternatif yang mungkin. Dan Anda perlu menggunakan bahasa yang mereka pahami .

Jika Anda mengatakan "ini akan menjadi peretasan, yang membuat kodenya lebih mudah dibaca dan tidak dapat diperpanjang" , kata mereka, "yeah, terserahlah" .
Jika Anda mengatakan "ini akan menjadi perbaikan jangka pendek, yang akan membuat pengembangan dan pemeliharaan jangka panjang lebih mahal, dan meningkatkan risiko memperkenalkan bug" , kata mereka "ha, mari kita pertimbangkan" .
Dan jika Anda mengatakan "solusi ini akan dikenakan biaya $ 100 sekarang, tetapi perkenalkan $ 500 dari hutang teknis yang Anda harus bayar kembali dengan bunga cepat atau lambat; OTOH solusi lain ini menelan biaya $ 400 sekarang dan tidak meninggalkan utang teknis; pilih yang Anda ingin " , kata mereka " sekarang kita berbicara! " .

OTOH mereka bisa mengajari kita satu atau dua hal tentang perspektif bisnis. Bisnis menginginkan solusi yang dapat digunakan dan cukup baik - hampir tidak sempurna -. Dan mereka tahu mungkin lebih baik daripada siapa pun bahwa "sempurna adalah musuh kebaikan". Jadi, Anda harus ingat bahwa tugas kami adalah memberikan solusi untuk masalah klien kami, daripada menghasilkan perangkat lunak yang sempurna secara teknis. Terkadang keduanya bertemu dengan yang sama, tetapi lebih sering tidak. Ini mungkin dipandang menyedihkan oleh banyak orang, tetapi ini adalah kenyataan bisnis. Bagi saya, jika saya berhasil memecahkan masalah pelanggan saya, dan saya melihat bahwa itu membuat hidup mereka tampak lebih mudah, saya bahagia seperti mereka. OTOH jika saya berhasil menerapkan desain sempurna yang ada dalam pikiran saya, tetapi perusahaan itu bangkrut pada minggu berikutnya, hampir tidak ada kemenangan bagi siapa pun, bukan?

Seorang pemilik bisnis yang masuk akal akan mengerti - jika Anda menjelaskannya menggunakan bahasa mereka sendiri - mengapa penting untuk menjaga perangkat lunak tetap bersih, untuk menulis unit test, untuk refactor dll. Meskipun ini tampaknya tidak secara langsung berkontribusi apa pun dalam jangka pendek, mereka sangat penting untuk pemeliharaan jangka panjang. Dan pelanggan yang masuk akal peduli dengan pemeliharaan jangka panjang dari bisnis mereka, jadi mereka pasti mau berinvestasi ke dalamnya ketika mereka melihat nilai yang dihasilkan dari investasi mereka. Namun, sumber daya dan waktu Anda terbatas, sehingga Anda perlu memprioritaskan dan fokus pada hal-hal yang paling penting. Tapi itu penting hanya jika itu penting bagi Anda berdua .

Anda mungkin ingin memperbarui modul A karena kode di sana hanya buruk, dan Anda memiliki ide yang luar biasa bagaimana membuat ulang kode menjadi ringkas, elegan dan bersih, menggunakan pola desain yang baru saja Anda baca. Namun, jika modul itu belum disentuh selama bertahun-tahun, dan itu berfungsi dengan baik, Anda kemungkinan besar lebih baik berfokus pada modul B, yang akan diperpanjang minggu depan dengan fitur baru yang sangat penting, dan berisi banyak bug sudah.

— Péter Török
sumber

3

Wow, Anda punya klien yang sebenarnya menghindari utang teknis? Sebagian besar yang saya miliki akan menjadi '$ 100, ya saya akan mengambil yang'.

— sevenseacat

Nah, itu agak sulit, bukan? Apa itu "cukup baik", dan di mana pengembalian Anda mulai berkurang ketika Anda mempertimbangkan menghabiskan waktu untuk kesehatan jangka menengah-panjang dari produk / sistem bisnis Anda? Saya berpendapat bahwa itu adalah sesuatu yang harus dilakukan oleh seorang profesional.

— Eric Smith

2

@ Kubarpie, ya, ada klien yang telah belajar apa sebenarnya utang teknis (biasanya cara yang sulit).

— Péter Török

2

@ EricSmith, ya, ini adalah keputusan yang kabur, tanpa jawaban yang benar. Kami pengembang memahami konsekuensi teknis dari berbagai hal; pelanggan mengetahui batasan anggaran dan bisnis. Idealnya, kami memberi tahu berapa biaya setiap fitur / tugas; pelanggan memprioritaskan berdasarkan nilai dan biaya masing-masing. Selalu ada kompromi ketika Anda perlu menjaga sistem dan menjalankannya sambil memperbaiki masalah yang paling mendesak satu per satu.

— Péter Török

3

Saya setuju dengan apa yang Anda katakan di sini meskipun saya telah berlari ke budaya perusahaan di mana pengguna menolak untuk berkomunikasi. Itu harus jalan dua arah atau tidak akan berhasil. Saya hanya setengah bercanda tentang menggunakan donat untuk pengkondisian dalam komentar saya di atas. Terkadang Anda harus menggunakan penguatan positif atau bahkan negatif untuk mendapatkan partisipasi.

— jfrankcarr

4

Bagaimana pelanggan Anda memandang diri mereka sendiri:

Saya punya proyek yang harus saya lakukan secepatnya
Saya tahu kebutuhan bisnis saya
Saya perlu menyelesaikan masalah dengan cara yang tidak akan mengganggu praktik bisnis saat ini
Saya memiliki anggaran terbatas untuk menyelesaikan ini.

Di sisi lain, mereka melihat grup Anda sebagai:

Cowok yang tidak mengerti bahwa mereka menyedot uang dari anggaran saya.
Tidak mengerti kebutuhan bisnis kita
Ingin mendesain ulang semuanya meskipun itu akan membuat penerapannya lebih sulit pada bisnis.
Ingin punya solusi cerdas yang pintar ketika semua yang saya punya anggaran untuk fungsional dan efektif.

Masalah utama Anda tampaknya bukan Anda berdua yang memahami apa yang mereka butuhkan dari pihak lain.

— SoylentGray
sumber

3

Yah, pertama dan terpenting, Agile bukan solusi untuk semua masalah yang Anda miliki di proyek Anda.

Bagaimana pelanggan berpikir secara fundamental berbeda dengan bagaimana seorang insinyur perangkat lunak berpikir

Iya. Terkadang itu benar. Bahkan ada kasus di mana pelanggan tidak tahu apa dan bagaimana yang mereka inginkan (yaitu; persyaratan tidak jelas). Apa pun, Jika Anda gesit, Anda mendapatkan hasilnya setelah setiap sprint (katakanlah 2 minggu) dan Anda mendapatkan kesempatan untuk mendapatkan umpan balik pelanggan dan memastikan semua berada di halaman yang sama. Ini membantu dalam mengidentifikasi dan memperbaiki masalah awal yang secara internal akan membantu membangun kepercayaan.

Ada juga yang mengatakan, pengguna seperti anak-anak gila, jadi ketika mereka meminta pistol dan Anda tahu itu tidak aman, Anda mungkin mempertimbangkan untuk memberikan pistol mainan untuk menenangkan mereka .

Apa cara terbaik untuk mengatasi ini?

Seperti yang telah saya katakan, tidak ada tongkat ajaib yang dapat menyelesaikan semua masalah tesis ini . Anda perlu lebih terlibat dengan pelanggan Anda sehingga ada pemahaman yang baik tentang apa yang masing-masing lakukan. Promosikan kunjungan situs, buka umpan balik dll.

Pastikan pemilik produk Anda dan pemegang pasak menghadiri demo sprint dan memberikan saran yang berharga untuk meningkatkan produk .

— ManuPK
sumber

1

Jika Anda tidak menerima dari pelanggan, Agile bisa menjadi hampir mustahil.

Dengan membeli, maksud saya mendapatkan persentase yang dijamin dari waktu perwakilan pelanggan per minggu atau bulan. Persentase ini akan bervariasi tergantung pada proyek.

Jelas mereka memiliki pekerjaan harian mereka, jadi mereka tidak hanya bergantung pada perwakilan pelanggan, tetapi juga manajemen mereka yang menyediakan waktu untuk mereka.

Jadi mendapatkan persetujuan dari manajemen di sisi pelanggan adalah kunci untuk masalah ini

— ozz
sumber

tanpa pelanggan membeli dengan metode apa pun hampir tidak mungkin

— Ryathal

@ Ryathal - memang, tapi itu sangat penting dalam cara saya menggambarkan untuk Agile.

— ozz

0

Ingatlah bahwa lincah tidak berarti bahwa pelanggan terlibat dalam standup harian atau beberapa aspek lincah sehari-hari lainnya. Agile, dari perspektif pelanggan, adalah tentang komunikasi. Itu tidak berarti mereka berkomunikasi dengan para insinyur tentang detail implementasi.

Pelanggan berkolaborasi dengan pemilik produk untuk mendapatkan dan memberikan umpan balik yang konstan. Topiknya adalah fitur, tetapi bukan bagaimana implementasinya. Apakah Anda memberikan fitur yang tepat? Apakah Anda sesuai jadwal? Apakah mereka memiliki persyaratan yang berubah yang perlu Anda adaptasi?

Agile membantu Anda dan pelanggan Anda menjawab pertanyaan-pertanyaan itu.

— Bryan Oakley
sumber