Bagaimana saya harus menggambarkan proses belajar kode orang lain? (Dalam situasi faktur.) [Ditutup]

Sunting: Justin Cave menyatakan dengan baik bahwa komunikasi semacam ini harus ada di depan dalam kutipan / perkiraan saya. Apakah ini kasus, saya masih tertarik untuk mengetahui jenis bahasa apa yang digunakan orang untuk menggambarkan kegiatan 'belajar kode yang ada'. Terutama untuk perusahaan yang belum pernah berurusan dengan kontraktor perangkat lunak sebelumnya. Akhiri edit

Saya memiliki kontrak untuk memutakhirkan beberapa perangkat lunak internal untuk perusahaan besar. Perusahaan telah meminta beberapa penambahan fitur dan beberapa perbaikan bug. Ini adalah pekerjaan gaya freelance pertama saya.

Pertama, saya harus terbiasa dengan cara kerja aplikasi - saya mempelajarinya seolah-olah saya adalah pengguna.

Selanjutnya, saya harus belajar bagaimana perangkat lunak itu bekerja. Saya mulai dengan konsep yang luas, dan kemudian mempersempit ke detail yang diperlukan sebelum mengerjakan setiap perbaikan bug dan fitur.

Setidaknya pada awal proyek, saya perlu waktu lebih lama untuk mempelajari kode yang ada daripada menulis fitur tambahan.

Bagaimana saya bisa menggambarkan proses mempelajari kode yang ada pada faktur? (Bagian dari perusahaan ini biasanya melakukan hal-hal di rumah, jadi tidak memiliki banyak pengalaman berurusan dengan kontraktor perangkat lunak seperti saya, dan saya khawatir mereka mungkin tidak memahami overhead mempelajari kode orang lain). Saya tidak ingin hanya menyematkan waktu belajar ke peningkatan fitur yang sebenarnya, karena dalam beberapa kasus ini akan membuat 'tugas sederhana' terlihat seperti itu terlalu lama. Saya ingin memecah faktur menjadi langkah-langkah yang relevan, dan mengomunikasikan bahwa saya membebankan biaya besar untuk mempelajari kode orang lain sebelum dapat menambahkan saya sendiri ke dalamnya.

Apakah ada cara standar untuk menggambarkan aktivitas semacam ini saat menagih pekerjaan?

Saya akan menagih tugas-tugas seperti "Tinjau fungsi yang ada" dan / atau "Tinjau kode yang ada". Bergantung pada kerumitan fitur-fitur baru saya akan menambahkan tugas "Desain xxx" yang akan mencakup waktu yang saya habiskan mencari tahu poin integrasi ke dalam kode yang ada.

Saya pikir itu adalah ide yang baik untuk menjelaskan kepada pelanggan bahwa ada beberapa biaya tambahan dalam membawa konsultan baru - dan bahwa, jika mereka senang dengan hasilnya, melanjutkan bekerja dengan konsultan yang sama kemungkinan akan menyelamatkan mereka. uang.

Diagnosis Masalah.

Ini adalah istilah yang umum, jika Anda pernah memperbaiki mobil Anda atau pergi ke dokter, diagnosis adalah istilah umum untuk mencari tahu apa yang salah. Ini juga akurat, Anda harus pergi di bawah tenda dan melihat bagaimana semuanya terhubung untuk mencari tahu apa yang tidak berfungsi. Ini benar-benar mirip dengan bekerja pada mesin tanpa manual, dan perusahaan pergi dan membuat mesin tanpa melihat mesin lain sebelumnya (jadi sepertinya unik).

Item baris bertele-tele atau aneh akan mendapatkan lebih banyak pertanyaan yang sebenarnya tidak Anda inginkan. "Diagnosis masalah" adalah konsep yang kurang lebih dipahami secara universal.

Tidak ada pada faktur kepada pelanggan harus menjadi kejutan bagi pelanggan. Karena itu, saya berharap Anda sudah menetapkan harapan dengan pelanggan bahwa sebagian besar waktu Anda pada awalnya akan dihabiskan untuk membiasakan diri dengan aplikasi baik dari perspektif pengguna dan dari perspektif pengembang. Dan perkiraan Anda untuk beberapa fitur pertama mudah-mudahan menentukan bahwa mereka menyertakan jumlah waktu yang layak untuk membiasakan diri dengan kode.

