Memerangi hutang teknis sebagai "pengembang terendah"?

Katakanlah Anda bekerja untuk perusahaan dan apa yang Anda lakukan adalah mengembangkan perangkat lunak untuk mereka. Anda tidak tahu gambaran besarnya atau mungkin sedikit. Apa yang Anda miliki adalah tugas yang diberikan kepada Anda melalui sistem pelacakan masalah. Anda diberi tugas, Anda membuatnya bekerja dengan cara tugas itu menggambarkannya, Anda mengirimnya kembali. Seperti menambahkan 2 bilangan bulat:

function add(a,b){return a + b;}

Tetapi kemudian, ketika proyek berjalan maju, Anda melihat bahwa ketika addmenjadi lebih kompleks, Anda menyadari bahwa itu harus memerlukan beberapa bentuk arsitektur, lebih dari sekedar fungsi yang menambah parameter dan mengembalikan nilai. Namun, Anda tidak tahu itu. Pertama, yang mereka butuhkan adalah sesederhana itu add. Anda tidak berharap menambah menjadi begitu rumit.

Proyek ini berjalan dengan lebih banyak fitur, yang awalnya tidak Anda harapkan. Dan pada akhirnya, Anda terus menumpuk hacks dan lapisan fungsi untuk menghindari melanggar / menulis ulang kode yang ada.

Bagaimana Anda menghadapi situasi ini? Bagaimana Anda melawan hutang teknis sebagai "pengembang terendah"?

Klarifikasi:

• Anda adalah "pelaksana", yang terendah dalam hierarki.

• Anda melihat masalahnya, tetapi tidak memiliki suara untuk masalah ini.

• Saya tidak menghitung utang teknis atau mencari alat.

• Mengenai "duplikat" ketiga

  • Refactoring & Menulis Ulang - Anda dikunci untuk tugas Anda. Anda tidak dibayar untuk melakukan ekstra.
  • Tinjauan Arsitektur - Anda tahu keseluruhan sistem, tetapi tidak tahu arsitekturnya.
  • Pembekuan Kode - Bukan panggilan Anda. Anda bukan manajemen.
  • Modularisasi - Tidak tahu arsitektur. Modul berubah seiring perubahan persyaratan.
  • Tes Otomatis - Tidak ada.

Setiap kali Anda melihat sesuatu seperti itu, masukkan tiket baru ke dalam sistem pelacakan masalah Anda.

Biasakan untuk menggunakan pelacak isu sebagai yang utama alat untuk mengomunikasikan hal-hal seperti itu, karena dari sana, akan mudah untuk memilih, mengevaluasi, dan memprioritaskan kolega senior Anda / pemimpin / manajer / siapa pun yang bertanggung jawab untuk melacak masalah di proyek Anda .

Gunakan alat yang tepat untuk pekerjaan itu. Saya selalu melakukannya dan sangat menyarankan Anda melakukan hal yang sama.

Sebagai contoh, berikut adalah tiket yang saya buat sekitar sebulan yang lalu. Setelah menyelesaikan fitur tertentu saya menemukan bahwa kode menjadi jauh lebih rumit daripada sebelumnya tetapi saya tidak dapat memperbaikinya dalam tenggat waktu yang diberikan untuk implementasi fitur.

(Nama fitur, tiket, dan kode yang digunakan dalam pelacak nyata dikaburkan, tetapi teks disalin sebagaimana adanya).

Ringkasan: mempermudah desain yang melibatkanParticularPieceOfCode

Deskripsi:
Dalam pelaksanaan per TICKET-12345, kode yang melibatkan penggunaan ParticularPieceOfCodesedikit kesulitan yang timbul dan menjadi agak sulit untuk dibaca, dipahami, dan dipelihara (lihat contoh cuplikan kode di bawah).

Temukan cara untuk menyederhanakannya.

Contoh kode yang diinginkan untuk didesain ulang dapat ditemukan di ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW saran saya berlaku terlepas dari "level" Anda.

