- Teknik borca stratejik bir araç olarak bakmak için gerekenler
- Teknik borca dair olumsuz varsayımları fark edip ele almak
- Teknik borcun 6 türünü sınıflandırmak ve her birine farklı yaklaşmak
- Teknik borcun ölçeğini anlamak
- Teknik borca nasıl öncelik verileceğini belirlemek
How to Not Manage Tech Debt
- Teknik borcun kötü yönetilmesine yol açan 4 varsayım
Varsayım #1 : Teknik borç = kötü bir şey
- Tüm teknik borçlar 'kötü' olarak sınıflandırılmamalıdır
- Her birine ad vermek, yarattığı acının büyüklüğünü ölçmek ve teknik borçları buna göre sınıflandırmak çok daha iyidir
- Bazı teknik borçlara sahip olmak faydalıdır ve her ekip teknik borca sahip olmalıdır
- 'İyi teknik borca sahip olan' Twitter örneği: genel amaçlı storage kullanırken, daha sonra kendi dağıtık veritabanı Manhattan'ı geliştirdi
- 'Teknik borç = kötü bir şey' varsayımına karşılık sormak gereken sorular
- Bu teknik borcu şimdi biriktirip gelecek ay çözersek ne kazanırız?
- Yönetim hangi durumda bu teknik borçla ilgilenir? CTO'nun bunu yönetime anlatmasına yardımcı olacak bilgiyi nasıl sunmalıyız?
- Bu girişim şirketin daha büyük vizyonuna veya stratejik yönüne nasıl bağlanabilir?
Varsayım #2 : Tüm teknik borç = karmaşık işler
- Teknik borçta olduğu gibi tüm zor işlerde de karmaşık işleri ele almanın çeşitli yolları vardır
- Özellikle teknik borçta Defined/Undefined (tanımlı/tanımsız) işlere yaklaşım kullanılabilir
- Defined = işin bir başlangıcı ve bitişi vardır
- Undefined = işin bir başlangıcı vardır ama sonu net değildir
- Teknik borç = karmaşıktır varsayımına karşılık vermek için
- Önünüzdeki teknik borcun Defined mı Undefined mı olduğunu netleştirin
- Defined ise işi tamamlamak için gereken tahmini süreyi anlayın ve biraz tampon süre ekleyin
- Undefined ise işin neden karmaşık olduğunu ve neden net bir bitiş tarihi olmadığını anlamak için belirsiz noktaları listeleyin, bunları paydaşlara aktarın ve ilerlemek için en iyi yol konusunda görüş isteyin
- Undefined teknik borcu daha kolay hazmedilebilir parçalara ayırarak daha az karmaşık hale getirin
- Karmaşık ve büyük bir işi, hâlâ karmaşık ama uygulanabilir küçük işlere dönüştürmek; ekibin sprint veya çeyrek gibi belirli dönemlerde teknik borcun bir kısmını çözmek için daha motive olmasını sağlayabilir
- 'Teknik borç = karmaşık iş' varsayımına karşılık sormak gereken sorular
- Sistem hakkında hangi yanlış varsayımlara sahibiz?
- Bu alanda deneyimli veya aşina birini getirsek mutlaka sormamız gereken sorular neler olur?
- Ekibimizde bu işi yapmak için doğru insan kaynağı ve bilgi var mı? Yoksa bilgiyi nasıl yeniden dağıtmayı düşünmeliyiz ve bu sorunu çözmek için en ideal zaman ne zaman olur?
- Bu teknik borcun karmaşıklığını hiç anlamayan birine bunu anlatmanın en iyi yolu nedir?
Varsayım #3 : Teknik borç ≠ ürün işi
- Organizasyonlar ürün işinin şirket metriklerini nasıl iyileştireceği konusunda nettir
- Ama teknik borç genellikle bu resmin dışında kalır
- Teknik borcu zamanında çözmek, etkisi hemen nicel olarak ölçülemese bile şirket büyümesini hızlandırmak açısından önemli olabilir
- Teknik borç ≠ ürün işi varsayımına karşılık vermek için
- Teknik borcun belirli bir alanı metriklerle doğrudan bağlantılı olmasa bile, hangi kullanıcı/ürün deneyimine yardımcı olabileceğini daha geniş çerçevede düşünün
- Teknik faydaları öne çıkarmanın yanı sıra kullanıcı ve ürüne sağlanan faydayı da eşit biçimde vurgularsanız, başkalarının ekibin neden bu işe önem vermesi gerektiğini anlaması kolaylaşır
- İş liderleri ile teknik liderlerin aynı sayfada olduğundan emin olmak için zaman ayırın
- 'Teknik borç ≠ ürün işi' varsayımına karşılık sormak gereken sorular
- Bu işe şimdi başlamamız için en önemli tek neden nedir?
- Bu işin etkisini anlaması gereken kişiler kimler? Neden bunu önemsemeliler?
- Vermek istediğim mesaj ne? Bu, paydaşların duymak istediği şeyle örtüşüyor mu? Örtüşmüyorsa onların sorununu nasıl çözebilirim?
- Benim veya ekibin makul sonuç ile mükemmel sonuç olarak gördüğü şey nedir?
- Beklenen sonuçlar konusunda fazla mı söz veriyoruz? Beklentileri, harika sonuç ve iyi sonuç olarak ayırıp dengeleyebilir miyiz?
Varsayım #4 : Bireysel acı = organizasyonel acı
- Teknik borca yakın çalışan mühendisler, teknik borçla uğraşmanın kişisel olarak ne kadar acı verici olduğunu düzenli olarak tekrarlar
- Çalışan için bu dünyanın sonu gibi gelebilir, ancak organizasyonun geri kalanı aynı acıyı hissetmez
- Bu durum kariyerinin başındaki kişilerde daha yaygındır ve genellikle daha geniş stratejik bağlam eksikliğinden kaynaklanır
- Bireysel acı = organizasyonel acı varsayımına karşılık vermek için
- Teknik borç içinde önceliği yüksek bir alana geldiğinizde, bunun bireysel düzeyde mi yoksa organizasyon düzeyinde mi bir sıkıntı noktası olduğuna kısaca bakın
Genel olarak organizasyon düzeyindeki sorunlar bir şekilde doğrudan müşteriyi veya işi etkiler
- Sizden daha fazla organizasyonel bağlama sahip birinin bakış açısından düşünün. Bunu başka bir ekipten birine anlatmak da yardımcı olabilir
- 'Bireysel acı = organizasyonel acı' varsayımına karşılık sormak gereken sorular
- Bu teknik borcu sınıflandırıp çözerek kaç ekip fayda sağlar?
- Şirket teknik borç işi üstlenen kişiyi ne zaman takdir etti veya ödüllendirdi? Bu hangi tür teknik borçtu ve o sırada neden gerekliydi? O kişi bu işi nasıl konumlandırdı, anlatabilir misiniz?
- Engineering manager'ım teknik borç işinin değerini anlıyor mu? Performance review sırasında bu işe yaptığım katkıyı savunur mu?
Teknik borcun 6 türü
- Maintenance debt (bakım borcu)
- Ekip teknolojideki güncellemeleri takip edemediğinde ortaya çıkar
- Deney başlatma / feature rollout / deploy iptali gibi adımlardan sonra dead code temizlenmemesi, kütüphane güncellemelerinin yapılmaması, bağlam koduna yorum eklenmemesi veya implementasyon kararlarının dokümante edilmemesi de buna dahildir
- Örn.) 'log in with Spotify' özelliği için deney yapıldıktan sonra iptal edilmesine rağmen ilgili kod silinmedi
- Developer efficiency debt (geliştirici verimliliği borcu)
- Şirkette ürün için yeterli test, monitoring ve alerting sistemi olmadığında
- Engineering workflow'un çok verimsiz olduğu; deploy/build işlemlerinin saatler veya günler sürdüğü ve geliştiricilerin production'a çıkmadan önce teknik sorunları tespit edemediği yaygın borç türüdür
- Örn.) Organizasyon bir yıl içinde 15 kişiden 50 kişiye çıkarken çok fazla deney yapılır. Production'da bulunan bug'ları düzeltmeye yönelik release'ler 2-3 sürüm geriden gelir. Satın alma deneyimi için yeni testler de bunun arkasında kalır
- Stability debt (istikrar borcu)
- Organizasyonda çeşitli teknik borçlar birikerek altyapı istikrarını etkilemeye başladığında
- On-call sürecini önceden yönetmek yerine sorun çıktığında ilgili uzman sonradan çağrılır ya da tüm ekip on-call olmak zorunda kalır
- Bu, mühendisler ve on-call rotasyonundaki ekip için büyük bir baş ağrısıdır; ancak şirketin geri kalanının sorunu anlaması ve açıklaması bile zordur
- İstikrar borcu ürünün güvenilirliğini de etkiler ve müşterilerin karşılaştığı sorunlara yol açabilir
- Örn.) Mobil ekipte iOS geliştiricisi sayısı daha fazla olduğu için Android uygulaması yerine iOS'a öncelik verilir. Sonuç olarak Android uygulamasında iş açısından kritik akışlar için ürün yönergeleri eksiktir ve üçüncü tarafın ilk dönemde geliştirdiği zayıf (Kryptonite) kodlar kalır. Bunun sonucunda Android kullanıcıları eski özelliklere erişirken çökme yaşar ve Google Play puanları düşer
- Security debt (güvenlik borcu)
- Brute-force denemeler, veri sızıntıları gibi güvenlik açıkları barındıran bir teknoloji yığını kullanıldığında
- İnsanların gerçekleşebilecek (veya gerçekleşmeyebilecek) olayları planlayıp değerlendirmesi zor olduğundan birçok organizasyonda güvenlik borcu oluşur
- Örn.) Şirket içi süreç sorunları nedeniyle güncellemeler zamanında yapılamaz, bilinen açıklar patch'lenemez ve müşteri kişisel verileri sızar (küçük şirketlerden 140 milyon kişiyi etkileyen Equifax gibi şirketlere kadar)
- Technical product debt (teknik ürün borcu)
- Ürün üzerindeki olumsuz etki görünür hale geldiğinde
- Çözmesi en kolay ve en faydalı borç türlerinden biridir; kullanıcıyı etkiler ve organizasyondaki tüm ekipler bunun satış/gelir üzerindeki etkisini görebilir
- Örn.) Kullanıcının ürün içinde belirli bir işi yapması birkaç saniye sürer. Bunun nedeni farklı borç türleri olabilir ama sonuçta kullanıcının temel ürün deneyimi etkilenir
- Decision debt (karar borcu)
- Önceki teknik bir kararın %X oranında yanlış çıkması ya da kapsam, zaman, kaynak açısından verilen ödünler nedeniyle o kararın bedelinin sonradan ödenmesi
- Teknik borcun en yaygın biçimidir
- Örn.) Web sitesinde belirli bir deney için üçüncü taraf çözüm kullanılır. Şirket birkaç yılda çok büyür ve artık siteye milyonlarca kullanıcı gelir. Sonuç olarak teknik ekip, veri ekibi ve ürün ekibi her karmaşık deneyi yürütürken zorlanır.
Bu, ekibin üçüncü taraf çözüm ile şirket içi geliştirme arasında bir trade-off kararı vermesi nedeniyle oluşan karar borcudur. O zaman için doğru karar olabilir ama artık etkileri hissedilmektedir
Teknik borcun ölçeğini belirlemek: Acute vs Systemic
- Teknik borç türlerini anladıktan sonra, elde edilecek faydayla karşılaştırabilmek için maliyetin ölçeğini belirlemek gerekir
- Ekip 'teknik borç üzerinde çalışacak zamanı ne zaman bulacağız?' diye sorduğunda, bunun zaman, düşünce ve emek açısından küçük mü büyük mü olduğunu anlamak zor olabilir
- Acute (akut) teknik borç
- Görece küçük teknik borç
- Örn.) Yeni bir özellik sunmak için kullanım oranı düşük bir platform/tarayıcı için çalışma atlanmıştır. Başka iş yoksa 1 gün içinde kolayca eklenebilir
- Systemic (sistemik) teknik borç
- Büyükten devasa ölçeğe uzanan teknik borç
- Örn.) CTO/kurucu 5 yıl önce ürün (dolaylı olarak teknoloji) hakkında bir karar vermiş ve ekip bunun üzerine çalışmıştır. Bunu değiştirmek pek çok şeyi etkiler.
Bu teknik borç kolay çözülemez ve değiştirilmesi aylar hatta yıllar sürebilir
Teknik borca stratejik olarak öncelik vermek
- Esnek şekilde değerlendirme ve ele alma yöntemi
- Confidence : Bunun ciddi bir soruna yol açma ihtimali yüksek mi? düşük/yüksek
- Time : Bu ne zaman sorun olur? acil değil/acil
- Impact to User : Bunu yapmazsak kullanıcı deneyimini bozan hız/kalite sorunları ortaya çıkar mı? düşük/yüksek
- Sequence : Bu, önemli bir milestone'a ulaşmayı engelliyor mu? küçük etki/blocker
- Accumulated debt : Ne kadar borç biriktirmeyi zaten seçmiş durumdayız? az/çok
Şirketin büyüme aşamasına göre stratejik teknik borç portföyü
- Traction :
- Product-Market fit öncesi
- Doğruluk, istikrar ve süreçten çok hıza odaklanan engineering kararları alınmalıdır. Büyük ölçekli geliştirici verimliliği borcu oluşur
- Bu genellikle hızlı geliştirme için Django, Rails, PHP gibi full-stack framework'lerin seçilmesi anlamına gelir
- Inflection :
- PMF işaretlerinin görüldüğü ve ürünün ölçeklenebilir döngülere geçtiği dönem
- Ekip bazı süreçlerin gerekli olduğunu fark eder (geliştirici verimliliği borcu çözülmeye başlar), ancak hâlâ iç süreçlerle kullanıcı deneyimi arasında denge kurulduğu için teknik ürün borcu artar
- Scale :
- Şirketin hyper-growth dönemi
- İç pratikler ve süreçlerle kullanıcı deneyimi arasında denge kurarken teknik ürün borcu ile geliştirici verimliliği borcu azalmaya ve istikrar kazanmaya başlar
- Çok hızlı büyümenin sonucu olarak güvenlik borcu, bakım borcu ve karar borcu artar
- Test otomasyonu, deployment sistemleri, monitoring ve alerting, logging ve instrumentation, test ve staging, ETL vb. alanlarda pek çok değişiklik ve düzeltme yapılır
- Expansion :
- Doygunluğun başladığı dönem. İş daha olgun hale gelir
- Eski kodların ve geçmiş kararların çokluğu nedeniyle bakım borcu ve karar borcu artmaya devam eder
- Ekip büyüme için yeni fırsatlar ararken geliştirici verimliliği borcu yeniden artmaya başlar
- Teknik ürün borcu, güvenlik borcu ve istikrar borcu ise önceki döneme göre daha dengeli hale gelmektedir
Teknik borç portföyünü yönetmek için ipuçları
- Oluşan teknik borcu azaltmaya yönelik süreçler
- Teknik borç biriktirmek stratejik olabilir, ancak bazı durumlarda en baştan süreçler kurarak teknik borcun oluşmasını önlemek daha doğrudur
- Bu özellikle daha fazla mühendisin katıldığı ve geliştirici verimliliği borcunun azalması gereken Inflection ve Scale aşamalarında geçerlidir
- Geliştirici verimliliği borcu azaldığında bunun yerini karar borcu ve bakım borcu alabilir
- Bu süreçlere örnek olarak code/PR review, monitoring standartları, QA onayı ve teknik/tasarım incelemeleri verilebilir
- Belirli borç türlerinin oluşmasını önleyen araçlar
- Temel araçlara yatırım yapmak bazı borç türlerinin oluşmasını baştan engelleyebilir
- Özellikle Scale aşamasında güvenlik sorunlarını (güvenlik borcu), kullanıcı deneyimini etkileyen bug'ları (teknik ürün borcu) ve kod tutarlılığını (geliştirici verimliliği borcu) önlemek açısından önemlidir
- Bu araçlara örnek olarak linter'lar ve CI/CD pipeline'ları verilebilir
- Reactive & Acute teknik borç için sprint çalışmaları
- Organizasyon on-call gerektiren bir ölçeğe ulaştığında, on-call sprint'leri mevcut yangınları söndürmeye veya teknik borçla ilgili müdahale işlerine ayrılmalıdır
- Böylece organizasyon acil teknik borç maddelerini ele alabilir ve on-call ekipleri sayesinde mevcut/geçmiş sorunlar için gerçekten aksiyon alabilir
- Müdahale işlerinde on-call kullanabilmek özellikle Scale/Expansion aşamalarında önemlidir. Çünkü acil teknik borcu çözmek, diğer ekiplerin yeni özellikler/ürünler geliştirirken ek borçları da ele alabilmesini sağlar
- Proaktif ve sistemik teknik borç için roadmap çalışmaları
- Teknik borcu roadmap'e koymak, birçok ekip arasında hizalanma gerektirir
- Teknik borcun roadmap'e alınmasına örnekler: büyük çaplı rewrite, müşterilerin yoğun kullandığı bir özelliğin veri sistemini yeniden düzenleme, kritik akışlar için alert tanımlama ve implementasyonu, ödeme sisteminin değiştirilmesi gibi
Teknik borcu bir yükten stratejik araca dönüştürmek
- Birikmiş teknik borç üzerinden ekip, hangi inisiyatifleri yürüteceğine dair genel stratejik kararlar alabilir
- Ekipte sık görülen teknik borç varsayımlarını düşünün. "Teknik borç = kötü bir şey" ya da "Teknik borç ≠ ürün işi" görüşüne karşı mısınız? "Bireysel acı = organizasyonel acı" diye düşünen bir çalışma arkadaşınızı dinliyor musunuz?
- "Teknik borç" gibi kapsayıcı bir terim kullanmayın. Bunun yerine bakım borcu, geliştirici verimliliği borcu, istikrar borcu, güvenlik borcu, teknik ürün borcu ve karar borcu gibi adlar verin
- Belirsizliği azaltmak için teknik borcun ölçeğini belirleyin. Acute mı Systemic mi?
- Teknik borca, şirketin diğer alanlarıyla kıyaslayarak stratejik öncelik verin. Güven düzeyi, zaman, kullanıcı etkisi gibi vektörler üzerinden önceliklendirin
- Şirket büyüdükçe değişen ihtiyaçlara göre teknik borç portföyünü evrimleştirin ve dengede tutun
2 yorum
Bence en temel ve en önemli nokta, bunun "işte sizin acınız" olduğunu net bir şekilde göstermek. Bu ister sayılarla olsun ister başka bir şeyle.
Bunu yapamıyorsanız, açıkçası belki de bunun teknik borç olmadığı sonucuna varmak da mümkün olabilir.