Bagaimana saya bisa dibayar untuk mengurangi hutang teknis?


16

Saat ini saya bekerja untuk perusahaan kecil yang memiliki beberapa produk yang rumit secara teknis. Saya satu-satunya pengembang untuk salah satunya. Sekitar setahun yang lalu, saya mendapatkan versi produk warisan dan mulai "mendukung" itu.

Pelanggan hanya berbicara tentang fitur baru, nilai bisnis, dan lainnya dari jenis itu. Masalahnya adalah, meskipun kodenya dalam C #, itu cukup prosedural. Tidak ada abstraksi, kelas hanya digunakan di mana Visual Studio membutuhkannya - Formulir, misalnya. Implementasi kelas-kelas ini sangat buruk dan kodenya sangat sulit untuk dipelihara.

Sepanjang tahun ini saya menghabiskan waktu saya sendiri untuk refactoring. Dalam versi terbaru, ada banyak abstraksi dan semacamnya. Saya harus menerapkan kembali sejumlah komponen dari awal dan saya benar-benar merasa bahwa menambahkan fitur baru atau mengubah perilaku ke komponen-komponen ini JAUH lebih mudah daripada yang lain.

Masalahnya adalah, saya menghabiskan waktu saya sendiri. Saya sangat suka hasilnya, tapi saya tidak suka bekerja 12 jam per hari. Pernahkah Anda ke situasi yang sama? Apa yang harus saya coba? Saya sudah mencoba membahasnya, tetapi masih belum berhasil.

Saya hanya takut pada saat ketika kami memutuskan untuk mengimplementasikan fitur baru yang membutuhkan banyak perubahan pada kode legacy. Itu bisa sangat mengejutkan bagi pelanggan: mengapa Anda perlu 8 jam untuk mengubah ikon ini? Pelanggan tidak peduli bahwa ada 500 tempat dalam kode yang perlu saya ubah. Dan saya juga harus menemukan semua 500 tempat ini terlebih dahulu.

Ada ide?


3
Apa pertanyaan Anda? Jika Anda seorang karyawan, mengapa Anda memiliki kode ini dan mengapa Anda memodifikasinya sendiri? Apa yang kamu inginkan? Untuk mendapat kompensasi atas waktu Anda yang belum dibayar untuk mengerjakannya? Atau hanya bekerja lebih sedikit? Apakah atasan Anda tahu Anda membuat perbaikan pada waktu Anda sendiri? Pertanyaan Anda tidak dapat dijawab seperti saat ini sedang ditulis.
Robert Harvey

3
Oke, jadi apa pertanyaan spesifik Anda? Mengapa Anda ingin membuatnya tetap prosedural jika arsitektur yang Anda kembangkan pada waktu Anda sendiri lebih baik?
Robert Harvey

8
Mereka tidak berbicara bahasa Anda, jadi Anda perlu belajar bahasa mereka. Ini adalah bagaimana itu sangat SERING. Ini bukan alasan untuk melarikan diri, karena seperti ini hampir di mana-mana. Anda memerlukan alasan yang setengah-benar-tetapi-masuk akal untuk membawa pembuat kode GOOD yang lain , dan kemudian membangun waktu re-factoring. Jika tidak, lakukan yang terbaik untuk memenuhi perkiraan Anda sendiri dan tambahkan waktu pembuatan ulang faktor untuk setiap proyek yang Anda melakukan. Para pebisnis biasanya memiliki titik lemah di suatu tempat. Beberapa tugas lebih besar daripada yang lain di mata mereka. Pad yang "besar". Oh, dan jangan lupa untuk menulis tes :) Juga, terus lakukan lembur untuk saat ini - invstmnt
Ayub

2
@Robert Harvey, penanya tahu bagaimana melakukan hal-hal yang benar, tetapi terjebak dengan omong kosong orang lain dan satu-satunya yang melihat banyak risiko, adalah satu-satunya kesalahan siapa itu ketika omong kosong itu pecah. Bisnis kecil berusaha untuk bertahan dan penjualan / pendapatan - agresif, tetapi meningkatnya hutang teknis membuat dia stres tanpa orang lain menyadarinya. Dia membutuhkan peta jalan dan kiat untuk keluar dari lubang ini.
Pekerjaan

1
Saya telah mengubah judul pertanyaan Anda. Semoga judul baru lebih akurat mencerminkan niat Anda. Saya tidak yakin Anda bisa memulihkan jam yang hilang; Saya akan melakukan apa yang orang lain sarankan dan menambahkan beberapa padding ke dalam beberapa estimasi Anda sehingga ada sejumlah uang yang tersedia untuk memasukkan peningkatan Anda.
Robert Harvey