Saya telah menggunakannya pada level Anda saat ini ("terendah") dan saya menggunakannya sekarang karena level saya cukup jauh dari "terendah" dan saya sudah memuaskan "katakan" seperti yang Anda sebut, dan saya akan menggunakannya selalu apa pun yang terjadi.

Pikirkan saja, tidak ada level, tidak peduli berapa banyak otoritas yang Anda miliki, tidak mungkin ada cara yang lebih baik.

Jika Anda "mengatakan" hei kita punya masalah , itu hanya berderak udara. Dan bahkan jika bos / pimpinan Anda setuju dan mengatakan Anda benar, kami punya masalah , ini tidak mengubah apa pun - itu hanya udara yang bergetar lagi, dan itu tidak bisa apa-apa lagi.

• ^{Anda mungkin berpikir bahwa menulis kata-kata Anda (misalnya dalam email) akan lebih baik, tetapi jika Anda memikirkannya, sebenarnya tidak. Jika proyek Anda memiliki aktivitas email yang substansial, apa yang ditulis akan hilang dan lama terlupakan sebulan kemudian.}

Gunakan alat yang tepat untuk pekerjaan itu. Untuk pekerjaan yang Anda jelaskan, lacak pelacak adalah alat yang tepat.

Anda melihat masalah, Anda memasukkannya ke dalam sistem yang dirancang untuk melacak ini dan mengurus sisanya, dengan cara terbaik - hanya karena itu dirancang untuk itu :

paket perangkat lunak komputer yang mengelola dan mengelola daftar masalah , seperti yang dibutuhkan oleh suatu organisasi ... yang biasa digunakan ... untuk membuat, memperbarui, dan menyelesaikan masalah pelanggan yang dilaporkan, atau bahkan masalah yang dilaporkan oleh karyawan lain dari organisasi itu ... Pelacakan masalah sistemnya mirip dengan " bugtracker ", dan sering kali, perusahaan perangkat lunak akan menjual keduanya, dan beberapa bugtracker mampu digunakan sebagai sistem pelacakan masalah, dan sebaliknya. Konsisten menggunakan masalah atau sistem pelacakan bug dianggap sebagai salah satu "keunggulan tim perangkat lunak yang baik" ¹ ...

Apa pun cara lain yang ingin Anda pilih untuk berkomunikasi, memiliki tiket di pelacak hanya akan memudahkan Anda.

Bahkan jika Anda lebih suka mengoceh , mengatakan "Saya ingin membahas TICKET-54321 ..." membuat titik awal yang lebih solid daripada "Dengar, saya ingin berbicara tentang beberapa kode yang saya bahas beberapa waktu lalu. ... "Dan Anda dapat dengan aman mengirimkan referensi ke tiket melalui surat: bahkan jika surat hilang, masalahnya masih ada di pelacak, dengan semua detail yang ingin Anda ceritakan.

Apa yang membuat saya merasa tidak enak tentang skenario Anda adalah persis apa yang Anda tulis di judul dan beberapa kali dalam teks pertanyaan:

Anda adalah pengembang terendah dalam rantai

Mengapa poin itu begitu penting? Pertama-tama, dan dari sudut pandang murni teknis, Anda tentu benar. Anda dipekerjakan sebagai apa yang Anda sebut "pelaksana" hal-hal, lebah pekerja yang bertindak atas perintah yang diberikan.

Tetapi bahkan jika Anda adalah pengembang terendah dalam hal peringkat, ini masih belum sepenuhnya benar. Kuncinya di sini adalah untuk menyadari, bahwa Anda hanya menganggap diri Anda sebagai pengembang terendah. Pernahkah Anda mencoba mengatasi persepsi diri itu dan benar-benar mengambil alih tanggung jawab untuk sesuatu ?

Mengambil! Jangan menunggu, sampai seseorang membuat Anda bertanggung jawab.

• Anda melihat masalahnya, tetapi tidak memiliki suara untuk masalah ini.
• Saya tidak menghitung utang teknis atau mencari alat.
• Anda dikunci untuk tugas Anda. Anda tidak dibayar untuk melakukan ekstra.
• Bukan teleponmu. Anda bukan manajemen.

