Bagaimana menjawab "Kapan itu akan dilakukan?"

Kita semua memilikinya, masalah yang terbukti sulit untuk diperbaiki dan diperbaiki melalui kode yang tidak jelas dan fungsi yang tidak terduga yang aneh. Perlahan, secara logis kerjakan jalan Anda dengan mencoba menemukan pola, kesalahan, kesalahan. Proses ini membutuhkan waktu dan masalah seringkali tidak mudah dipahami oleh klien.

Bagaimana seseorang menjawab ketika ditanya pertanyaan "Kapan itu akan dilakukan?", Terutama ketika klien mungkin tidak memahami kompleksitas yang melekat dari pengembangan perangkat lunak?

Anda menjawab pertanyaan dengan jujur.

Anda memberi tahu mereka bahwa ini adalah masalah yang sulit, solusinya tidak jelas, dan Anda tidak yakin berapa lama untuk menyelesaikannya. Berjanji untuk memperbarui mereka pada kemajuan Anda setiap [jangka waktu], sehingga mereka tahu Anda sedang mengusahakannya, dan tentu saja, benar-benar mengirimi mereka pembaruan.

Pengembang mendekati masalah yang kompleks dengan menguraikannya menjadi yang lebih kecil dan menyelesaikannya secara terpisah.

Dalam dunia yang ideal , menyelesaikan masalah akan menjadi masalah yang kompleks A dan Anda akan dapat, dalam waktu tertentu, untuk menguraikannya menjadi daftar pendek masalah kecil A ₁ hingga A _n , untuk setiap evaluasi waktu adalah langsung, mengingat bahwa waktu yang diperlukan untuk menyelesaikan masalah kompleks awal adalah:

dengan D menjadi proses dekomposisi itu sendiri.

Di dunia nyata , satu-satunya masalah adalah bahwa t ( D ) akan benar-benar lebih besar daripada waktu yang Anda habiskan untuk menyelesaikan masalah kecil. Dengan kata lain, untuk mencapai tingkat penguraian masalah ini, Anda secara praktis perlu menyelesaikan masalah itu sendiri.

Kamu masih bisa:

• Pisahkan tugas yang diberikan (memecahkan masalah) menjadi potongan-potongan kecil, masing-masing potongan masih menjadi masalah yang kompleks,

• Mengevaluasi waktu yang diharapkan untuk setiap potongan dan risiko yang sesuai.

  Misalnya, tugas 1 membutuhkan sekitar. 5 jam, tetapi risiko untuk diblokir melakukannya adalah tinggi, jadi berikan 12 jam sesuai harapan Anda kepada pelanggan.

• Mengevaluasi dependensi dan bagaimana mereka mempengaruhi waktu.

  Misalnya, tugas 19 membutuhkan 2 jam, dan risikonya sangat rendah sehingga Anda dapat mengatakan itu 2 jam pasti. Bukan 1. Bukan 3. Tetapi tugas 19 bergantung pada tugas 24: tugas 24 dapat memengaruhi tugas 19 dengan cara yang Anda perlukan untuk sepenuhnya menulis ulang kode tugas 19 menggunakan pendekatan yang berbeda.

• Berikan semua detail itu kepada pelanggan Anda. Jangan berikan jumlahnya.

Poin terakhir itu penting. Jika Anda memberikan jumlah, katakanlah 192 jam, pelanggan percaya bahwa itu adalah metrik yang sangat tepat, dan waktu yang akan Anda habiskan adalah, katakanlah, 189 hingga 195 jam.

Sebaliknya, jika Anda memberikan detailnya,

• Pelanggan yang peduli akan mengerti bahwa ini bukan 192 jam. Ini 192 jam jika semuanya beres mengingat risiko ditentukan selama penilaian. Ini juga 238 jam jika semuanya berjalan lebih buruk. Ini juga 85 jam jika semuanya baik-baik saja.

• Adapun pelanggan yang tidak peduli, dia tidak akan membaca jawaban Anda dalam semua kasus. Yang dia inginkan hanyalah angka, untuk bisa menyalahkanmu nanti. Dengan memberikan jawaban yang sangat terperinci yang tidak akan pernah ia baca, Anda tahu bahwa ia tidak dapat meminta waktu yang diperlukan untuk itu lagi: Anda sudah menjawabnya. Dia juga tidak bisa menyalahkan Anda nanti, karena dia tidak membaca jawaban untuk menghitung jumlahnya.

Apa pun yang Anda perkirakan jangan lupa menyertakan hukum Hofstadter : Selalu dibutuhkan waktu lebih lama dari yang Anda harapkan, bahkan ketika Anda memperhitungkan hukum Hofstadter.

