it-swarm-id.com

Berurusan dengan spesifikasi yang buruk / tidak lengkap / tidak jelas?

Saya sedang mengerjakan proyek di mana tim pengembang kami mendapatkan spesifikasi dari bagian bisnis perusahaan. Baik manajemen bisnis dan manajemen TI memerlukan perkiraan dan proyeksi tenggat waktu, sebagaimana mestinya.

Hal yang baik adalah bahwa estimasi sebagian besar dibuat oleh pengembang aktual yang dapat melakukan fitur yang diperlukan. Yang buruk adalah bahwa spesifikasi biasanya terlalu sederhana (ternyata Anda ditinggalkan dengan banyak tanda tanya di kepala Anda karena banyak informasi yang tampaknya hilang) atau terlalu rumit (sampai pada titik Anda dapat bahkan memvisualisasikan di mana semuanya akan "cocok" di app). Lebih sering daripada tidak, bagian bisnis dari spesifikasi tidak lengkap atau tidak menyadari apa yang dapat dan tidak dapat dilakukan (mengingat logika bisnis yang diterapkan sebelumnya).

Tim pengembang diberikan sekitar satu hari per spec baru untuk memberikan estimasi dan kami mencoba untuk menghapus ketidakpastian, biasanya dengan bertemu dengan siapa pun yang melakukan spec. Sebagian besar waktu ternyata penulis spec tidak benar-benar memikirkan semuanya, dan biasanya hanya ketika kita mulai merancang dan mengembangkan kita berakhir dalam masalah, karena banyak spek tampaknya memiliki lubang.

Bagaimana Anda menangani ini? Apakah Anda murah hati dengan perkiraan sebelumnya?

44
eagerMoose

Jika Anda menemukan masalah selama tahap desain, apakah Anda benar-benar memiliki masalah?

Pastikan mereka yang membuat spesifikasi tidak merasa harus melakukan semuanya di muka. Mereka tidak bisa memikirkan segalanya dan kita juga tidak. Mereka juga perlu tahu bahwa mereka tidak bisa hanya melakukan all-nighter pada beberapa dokumen spesifikasi dan kemudian dilakukan dengan proyek. Praktek ini juga mengarah pada mereka menambahkan setiap hal kecil yang mungkin dapat mereka pikirkan karena mereka 'mungkin' membutuhkannya dan jika mereka tidak bertanya sekarang, mereka akan pernah mendapatkannya. Mereka harus tersedia untuk meninjau, menguji, dan menyetujui persyaratan mereka berulang kali.

Jangan mencoba mendesain atau membangun seluruh aplikasi sekaligus. Setiap proyek/aplikasi dapat dipecah menjadi beberapa fase, bagian, modul atau apa pun yang mereka inginkan. Anda tidak harus gesit jika itu bukan urusan Anda. Mulailah dengan bagian Keamanan Pengguna dan pergi dari sana.

Luangkan waktu untuk duduk bersama orang-orang ini dan mencari tahu apa yang sebenarnya mereka inginkan. Saya ingin seseorang memberikan saya spesifikasi yang memungkinkan saya untuk membuat seluruh proyek sekaligus, tetapi apa yang akan saya lakukan untuk satu setengah tahun ke depan?

13
JeffO

Saya menggunakan Cone of Ketidakpastian Katakan dengan suara ledakan keras

Pada dasarnya Anda melakukan estimasi terbaik yang dapat Anda berikan informasi yang Anda miliki.
Tetapi Anda juga menunjukkan bahwa dengan memberikan ketidakjelasan dalam spesifikasi bahwa ada ketidakpastian yang tinggi pada perkiraan ini (Manajemen poin di situs sehingga mereka dapat membaca pada prinsipnya).

Saat Anda maju menuju target dan memperketat spesifikasi, Anda dapat memperbarui perkiraan dan memperketat ketidakpastian.

20
Martin York

Ya, saya murah hati pada perkiraan. Jangan lupa hukum Hofstadter

Hukum Hofstadter: Selalu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan Hukum Hofstadter. Dari Gödel, Escher, Bach: An Eternal Golden Braid.

9
Brian Carlton