Biasanya itu justru sebaliknya: Anda dibayar lebih dan pendapat Anda lebih dihormati, begitu Anda menunjukkan bahwa Anda bernilai uang . Ini "do before have", bukan sebaliknya.

Apa yang saya harapkan dari orang-orang dalam tim saya adalah persis seperti itu: Rasa tanggung jawab atas proyek atau produk yang kami coba bangun dan untuk semua proses yang terkait dengan upaya itu. Setiap kali seseorang di tim saya membuat saya terkesan dengan mengambil alih tanggung jawab, misalnya mengusulkan perbaikan atau bahkan lebih baik mulai memperbaiki sendiri, ini adalah orang-orang yang akan dipromosikan.

Dengan kata lain: Tidak ada yang mempromosikan lebah pekerja, orang-orang secara pasif menunggu tugas-tugas yang diberikan kepada mereka, bahkan tidak memiliki kedipan inisiatif sekecil apa pun " karena mereka tidak dibayar untuk itu. ", akhirnya mengeluh bahwa mereka tidak pernah memiliki kesempatan.

Tentu saja, semua ini lagi tergantung pada budaya perusahaan Anda, dengan apa yang terkait dengan Joel dalam "Two Stories" yang ditautkan oleh Arthur. Jika manajer perusahaan benar-benar bodoh untuk memblokir orang-orang mereka sendiri dari membuat kemajuan, maka rasio fluktuasi mungkin sudah sangat tinggi dan mungkin sudah waktunya untuk mengambil kesimpulan dari itu. Tetapi jika itu tidak terjadi, masalah sebenarnya mungkin ada di dalam diri Anda.

Anda seorang profesional. Majikan Anda mempekerjakan Anda untuk menjadi profesional. Jadi, perlakukan kekhawatiran Anda dengan cara yang sama Anda inginkan profesional yang Anda sewa untuk memperlakukan pendapat profesional mereka . Secara khusus, Anda mengharapkan para profesional lain untuk melakukan optimasi dan koreksi yang diperlukan di sepanjang jalan, asalkan optimasi tersebut tidak secara tidak terduga meningkatkan biaya.

Sebagai contoh, misalkan Anda membawa mobil Anda ke mekanik untuk mengganti lampu. Mekanik memperhatikan empat hal:

1. Kawat yang mengarah ke lampu sudah usang dan berbahaya. Tapi, itu bisa dipangkas tanpa perlu menaikkan biaya. Anda akan mengharapkan dia mengambil beberapa menit untuk memotong kawat, mungkin tanpa menyadarinya.
2. Sebuah baut longgar. Ini sama sekali tidak berhubungan, dia kebetulan melihatnya. Sudah 20 detik waktunya untuk mengambil pengemudi yang diperlukan dan mengencangkannya; jadi, Anda berharap dia melakukannya.
3. Sasis untuk lampu retak, yang akan menyebabkan lampu berderak. Mahal untuk mengganti. Dan itu tidak penting. Jadi, dia memanggil Anda untuk menanyakannya - jika Anda mengatakan "tidak", ia memberikan rekomendasi tertulis pada ringkasan kunjungan Anda.
4. Ada cukup banyak minyak rem di bawah mobil. Dia harus, dan bahkan mungkin diminta sebagai seorang profesional, untuk mencegah Anda menggunakan mobil sampai Anda mengizinkan seseorang untuk memperbaiki kebocoran.

Masing-masing skenario ini, dan saya yakin orang lain, memiliki paralel dalam pengembangan perangkat lunak - terutama jika Anda menganggap diri Anda seorang profesional dari tingkat apa pun . Sebagai seorang profesional, dengan sangat sedikit pengecualian, tugas Anda adalah mencapai tujuan akhir untuk meningkatkan produk dengan cara tertentu sesuai dengan pemahaman profesional Anda .

