Neden kimse ilerleme konusunda size net bir cevap vermiyor
Üç aydır her durum güncellemesinde aynı cümleyi duyuyorsunuz: proje yüzde seksen tamam. Faturalar aksamadan geliyor, toplantılar yapılıyor, arada birkaç ekran görüntüsü paylaşılıyor, ama elinizde o yüzde sekseni sınayabileceğiniz tek bir şey yok. Bu durum sandığınızdan çok daha yaygın, çünkü dışarıdan bakan biri için hareket ile ilerleme neredeyse aynı görünür.
Hareket, ekibin meşgul olmasıdır: toplantılar, tasarım turları, üzerinde çalışılan ekranlar, tartışılan teknik kararlar. İlerleme ise tek bir şeye iner, bugün gerçek bir müşterinin açıp baştan sona kullanabileceği çalışan bir parça. Haftalık raporda ikisi birbirine çok benzer, oysa yalnızca ikincisi para eder, çünkü yalnızca o elinizde kalır.
Şunu baştan söylemekte fayda var: projelerin çoğu bir noktada takvimden sapar ve bu, atlatılamayacak bir felaket değildir. Pahalı olan sapmanın kendisi değil, geç fark edilmesidir. İkinci ayda görülen iki haftalık gecikme tek bir toplantıyla kapanır, aynı gecikme beşinci ayda ortaya çıktığında ise bütçenin tamamını yeniden tartışmaya açar.
Bu yazının sonunda, veritabanının ne olduğunu bilmenize gerek kalmadan kendi projenizi değerlendirebilir hale geleceksiniz. Kullanacağınız sorular dürüst çalışan hiçbir ekibi rahatsız etmez; aksine işini bilen bir ekip bu soruların cevabını zaten hazır tutar, çünkü aynı cevaplar onların da işini kolaylaştırır.
Tek geçerli kanıt, kendi telefonunuzda tıklayabildiğiniz yazılımdır
Önce bir terimi yerine oturtalım. Test sitesi, sektörde çoğu zaman staging diye geçer, sistemin size ait özel bir kopyasıdır: müşteriler görmeden önce işin denendiği, kendi adresi olan, tarayıcıdan açılabilen canlı bir örnek. Projenizin böyle bir kopyası yoksa bu başlı başına bir bulgudur ve ilk sorunuz da bu olmalıdır, çünkü gösterilemeyen iş genellikle henüz bir araya getirilmemiş iştir.
Bütün yüzde hesaplarının yerini alacak tek kural şudur: kendi telefonunuzdan açıp kullanamıyorsanız, rapor ne yazarsa yazsın o iş bitmemiştir. Kural sert görünüyor olabilir, ama sizi bitmek bilmeyen bir tartışmadan kurtarır, zira kanaate değil denenebilir bir şeye bakarsınız.
Linkysoft olarak özel yazılım projelerinde işleyen ritim şudur: her hafta otuz ile kırk beş dakikalık bir demo, üstelik farenin müşterinin elinde olduğu bir demo. Anlatılan bir sunum değil, sizin tıkladığınız gerçek ekran. Aradaki fark rakamlara da yansıyor: haftalık tıklanabilir demosu olmayan altı aylık projelerde tipik sapma yüzde 25 ile 40 arasında, yani altı ay yedi buçuk ile sekiz buçuk aya çıkıyor. Aynı iş haftalık demo ve yazılı bir değişiklik kaydıyla yürütüldüğünde sapmayı genelde yüzde 10 ile 15 bandının altında tutabiliyoruz.
Bir de "bitti" kelimesinin ortak bir tanımı olsun, çünkü bu kelime herkeste başka bir anlama geliyor. Bizim tanımımız dört kutuludur: yazıldı, test edildi, sizin tarafınızdan görülüp onaylandı ve test sitesinde çalışıyor. Dördü birden işaretlenmeden o kalem bitmiş sayılmaz. Bir özel web uygulaması geliştirme işinin içinde ekranların yanı sıra yetkiler, iş kuralları, raporlar ve dış servis bağlantıları da olduğu için bu tanım daha da kıymetlidir; ekran hazır göründüğünde arkadaki işin yarısı hâlâ duruyor olabilir.
Gerçek bir durum raporunda ne vardır, muğlak olan neyi gizler
İşe yarayan bir güncelleme üç parçadan oluşur. Birincisi, geçen görüşmeden bu yana biten ve şu anda tıklanabilen işler. İkincisi, hâlihazırda üzerinde çalışılanlar ve her birinin tarihi. Üçüncüsü, tıkanmış olanlar ve tıkanmanın kimde beklediği, isim vererek. Bu üçü varsa rapor kısa da olsa yeterlidir; biri eksikse rapor uzun da olsa boştur.
Bir soru daha sormanızı gerektiren yumuşatıcı ifadeler ise hep aynıdır:
- Neredeyse bitti. "Neredeyse" ölçülemez, o yüzden kaç kalem kaldığını sorun.
- Son rötuşlar kaldı. Bu cümle çoğu zaman birleştirme ve test demektir ve günler alır.
- Birkaç şeyi bekliyoruz. Tam olarak neyi, kimden ve ne zamandır?
- Entegrasyon sorunları yaşıyoruz. Hangi servis, hangi hata, kim uğraşıyor?
- İçinde tek bir somut isim, tarih ya da sayı geçmeyen her cümle.
Tıkanıklıkların dile getirilmesini kötü haber saymayın. Tıkandığı yeri ismiyle söyleyen ekip, nerede durduğunu bilen ekiptir. Hiç tıkanıklığı olmayan ekip ise genelde onları saklıyordur, çünkü dört ay boyunca hiçbir şeyin beklemediği bir yazılım projesi pratikte yoktur.
Elinizde hazır kelimeler olsun diye, e-postayla gönderebileceğiniz üç soruyu aynen bırakıyorum:
- Geçen görüşmeden bu yana test sitesinde tıklayabileceğim ne bitti?
- Şu anda tıkanmış olan nedir, kimde bekliyor ve kaç gündür orada?
- Bugünkü bilgiyle yayın tarihi hâlâ aynı mı, değilse yeni tarih nedir?
Bu hafta yapabileceğiniz beş kontrol, teknik bilgi gerekmiyor
Tıklama testi, on dakika
Test sitesini kendi telefonunuzdan açın ve bir müşterinin yapacağı tam bir işi baştan sona tamamlayın: üye olun, ürünü sepete atın, randevu alın, formu gönderin ve sonucu görün. Yarım kalan her adım, raporda "tamamlandı" yazsa bile açık bir iştir.
Değişiklik kaydı testi, on beş dakika
Proje başladığından bu yana talep edilen bütün değişikliklerin yazılı listesini, her birinin kaç gün eklediğiyle beraber isteyin. Böyle bir liste yoksa takvim de gerçek değildir, çünkü eklenen işin bedelini kimse hesaba katmamıştır. Dört aylık bir projede kapsamın yüzde 15 ile 30 arasında değişmesi normaldir, hatta çoğu zaman sağlıklıdır; anormal olan, bu değişikliğin kaç gün ve hangi yeni tarih anlamına geldiğinin yazılmamasıdır.
Hata defteri testi, on dakika
Bugün kaç açık hata var, bir ay önce kaç taneydi? Tek bir sayı hiçbir şey anlatmaz, iki sayının karşılaştırması ise çok şey anlatır: liste kısalıyorsa iş toparlanıyor, uzuyorsa yeni yazılan her şey eskisini bozuyor demektir.
Kapsam ile fatura karşılaştırması, yirmi dakika
İlk anlaşmadaki özellik listesini alın, yanına bugüne kadar ödediğiniz tutarı koyun ve tıklayabildiğiniz özellikleri sayın. "Üzerinde çalışılıyor" durumundakiler bu sayıma girmez, çünkü henüz size ait değildir.
İki kişi testi, beş dakika
Ekipten iki ayrı kişiye tek tek sorun: önümüzdeki hafta ne olacak? İki farklı cevap alıyorsanız plan tek bir kişinin kafasında yaşıyordur ve o kişi izne çıktığı hafta proje de izne çıkar.
Beş kontrol toplamda bir saat alır ve hiçbiri teknik bilgi istemez. En çok sürprizin çıktığı başlık genellikle testtir, o yüzden test tarafında yazdıklarımıza göz atmanız ekibinizle aynı dili konuşmanızı kolaylaştırır.
Takvimin herkesin yapabileceği aritmetiği
Yüzdeleri bırakın ve kalem sayın. Son dört haftada gerçekten biten, yani tıklanabilen kaç iş oldu? O sayı, planda ne yazarsa yazsın ekibin gerçek haftalık hızıdır ve gelecek hafta sihirli bir şekilde iki katına çıkmaz.
Örneği yavaş yürütelim. Diyelim ki proje toplam 60 kalemden oluşuyor, bunların 25'i bitmiş ve tıklanabiliyor, son bir ayda ise haftada ortalama 3 kalem tamamlanmış. Geriye 35 kalem kalıyor ve 35'i 3'e böldüğünüzde yaklaşık 12 hafta çıkıyor. Planda kalan süre 6 hafta yazıyorsa plan yanlış değildir, sadece bir dilek listesidir, zira o tarihin tutması için ekibin son dört haftadaki gerçek hızının ikiye katlanması gerekir.
Bir de kapasite düzeltmesi var. Tam zamanlı denen bir geliştirici, 40 saatlik haftadan toplantılar, başkalarının yazdığı işi okuyup denetleme, destek işleri ve sürekli konu değiştirme düşüldükten sonra pratikte 25 ile 30 saat arası verimli iş çıkarır. Yani 40 saatlik hafta varsayan bir plan, daha hiçbir şey ters gitmeden iyi ihtimalle yüzde 25, aralığın öbür ucunda ise yüzde 40'a yakın iyimserdir.
Son olarak yüzde doksan tuzağı. Bir iş yüzde 90 diye raporlandığında kapanması için genelde ilk tahminin yüzde 20 ile 40'ı kadar daha zaman gerekir, çünkü kalan kısım işin kendisi değil, onu geri kalan her şeye bağlamak ve test etmektir. On günlük bir özellik yüzde 90'daysa içinde yarım gün değil, iki ile dört gün vardır. Bunu bir kez kabul ettiğinizde "yarın biter" cümlesini duyduğunuzda ne soracağınızı bilirsiniz.
Göremediğiniz iş, ve ekranların neden işin sadece üçte biri olduğu
Ekranlar projenin görünen yüzüdür ve tipik bir özel web uygulamasında toplam emeğin kabaca yüzde 35'ini oluşturur. Geri kalanı demoda görünmez ama vakti aynen yer: kimin neyi görebileceği ve değiştirebileceği, yani yetkiler; ödeme, kargo veya muhasebe servislerine bağlantılar; eski kayıtların yeni sisteme taşınması; test ve düzeltme; güvenlik sıkılaştırması, yedekler ve yayının kendisi.
Bu dağılımın size verdiği pratik sonuç şudur: tasarımlar onaylandığında işin aşağı yukarı üçte biri arkanızda kalmıştır. Dolayısıyla ekranlar geldiğinde bütçenin yarısı harcanmışsa durum normaldir, bütçenin yüzde 80'i harcanmışsa değildir, çünkü kalan yüzde 20 ile işin üçte ikisini yapmanız gerekir ve bu aritmetik tutmaz.
Güvenlik tarafı özellikle aldatıcıdır, zira demoda hiçbir zaman görünmez. Yetkilerin doğru kurulması, verinin korunması, yedeklerin gerçekten denenmesi ve siber güvenlik tarafındaki sıkılaştırma işi ekranda tek bir pikseli değiştirmez, buna karşılık yayın öncesi haftaların ciddi bir kısmını götürür. "Her şey hazır, sadece yayına almak kaldı" cümlesi bu yüzden çoğu zaman bir haftadan uzun bir işi anlatır.
Projeler haftalarını nerede kaybeder, ve bu nadiren koddur
İki ay geciken altı aylık bir projeye yakından baktığınızda tablo hemen hemen hep aynıdır: yaklaşık 2,5 hafta müşteri kararlarının beklenmesi, 2 hafta yol ortasında eklenen kapsam, 1,5 hafta ödeme altyapısı, banka ya da resmi kurum portalı gibi üçüncü taraf servisler, 1,5 hafta eksik hesaplanmış test ve 1 hafta kilit bir kişinin işbaşında olmaması.
Burada açık konuşalım, çünkü bu aslında iyi haber: gecikmenin en büyük dilimi çoğu zaman alıcının masasındadır, yani tamamen sizin kontrolünüzdeki kısımdır. Normal bir proje alıcıdan 12 ile 20 arasında karar ister; hangi ödeme yöntemleri olacak, iade akışı nasıl işleyecek, faturada hangi bilgiler görünecek gibi. Bu beklemelerin çoğu hiçbir şeye mal olmaz, çünkü ekip cevap gelene kadar başka bir işe geçer; pahalıya gelenler, bir sonraki işi durduran birkaç karardır ve bunlardan yalnızca iki üç tanesinin birer iş haftası bekletilmesi, kimse hata yapmadan yukarıdaki 2,5 haftayı üretmeye yeter.
Bunun size hiçbir şeye mal olmayan çözümü şudur: her satırın yanında bir isim ve bir tarih olan yazılı bir karar listesi, demo toplantısının aynı yarım saatinde gözden geçirilir. Linkysoft'ta bu listeyi biz tutarız ama kararlar sizindir; asıl fayda, bir kararın kaç gündür beklediğini herkesin aynı ekranda görmesidir, zira bekleyen karar sessiz kaldığı sürece kimseye gecikme gibi gelmez.
Anlam taşıyan sinyaller ve taşımayan gürültü
İşletme sahiplerinin boş yere paniklediği şeyler genelde aynıdır: tek bir özelliğin tarihinin kayması, yarım kalmış ve çirkin duran bir ara ekran, bir geliştiricinin bir haftalık izni, ofis dışında kimsenin görmeyeceği kaba görünümlü bir yönetim sayfası. Bunların hiçbiri projenin sağlığı hakkında bilgi vermez, çünkü hepsi yapım sürecinin sıradan görüntüsüdür.
Gerçekten anlam taşıyan sinyaller ise şunlardır:
- Üst üste iki demoda tıklanacak yeni bir şeyin çıkmaması.
- Açık hata sayısının üç hafta üst üste artması.
- Aniden "sıfırdan yeniden yazalım" önerisinin gelmesi.
- "Bitti" tanımının sessizce esnemesi, mesela test sitesinde çalışma şartının düşmesi.
- Sessizlik, çünkü iyi haber kendini duyurur, kötü haber susar.
Hata aritmetiği tek bir kurala iner: yayından önceki altı haftada sağlıklı bir proje, üç hafta üst üste açtığından daha fazla hatayı kapatır. Açık liste üç hafta boyunca büyüyorsa, kimse söylemese bile yayın tarihi çoktan kaymıştır ve o tarihi konuşmak için resmî bir duyuru beklemenize gerek yoktur. Yayın öncesi listenin içinde güvenlik testleri de olduğu için bu haftalar genelde tahmin edilenden uzun sürer.
Harcanan parayı teslim edilen işle birlikte okumak
Beş dakikada yapabileceğiniz tek satırlık bütçe kontrolü şudur: harcanan paranın yüzdesi ile tıklayabildiğiniz özelliklerin yüzdesini yan yana koyun. Harcama yüzde 70'te, tıklanabilir iş yüzde 40'ta ise bütçenin kalan yüzde 30'u işin yüzde 60'ını taşımak zorundadır, ki bu mümkün değildir. Bu tek karşılaştırma, aylarca süren "yolunda mı değil mi" tartışmasını bir sayfaya indirir.
Ödeme aşamalarını takvim ayına değil, açıp kullanabileceğiniz bir şeye bağlayın. Takvime bağlı bir aşama geçen zamanın parasını öder, çalışan bir şeye bağlı aşama ise ilerlemenin parasını öder ve ikisi arasındaki fark, sorun çıktığında kimin risk taşıdığını belirler. Örnek çalışmalarımızda projeleri nasıl ödenmiş ve çalışan aşamalara böldüğümüzü görebilirsiniz.
Bir de şu beklentiyi baştan kurun: proje yayınla bitmez. Her yıl yapım maliyetinin yüzde 15 ile 20'si kadar bir bütçeyi barındırma, güncellemeler, güvenlik yamaları ve küçük değişiklikler için ayırın. Bu rakamı ilk günden hesaba katmak, birinci yılın sonunda "bu masraf da nereden çıktı" cümlesini tamamen ortadan kaldırır.
Geride kaldığınızı anladınız, peki şimdi ne olacak
Elinizde yalnızca dört kol var, o yüzden adlarını açıkça koyalım: kapsamı küçültmek, tarihi ötelemek, para eklemek veya durmak. Duyduğunuz her çözüm önerisi bu dördünün bir birleşimidir, dolayısıyla masaya oturduğunuzda hangi kolu çektiğinizi bilerek konuşursunuz.
Adam eklemek bu kolların en yavaşıdır. Yeni kişi ilk günden üretmeye başlamaz; hâlihazırda inşa eden ekip iki ile dört hafta boyunca inşa etmek yerine anlatmakla uğraşır, yani geciken projeye insan eklemek kısa vadede projeyi daha da yavaşlatır. Bu kol ancak gecikme aylarla ölçülüyorsa ve eklenen kişi uzun süre kalacaksa mantıklıdır.
Genellikle en iyi cevap daha küçük bir ilk sürümdür. Kapsamın yüzde 60'ını üç ay erken canlıya almak üç şey yapar: kazanmaya başlar, gerçek müşteri geri bildirimi toplar ve geri kalanın parasını çoğu zaman kendi kendine öder. Üstelik erken yayınlanan sürüm, kalan yüzde 40'ın gerçekten gerekip gerekmediğini de gösterir, ki listedeki her özellik canlı kullanımdan sonra aynı kadar önemli kalmaz.
Tarihi ve kapsamı yeniden kurmaya karar verirseniz bunu tek sayfada yazın: yeni tarih, yeni kapsam, ne değişti ve neden değişti, iki tarafın yazılı onayıyla. Yazılmayan bir yeniden başlangıç, sessiz bir kaymanın devamından başka bir şey değildir.
Durmak da bir seçenektir ve başarısızlık sayılmamalıdır. Yarım kalmış ya da terk edilmiş bir yazılımı devralmak, sıfırdan yapmanın yüzde 40 ile 70'i kadara mal olur ve elde ne olduğunu anlamak için üç ile altı hafta ister. Bu sayılar tam olarak şunu söyler: yanlış bir projeyi erken durdurmak, onu inatla yayına taşımaktan neredeyse her zaman ucuzdur.
Küçük ve ucuz seçeneğin dürüst cevap olduğu durumlar
Hesabı yüksek sesle yapalım. Aylık 30 ile 80 dolar arasındaki hazır bir araç yılda 360 ile 960 dolar tutar. Özel yazılım ise genelde 8.000 ile 25.000 dolar bandında başlar ve üstüne her yıl bunun yüzde 15 ile 20'si bakım gideri biner. Arada bu kadar büyük bir fark varken özel geliştirmenin tercihten öte bir gerekçesi olmalıdır.
Gerekçe sayılan üç durum vardır: piyasadaki hiçbir ürünün desteklemediği bir iş akışınız olması, verinizi mevzuat gereği kendi elinizde tutmak zorunda olmanız, ya da kullanıcı başına ödenen abonelik ücretlerinin büyüyüp yapım maliyetini geçmesi. Bu üçünden biri yoksa hazır araç muhtemelen sizin için doğru cevaptır ve bunu söylemek bizim işimizin bir parçasıdır.
Linkysoft olarak hazır bir aracın işi gördüğü durumlarda projeyi geri çeviririz, çünkü yapılmaması gereken bir sistem ne kadar iyi yönetilirse yönetilsin asla yolunda olmaz. Kararı verirken bütçe tarafını da beş yıllık toplamla bakmanızı öneririz, tek yılın rakamıyla değil.
Pazartesi başlayabileceğiniz ritim ise gayet sade: haftada bir tıklanabilir demo, ayda bir kalan kalemlerin yeniden sayımı ve üç ayda bir sistemin kazandırdığının maliyetini aşıp aşmadığının kontrolü. Bu üçü yerindeyse projeniz kötü haftalar geçirse bile yolunu kaybetmez. İkinci bir göz isterseniz mevcut durumu birlikte okumak için bize yazın; işiniz daha küçük bir kapsama sığıyorsa web tasarım ve geliştirme tarafındaki daha hafif bir çözüm çoğu zaman aynı sonucu çok daha erken verir.
