6 Jenis Utang Teknis: Utang teknis bukan beban, melainkan sarana strategis untuk meraih kesuksesan

xguru · 2023-03-20T11:21:01+09:00

Hal-hal yang diperlukan untuk memandang utang teknis sebagai sarana strategis Mengenali dan mengatasi asumsi negatif tentang utang teknis Mengklasifikasikan 6 jenis utang teknis dan menanganinya secara berbeda Mengukur skala utang teknis Cara menentukan prioritas utang teknis How to Not Manage Tech Debt 4 asumsi yang membuat utang teknis dikelola dengan keliru Asumsi #1 : utang teknis = hal buruk Tidak semua utang teknis harus diklasifikasikan sebagai sesuatu yang 'buruk' Jauh lebih baik memberi nama, mengukur tingkat rasa sakitnya, lalu mengelompokkan utang teknis tersebut Ada utang teknis yang justru baik untuk dimiliki, dan semua tim seharusnya memiliki utang teknis Contoh Twitter yang 'memiliki utang teknis yang baik': menggunakan storage publik lalu mengembangkan Manhattan, DB terdistribusi milik mereka sendiri Pertanyaan untuk menanggapi asumsi 'utang teknis = hal buruk' Jika kita menumpuk utang teknis ini sekarang dan menyelesaikannya bulan depan, apa yang akan kita dapatkan? Dalam situasi seperti apa manajemen akan peduli dengan utang teknis ini? Informasi seperti apa yang perlu disampaikan agar membantu CTO mem-pitch hal ini ke manajemen? Bagaimana inisiatif ini dapat terhubung ke visi perusahaan yang lebih besar atau arah strategisnya? Asumsi #2 : semua utang teknis = pekerjaan yang kompleks Seperti halnya pekerjaan sulit lainnya, ada banyak cara untuk menangani pekerjaan yang kompleks, bukan hanya pada utang teknis Khusus untuk utang teknis, ada pendekatan terhadap pekerjaan Defined/Undefined (terdefinisi/tidak terdefinisi) Defined = pekerjaan memiliki awal dan akhir Undefined = pekerjaan punya awal, tetapi akhirnya tidak jelas Untuk menanggapi asumsi bahwa utang teknis = kompleks Perjelas apakah utang teknis yang dihadapi termasuk Defined atau Undefined Untuk Defined, pahami estimasi waktu penyelesaian dan sediakan sedikit buffer waktu Untuk Undefined, daftar bagian-bagian yang belum jelas dan sampaikan ke para pemangku kepentingan agar mereka memahami mengapa pekerjaan ini kompleks dan tidak memiliki tanggal selesai yang pasti, lalu minta pendapat tentang cara terbaik untuk maju Pecah utang teknis Undefined menjadi bagian pekerjaan yang lebih mudah dicerna agar tidak terlalu kompleks Jika pekerjaan besar yang rumit dipecah menjadi tugas kecil yang tetap kompleks namun bisa dieksekusi, tim dapat lebih termotivasi untuk menyelesaikan sebagian utang teknis dalam periode sprint/kuartalan yang sudah ditentukan Pertanyaan untuk menanggapi asumsi 'utang teknis = pekerjaan yang kompleks' Asumsi keliru apa yang kita miliki tentang sistem ini? Jika kita membawa orang yang berpengalaman atau familier di bidang ini, pertanyaan apa yang wajib kita ajukan? Apakah tim kita memiliki orang dan pengetahuan yang tepat untuk mengerjakan ini? Jika tidak, bagaimana kita sebaiknya mempertimbangkan redistribusi informasi, dan kapan waktu paling ideal untuk menyelesaikan masalah ini? Apa cara terbaik menjelaskan kompleksitas utang teknis ini kepada orang yang sama sekali tidak memahaminya? Asumsi #3 : utang teknis ≠ pekerjaan produk Organisasi biasanya jelas soal bagaimana pekerjaan produk akan meningkatkan metrik perusahaan Namun, utang teknis sering kali tidak ikut dimasukkan dalam pembahasan ini Menyelesaikan utang teknis pada waktu yang tepat dapat menjadi hal penting untuk mendorong pertumbuhan perusahaan, meskipun dampaknya tidak selalu bisa langsung diukur secara kuantitatif Untuk menanggapi asumsi bahwa utang teknis ≠ pekerjaan produk Meski area tertentu dari utang teknis tidak terhubung langsung ke metrik, pikirkan secara lebih luas bagaimana hal itu dapat membantu pengalaman pengguna/produk Alih-alih hanya menonjolkan manfaat teknis, jika manfaat bagi pengguna dan produk juga ditekankan secara setara, orang lain akan lebih mudah memahami mengapa tim perlu peduli pada pekerjaan ini Luangkan waktu untuk memastikan business lead dan technical lead benar-benar memahami hal yang sama (on the same page) Pertanyaan untuk menanggapi asumsi 'utang teknis ≠ pekerjaan produk' Apa satu alasan terpenting mengapa pekerjaan ini harus dilakukan sekarang? Siapa yang perlu memahami dampak pekerjaan ini? Mengapa mereka harus peduli? Apa yang sebenarnya ingin saya sampaikan? Apakah itu sejalan dengan apa yang ingin didengar para pemangku kepentingan? Jika tidak, bagaimana saya bisa membantu memecahkan masalah mereka? Apa yang saya atau tim anggap sebagai hasil yang wajar vs. hasil yang luar biasa? Apakah kita menjanjikan hasil secara berlebihan? Bisakah ekspektasi dibagi antara hasil yang luar biasa dan yang cukup baik agar lebih realistis? Asumsi #4 : rasa sakit individu = rasa sakit organisasi Engineer yang dekat dengan utang teknis sering berulang kali mengatakan bahwa menangani utang teknis itu menyakitkan secara pribadi Bagi karyawan, hal itu bisa terasa seperti kiamat, tetapi orang lain di organisasi belum tentu merasakan rasa sakit yang sama Ini umum terjadi pada orang di tahap awal karier dan biasanya muncul karena kurangnya konteks strategis yang lebih luas Untuk menanggapi asumsi bahwa rasa sakit individu = rasa sakit organisasi Saat menyentuh area utang teknis berprioritas tinggi, berhentilah sejenak untuk melihat apakah ini merupakan pain point pada level individu atau level organisasi Secara umum, masalah di level organisasi akan berdampak langsung pada pelanggan atau bisnis dalam satu bentuk atau lainnya Cobalah melihatnya dari sudut pandang orang yang memiliki konteks organisasi lebih besar daripada Anda. Menjelaskannya kepada seseorang dari tim lain juga bisa membantu Pertanyaan untuk menanggapi asumsi 'rasa sakit individu = rasa sakit organisasi' Berapa banyak tim yang akan mendapatkan manfaat jika utang teknis ini diklasifikasikan dan diselesaikan? Kapan perusahaan pernah mengakui atau memberi penghargaan kepada seseorang yang menangani pekerjaan utang teknis? Jenis utang teknis apa itu, dan mengapa saat itu dianggap perlu? Bisa ceritakan bagaimana orang tersebut memosisikan pekerjaannya? Apakah engineering manager saya memahami nilai dari pekerjaan utang teknis? Apakah dia akan mengadvokasi kontribusi saya dalam pekerjaan ini saat performance review? 6 jenis utang teknis Maintenance debt (utang pemeliharaan) Saat tim tidak mampu mengikuti update teknologi Termasuk tidak menghapus dead code setelah eksperimen dimulai / feature rollout / rollback deployment, juga tidak memperbarui library, komentar pada kode kontekstual, atau dokumentasi atas keputusan implementasi Contoh) setelah bereksperimen dengan fitur 'log in with Spotify' lalu membatalkannya, kode terkait tidak dihapus Developer efficiency debt (utang efisiensi developer) Saat perusahaan tidak memiliki testing, monitoring, dan sistem alert yang memadai untuk produknya Ini adalah jenis utang umum ketika workflow engineering sangat tidak efisien, deployment/build memakan waktu berjam-jam atau berhari-hari, dan developer tidak bisa mendeteksi masalah teknis sebelum masuk ke production Contoh) organisasi tumbuh dari 15 menjadi 50 orang dalam setahun, sehingga terlalu banyak eksperimen berjalan. Rilis perbaikan bug yang ditemukan di production tertunda 2-3 batch. Testing baru untuk pengalaman pembelian pun ikut tertinggal Stability debt (utang stabilitas) Saat berbagai jenis utang teknis menumpuk di organisasi dan mulai memengaruhi stabilitas infrastruktur Bukan mengelola on-call secara proaktif, tetapi malah memanggil ahli terkait setelah masalah terjadi, atau bahkan seluruh tim ikut on-call Ini adalah masalah besar bagi engineer dan tim rotasi on-call, tetapi bagi orang lain di perusahaan, memahami apalagi menjelaskannya hampir mustahil Utang stabilitas juga memengaruhi reliabilitas produk dan bisa menimbulkan masalah yang dihadapi pelanggan Contoh) tim mobile memiliki lebih banyak developer iOS sehingga iOS diprioritaskan dibanding aplikasi Android. Akibatnya, aplikasi Android kekurangan product guideline untuk alur yang penting bagi bisnis, dan masih memiliki kode lemah (Kryptonite) yang awalnya dibuat pihak ketiga. Hal ini menyebabkan pengguna Android mengalami crash saat mengakses fitur lama dan rating Google Play memburuk Security debt (utang keamanan) Saat menggunakan tech stack yang memiliki kerentanan keamanan seperti brute-force password attack, kebocoran data, dan sebagainya Banyak organisasi memiliki utang keamanan karena manusia memang sulit merencanakan dan mengevaluasi hal-hal yang mungkin terjadi atau mungkin tidak terjadi Contoh) karena masalah proses internal, perusahaan gagal melakukan update tepat waktu sehingga tidak bisa menambal kerentanan yang sudah diketahui, lalu data pribadi pelanggan bocor (dari perusahaan kecil sampai perusahaan seperti Equifax yang berdampak pada 140 juta orang) Technical product debt (utang produk teknis) Saat dampak negatif pada produk terlihat jelas Ini adalah utang yang paling mudah dipahami dan paling baik untuk diselesaikan karena berdampak pada pengguna, dan semua tim di organisasi bisa melihat efeknya terhadap penjualan/pendapatan Contoh) pengguna membutuhkan beberapa detik untuk melakukan tugas tertentu di dalam produk. Hal ini bisa muncul dari berbagai jenis utang, tetapi tetap memengaruhi pengalaman inti pengguna terhadap produk Decision debt (utang keputusan) Saat harus membayar biaya dari keputusan teknis sebelumnya karena keputusan itu salah sebesar X% atau karena ada trade-off dari sisi scope, waktu, atau sumber daya Ini adalah bentuk utang teknis yang paling umum Contoh) sebuah website menggunakan pihak ketiga untuk eksperimen tertentu. Setelah tumbuh pesat selama beberapa tahun, kini situs itu dikunjungi jutaan pengguna. Akibatnya, tim teknis, data, dan produk semuanya kesulitan setiap kali ingin menjalankan eksperimen yang kompleks. Ini menjadi utang keputusan karena tim saat itu membuat keputusan trade-off antara memakai pihak ketiga atau membangunnya sendiri. Mungkin itu keputusan yang benar pada saat itu, tetapi sekarang dampaknya mulai terasa Menentukan skala utang teknis: Acute vs Systemic Setelah memahami jenis utang teknisnya, berikutnya perlu menentukan skala biayanya agar bisa dibandingkan dengan manfaat yang akan didapat Saat tim bertanya, 'kapan kita akan punya waktu untuk mengerjakan utang teknis?', sering kali sulit mengetahui apakah itu kecil atau besar dari sisi waktu, pemikiran, dan usaha Acute (akut) technical debt Utang teknis yang relatif kecil Contoh) untuk merilis fitur baru, pekerjaan untuk platform/browser dengan skala penggunaan kecil dilewati dulu. Jika tidak ada hal lain, itu bisa ditambahkan dengan mudah dalam satu hari Systemic (sistemik) technical debt Utang teknis berskala besar hingga sangat besar Contoh) CTO/pendiri membuat keputusan terkait produk (secara tidak langsung juga teknologi) lima tahun lalu, dan berbagai upaya dibangun di atas keputusan itu. Jika diubah, banyak hal akan ikut terdampak. Utang teknis ini tidak mudah diselesaikan dan perubahannya bisa memakan waktu dari beberapa bulan hingga beberapa tahun Menetapkan prioritas utang teknis secara strategis Cara mempertimbangkan dan mengevaluasinya secara fleksibel Confidence: seberapa besar kemungkinan ini akan mengarah ke masalah serius? rendah/tinggi Time: kapan ini akan menjadi masalah? tidak mendesak/mendesak Impact to User: jika ini tidak dilakukan, apakah akan muncul masalah kecepatan/kualitas yang merusak pengalaman pengguna? rendah/tinggi Sequence: apakah ini menghalangi tercapainya milestone penting? dampak kecil/memblokir Accumulated debt: seberapa banyak utang yang sudah kita putuskan untuk ditumpuk? sedikit/banyak Portofolio utang teknis strategis menurut tahap pertumbuhan perusahaan Traction: Sebelum Product-Market fit Keputusan engineering harus lebih memprioritaskan kecepatan daripada akurasi, stabilitas, atau proses. Utang efisiensi developer dalam skala besar Umumnya berarti memilih full-stack framework seperti Django, Rails, PHP, dan lain-lain agar bisa berkembang cepat Inflection: Saat mulai ada tanda-tanda PMF dan produk beralih ke loop yang dapat diskalakan Tim mulai sadar bahwa sebagian proses dibutuhkan (utang efisiensi developer mulai terselesaikan), tetapi karena masih menyeimbangkan proses internal dan pengalaman pengguna, utang produk teknis meningkat Scale: Fase hyper-growth perusahaan Sambil mencari keseimbangan antara praktik/proses internal dan pengalaman pengguna, utang produk teknis dan utang efisiensi developer mulai menurun dan stabil Sebagai hasil dari pertumbuhan yang sangat cepat, utang keamanan, utang pemeliharaan, dan utang keputusan meningkat Banyak perubahan dan perbaikan terjadi pada otomatisasi testing, sistem deployment, monitoring dan alert, logging dan instrumentation, testing dan staging, ETL, dan lain-lain Expansion: Awal dari saturation. Bisnis menjadi lebih matang Karena banyaknya kode lama dan keputusan lama, utang pemeliharaan serta utang keputusan terus meningkat Saat tim mencari peluang pertumbuhan baru, utang efisiensi developer mulai meningkat lagi Utang produk teknis, utang keamanan, dan utang stabilitas sedang bergerak menuju keseimbangan setelah periode sebelumnya Tips untuk mengelola portofolio utang teknis Proses untuk mengurangi utang teknis yang tercipta Meski menumpuk utang teknis bisa menjadi strategi, dalam beberapa kasus justru lebih tepat menerapkan proses sejak awal agar utang teknis tidak tercipta Ini особенно berlaku pada tahap Inflection dan Scale, ketika utang efisiensi developer seharusnya mulai menurun seiring bergabungnya lebih banyak engineer Saat utang efisiensi developer menurun, hal itu bisa tergantikan oleh peningkatan utang keputusan dan utang pemeliharaan Contoh proses seperti ini: code/PR review, standar monitoring, persetujuan QA, serta review teknis/desain Alat untuk mencegah terbentuknya jenis utang tertentu Investasi pada alat dasar dapat mencegah terbentuknya beberapa jenis utang Sangat penting terutama pada tahap Scale untuk isu keamanan (utang keamanan), pencegahan bug yang memengaruhi pengalaman pengguna (utang produk teknis), dan konsistensi kode (utang efisiensi developer) Contoh alat semacam ini: linter dan pipeline CI/CD Pekerjaan sprint untuk reactive & acute technical debt Saat organisasi mencapai skala yang membutuhkan on-call, sprint on-call harus digunakan untuk memadamkan kebakaran yang sedang terjadi atau pekerjaan respons terkait utang teknis Dengan cara ini, organisasi dapat menangani item utang teknis yang mendesak, dan tim on-call dapat benar-benar mengambil tindakan terhadap masalah saat ini maupun masa lalu Memungkinkan on-call untuk pekerjaan respons sangat penting terutama pada tahap pertumbuhan Scale/Expansion. Menangani utang teknis yang mendesak memungkinkan tim lain membangun fitur/produk baru sambil mengelola utang tambahan Pekerjaan roadmap untuk utang teknis yang proaktif dan sistemik Memasukkan utang teknis ke dalam roadmap membutuhkan penyelarasan lintas banyak tim Contoh memasukkan utang teknis ke roadmap: rewrite besar-besaran, penataan ulang sistem data untuk fitur yang paling sering digunakan pelanggan, mendefinisikan dan mengimplementasikan alert untuk jalur utama, perpindahan sistem pembayaran, dan sebagainya Cara mengubah utang teknis dari beban menjadi sarana strategis Dengan utang teknis yang telah terakumulasi, tim dapat mengambil keputusan strategis secara menyeluruh tentang inisiatif apa yang akan dijalankan Pikirkan asumsi-asumsi umum tentang utang teknis yang mungkin dihadapi tim. Apakah Anda menentang gagasan seperti 'utang teknis = hal buruk' atau 'utang teknis ≠ pekerjaan produk'? Apakah Anda mendengar rekan kerja yang menganggap 'rasa sakit individu = rasa sakit organisasi'? Jangan gunakan istilah payung 'utang teknis'. Beri nama yang lebih spesifik: utang pemeliharaan, utang efisiensi developer, utang stabilitas, utang keamanan, utang produk teknis, dan utang keputusan Tentukan skala utang teknis agar tidak terlalu ambigu. Apakah ini Acute atau Systemic? Tetapkan prioritas utang teknis secara strategis dengan membandingkannya dengan area lain di perusahaan. Gunakan vektor seperti tingkat keyakinan, waktu, dampak terhadap pengguna, dan sebagainya Evolusikan dan jaga keseimbangan portofolio utang teknis sesuai perubahan dan kebutuhan yang muncul seiring pertumbuhan perusahaan