1. Jika perbaikannya sepele, apakah tidak terkait atau tidak, lakukan perbaikan.
2. Jika perbaikannya tidak sepele dan tidak perlu, buat rekomendasi formal menggunakan mekanisme komunikasi / pelacakan masalah formal apa pun yang telah Anda sepakati.
3. Jika suatu kasus dapat dibuat bahwa perbaikan diperlukan untuk menyelesaikan tugas utama, tetapi secara tak terduga akan meningkatkan biaya, komunikasikan perubahan ruang lingkup.
4. Jika masalah yang teridentifikasi merupakan ancaman serius bagi keberhasilan proyek, jelaskan. Secara formal. Jika ada masalah etika dengan membiarkan masalah tidak terselesaikan (seperti dalam kesehatan, darurat, atau sistem transportasi), bersikeras mengatasi masalah sebelum produk dikirimkan (beri tahu media atau pihak berwenang jika diperlukan secara etis).

Anda melakukan ini dengan cara yang sama seperti petugas di kantor hukum berperang melawan perilaku yang tidak etis, pekerja makanan cepat saji berperilaku tidak bersih, atau petugas penegak parkir memerangi korupsi polisi.

1. Jadilah contoh yang bagus. Sejauh yang Anda bisa, menghasilkan kode yang bersih dan masuk akal. Ketika diberi pilihan, pilih yang memenuhi persyaratan Anda dengan lebih sedikit downside. (Ketahuilah bahwa utang teknis tidak seperti utang hipotek - hanya dengan memilikinya tidak selalu berarti hal buruk.)
2. Komunikasikan kekhawatiran Anda . Anda harus memiliki seseorang, baik pemimpin tim atau pelanggan atau arsitek, yang memiliki tanggung jawab aktual untuk mengelola utang teknis dan mengalokasikan sumber daya perusahaan Anda. Ketika Anda melihat sesuatu yang Anda yakini buruk, sampaikan kekhawatiran Anda kepada mereka. Tuliskan secara tertulis (mis., Email) jika Anda tidak yakin mereka akan mengerti, merespons, dan memberi kredit atas masukan Anda.
3. Jangan stres. Hutang teknis jarang menyebabkan kegagalan pekerjaan yang diakhiri perusahaan. Selama Anda telah mengomunikasikan keprihatinan Anda dan melakukan pekerjaan Anda, masalah arsitektur seperti utang teknis secara harfiah bukan masalah Anda. Ya, mereka dapat mempengaruhi Anda, tetapi mereka tidak lebih dari kekhawatiran Anda daripada pemilihan kembali sheriff adalah kekhawatiran seorang perwira polisi junior.

Dalam contoh yang Anda berikan, dengan addfungsi yang telah mengalami creep fitur lengkap, luangkan waktu beberapa menit dan konsep garis besar apa yang akan memperbaikinya. Kirim itu kepada siapa pun yang Anda memerlukan persetujuan untuk mengimplementasikannya, dan lanjutkan.

Dengan asumsi perusahaan Anda dikelola oleh orang-orang yang sangat kompeten dan terstruktur dengan benar, baik kekhawatiran Anda akan dialihkan ke perancang sistem yang tepat untuk suatu keputusan atau Anda akan diberikan kelonggaran untuk mengimplementasikan saran Anda. Sebagai pengembang junior, saya lebih khawatir tentang cara belajar perusahaan Anda daripada utang teknis - dan jika Anda tahu yang pertama, bagaimana menangani yang kedua harus jelas.

Saya belum pernah mendengar tentang organisasi yang tidak ingin karyawannya berpartisipasi. Anda mengatakan bahwa Anda hanya dibayar untuk melakukan tugas. Saya sungguh ragu Anda memiliki tugas yang tepat dalam pikiran. Karena Anda dibayar untuk menulis perangkat lunak yang bagus.

Ambil tanggung jawab ini. Katakan tidak untuk menambahkan fitur jika Anda tidak dapat mendukung basis. Nasihat pelanggan dengan keahlian Anda. Menginjak rem sekarang, sebelum terlambat dan Anda harus membuang seluruh proyek, karena itu tidak lagi dapat dipertahankan.