Proses yang Anda gambarkan sebenarnya cukup normal. Masalahnya adalah bahwa jenis bisnis cenderung memikirkan hal-hal dalam hal "fase persyaratan", kemudian "fase desain", dll. Ketika tim menciptakan produk, Anda benar-benar membutuhkan pendekatan berulang. Beberapa ide yang saya temukan berhasil adalah:

  • Tetapkan tujuan utama untuk perubahan yang diusulkan/aplikasi baru. Ini terkait dengan bisnis sasaran seperti "mengurangi biaya pemrosesan klaim sebesar 10%" atau "bagikan penelitian pasar dari kantor satelit kami sehingga produk lebih baik memenuhi kebutuhan klien kami". Ini membantu untuk membawa fokus ke persyaratan terbuka pada apa kebutuhan sebenarnya.
  • Lakukan Swag awal Anda (Seriously Wild-A ** Guess) untuk persyaratan yang buruk seperti yang tertulis, tetapi mendokumentasikan apa Anda diasumsikan implementasi akan. Ini adalah umpan balik yang perlu ditingkatkan oleh orang-orang bisnis (dan klien Anda) dan pikirkan hal-hal ini. Mereka mengandalkan Anda untuk mereka.
  • Jika Anda memiliki pilihan antara perkiraan yang sangat panjang dan yang sangat pendek, selalu berjalan lama. Kemungkinan akan mengejutkan siapa pun yang meminta Anda untuk melakukan pekerjaan, yang merupakan hal yang baik. Ini akan memaksa kalian berdua untuk mendiskusikan apa yang sebenarnya mereka cari.

Ingat perkiraan pertama Anda tidak dapat akurat. Dasarkan estimasi Anda pada interpretasi yang masuk akal dari persyaratan yang Anda dapatkan, dan dokumentasikan asumsi/interpretasi Anda. Akan ada lebih banyak persyaratan yang diturunkan karena lubang yang Anda temukan. Ini normal.

6
Berin Loritsch

Bersikap murah hati pada perkiraan mungkin terdengar bagus, tetapi masalah apa yang dipecahkan? Itu tidak akan membuat spec lebih baik, itu tidak akan membuat perencanaan lebih mudah. Itu mengatakan 'tidak mungkin jauh lebih buruk daripada X', sebagai lawan dari mengatakan 'itu mungkin Y'. Yang benar adalah kamu tidak tahu. Cari tahu apa yang Anda bisa.

Jika analis bisnis perlu melibatkan pengembang lebih awal, beri tahu mereka. Laporan tertulis sebenarnya bukan metode komunikasi terbaik. Jika Anda dapat meminta bantuan pengembang dengan pengumpulan persyaratan awal, dan analis bisnis membantu pengembangan dan pengujian, hasil Anda akan lebih baik.

Saya baru saja membaca Cone of Ketidakpastian; itu barang bagus, tapi mudah salah. Manajemen dapat melihat gambar pertama dan berkata: 'ok, kami memiliki persyaratan bisnis, jadi perkiraan Anda harus akurat 50% sesuai dengan kerucut Anda. Katakan padaku'. Itu tidak akan membantu.

Analogi mobil: seseorang bertanya berapa harga mobil, dan memberi Anda kertas dengan persyaratannya. Koran itu mengatakan beratnya sekitar 1.200 kg, memiliki empat roda dan setidaknya dua pintu, tapi mungkin empat, harus memuat empat orang, dan lampu depan yang baik sangat penting. Warna harus abu-abu (tetapi apakah hitam juga mungkin?).

Anda bisa mengatakan $ 25K, dan jika ternyata nanti dia ingin Range Rover baru Anda kacau. Itu tidak membuatnya lebih benar, atau lebih berguna untuk mengatakan harganya $ 100K. Dia mungkin hanya membutuhkan Prius (maaf, yang dimiliki) sebelumnya. Jika Anda tidak punya waktu untuk mencari tahu, Anda tidak akan pernah tahu.

3
Jaap

Sebagian besar waktu ternyata penulis spec tidak benar-benar memikirkan semuanya, dan biasanya hanya ketika kita mulai merancang dan mengembangkan kita berakhir dalam masalah, karena banyak spek tampaknya memiliki lubang.

