“Bu sadece bir anlık iş”
Bir web sitesi, uygulama veya sistem oluşturma ya da bakımında çalışan herkes bu ifadeyi bilir.
“Sadece bu düğmeyi değiştirebilir misiniz?”
“Bu gerçekten küçük bir düzeltme.”
“Lütfen sadece bu elementi kaydırın.”
“Bunu çabucak yapabilir misiniz?”
“Sanırım 5 dakika sürer, değil mi?”
Ve bazen gerçekten de öyledir.
Bazen bir düğme renginin değiştirilmesi birkaç dakika sürer. Bazen bir yazım hatasını düzeltmek bir tıklama gerektirir. Bazen geliştirici kodu açar, bir satırı değiştirir ve iş biter.
Sorun şu ki, kullanıcı perspektifinden küçük görünen her değişiklik, sistem perspektifinden de küçük olmayabilir.
Ve daha büyük sorun, böyle “küçük değişiklikler” ayda on, kırk veya yüz adet olduğunda ortaya çıkar. O zaman ilginç şeyler olmaya başlar.
Şirket, aslında büyük bir şey sipariş etmediğini düşünebilir. Aynı zamanda BT ekibi bu küçük görevlerin gerçekleştirilmesine önemli bir zaman harcar.
Ve burada soru ortaya çıkar: Bir "Hemen düzeltin" düğmesi gerçekte ne kadar tutar?
Basit bir örnekle başlayalım
Diyelim ki pazarlama departmanı bir yazılım şirketine şu mesajı gönderiyor:
“Hey, sadece düğmenin üzerindeki metni değiştirmemiz gerekiyor. ‘Teklifinize göz atın’ yerine ‘Teklifimizi keşfedin’ olmalı. Küçük bir şey, lütfen çabucak yapın.”
Basit gibi geliyor. Ama teknik ekip açısından durum tamamen farklı görünebilir.
Geliştirici şunları yapmak zorunda:
1. Talebi analiz etmek
Düğme nerede bulunuyor?
Sadece tek bir yerde mi?
Sayfanın birkaç versiyonunda mı görünüyor?
Metin doğrudan kodda mı yazılı?
Bir CMS tarafından mı yönetiliyor?
Değişiklik masaüstü ve mobil versiyonları mı kapsıyor?
Düğme, başka yerlerde kullanılan bir bileşenin parçası mı?
2. Değişikliği uygulamak
Metni değiştirmek.
Bileşeni yeniden yapılandırmak.
CMS içeriğini güncellemek.
Ya da kodu düzenlemek.
3. Sonucu kontrol etmek
Düğme hâlâ doğru görünüyor mu?
Metin düğmenin alanından taşıyor mu?
Mobilde her şey düzgün çalışıyor mu?
Değişiklik başka yerleri etkilemiş olabilir mi?
4. Test etmek
Düğmeye tıklanabiliyor mu?
Link doğru yere gidiyor mu?
Hata oluştu mu?
5. Değişikliği dağıtmak
Eğer değişiklik deploy gerektiriyorsa, üretim ortamına konulmalı.
Ve birdenbire ortaya çıkar ki: “Sadece metin değişikliği”
her zaman demek değildir: “Sadece 5 dakika iş”.
Bir küçük değişiklik ne kadar tutabilir?
Çok muhafazakar bir senaryo varsayalım.
Geliştirici harcar:
- analiz için 15 dakika,
- uygulama için 20 dakika,
- test için 15 dakika,
- hazırlama ve deploy için 10 dakika.
Toplam: 60 dakika çalışma.
Ve burada önemli bir noktaya geliyoruz. Eğer ekibin saatlik ücreti örneğin 200 zł net ise, görünüşte küçük bir değişiklik maliyeti yaklaşık: 200 zł net.
Ama hepsi bu değil. Gerçekte şu ek aşamalar ortaya çıkabilir:
- görevin devri,
- kapsamın netleştirilmesi,
- müşteriye sorular,
- cevap bekleme süresi,
- değişikliği talep eden kişinin sonucu kontrol etmesi,
- geri bildirim sonrası düzeltme,
- yeniden deploy.
Bir saat kolayca iki saate dönüşebilir. Ve bir küçük değişiklik tüm ekibin birkaç saatlik çalışmasına dönüşebilir.
En pahalı olan değişikliği yapmak değil
Bu paradoksal gelebilir. Bazen görevin yapılması 10 dakika sürer. Ama ona hazırlanmak için ek 20 dakika gerekir. Sonra testler, deploy, iletişim ve bağlam değiştirme eklenir.
Ve genellikle en çok göz ardı edilen unsur bağlam değiştirmedir.
Context switching - küçük görevlerin gizli maliyeti
Geliştirici büyük bir özellik üzerinde çalışıyor. Kodu açık; problemi analiz ediyor; odaklanmış durumda.
Aniden bir mesaj gelir: “Hey, sadece küçük bir şey. Düğmeyi düzeltebilir misin?”
Geliştirici çalışmayı keser. Talebi açar. Sayfayı kontrol eder. Kodda yeri arar. Değişikliği yapar. Test eder. Deploy eder. Önceki işine geri döner...
Ve sonra hatırlamaya çalışır: “Ben ne üzerinde çalışıyordum yine?”
İşte bu context switching, yani bağlam değiştirme ve çok maliyetli olabilir. Çünkü her değişiklik düşünce sürecini böler.
Ne kadar karmaşık görev olursa, işe geri dönmenin maliyeti o kadar yüksek olur. Bu yüzden 10 mikro-görev her zaman 10 × 10 dakika anlamına gelmez. Pratikte çok daha fazlasını ifade edebilir.
Bir düğme önemsizdir. Yüz düğme ise süreçtir.
Diyelim ki şirket teknik ekibe gönderiyor:
- ayda 20 küçük değişiklik,
- her biri ortalama 45 dakika sürüyor.
Bu verir: ayda 15 saat çalışma.
Saatlik 200 zł net ücretle: ayda 3000 zł net.
Yıllık: 36.000 zł net.
Ve burada sadece ayda 20 küçük görevden bahsediyoruz. Büyük yeni özellikler yok; ürün geliştirme yok; yeni modüller yok; entegrasyon yok; tasarım yok.
Sadece: “değiştirin”, “düzeltin”, “kaydırın”, “ekleyin”, “silin”.
Şimdi böyle görevlerin ayda 50 olduğu bir organizasyonu hayal edin. Ya da 100.
Ölçek tamamen farklı görünmeye başlar...
Mikro-görevlerin başka bir maliyeti daha var - gelişimi engellerler
Bu, tüm tablonun en önemli parçalarından biridir.
Eğer geliştirme ekibi zamanının %20'sini küçük düzeltmelere harcıyorsa, o %20'yi ürün geliştirmeye ayıramaz. Bu kulağa basit geliyor ama pratikte sıkça görünmez.
Şirket sorar: “Neden yeni özellik hâlâ hazır değil?”
Geliştirici cevaplar: “Çünkü çok sayıda günlük konu vardı.”
“Hangi konular?”
“Düzeltmeler, küçük değişiklikler, güncellemeler, küçük görevler.”
Her biri küçük olabilir. Ama birlikte büyük bir çalışma engeli oluştururlar. Bu biraz telefondaki bildirimler gibidir. Bir bildirim dikkat dağıtmaz. On bildirim biraz dikkat dağıtır. Yüz? Bir anda tüm günü bildirimlere cevaplayarak geçiririz.
Mikro-görevlerde de durum benzerdir.
“Küçük görev” her zaman küçük değildir
Ayrıca her değişikliğin aynı olmadığını anlamak önemlidir. CMS'de bir metni değiştirmek gerçekten birkaç dakika alabilir.
Ancak bir uygulamada metnin değiştirilmesi şu gereksinimleri getirebilir:
- bileşenin bulunması,
- kodun değiştirilmesi,
- çevirilerin güncellenmesi,
- testler,
- uygulamanın yeniden derlenmesi (rebuild),
- deploy.
Bir alanın değiştirilmesi front-end, back-end, veri tabanı ve API'lerde değişiklik gerektirebilir.
Sistemdeki bir öğeyi değiştirmek diğer öğeleri etkileyebilir.
Bu yüzden “Bu düğmenin değiştirilmesi ne kadar sürer?” sorusuna mimari bilinmeden anlamlı bir cevap vermek genellikle mümkün değildir.
Önce kontrol etmek gerekir. Ancak sonra tahmin edilebilir.
Geliştirici neden bazen “Kontrol etmem gerekiyor” der?
Bu cevaptan kaçınma değildir; çoğunlukla profesyonelliktir.
İyi bir geliştirici “Evet, tabii, beş dakika” diye söz vermemelidir
eğer altındaki yapıyı bilmiyorsa.
Bunun yerine şunu söylemelidir: “Bu öğenin nerelerde kullanıldığını kontrol edeceğim ve size haber vereceğim.”
Bu 10 dakika sürebilir. Ama o 10 dakika birkaç saatlik problemi önleyebilir. Çünkü en pahalı değişiklik genellikle bir saat süren değil;
en pahalı olan,
- başka bir fonksiyonu bozandır,
- üretimde hata yaratandır,
- acil rollback gerektirendir,
- peşi sıra yeni taleplere neden olandır,
- birden fazla kişinin müdahalesini gerektiren olandır.
Bu yüzden değişiklik öncesi analiz işin bir parçasıdır, zaman kaybı değil.
Müşteri mikro-görevlerin maliyetini nasıl azaltabilir?
Amaç küçük değişiklikleri bildirmeyi bırakmak değil. Küçük değişiklikler ürün gelişiminin normal bir parçasıdır. Ama bunları iyi yönetmek gerekir.
1. Küçük görevleri gruplayın
Şunu göndermek yerine:
“Düğmeyi değiştirin.”
“Başlığı da düzeltin.”
“Bu arada şu linki ekleyin.”
“Ve şu elementi kaydırın.”
Bunları bir paket halinde toplayın.
Ekip böylece tek bir çalışma döngüsünde birden çok değişiklik yapabilir.
Daha az bağlam değiştirme.
Daha az iletişim.
Daha az deploy.
Daha düşük maliyet.
2. Öncelikleri belirleyin
Her şey acil değildir.
Eğer her şeyin durumu:
ACİL
ise aslında hiçbir şey gerçekten acil değildir.
Görevleri şu şekilde sınıflandırmak faydalıdır:
- kritik,
- önemli,
- planlanabilir,
- kozmetik.
Böylece ekip daha verimli çalışabilir.
3. Değişikliğin kod gerektirip gerektirmediğini düşünün
Eğer şirket düzenli olarak şu değişiklikleri yapıyorsa:
- metinler,
- fotoğraflar,
- bannerlar,
- linkler,
- iletiler,
sorun geliştiricinin yavaşlığı olmayabilir.
Sorun mimaride olabilir.
Her içerik değişikliğinin bir geliştirici gerektirdiği bir sistem yerine, bir CMS veya yönetim paneli düşünmek gerekir.
İyi tasarlanmış bir sistem, iş tarafındaki kişilerin geliştirici müdahalesi olmadan yapabilecekleri işleri kendilerinin yönetmesine izin vermelidir.
İyi bir sistem şu soruya cevap vermeli: bu değişikliği kim yapmalı?
Bu çok önemli bir tasarım kuralıdır. Her değişiklik geliştiriciye gitmemelidir.
Eğer pazarlama kendi başına şunları yapabiliyorsa:
- metni değiştirmek,
- fotoğrafı değiştirmek,
- makale eklemek,
- bölümlerin sırasını değiştirmek,
o zaman geliştiriciyi devreye sokmaya gerek yoktur.
Geliştirici, yetkinliğini gerektiren işlerle meşgul olmalıdır.
Yani örneğin:
- yeni özellikler geliştirmek,
- sistemi büyütmek,
- entegrasyonlar,
- optimizasyon,
- güvenlik,
- mimari,
- teknik sorun çözümü.
Aksi takdirde şirket, sistem kullanıcısının yapabileceği işleri yapmak için geliştiriciye ödeme yapmaya başlar.
Bu, bir araba tamircisini sadece arabayı yakıt doldurması için işe almak gibi olur. Evet, yapabilir. Ama gerçekten buna ihtiyaç var mı?
Ne zaman demeli: “Bunu farklı yapalım”?
Aynı istek düzenli olarak geliyorsa, durup şu soruyu sormak gerekir:
Neden her seferinde bunu elle yapmak zorundayız?
Eğer her hafta aynı öğeyi değiştirmemizi istiyorsak, belki de şu çözümler düşünülmelidir:
- CMS ayarı,
- konfigürasyon,
- yönetim paneli,
- otomasyon,
- self-service mekanizması.
Böyle bir çözümün oluşturulmasının tek seferlik maliyeti daha yüksek olabilir. Ama sonrasında her değişiklik saniyeler içinde birkaç dakika yerine yapılabilir.
Bu, her değişiklik için ödeme yapmak ile değişiklikleri kendiniz yapmanızı sağlayacak bir sisteme yatırım yapmak arasındaki farktır.
Mikro-görevler ve yazılım firması ile çalışma modeli
Bu konu müşteriler için de önemlidir.
Eğer bir yazılım firması ile çalışma sadece “talep ediyoruz - fiyatlandırıyorsunuz - onaylıyoruz - yapıyorsunuz” modeline dayanıyorsa, her küçük değişiklik ek organizasyon yükü yaratır.
Bu nedenle sürekli işbirliğinde genellikle işe yarayan modeller şunlardır:
- saatlik paketler,
- bakım abonmanları,
- sabit ekip,
- iş listesi (backlog),
- düzenli sprintler,
- belirlenmiş deploy pencereleri.
Bu, her müşterinin aynı modeli seçmesi gerektiği anlamına gelmez. Önemli olan çalışma şeklini projenin karakterine uydurmaktır.
Eğer şirket aylık bir değişiklik istiyorsa, karmaşık süreç gereksiz olabilir. Eğer aylık 50 görev gönderiyorsa, süreç eksikliği çok maliyetli olabilir.
Her değişikliği ücretlendirmek gerekli mi?
Duruma bağlıdır.
Bazı projelerde her dakikanın ayrıntılı kaydı anlamlıdır. Diğerlerinde bu, yönetimsel yük olarak tasarruftan daha maliyetli olabilir.
Bu yüzden işbirliğine geniş açıdan bakmak gerekir.
En önemli soru şudur: “Bu tek değişiklik ne kadar tuttu?” değil;
Daha iyi soru: “Tüm değişiklikleri yönettiğimiz yöntem bize ne kadarya mâl oluyor?”
Eğer şirket bir değişiklik için 200 zł ödeyip böylece hatalardan kaçınıyor ve her şeyin düzgün çalıştığından emin oluyorsa, bu makul olabilir.
Ama eğer her ay birkaç bin zł benzeri mikro-görevler için ödeniyorsa, problemi sistemsel olarak çözmenin mümkün olup olmadığını düşünmeye değer.
BT'deki en pahalı kelimeler?
Bunlar belki de: “Bu sadece küçük bir değişiklik.”
Bunun nedeni, küçük değişikliklerin kötü olması değildir. Gereklidirler.
Dijital ürün canlıdır. Müşteri ihtiyaçları değişir. Pazar değişir. Pazarlama değişir. Teknoloji değişir. Değişiklikler doğaldır.
Sorun, organizasyonun bunların birikimli maliyetini görmemesidir.
Bir küçük değişiklik? - Pek bir şey değil.
On? - Hâlâ çok değil.
Yüz? - Bu artık bir süreçtir.
Ve eğer bu tür süreçler on tane varsa? Birdenbire şirketin parayı ürün geliştirmeye harcamadığı; sürekli küçük düzeltmelere harcadığı ortaya çıkar.
Düğmeleri saymak yerine zamanı sayalım
İyi yönetilen dijital ürün geliştirme, müşterinin küçük değişiklik bildirimlerini yasaklamak değildir.
Ama bilinmesi gerekir:
- hangi değişikliklerin gerçekten geliştirici gerektirdiği,
- hangilerinin kendi başına yapılabileceği,
- hangilerinin otomatikleştirilmeye değer olduğu,
- hangilerinin gruplanması gerektiği,
- hangilerinin gerçekten acil olduğu,
- hangilerinin planlanabileceği,
- hangilerinin sistemsel olarak çözülmeye değer olduğu.
Çünkü bazen “Hemen düzeltin” sorusuna en iyi cevap:
“Tamam, yaparız” olmamak gerekir;
yerine: “Neden bir ay sonra yine bunu düzeltmek zorunda kalacağımızı düşünelim?” demektir.
İşte o zaman yazılım firması sadece bir görev yapan değil, teknolojik bir ortak olur. Çünkü iyi bir ortak sadece gelen talepleri yerine getirmez.
Ayrıca gösterir ki bazen en ucuz değişiklik daha hızlı yaptığımız değişiklik değildir. En ucuzu tekrar tekrar yapmak zorunda kalmadığımız değişikliktir.
Ve bu yüzden bir "Hemen düzeltin" düğmesi bir saati mal edebilir.
Ama iyi tasarlanmış bir sistem sayesinde benzer yüz değişikliği birkaç dakika içinde kendiniz yapabilirsiniz.
Bu programcılardan tasarruf değil; daha iyi bir süreçe, daha iyi bir mimariye ve tüm ekibin zamanının daha akıllıca kullanılmasına yapılan bir yatırımdır.