(reforge.com)

47 poin oleh xguru 2023-03-20 | 2 komentar | Bagikan ke WhatsApp

Hal-hal yang diperlukan untuk memandang utang teknis sebagai sarana strategis
- Mengenali dan mengatasi asumsi negatif tentang utang teknis
- Mengklasifikasikan 6 jenis utang teknis dan menanganinya secara berbeda
- Mengukur skala utang teknis
- Cara menentukan prioritas utang teknis

How to Not Manage Tech Debt

4 asumsi yang membuat utang teknis dikelola dengan keliru

Asumsi #1 : utang teknis = hal buruk

Tidak semua utang teknis harus diklasifikasikan sebagai sesuatu yang 'buruk'
Jauh lebih baik memberi nama, mengukur tingkat rasa sakitnya, lalu mengelompokkan utang teknis tersebut
Ada utang teknis yang justru baik untuk dimiliki, dan semua tim seharusnya memiliki utang teknis
Contoh Twitter yang 'memiliki utang teknis yang baik': menggunakan storage publik lalu mengembangkan Manhattan, DB terdistribusi milik mereka sendiri
Pertanyaan untuk menanggapi asumsi 'utang teknis = hal buruk'
- Jika kita menumpuk utang teknis ini sekarang dan menyelesaikannya bulan depan, apa yang akan kita dapatkan?
- Dalam situasi seperti apa manajemen akan peduli dengan utang teknis ini? Informasi seperti apa yang perlu disampaikan agar membantu CTO mem-pitch hal ini ke manajemen?
- Bagaimana inisiatif ini dapat terhubung ke visi perusahaan yang lebih besar atau arah strategisnya?