Penggunaan kebanyakan salah.

Tidak mungkin bagi penulis spec untuk berpikir semuanya sampai. Titik. Jika mereka berpikir semuanya melalui, mereka akan tahu berapa banyak baris kode untuk ditulis dan baris kode mana yang benar.

Karena spek pasti salah, tidak banyak yang dapat Anda lakukan tentang itu.

berakhir dalam masalah adalah masalahnya.

Baik manajemen bisnis dan manajemen TI memerlukan perkiraan dan proyeksi tenggat waktu, sebagaimana mestinya.

Mungkin tidak. Taksiran dan tenggat waktu keseluruhan bukanlah hal yang paling berguna.

Oleh karena itu pengembangan metode Agile.

Intinya adalah ini. Semua perkiraan berdasarkan spesifikasi harus memiliki kesalahan. Mereka hanya benar karena keberuntungan. Separuh waktu, perkiraannya jauh di bawah dan separuh waktu perkiraannya berakhir. Ini adalah konsekuensi logis dari upaya untuk memprediksi masa depan dengan informasi yang tidak lengkap.

Karena itu harus terjadi, Anda seharusnya tidak berakhir dalam kesulitan ketika Anda salah. Anda pasti salah. Dan Anda harus salah secara konsisten dan acak. Kalau tidak, Anda menipu angka-angka.

2
S.Lott

Anda harus menjelaskan manajemen bahwa dengan spesifikasi yang tidak jelas ada tingkat kepercayaan yang rendah terhadap estimasi tersebut. mis. Anda memperkirakan dapat bervariasi 30% atau 40% atau 50% atau apa pun yang Anda pikirkan. Jadi jika sesuatu diperkirakan 2 hari itu sebenarnya berkisar 2-3 hari.
Lalu buat register masalah proyek (bisa di wiki atau Jira dll). Buat semua pertanyaan Anda sebagai masalah dan usahakan bisnis menjawab pertanyaan Anda. Selama masalah masih belum terselesaikan estimasi masih belum pasti. Jika memungkinkan, dapatkan analis bisnis untuk memfasilitasi ini dan membuat persyaratan yang lebih baik. Mintalah tim pengujian Anda untuk meninjau spesifikasi karena mereka harus membuat kasus uji terhadap spesifikasi. Seringkali keterlibatan mereka dapat menyebabkan penulisan spesifikasi yang lebih baik. Laporkan setiap hari/setiap minggu ke manajemen, berapa banyak masalah yang belum Anda selesaikan. Semakin banyak diselesaikan, semakin baik perkiraan Anda. Selalu sajikan metrik kepada manajemen karena angka membuat mereka berpikir secara objektif dan menempatkan Anda pada posisi yang kuat juga.
Juga tergantung pada ukuran proyek yang diberikan 1-4 minggu untuk tahap desain solusi di mana Anda membahas masalah utama (baik persyaratan maupun teknis). Adakan banyak lokakarya dengan UKM bisnis dan cobalah untuk memahaminya dan pada gilirannya jelaskan pandangan Anda untuk sampai pada kesimpulan. Hanya setelah kasus penggunaan utama telah dipahami dan perkiraan Anda mencapai sekitar 80% kepercayaan Anda harus melanjutkan ke tahap membangun.

1
softveda

Komunikasi biasanya membantu, setidaknya dalam organisasi yang sehat.

Ini bukan peluru perak, tetapi apa yang saya coba lakukan (dan itu berhasil di perusahaan kami) adalah meyakinkan para pebisnis untuk menjelaskan masalahnya, daripada menyarankan solusi langsung. Jadi permintaan fitur kami mulai dengan deskripsi masalah atau tujuan yang ingin mereka capai.

Kemudian seorang pengembang dengan beberapa pengetahuan domain mencoba menyempurnakan solusi, sambil berkonsultasi dengan seseorang di sisi bisnis. Biasanya proses ini menghasilkan beberapa solusi alternatif, lengkap dengan perkiraan.