Jika Anda sudah menetapkan harapan itu dengan pelanggan bahwa sebagian besar waktu pada faktur awal akan dihabiskan untuk membiasakan diri dengan aplikasi tersebut, seharusnya tidak terlalu penting bagaimana tepatnya Anda menuliskannya pada faktur. Gunakan bahasa apa pun yang Anda gunakan saat memberikan perkiraan dan menetapkan harapan. Jika Anda hanya mencoba mengomunikasikan ini sekarang, Anda punya masalah.

Dalam kapasitas saya sebagai pekerja lepas, saya mungkin akan menyebut ini sesuatu seperti "Asimilasi Pengetahuan", dalam arti umum. Dan, ini akan dimasukkan dalam estimasi yang diberikan pada awalnya kepada pelanggan.

Ini mungkin tidak membantu Anda di sini, tetapi untuk referensi di masa mendatang, saya sarankan Anda menjadikan ini lebih sebagai tugas aktif di masa depan. Misalnya, faktur pelanggan untuk waktu yang Anda habiskan melalui dan menambahkan komentar ke kode yang tidak dikomentari, menambahkan unit test ke kode yang belum diuji, dll. Ini adalah contoh tugas yang menambahkan setidaknya sedikit nilai sambil memfasilitasi pemahaman Anda tentang basis kode .

Bahkan jika tidak ada banyak perbedaan antara membaca dan membaca saat mendokumentasikan, pelanggan Anda mungkin akan memiliki preferensi psikologis kecil untuk tugas-tugas yang lebih 'aktif' ini. Dan, Anda mungkin sebenarnya belajar lebih banyak dengan mendokumentasikan kode orang lain daripada Anda hanya dengan membacanya. (Ini tentu akan menjadi masalah jika Anda menulis tes terhadap kode mereka).

Jika Anda melakukan ini, Anda dapat memiliki item baris faktur yang mengatakan sesuatu seperti "Asimilasi Pengetahuan dan Pengujian / Dokumentasi Kode Warisan".

Sunting: Dalam situasi Anda seperti yang dijelaskan, saya mungkin akan dengan jujur ​​memakan biaya kegiatan ini. Saya tidak dapat berbicara dengan keuangan Anda, dan saya tidak bermaksud berasumsi, tetapi ketika Anda memulai, saya akan memberi nilai lebih tinggi pada pemerasan kesaksian dan menyenangkan pelanggan daripada beberapa jam penagihan. Jika itu berarti tingkat yang lebih rendah efektif di awal, mungkin investasi yang baik. Makan beberapa jam yang dapat ditagih dalam jangka panjang mungkin adalah harga yang kecil untuk membayar pelanggan yang puas yang berpikir dia mendapat goyangan yang adil.

Memperbaiki bug: analisis akar penyebab.

Fitur baru: analisis, desain, integrasi, dan pengujian.

Memperkenalkan bug baru: keamanan pekerjaan. :)

Dengan klien yang suka memahami bagaimana hal-hal bekerja dan mendengarkan saya dengan mata melamun, saya akan pergi dengan lurus Codebase Familiarization. Saya sudah menjelaskan kepadanya betapa sakitnya dia, dan keuntungan datang kepada saya untuk peningkatan lebih lanjut.

Dengan pelanggan jenis lain ... (perlakuan yang sama, tetapi dia jelas tidak mendengarkan satu kata pun yang saya katakan ) saya akan menggunakan sesuatu di baris:

• Planning Phase

• Intervention Planning

  (Sebenarnya saya akan menggunakan yang ini, tetapi saya akan menulisnya dalam bahasa Italia, yang kedengarannya jauh lebih baik)

• Lalu, mungkin ... Solution Planning

Saya suka Diagnosisbagian dari Problem Diagnosissaran itu anon, tetapi Problemitu tidak terdengar benar bagi saya. Ini bisa terbuka untuk kritik ringan, bias, bodoh, dan dangkal ... yang mungkin meninggalkan selera buruk.

Anda tahu, semua orang ingin melempar anak panah ke konsultan eksternal, dan mereka melakukannya. (... seperti dia tidak cukup baik untuk memahami akar masalah saat berbicara dengan mereka, dan harus menagih kesalahannya, atau Tuhan yang tahu apa)

Mekanik saya mengirimi saya tagihan "Ganti oli, percikan plus, periksa filter, rotasi ban. Perbaiki kerincingan mesin, uji jalan .....

Bagian (diperinci),

Tenaga kerja x @ $ y / jam = z)

Dia tidak memecah tenaga kerja, begitu pula Anda. Tagihan total jam, dan jelaskan apa yang Anda lakukan.