Jawaban:


37

Langkah 1: Berhenti bekerja lembur tanpa dibayar.

Anda telah melatih pelanggan dan manajer Anda selama setahun untuk meyakini bahwa laju perkembangan saat ini adalah apa yang harus diharapkan. Ini adalah bagian dari alasan mengapa mereka tidak mengerti mengapa hal "sederhana" bisa memakan waktu sehari penuh untuk dilakukan. Anda tidak perlu menyandera mereka dan berusaha melukai proyek. Tetapi Anda perlu menjelaskan bahwa harapan mereka terlalu tinggi dan Anda perlu pengembang lain atau lebih banyak waktu sebelum batas waktu. Buat poin khusus untuk menyebutkan kepada manajer Anda bahwa Anda telah bekerja lembur tanpa dibayar dan berencana untuk tidak melakukan itu sebanyak. Bahkan jika Anda memotongnya menjadi 9 jam hari, perbedaannya akan diperhatikan. Jika manajer Anda bertanya kepada Anda mengapa Anda tidak menyelesaikan pekerjaan Anda, Anda dapat menunjukkan fakta bahwa Anda telah membuat titik untuk memperingatkannya bahwa ini akan menjadi masalahnya.

Langkah 2: Buat catatan

Hanya karena Anda tidak punya waktu untuk melakukan pekerjaan, tidak berarti Anda tidak dapat membuatnya lebih mudah ketika pekerjaan (semoga) selesai. Pantau terus ide-ide yang Anda miliki untuk memperbaiki kode dan bawalah mereka ke rapat agar orang lain mengetahui kekhawatiran Anda. Akhirnya, Anda akan menemukan patch lambat atau orang-orang akan mulai memahami bahwa kekhawatiran Anda memiliki nilai. Ketika waktu ini tiba, Anda sudah memiliki beberapa ide dasar tentang apa yang harus dilakukan daripada membuatnya kering karena Anda belum melihat bagian kode dalam beberapa saat.


apa yang Anda katakan adalah ide yang sangat bagus. Sekitar sebulan yang lalu saya memutuskan untuk menambahkan tugas di pelacak bug kami. Saya tidak peduli bahwa tugas ini tidak dikonfirmasi, setiap kali saya melihat masalah potensial, saya menambahkan tugas dan memberi tahu pelanggan. Lain kali saya harus memperbaiki sesuatu yang saya harapkan secepatnya, saya hanya mengingatkan pelanggan tentang tugas yang telah saya buat beberapa bulan yang lalu. Semoga itu bisa membantu.
Andrey Agibalov

17
"Berhenti bekerja lembur tanpa dibayar" harus berlaku bahkan jika Anda benar-benar menyukai pekerjaan itu. Anda tidak mendapat manfaat dari jam kerja ekstra Anda; mereka. Jika Anda ingin menghabiskan waktu di depan komputer, lakukan untuk proyek Anda, di rumah Anda.
Christopher Mahan

1
Setelah lebih dari satu dekade di industri ini, saya masih belum pernah "menambal lambat". Apa yang saya lakukan salah?
sbi

@sbi Saya pikir itu bisa "melakukannya dengan benar" :)
Stephen

13

... kode ini sangat sulit untuk dipelihara.

Ini cara Anda bersama manajemen. Tunjukkan bahwa biaya "hanya" untuk memperbaiki bug dan menambahkan fungsionalitas baru lebih besar daripada biaya refactoring dan penulisan ulang kode.

Misalnya jika dengan kode saat ini, fitur baru akan membutuhkan 2 minggu untuk ditambahkan dan kemudian sejumlah besar waktu untuk mempertahankan (mis. 1 hari seminggu), tunjukkan bahwa dengan seminggu refactoring Anda dapat menyelesaikan pengembangan dalam 1 1/2 minggu tetapi Anda akan memotong pemeliharaan menjadi 1 hari dalam sebulan (atau kurang). Angka-angka ini akan menunjukkan bahwa apa yang Anda lakukan adalah hemat biaya dalam jangka menengah hingga panjang walaupun ada biaya jangka pendek.

Walaupun perusahaan mungkin tidak suka menghabiskan uang sekarang, mereka akan melihat bahwa manfaat potensial jauh lebih besar - yaitu Anda akan lebih produktif menghasilkan kode lebih banyak dalam waktu lebih sedikit dan kode itu akan kualitas lebih baik.


7

Terapkan Aturan Kepanduan. Biarkan kode sedikit lebih rapi (mis. Dengan utang teknis lebih sedikit) setiap kali Anda menyentuhnya.

