Dapatkah staf non-teknis memenuhi persyaratan atas nama tim pengembangan?


8

Bekerja di organisasi besar, sering kali anggota tim pengembangan tidak bisa mendapatkan akses langsung ke klien untuk mengumpulkan persyaratan. Apakah mungkin / disarankan untuk memberikan daftar pertanyaan kepada manajer akun sehingga mereka dapat memenuhi persyaratan atas nama Anda?

Jawaban:


5
  • Kemungkinan: ya :-)

  • Disarankan: hanya jika benar-benar tidak ada cara lain. Ini akan dengan mudah menghasilkan persyaratan yang sangat rapuh dan kurang dipahami. Dan masalah hanya dapat muncul pada tahap selanjutnya, selama implementasi atau pengujian penerimaan.

Pengumpulan persyaratan idealnya harus berupa serangkaian diskusi terperinci antara klien dan pengembang.Klien biasanya memiliki ide-ide yang sangat samar tentang apa yang sebenarnya mereka inginkan, sehingga menerapkan deklarasi samar pertama mereka seperti yang hampir pasti akan menimbulkan masalah. Jadi pengembang harus dapat memberi tahu harga setiap ide / cerita / persyaratan, yang membantu klien memprioritaskan kebutuhan mereka, dan memberikan umpan balik teknis tentang apa yang mungkin dan layak. Juga, mereka harus memahami domain masalah sedalam yang diperlukan, untuk memberikan solusi teknis terbaik untuk masalah klien. Dan sepanjang jalan, mereka harus memastikan bahwa mereka memahami klien dengan benar, yang berarti sering meminta kembali untuk klarifikasi dan mengulangi apa yang mereka mengerti dengan kata-kata mereka sendiri selama sesi komunikasi (dan sering memberikan prototipe UI / maket ide-ide klien).Media terbaik untuk ini adalah komunikasi lisan - jika tidak memungkinkan secara langsung, konferensi video atau telepon adalah pilihan terbaik berikutnya.

Memiliki orang yang tidak teknis sebagai saluran komunikasi antara klien dan pengembang sangat membatasi efisiensi komunikasi. Bahkan mengirim dokumen bolak-balik melalui email akan lebih baik, di mana setidaknya tidak ada perantara, jadi ada satu kemungkinan yang kurang untuk kesalahpahaman.


Saya setuju dengan Anda, tetapi mengapa tidak ada proksi antara pengembang dan bisnis. Saya pengalaman saya di proyek-proyek perusahaan besar menyentuh banyak sistem (dengan kemungkinan tim pengembangan berbeda di lokasi berbeda), penyimpanan dan pelaporan data, infrastruktur, dan bahkan perubahan pada proses bisnis itu sendiri. Anda membutuhkan seseorang untuk mengurus semua ini.
softveda

3
@Ratik, itu disebut analis bisnis (BA) di beberapa toko. BA dalam beberapa kasus memang berguna (kami juga memilikinya dengan proyek kami saat ini). Namun, BA yang baik (IMHO) jauh dari manajer akun: dia tahu banyak tentang domain masalah, dan (walaupun tidak harus pada tingkat teknis yang dalam) tentang aplikasi juga.
Péter Török

Proksi antara pengembang dan bisnis dapat berfungsi, tetapi hanya jika proxy tersebut terlatih dan berpengetahuan cukup untuk mengetahui apa yang harus ditanyakan. Mengandalkan seseorang yang hanya tahu kebutuhan pelanggan adalah resep kegagalan jika mereka tidak tahu bagaimana menerjemahkan kebutuhan itu ke dalam spesifikasi teknis yang mencapai tingkat detail yang diperlukan untuk pengembangan.
Beofett

Sebagai Analis Bisnis, saya harus sepenuhnya tidak setuju dengan Anda bahwa orang yang tidak teknis yang bertindak sebagai saluran komunikasi sangat membatasi efisiensi. Di bagian khusus saya dalam industri TI (kontrak pemerintah), saya menghabiskan banyak waktu untuk mencoba memahami dengan tepat bagaimana pelanggan kami bekerja, bagaimana mereka ingin dapat bekerja, dan apa yang mereka anggap penting. Insinyur perangkat lunak kami TIDAK memiliki waktu atau kecenderungan (atau, biasanya keterampilan sosial) yang diperlukan untuk mengungkap aspek Bizantium dari proses bisnis pelanggan kami. Saya tahu banyak tentang pengguna, dan banyak tentang aplikasi
JBiggs

5

Meskipun saya setuju dengan Péter Török bahwa perantara dapat membatasi efisiensi, melakukan pembicaraan non-pengembang dengan pengguna akhir dapat meningkatkan efektivitas komunikasi.

Saya telah menemukan bahwa pengembang dan pengguna akhir sering kali dapat berbicara bersama tetapi masih salah paham satu sama lain karena mereka berasal dari "dunia yang berbeda." Sambil mengucapkan kata-kata yang sama, mereka mungkin memahaminya dengan makna hal-hal yang sama sekali berbeda ... Seorang perantara yang memahami baik pengguna akhir maupun pola pikir / bahasa pengembang, dapat sebanding dengan bobot mereka dalam emas yang meningkatkan saling pengertian tentang apa yang dibutuhkan / apa yang akan dikembangkan.