Asumsi #2 : semua utang teknis = pekerjaan yang kompleks

Seperti halnya pekerjaan sulit lainnya, ada banyak cara untuk menangani pekerjaan yang kompleks, bukan hanya pada utang teknis
Khusus untuk utang teknis, ada pendekatan terhadap pekerjaan Defined/Undefined (terdefinisi/tidak terdefinisi)
- Defined = pekerjaan memiliki awal dan akhir
- Undefined = pekerjaan punya awal, tetapi akhirnya tidak jelas
Untuk menanggapi asumsi bahwa utang teknis = kompleks
- Perjelas apakah utang teknis yang dihadapi termasuk Defined atau Undefined
  - Untuk Defined, pahami estimasi waktu penyelesaian dan sediakan sedikit buffer waktu
  - Untuk Undefined, daftar bagian-bagian yang belum jelas dan sampaikan ke para pemangku kepentingan agar mereka memahami mengapa pekerjaan ini kompleks dan tidak memiliki tanggal selesai yang pasti, lalu minta pendapat tentang cara terbaik untuk maju
- Pecah utang teknis Undefined menjadi bagian pekerjaan yang lebih mudah dicerna agar tidak terlalu kompleks
  - Jika pekerjaan besar yang rumit dipecah menjadi tugas kecil yang tetap kompleks namun bisa dieksekusi, tim dapat lebih termotivasi untuk menyelesaikan sebagian utang teknis dalam periode sprint/kuartalan yang sudah ditentukan