Luangkan waktu untuk melakukan ini dalam semua perkiraan yang Anda berikan. Kemudian, secara ajaib, seiring waktu hutang teknis akan lenyap dan Anda akan dibayar untuk melakukannya.

Pendekatan ini jauh lebih mudah daripada secara eksplisit mencoba mengukir waktu (dan karena itu meyakinkan pelanggan / manajer untuk membayar) untuk hutang teknis. Ini memberi Anda perasaan profesionalisme yang jauh lebih besar dan "pekerjaan yang dilakukan dengan baik". Dan akhirnya, pelanggan dan manajer Anda akan berterima kasih untuk itu dalam jangka panjang, bahkan jika mereka tidak mengerti bagaimana itu terjadi .....


Namun, pendekatan ini akan membuat tidak mungkin untuk melakukan refactoring yang lebih substansial.
sbi

1
@ sbi - Anda akan terkejut: jika Anda memiliki unit test yang baik dan SCM yang layak untuk rollback maka Anda dapat melakukan sejumlah besar langkah terkendali dan terverifikasi. Saya pernah mengubah hierarki warisan besar (kelas 50+) menjadi model berbasis prototipe dalam serangkaian refactoring tambahan, tidak ada yang membutuhkan lebih dari beberapa jam kerja.
mikera

@ sbi: Seseorang seharusnya tidak pernah benar-benar melakukan refactoring yang substansial - hanya satu perubahan / refactoring sekaligus. Unit kerja kecil, perubahan kecil, dan tentu saja menjalankan semua tes dan sejenisnya untuk membuat (dua kali lipat) yakin Anda tidak merusak apa pun.
Cthulhu

@ Cthulhu: Jika Anda memiliki unit test yang baik, Anda dapat merobohkan dan membangun kembali hampir sebanyak kode yang Anda inginkan, karena tes akan menangkap sebagian besar kesalahan.
sbi

4

Ini kurang lebih adalah kenyataan menyedihkan dari pemrograman pemeliharaan. Anda terjebak dengan apa yang Anda ditugaskan untuk mempertahankan dan jika orang yang membayar tagihan tidak ingin membayar apa yang dia anggap sebagai perubahan tanpa manfaat, maka perubahan itu cenderung tidak dilakukan.

Jika Anda ingin membuat kasus agar perubahan ini didanai, maka simpan log semua tempat yang harus Anda ubah bahkan untuk pembaruan yang paling sederhana sekalipun. Setelah beberapa perubahan, diskusikan log itu dengan manajer Anda. Jika Anda dapat mendokumentasikannya, ada kemungkinan (walaupun sangat tipis) bahwa orang yang memiliki dompet akan menyadari bahwa sebenarnya lebih murah dalam jangka panjang untuk membersihkan kode sekarang karena akan membuat perubahan di masa depan lebih murah.

Peluang Anda untuk menjual peningkatan ini semakin lama produk ini diharapkan akan digunakan. Peluang juga meningkat jika kegagalan dalam produk kemungkinan menyebabkan masalah hubungan masyarakat bagi pelanggan atau biaya uang pelanggan.

Kecuali itu, pelajari apa yang Anda bisa dan pindah ke posisi lain dengan sedikit perawatan.


3

Anda perlu menunjukkan kepada manajemen Anda bagaimana cara refactoring dan meningkatkan produk akan menguntungkan perusahaan.

Pelanggan tidak akan peduli apakah kode itu indah atau jelek asalkan kode itu berfungsi, dan manajemen tidak akan bersemangat untuk menjelaskan kepada pelanggan bahwa apa yang telah mereka bayar dirancang dengan buruk dan diimplementasikan dengan buruk. Pada saat yang sama, manajemen tidak akan mau memakan biaya waktu pengembangan yang tidak meningkatkan produk dengan cara yang terlihat (dapat ditagih).

Jadi ... Anda harus meyakinkan manajemen bahwa perubahan yang Anda usulkan akan membantu perusahaan:

  • Tunjukkan pada mereka bahwa arsitektur yang lebih baik akan memungkinkan Anda untuk menambahkan fitur baru dengan lebih cepat.
  • Jelaskan bahwa dengan melanjutkan sepanjang jalan saat ini mereka akan melukis diri mereka sendiri ke sudut.
  • Berikan contoh perubahan yang sangat mahal untuk dilakukan dalam sistem saat ini, tetapi yang sederhana dan murah dengan desain yang lebih baik.
  • Melacak waktu yang dihabiskan untuk mempertahankan kode lawas vs menambahkan fitur yang dapat dijual. - Bantu mereka menjelaskan kepada pelanggan yang ada dan yang akan datang bahwa sementara sistem yang ada cukup bagus, arsitektur baru yang dimodernisasi akan memungkinkan banyak peningkatan baru yang hebat, keandalan yang lebih baik, dan sebagainya.
  • Mitigasi risiko yang terkait dengan perubahan yang Anda usulkan. Manajer menolak risiko, dan menyapu perubahan pada sistem yang ada tampaknya berisiko.
    • Prioritaskan modernisasi berbagai komponen sesuai dengan biaya dan manfaat, dan pastikan manajemen setuju dengan prioritas Anda.
    • Gunakan pengujian unit untuk membantu memastikan bahwa komponen yang dimodernisasi akan kompatibel dengan kode warisan yang tersisa.
  • Lacak kemajuan upaya modernisasi. Tunjukkan keuntungan sesegera mungkin, tapi ingatkan semua pihak bahwa masih banyak yang harus dilakukan.