Terserah bisnis pada saat ini untuk memilih satu berdasarkan biaya dan seberapa lengkap solusinya. Ini juga bagaimana Anda mungkin dapat menjual metode ini kepada mereka, bahwa di sini mereka memiliki opsi, bukan hanya sejumlah manday, ambil atau tinggalkan. Tentu saja, itu juga membutuhkan lebih banyak sumber daya di pihak mereka tetapi jika Anda memiliki masalah dengan perkiraan dan spesifikasi, itu adalah investasi yang sepadan.

0
biziclop

Mengapa Anda menerima spesifikasi persyaratan yang tidak lengkap, berisi persyaratan yang saling bertentangan, atau tidak layak? Saya akan merekomendasikan bahwa proses Anda menyertakan cara bagi Anda untuk mengevaluasi spesifikasi dan mengirimkannya kembali untuk koreksi sebelum Anda menerimanya dan memberikan perkiraan apa pun.

0
oosterwal

Yakinkan manajemen/pelanggan bahwa layak berinvestasi dalam spesifikasi yang lebih baik. Coba membuat orang-orang dengan pengetahuan domain lebih terlibat. Pada akhirnya semua orang akan mendapat untung darinya.

0
FabianB

Hilangkan spesifikasi.

Meyakinkan bisnis untuk mencoba Agile (atau setidaknya proses Agile-ish) untuk sebuah proyek.

Alih-alih menuliskan spesifikasi

  • bertemu dengan orang-orang bisnis untuk mengidentifikasi fitur
  • bekerja bersama mereka untuk mengidentifikasi set minimal fitur/fungsi yang akan berguna (bahkan jika hanya untuk rilis internal)
  • kartu kerja
  • atur tanggal untuk pekerjaan (semakin sedikit fitur/pekerjaan semakin mudah untuk memperkirakan tanggal secara akurat).
  • bekerja dengan bisnis untuk memprioritaskan pekerjaan, pastikan mereka memiliki kemampuan untuk mengubah pikiran mereka tentang pesanan kartu, memberi tahu mereka bagaimana itu mempengaruhi tanggal
  • dengan setiap fitur selesai memiliki sistem kerja untuk menunjukkannya, dan minta mereka keluar pada setiap bagian pekerjaan setelah selesai
  • melepaskan
  • bilasan
  • ulang

Menampilkan fitur saat selesai. Lepaskan lebih awal dan sering. Bersikap transparan dan responsif. Saya telah menemukan ini akan mengarah pada penghapusan tenggat waktu yang tidak berguna.

Edit untuk arsitektur

Siapa pun yang memimpin harus mengadakan pertemuan untuk berkomunikasi dengan para devs tentang arsitekturnya. Memimpin juga benar-benar orang yang harus karena ketekunan untuk memastikan semua kebutuhan terpenuhi.

Jika Anda membutuhkan langkah-langkah tambahan dalam proses Anda daripada menambahkannya. Ada proses untuk memfasilitasi kemampuan tim untuk menyelesaikan pekerjaan. Jika sesuatu tentang tidak berfungsi mengubahnya. Tambahkan ke dalamnya, hapus dari sana, ubah untuk memenuhi Anda kebutuhan. Jika Anda perlu khawatir tentang keamanan tambahkan langkah-langkah untuk itu.

0
dietbuddha

Ingat, setiap kali spesifikasi diubah untuk menambah fungsionalitas baru atau menjernihkan pertanyaan, maka sekarang saatnya untuk meninjau kembali perkiraan tersebut. Ini tidak terlalu banyak sehingga perkiraan awal kami buruk mengingat apa yang kami katakan tetapi bahwa kami tidak menekan balik dan mengatakan tidak, kami membutuhkan ini ketika lebih banyak detail tersedia. Jika saya seorang kontraktor yang membangun rumah dan saya memperkirakan biayanya berdasarkan penggunaan meja lamiante dan sebulan kemudian klien menginginkan granit, Anda bisa bertaruh saya akan meninjau kembali perkiraan biaya dengannya. Kami membiarkan klien kami lolos dengan persyaratan yang buruk dan kemudian tidak mendorong kembali ketika ternyata ada banyak hal yang harus dilakukan daripada yang dibayangkan semula.

0
HLGEM