Pertanyaan untuk menanggapi asumsi 'utang teknis = pekerjaan yang kompleks'
- Asumsi keliru apa yang kita miliki tentang sistem ini?
- Jika kita membawa orang yang berpengalaman atau familier di bidang ini, pertanyaan apa yang wajib kita ajukan?
- Apakah tim kita memiliki orang dan pengetahuan yang tepat untuk mengerjakan ini? Jika tidak, bagaimana kita sebaiknya mempertimbangkan redistribusi informasi, dan kapan waktu paling ideal untuk menyelesaikan masalah ini?
- Apa cara terbaik menjelaskan kompleksitas utang teknis ini kepada orang yang sama sekali tidak memahaminya?

Asumsi #3 : utang teknis ≠ pekerjaan produk

Organisasi biasanya jelas soal bagaimana pekerjaan produk akan meningkatkan metrik perusahaan
Namun, utang teknis sering kali tidak ikut dimasukkan dalam pembahasan ini
Menyelesaikan utang teknis pada waktu yang tepat dapat menjadi hal penting untuk mendorong pertumbuhan perusahaan, meskipun dampaknya tidak selalu bisa langsung diukur secara kuantitatif
Untuk menanggapi asumsi bahwa utang teknis ≠ pekerjaan produk
- Meski area tertentu dari utang teknis tidak terhubung langsung ke metrik, pikirkan secara lebih luas bagaimana hal itu dapat membantu pengalaman pengguna/produk
- Alih-alih hanya menonjolkan manfaat teknis, jika manfaat bagi pengguna dan produk juga ditekankan secara setara, orang lain akan lebih mudah memahami mengapa tim perlu peduli pada pekerjaan ini
- Luangkan waktu untuk memastikan business lead dan technical lead benar-benar memahami hal yang sama (on the same page)
Pertanyaan untuk menanggapi asumsi 'utang teknis ≠ pekerjaan produk'
- Apa satu alasan terpenting mengapa pekerjaan ini harus dilakukan sekarang?
- Siapa yang perlu memahami dampak pekerjaan ini? Mengapa mereka harus peduli?
- Apa yang sebenarnya ingin saya sampaikan? Apakah itu sejalan dengan apa yang ingin didengar para pemangku kepentingan? Jika tidak, bagaimana saya bisa membantu memecahkan masalah mereka?
- Apa yang saya atau tim anggap sebagai hasil yang wajar vs. hasil yang luar biasa?
- Apakah kita menjanjikan hasil secara berlebihan? Bisakah ekspektasi dibagi antara hasil yang luar biasa dan yang cukup baik agar lebih realistis?