Yang sedang berkata, bertanya kepada manajer, apakah itu manajer akun atau jenis manajer lainnya, bukanlah cara yang tepat. Menjembatani kesenjangan antara dunia pengembang dan pengguna akhir adalah keterampilan dan bukan sesuatu yang Anda lakukan "sebagai tambahan."


Saya sepenuhnya setuju bahwa pengembang harus memahami domain masalah untuk memberikan solusi nyata, dan memperluas jawaban saya di sepanjang baris ini saat Anda menulis milik Anda :-)
Péter Török

@ Péter: ya, menjawab di StackOverflow seperti orang berbicara secara bersamaan. Anda hanya mendengar apa yang dikatakan orang lain setelah mereka mengatakannya dan Anda telah berhenti berbicara (menjawab) sendiri (atau memuat jawaban baru). Akan menyenangkan untuk mendapatkan indikasi bahwa seseorang sedang mengetik, seperti yang Anda lakukan dalam sesi obrolan, tapi saya kira itu akan meminta terlalu banyak dari server StackOverflow ... :-)
Marjan Venema

Saya setuju. Sebagai seorang analis bisnis, saya harus menjadi penghubung antara insinyur perangkat lunak yang tahu sedikit tentang bagaimana pelanggan berpikir dan bekerja dan pelanggan, yang tahu sedikit tentang bagaimana perangkat lunak dikembangkan. Saya telah mendengar dari kedua belah pihak bahwa orang yang melakukan apa yang saya lakukan sangat berharga untuk komunikasi. Saya dapat mengingat beberapa kali ketika saya bisa mewakili pelanggan selama sesi perencanaan yang berjalan di jalur keren teknologi-sentris dengan mengatakan sesuatu di sepanjang baris "itu hebat, tapi itu bukan cara yang ingin mereka gunakan ini. Mereka harus dapat melihat ... "
JBiggs

2

Singkatnya, cara kerja ini penuh dengan bahaya dan merupakan salah satu alasan lahirnya Manifesto Agile .

{upaya buruk humor} Memohon, meminjam, melawan, menipu, mencuri, pesona, bawa ke pub, melakukan apa pun yang Anda bisa untuk benar-benar terlibat dengan pengguna akhir {/ upaya buruk humor}

Tapi serius, jika Anda tidak bisa mendapatkan akses maka setidaknya pastikan ada siklus umpan balik yang cepat. Jadi ya Anda dapat mengajukan pertanyaan melalui manajer akun (jika Anda dapat mengakses klien secara langsung, bahkan jika dari jarak jauh melalui email yang masih lebih baik), tetapi tanyakan setiap hari dan berikan prototipe sesering mungkin bagi klien untuk dicoba.

Kalau tidak, Anda memiliki risiko besar mengirimkan sesuatu yang sebenarnya tidak diinginkan klien akhir.


2

Saya bekerja di organisasi ukuran sedang-besar dan kami memiliki tim solusi bisnis yang memiliki banyak analis bisnis. Mereka melakukan pekerjaan penting karena mereka memahami proses bisnis dengan sangat baik dan menerjemahkan apa yang diinginkan bisnis ke apa yang dipahami pengembang. Ini bekerja dengan cara lain juga. Jika saya mendeteksi beberapa masalah desain dan / atau arsitektur atau mengusulkan cara alternatif untuk menyelesaikan masalah saya berbicara dengan mereka dan mereka pada gilirannya akan berbisnis.

Dalam bisnis besar ada banyak hal yang perlu dipertimbangkan selain hal teknis ketika melakukan suatu persyaratan. Seperti masalah pelatihan staf, seperti tidak memengaruhi pelanggan dengan perubahan, seperti proses kompensasi yang ada untuk menjadikan pertanyaan Anda tidak menjadi masalah, atau "John" adalah pemasaran menggunakan fungsi ini dan Anda tidak bisa hanya mengubahnya, dll.

Untuk menjawab pertanyaan Anda jika Anda memiliki struktur, gunakan itu. Beri mereka daftar pertanyaan untuk ditindaklanjuti dengan manajer akun bisnis.


1

Anda sedang bermain persyaratan mengumpulkan versi permainan telepon. Paling-paling, ini akan menyebabkan banyak inefisiensi komunikasi. Paling buruk, itu akan menyebabkan persyaratan yang dikumpulkan tidak benar. Pentingnya putaran umpan balik ini dan efisiensinya adalah salah satu alasan utama mengapa Perwakilan Pelanggan adalah salah satu peran paling berharga (dan paling sulit untuk diukur) dalam tim Agile.


0

TIDAK

Menjawab pertanyaan Anda secara harfiah, jawabannya tidak bisa lain dari kata "TIDAK! TIDAK! RIBU DAN DUA PULUH EMPAT KALI TIDAK!" kecuali "Manajer Akun" juga merupakan konsultan, analis, dan pengembang yang terlatih

Jika harus ada perantara yang tidak terlatih dalam proses ini, Anda lebih baik mengirimkan survei pengguna melalui email dan hanya CC'ing manajer akun. Ia tidak mungkin dapat menambah nilai pada proses, tetapi tentu saja dapat memutarbalikkan komunikasi.

Peran yang tepat untuk Manajer Akun dalam proses ini adalah untuk berpartisipasi dalam percakapan sebagai pemangku kepentingan , bukan sebagai middleware atau analis amatir.


+1, harus setuju. Ini sering terjadi, tetapi saya belum pernah melihatnya berhasil.
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.