3

Anda mungkin tidak menyadarinya, tetapi Johnny Cash memprediksi gerakan refactoring dan menulis lagu tentang cara terbaik untuk refactor basis kode besar yang ada.

Tentu saja, ia harus membungkusnya dengan metafora otomotif sehingga audiensnya bisa mengaitkannya.

"One Piece at a Time" - Johnny Cash


2

Sepertinya Anda bisa menagih pelanggan untuk waktu perubahan "harus" ambil dan masih keluar WAY di depan dalam jangka panjang.

Jika Anda menikmati membersihkan kode (dan sepertinya Anda melakukan setidaknya sedikit), maka teruskan terus tetapi jangan sampai Anda kelelahan karenanya. Itu tidak baik bagi Anda, perusahaan Anda, atau pelanggan Anda lainnya.

Pastikan bahwa manajemen Anda dan siapa pun yang bekerja dengan pelanggan tahu bahwa kode tersebut tidak dalam kondisi terbaik sehingga mereka dapat membuat keputusan berdasarkan informasi - hanya karena Anda memiliki kode itu tidak berarti Anda harus membuat keputusan bisnis mengenai hal itu, jika mereka tidak mengetahui masalah dengan kode maka mereka tidak dapat melakukan pekerjaan mereka.


1
@robertharvey: ya dia membersihkan kode pada waktunya sendiri sehingga pelanggan yang akan ditagih untuk pembaruan tidak harus membayar lebih daripada jika kode itu ditulis dengan baik. Saya pikir perusahaannya perlu memakan sebagian besar biaya (jika terjadi). Masuk akal bahwa pelanggan membayar sebagian waktu, tetapi jika Anda menagih lebih karena kode omong kosong itu adalah cara yang baik untuk kehilangan niat baik dan bisnis masa depan.
DKnight

2

Meskipun aplikasi klien memiliki hutang teknis, jangan lupa, mereka mungkin dikenakan sedikit diskon. Mereka mungkin tidak dibuat sadar akan hal ini, tetapi itulah yang terjadi ketika Anda mengambil tawaran terendah.

Mereka perlu memutuskan apakah mereka ingin membayar harga penuh untuk perubahan fitur atau melakukannya tanpa mereka. Itu pilihan mereka. Anda dapat membiarkan mereka membuat keputusan atau terus bekerja secara gratis. Anda dapat mencoba dan menyebutkan pekerjaan pembersihan yang Anda lakukan dan menawarkan sedikit diskon untuk pekerjaan yang diselesaikan. Sekali lagi, itu pilihan mereka.


1

Cara saya mendekati ini adalah mulai dengan menjelaskan konsep utang teknis kepada bos Anda untuk memastikan mereka mendapatkannya. Pendekatan itu dari garis bawah, perspektif bisnis. Setiap kali mereka meminta fitur baru, utang teknis yang terkandung dalam produk memengaruhi efisiensi Anda, dan karenanya setiap fitur sedikit lebih mahal karena utang ini.

Setelah mereka mengerti apa yang Anda bicarakan, cobalah untuk bernegosiasi untuk sedikit waktu Anda untuk mengurangi hutang teknis. Di perusahaan saya, kami telah cukup berhasil dengan mengajukan petisi untuk 10% dari setiap waktu pengembang untuk mengerjakan pengurangan utang teknis.

Setelah Anda menyisihkan waktu untuk mengerjakan ini, pastikan Anda benar-benar menggunakannya (dan jangan hanya bekerja 10% lembur untuk melakukannya - tetap berpegang pada senjata Anda). Buat katalog barang-barang hutang teknis dan prioritaskan dan mulailah mengukir. Anda harus makan gajah satu gigitan sekaligus.


1

Dan jangan lupa untuk mempertimbangkan alat yang lebih baik. Resharper adalah alat refactoring yang bagus yang dihubungkan ke Visual Studio.

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.