Asumsi #4 : rasa sakit individu = rasa sakit organisasi

Engineer yang dekat dengan utang teknis sering berulang kali mengatakan bahwa menangani utang teknis itu menyakitkan secara pribadi
Bagi karyawan, hal itu bisa terasa seperti kiamat, tetapi orang lain di organisasi belum tentu merasakan rasa sakit yang sama
Ini umum terjadi pada orang di tahap awal karier dan biasanya muncul karena kurangnya konteks strategis yang lebih luas
Untuk menanggapi asumsi bahwa rasa sakit individu = rasa sakit organisasi
- Saat menyentuh area utang teknis berprioritas tinggi, berhentilah sejenak untuk melihat apakah ini merupakan pain point pada level individu atau level organisasi
  Secara umum, masalah di level organisasi akan berdampak langsung pada pelanggan atau bisnis dalam satu bentuk atau lainnya
- Cobalah melihatnya dari sudut pandang orang yang memiliki konteks organisasi lebih besar daripada Anda. Menjelaskannya kepada seseorang dari tim lain juga bisa membantu
Pertanyaan untuk menanggapi asumsi 'rasa sakit individu = rasa sakit organisasi'
- Berapa banyak tim yang akan mendapatkan manfaat jika utang teknis ini diklasifikasikan dan diselesaikan?
- Kapan perusahaan pernah mengakui atau memberi penghargaan kepada seseorang yang menangani pekerjaan utang teknis? Jenis utang teknis apa itu, dan mengapa saat itu dianggap perlu? Bisa ceritakan bagaimana orang tersebut memosisikan pekerjaannya?
- Apakah engineering manager saya memahami nilai dari pekerjaan utang teknis? Apakah dia akan mengadvokasi kontribusi saya dalam pekerjaan ini saat performance review?