Biasanya saya menggunakan formula yang dimodifikasi dari CPM / PERT. Ini sesuatu seperti ini:

Mn + Mx + C(T) / 2 + C, where
Mn is the minimum number of hours you think it will take,
Mx is the maximum number of hours you think it will take,
T is the typical number of hours it takes,
and C is a confidence factor from 1 - 3 based on how much you've done similar things.

(Saya tidak yakin bagaimana melakukan semua format matematika mewah; jika seseorang ingin mengedit ini untuk itu, maka merasa bebas.)

So, if you think:
Mn = 60  hours
Mx = 180 hours
T  = 100 hours
C  = 2
Then: 60 + 180 + 2(100) / 4 = 110 hours.

Saya menekankan bahwa ini bisa sangat bervariasi, tergantung pada bagaimana proyek berjalan. Jika Anda mengevaluasi kembali proyek Anda setiap beberapa hari, Anda bahkan dapat menyediakan pembaruan mingguan. Ini sangat membantu memuaskan klien yang kesal. :)

Menjelaskan garis waktu yang tidak jelas kepada pengguna non teknis itu sulit. Ini benar baik dalam fase kreatif proyek, dan ketika melacak bug sial. Dalam kedua kasus tradisional "menguraikan pekerjaan menjadi potongan-potongan kecil" tidak berfungsi juga.

Tugas awal berfokus pada kasus yang terakhir jadi mari kita membahasnya. Jika Anda tidak dapat memberikan garis waktu, beri tahu pengguna apa yang akan Anda coba dan kapan Anda akan kembali kepada mereka. Ketika Anda mencapai titik tengah pada timeline yang diberlakukan sendiri, berikan pembaruan email yang singkat dan jujur. Setidaknya satu jam sebelum batas waktu memberikan tanggapan resmi Anda. Sekarang Anda memiliki kredibilitas. Jika masalah tidak terpecahkan setidaknya Anda menyinari. Ini mungkin tampak seperti buang-buang waktu, tetapi tidak.

Karena Anda tidak dapat menjelaskan penghalang jalan yang tidak diketahui dan kejutan yang tidak terduga, mungkin sulit untuk memperkirakan dengan percaya diri. Ide ide:

• Coba rentang - "Saya yakin itu akan memakan waktu setidaknya N hari (misal 3), tetapi mungkin perlu sebanyak 4N."
• Mencari dukungan dari lebih banyak insinyur senior dalam memperkirakan & mempertahankan perkiraan.
• Bekerja dalam iterasi yang lebih pendek (gaya Agile / Scrum) untuk menghasilkan kode minimum yang menambah nilai bisnis (mendapatkan kepercayaan & kepercayaan), kemudian ulangi.
• Pelajari keterampilan negosiasi dari buku seperti klasik Getting to Yes (http://www.amazon.com/gp/aw/d/0143118757).

Untuk pengembangan baru, khususnya pengembangan Agile:

"Kesempurnaan tercapai, bukan ketika tidak ada lagi yang bisa ditambahkan, tetapi ketika tidak ada lagi yang tersisa untuk diambil." - Antoine de Saint-Exuper

Jika Anda memperkirakan upaya dan waktu untuk memperbaiki beberapa yang hampir tidak mungkin untuk mereproduksi kesalahan (s) dalam sistem yang terlalu rumit dengan sangat sedikit atau tidak ada pengembang dengan pengetahuan domain intim dari sistem maka satu-satunya jawaban yang benar adalah "Ketika itu diperbaiki."

Biasanya, saya hanya akan mengatakan yang sebenarnya kepada mereka. Saya akan memberi tahu mereka bahwa saya tidak tahu sekarang, dan saya mungkin memiliki wawasan yang lebih baik dalam seminggu. Saya kemudian akan memberi mereka taman bola dengan banyak coretan di depannya yang dapat Anda muat di atas kertas untuk menunjukkan bahwa itu adalah dugaan berdasarkan perasaan. Jika mereka mulai menyulitkan Anda, mulailah setiap kalimat dengan "Itu mungkin ..." Biasanya semua orang yang saya lakukan senang dengan "Periksa kembali dalam seminggu atau lebih, tapi sekarang yang bisa saya katakan adalah sekitar 2 bulan" atau semacam itu.

Proses Perangkat Lunak Pribadi (PSP) berfokus pada peningkatan perkiraan. Ini dicapai dengan pendataan tugas yang disiplin. Ini, pada dasarnya agak "mempercepat" bagian "pengalaman" memperkirakan karena Anda akan memiliki data aktual tentang tugas-tugas khas. Tentu saja, profesi ini masih membutuhkan solusi unik untuk banyak masalah, tetapi menurut pengalaman saya, perkiraan lebih baik setelah menggunakan PSP.