- Yaklaşık 45 kişilik mühendislik organizasyonu, her çeyrekte bir hafta boyunca yol haritası, tasarım ve toplantıları durdurup ‘Fixit haftası’ düzenleyerek küçük hataları ve verimlilik sorunlarını çözmeye odaklanıyor
- Bu Fixit sürecinde 189 hata düzeltildi; 40 kişi katıldı, kişi başına medyan 4, en fazla 12 hata kapatıldı
- 2 gün içinde çözüm kuralı, puan ve lider tablosu sistemi, tişört ödülleri gibi unsurlarla motivasyon ve ekip morali artırıldı
- Yapay zeka araçlarının kullanımı, kod keşfi ve düzeltme önerilerini hızlandırarak bağlam değiştirme yükünü azalttı
- Fixit’in, ürün kalitesini artırırken ekip bağlarını da güçlendiren ve küçük sorunları çözmenin keyfini yeniden canlandıran bir kültür olduğu değerlendiriliyor
Fixit kavramı ve işleyiş biçimi
- Fixit, her çeyrekte bir hafta süren yoğun bir hata düzeltme haftası; bu sürede normal yol haritası çalışmaları, tasarım ve toplantılar tamamen durduruluyor
- Mühendisler, kullanıcıların ve geliştiricilerin rahatsız olduğu küçük hataları veya verimlilik düşüren etkenleri çözüyor
- Örnekler: 2 yıldır belirsiz kalan bir hata mesajı, aynı anda kaydırma ve yakınlaştırma sırasında oluşan bir görsel bozulma, yavaş testler nedeniyle CI gecikmesi
- İki kural var
- Hiçbir hata 2 günden uzun sürmemeli
- Çalışmalar son kullanıcı iyileştirmesi veya geliştirici verimliliği artışı üzerine odaklanmalı
- Puan sistemi ve lider tablosu ile katılım görünür kılınıyor; ‘ilk hata düzeltmesi’, ‘en sinir bozucu hatanın düzeltilmesi’ gibi farklı kategorilerde tişört ödülleri veriliyor
Fixit sonuçları
- Bu Fixit’in sonuçları
- 189 hata düzeltildi, 40 kişi katıldı, kişi başına medyan 4, en yüksek 12
- Öne çıkan örnekler
Fixit’in etkileri
-
Ürün açısından: incelik ve tamamlanmışlık
- İyi bir ürünün özelliği, ayrıntılara gösterilen dikkat ve tutarlılık
- Fixit, kullanıcıların doğrudan fark etmeyebileceği küçük rahatsızlık unsurlarını ortadan kaldırarak ürün kalitesini bir seviye yukarı taşıma fırsatı sunuyor
-
Bireysel açıdan: uygulama odaklı tatmin
- Kariyerin ilk dönemlerinde hissedilen “sorunu bul → düzelt → yayımla” döngüsündeki anlık başarı hissini geri getiriyor
- Fixit sırasında ‘ne inşa edelim?’ yerine ‘nasıl iyileştirelim?’ sorusuna odaklanılıyor; kısa döngülerle başarı hissi birikiyor
-
Ekip açısından: moral ve iş birliğinin güçlenmesi
- İki zaman dilimindeki 40 kişi aynı anda hata düzeltirken organizasyon genelinde enerji yükseliyor
- Sohbet odalarında anlık düzeltme paylaşımları, ekran görüntüleri, demo gösterimleri gibi canlı etkileşimler yaşanıyor
- Her sabah düzeltilen hata sayısı, katılımcı sayısı ve lider tablosu sıralaması paylaşılarak motivasyon güçlendiriliyor
Başarılı bir Fixit için gereklilikler
-
Ön hazırlık
- Yıl boyunca hatalar “good fixit candidate” etiketiyle işaretleniyor; Fixit’ten önceki hafta küçük, orta, büyük (0.5, 1, 2 gün) olarak sınıflandırılıyor
- Her boyuta göre 1, 2, 4 puan veriliyor ve öncelikli hata listesi hazırlanıyor
- Bu hazırlık süreci, ilk gün yaşanabilecek karmaşayı önlemenin temel unsuru
-
2 günlük sınır kuralı
- Geçmişte bir hatanın beklenenden daha karmaşık çıkıp tüm Fixit haftasını tükettiği bir örnek yaşandı
- Bunun ardından 2 günü aşan işlerin durdurulup backlog’a taşınması ilkesi benimsendi; amaç sürekli başarı hissini korumak
-
Katılımcı sayısının ölçeği
- Başlangıçta 7 kişilik ölçekte sonuç alındı ancak organizasyon genelinde yeterli ortak his oluşmadı
- Yaklaşık 40 kişi seviyesinde kritik kütle oluşuyor ve kolektif enerji ile odaklanma en üst düzeye çıkıyor
-
Oyunlaştırma
- Puanlar doğruluktan çok eğlence odaklı (1/2/4 puan)
- Başarı geniş bir yelpazede tanınıyor: ilk düzeltme, en sinir bozucu hata gibi farklı kategoriler
- Performans değerlendirmesinden ayrı tutuluyor, böylece saf katılım motivasyonu korunuyor
- Sosyal normlar ve ekip ölçeği sayesinde sistemin kötüye kullanımı neredeyse hiç görülmüyor
Yapay zeka araçlarının rolü
- Yapay zeka, Fixit’in temel zorluklarından biri olan bağlam değiştirme yükünü azaltıyor
- İlgili dosyaları bulup özetlemeyi hızlandırarak bilişsel yükü düşürüyor
- Örnekler
- Sonuç olarak başlangıç noktasına ulaşma hızı artıyor ve bazı durumlarda anında düzeltme mümkün oluyor
Fixit’e yönelik eleştiriler ve yanıtlar
-
“Bu, normalde hataların göz ardı edildiği anlamına gelmiyor mu?”
- Kısmen doğru; ancak küçük rahatsızlık veren hataların (papercut bugs) öncelik sıralamasında geriye düşmesi gerçeğini telafi ediyor
- Fixit, “küçük ama önemli sorunları” çözmek için açık biçimde ayrılmış zaman yaratmanın bir yolu
-
“Yol haritası çalışmalarını durdurmak israf değil mi?”
- 40 kişi ve 1 haftalık emek büyük görünebilir; ancak ürün kalitesindeki artış ve kullanıcı memnuniyetindeki yükseliş bunu dengeliyor
- Test hızının artması, hata mesajlarının netleşmesi, iş akışlarının kısalması gibi verimlilik kazanımları uzun vadede kalıcı oluyor
-
“Bu yöntem sadece büyük şirketlere mi uygun?”
- Küçük ekipler de bunu ‘Fixit Friday’ veya 2 günlük mini Fixit gibi formatlara uyarlayabilir
- Önemli olan, odaklanmış ve korunan bir zaman dilimi ile ortak iyileştirme faaliyeti
Fixit’in özündeki değer
- Resmî amaç, ürün kalitesini ve geliştirici verimliliğini artırmak
- Gayriresmî neden, “bir şeyi düzeltmenin keyfi”
- Bunun, daha sade dönemlerin tatminini geri getiren ve özenli ürün geliştirme kültürünü ayakta tutan temel bir unsur olduğu düşünülüyor
2 yorum
Baemin’in pit stop kültürünü hatırlattı. Şu anda artık olmadığını duydum.
Hacker News görüşleri
Fikir hoşuma gidiyor ama "hatalar 2 günden uzun sürmemeli" cümlesi tuhaf geliyor
Gerçekte, bir hatayı düzeltmeden önce ne kadar süreceğini tahmin etmek neredeyse imkansızdır
Yine de büyük bir refactoring gerekmiyorsa, bir günden uzun sürmesi gereken işler pek olmaz diye düşünüyorum
Ben genelde hataları ciddiyet veya öncelik düzeyine göre ele alıyorum. Ağır hataları bulmak bazen şaşırtıcı biçimde daha kolay oluyor
Nedeni bulunduğunda çözüm hızlı geliyor
Yıllarca logları analiz ettik ama nedeni bulamadık; sonra belirli bir durumdaki DB ve commit kombinasyonunda %100 yeniden üretilebildiğini keşfettik
NDA imzalayıp minimum yeniden üretim binary'sini oluşturduk ve bunu bir PowerShell script'iyle otomatikleştirdik; MS bir ay içinde düzeltti
İçeride olan şey buffer overflow gibi görünüyordu ama emin değilim
Bir hafta boyunca sadece hata düzeltip Jira'da story point biriktiremediğinizde, birkaç yönetici başınıza üşüşüp neden hızın düşük olduğunu sorardı
Bu yüzden öğrendiğim ders şu oldu: zor hatalardan kaçınmak ve puan getirmeyen işlerden erken vazgeçmek daha iyi
Sorunun kodda mı, compiler'da mı, donanımda mı olduğunu anlayamıyorsunuz ve aynı anda birbirine dolanan birden fazla unsurdan doğan bileşik hatalar bazen tek başına yeniden üretilemez bile
Böyle durumlarda hızlı geçici çözümler biriktikçe, sonradan yapılacak düzgün hata düzeltmeleri büyük çaplı rework'e dönüşüyor
Ayrıca düşük güven ortamlarında, Jira süreçleri yüzünden küçük bir hata bile hemen düzeltilemeyebilir
Meta'da çalışırken her çeyrekte Fix-it Week yapardık
Başta liderliğin kaliteyi önemsediğini düşündüm ama gerçekte bu, teknik borç biriktirme ruhsatı verilen dönem gibiydi
Bir hafta boyunca hata düzeltmeye çalıştık ama birikmiş borç yüzünden neredeyse hiçbir şeyi çözemiyorduk
Aksi halde yeni kod hatanın üstüne yığılır ve istikrarsız bir temel oluşur
John Romero'nun konuşma videosu da aynı felsefeyi vurguluyor
Geliştiriciler geçmişte bıraktıkları TODO'ları ele alıp LOC artırıyordu; hatta bazıları sonradan "düzeltmek" için bilerek yanlış kod yazarak diff sayısını şişirme hilesi bile yapıyordu
Yani acil olmayan ama rahatsız eden sorunları ele alma zamanıdır
Liderliğin dürüst biçimde iş önceliklerini açıklaması ve hataların kullanıcı üzerindeki etkisini net göstermesi daha önemli
Özellik geliştirme sırasında acil müdahale ve öncelik değişimlerinin tekrarlandığı bir kısır döngü yaşadım
Sonunda sistem workaround dolu hale geliyor, hem müşteri hem geliştirici memnuniyetsiz oluyor
Böyle bir durumda en baştan durup temel hata düzeltmelerini yapmak daha doğru olurdu diye düşünüyorum
İletişim kopar, liderler başsız tavuk gibi koşturup durur ve sadece emir verir
Geliştiriciler tüm sorunların itfaiyecisine dönüşür ve sonunda tek çözüm oradan çıkmaktır
Hız düştükçe lider daha çok paniğe kapılıp projeyi oraya buraya savurarak kaos ve toksik kültürü büyütür
Ben her zaman "önce hata düzeltme" felsefesiyle çalıştım
Mevcut işlevler düzgün çalışmıyorsa yeni özellik geliştirmem
Bu yaklaşım hatasız bir codebase korumayı sağlar ve ekip verimliliğini artırır
Özellikle frontend'de, çeşitli ortam sorunları nedeniyle tam anlamıyla hatasız olma durumu neredeyse imkansız
Ayrıca "hata" tanımı muğlak olduğundan, yöneticinin istediği bir özellik bile hata diye sınıflandırılabiliyor
Örneğin neredeyse hiç kullanılmayan bir API sayfasındaki hata, yeni bir özellikten daha az önemli olabilir
Bunların çoğu küçük sorunlardır; bu yüzden liderlik yeni özellikleri daha çok tercih eder
Küçük bir SaaS ürünü işletiyorum ve "önce hata düzeltme" ilkesine bağlı kalıyorum
Yeni özelliklerden önce müşterilerin bildirdiği hataları çözüyorum
Bunu yaptığınızda yeni bulunan hata sayısı giderek azalıyor ve düzeltmeleri de kolaylaşıyor
İş açısından verimsiz olabilir ama kalite ve müşteri güveni bakımından en iyi strateji bu
Müşteriler bildirdikleri hatanın birkaç saat içinde düzeltilmesine gerçekten seviniyor
Fix-it Week gibi uygulamalar aslında hata düzeltmeyi geciktirmeyi teşvik ediyor
"Sonra Fix-it Week'te yaparız" diye bir bahane doğuyor
Bunun yerine çeyrek veya sprint planına bakım zamanını açıkça dahil etmenin daha iyi olduğunu düşünüyorum
Böylece geliştiricinin hatayı hemen düzeltmek için meşru zemini olur ve sürekli iyileştirme kültürü yerleşir
Fix-it Week'i ise daha çok küçük iyileştirmeleri veya POC'leri içeren mini bir hackathon gibi yürütmek daha iyi olur
Eski şirketim hep aynı döngüyü tekrar ediyordu
Bu örüntü, şirket kültüründe bir şeylerin yanlış olduğunun işaretiydi. Normal zamanda hata düzeltme için vakit ayrılmazsa bu asla değişmez
Eskiden Joel Spolsky'nin ortaya attığı Joel Test aklıma geliyor
Beşinci soru şuydu: "Yeni kod yazmadan önce hataları düzeltiyor musunuz?"
25 yıl sonra bugün bile hâlâ geçerli bir ölçüt
Orijinal bağlantı
Ben, hatalara puan veya boyut tahmini verilmemesi gerektiğini düşünüyorum
İlla puan gerekiyorsa hepsine 2 verin; ortalamada doğru çıkar
Hata düzeltmeleri Kanban yöntemiyle, önem sırasına göre ele alınıp zamanında bitirilebilir
Yazının yazarıyım. Canlı bir tartışma çıkmasına sevindim
Bu, teknik hijyen ya da büyük sorunları çözmenin yerine geçen bir yöntem değildi