Memerangi hutang teknis sebagai "pengembang terendah"?


20

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.


3
@gnat, saya pikir pertanyaannya terkait (terutama yang terakhir), tetapi tidak duplikat. Saya melihat pertanyaan ini sebagai "Mengingat arsitek suatu sistem bukanlah pelaksana, dan pelaksana tidak diberi pandangan tingkat tinggi terhadap sistem, bagaimana bisa dipastikan implementasi tersebut cukup fleksibel atau dapat diskalakan?"
MetaFight

1
Apakah Anda bertanya bagaimana cara melawan hutang teknis secara umum, atau apakah Anda bertanya bagaimana cara melawan hutang teknis ketika Anda berperan sebagai seorang pembuat kode tanpa tanggung jawab untuk memperbaiki arsitektur?
Doc Brown

2
@JosephtheDreamer Ya, ada banyak hal yang dapat dilakukan untuk meningkatkan kode sumber, tetapi Anda menyatakan dalam pertanyaan Anda bahwa masalahnya adalah kurangnya wewenang untuk bertindak atas perubahan apa pun. Saya bisa memberi tahu Anda semua praktik terbaik tetapi jika Anda tidak diizinkan menginvestasikan banyak waktu untuk menerapkannya, lalu apa gunanya? ;)
Reactgular

2
" Tapi tugas itu datang dari orang-orang yang lebih tinggi " - apa yang menghalangi Anda memberi diri Anda beberapa tugas, selain " Saya tidak dibayar untuk itu " hari ini? Jika Anda bertindak seperti lebah pekerja penerima perintah, Anda akan diperlakukan sebagai lebah.
JensG

Jawaban:


22

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:>
http://i.stack.imgur.com/ARBSs.jpg


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" 1 ...

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.


7
+1 Saran yang bagus, tetapi masalah pelacakan di lingkungan yang tidak mencakup proses hanya menjadi lubang hitam. Apa yang baik adalah pelacak masalah satu orang. Paling-paling daftar yang harus dilakukan.
Reactgular

@MathewFoscarini sebelum memposting, saya mengklarifikasi hal ini dengan komentar OP (terkait di bawah "sistem pelacakan masalah Anda" dalam jawaban saya) - 'Ya, karenanya "tugas" (masalah, tiket, apa pun yang Anda sebut)) ...' Saya juga tidak pesimis tentang kasus-kasus "lubang hitam", dalam jangka panjang hal-hal cenderung berubah, terutama jika pengembang "tingkat terendah" mengambil inisiatif dan menginvestasikan upaya untuk menjaga pelacak dan mempromosikan penggunaannya sendiri (sudah ada yang melakukan itu )
agas

Dan di atas itu, saya telah melihat orang-orang disalahkan karena mencemari sistem tiket (= membuka tiket "terlalu banyak"). Jika budaya tidak sesuai, tidak ada sistem tiket yang akan membantu. Sayangnya, secara teknis orang cenderung mencari alat teknis daripada solusi, dan orang teknis lainnya menganggapnya sebagai saran yang baik karena cocok dengan proses berpikir mereka.
JensG

1
@JensG "orang-orang disalahkan karena mencemari sistem tiket" - ini adalah fenomena yang diketahui, mungkin pantas mendapatkan pertanyaan khusus (atau mungkin sudah ditanyakan dan dijawab, saya tidak mencari). Jika budaya tidak sesuai, upaya khusus tambahan yang diperlukan untuk sistem tiket menjadi bermanfaat (seperti yang saya tulis di komentar sebelumnya saya sudah pernah mengalami itu sebelumnya).
nyamuk

8

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.


8

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).

Jawaban ini persis apa yang akan saya lakukan. Saya tidak memasukkan tugas refactoring kecil ke pelacak masalah. Saya hanya refactor. Menempatkan setiap sedikit hutang teknis ke dalam tumpukan masalah hanya menciptakan daftar besar masalah, yang akan membuatnya sulit bagi mereka untuk mendapatkan visibilitas, dan pada saat siapa pun bekerja pada tugas seperti itu, masalah itu bisa hilang, berubah bentuk , memburuk, pindah, atau siapa yang tahu apa. Jika butuh 5 menit, perbaiki saja!
Brandon

5

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.


2
"Hutang teknis jarang menyebabkan kegagalan pekerjaan yang berakhir pada suatu perusahaan." Saya tidak akan begitu yakin. Alasan di balik kegagalan banyak proyek perangkat lunak adalah hutang teknis.
Euforia

2
Sebuah proyek bukan perusahaan, @Euphoric. Mozilla tidak mati hanya karena Sunbird tidak pernah lepas landas. Jika proyek Anda gagal, Anda pergi ke proyek baru dengan majikan yang sama. Jika perusahaan Anda gagal, Anda perlu mencari pekerjaan baru.
DougM

Jawaban ini sangat salah. Saya telah melihat hutang teknis menghancurkan produk perusahaan. Dan untuk "utang teknis secara harfiah bukan masalah Anda", siapa yang bertanggung jawab, jika bukan pengembang perangkat lunak?
Brandon

2

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.


4
Apakah ini hanya pendapat Anda atau Anda dapat mendukungnya? Pada level OP ("terendah"), "menginjak rem, mengatakan tidak" dalam pengalaman saya jarang menjadi oke. Baik untuk proyek, maupun untuk karier. Menengok ke belakang, saya dapat dengan jelas mengingat kasus-kasus ketika saya melewatkan satu atau dua hal ketika "mengatakan tidak" terhadap visi kolega / pimpinan / manajer senior
nyamuk

Dalam hal sumber daya manusia, menempatkan orang di belakang tiket kerja tanpa penanganan masalah nilai kerja yang tepat kemungkinan akan berakhir dengan bencana. Pekerja yang bahagia bekerja lebih banyak dengan upah lebih rendah, ada bukti ekonomi tentang hal itu. Menginjak adalah kesempatan belajar bagi junior dan manajemen. Menginjak rem adalah bagaimana startup bisa sangat kompeten dalam waktu yang sangat singkat, kami tidak memiliki tiket sialan. Mungkin menimbulkan konflik, tetapi konflik adalah bagian dari kehidupan yang terkutuk. Peduli terhadap kualitas harus didengarkan dan ditegakkan, jadi saya sedang melangkah di sisi rem.
Arthur Havlicek

2
Saya merekomendasikan bacaan ini yang membahas tentang devs tingkat rendah yang memberdayakan joelonsoftware.com/articles/TwoStories.html
Arthur Havlicek
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.