[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"blog-yazilim-projesi-neden-gecikir":3},{"html":4,"toc":5,"faq":30},"\u003Cp>Yazılım projeleri çoğu zaman kod yazılırken değil, kararlar arasında gecikir: belirsiz kapsam, haftalarca bekleyen geri bildirim, takvimi sizin elinizde olmayan entegrasyonlar, taşınırken temizlenmesi gereken veri, ilk sürüm çıkmadan eklenen yeni istekler, unutulan yönetim ve rapor ekranları, sona bırakılan testler ve tek bir geliştiriciye bağımlılık. Bu sekiz sebebin hepsinin önceden alınabilecek bir önlemi var. Aşağıda her birini, erken işaretini ve önlemini anlatıyoruz.\u003C\u002Fp>\n\u003Ch2 id=\"gecikme-kod-yazarken-degil-kararlar-arasinda-birikir\">Gecikme kod yazarken değil, kararlar arasında birikir\u003C\u002Fh2>\n\u003Cp>Bir proje geciktiğinde ilk akla gelen şey, geliştiricilerin yavaş çalıştığıdır. Gerçekte gecikmenin büyük kısmı, kimsenin klavyeye dokunmadığı anlarda birikir: bir sorunun cevabını beklerken, bir test ortamının açılmasını beklerken, bir toplantının ertelenmesini beklerken. Bu bekleme süreleri tek tek küçük görünür ama üst üste eklendiğinde haftalara dönüşür.\u003C\u002Fp>\n\u003Cp>Bu yüzden gecikmeyi önlemek, büyük ölçüde iki tarafın da bekleme süresini kısaltmak demektir. Aşağıdaki sebeplerin yarısından fazlası, yazılımı yaptıran şirketin tarafında çözülebilecek türdendir. Bu bir suçlama değil; tersine, kontrolün önemli bir kısmının sizde olduğu anlamına gelir.\u003C\u002Fp>\n\u003Cp>Tedarikçi tarafında da bir sorumluluk var: süreyi uzatabilecek riskleri baştan, yazılı olarak söylemek. İyi bir teklif yalnızca bir bitiş tarihi vermez; o tarihi neyin kaydırabileceğini de üç beş madde halinde sayar. “Kargo firmasının test ortamı onayı”, “eski verinin temizliği”, “onay akışının kurallarının netleşmesi” gibi. Bu liste, gecikme yaşandığında kimin neyi beklediğini tartışmak yerine, en baştan hangi riskin kimin elinde olduğunu konuşmayı sağlar. Teklifinizde böyle bir liste yoksa, isteyin. Projenin ortasında ortaya çıkan her risk, baştan konuşulmuş olandan daha pahalıdır; hem süre hem de iki taraf arasındaki güven açısından.\u003C\u002Fp>\n\u003Ch2 id=\"kapsam-ve-kararlar\">Kapsam ve kararlar\u003C\u002Fh2>\n\u003Ch3 id=\"1-belirsiz-kapsam\">1. Belirsiz kapsam\u003C\u002Fh3>\n\u003Cp>“Sipariş takibi yapılacak” bir kapsam değil, bir başlıktır. Kabul kriterleri yazılmadan başlayan bir projede her ekran bir tartışmaya dönüşür, çünkü “bitti” kelimesinin herkes için anlamı farklıdır.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> İşe başlamadan önce kapsamı, kimin hangi adımı yapıp hangi sonucu göreceğini anlatan kabul kriterleriyle yazın. Açıkça kapsam dışı bırakılanları da listeleyin. Bu adım kısa bir keşif çalışması gerektirir ama projenin geri kalanında kaybedilecek zamanı ortadan kaldırır.\u003C\u002Fp>\n\u003Ch3 id=\"2-yavas-kararlar\">2. Yavaş kararlar\u003C\u002Fh3>\n\u003Cp>Prototip gönderilir, geri bildirim iki hafta sonra gelir. Bir alanın zorunlu olup olmadığı sorulur, cevap üç departmanın onayını bekler. Gecikmeleri en çok uzatan şey, deneyimimize göre, tam olarak budur.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Sizin tarafınızda kararı verebilecek tek bir kişi belirleyin ve bu kişinin haftada belli bir zamanı projeye ayırmasını sağlayın. Açık kararları bir listede tutun; her birinin bir sahibi ve bir tarihi olsun.\u003C\u002Fp>\n\u003Ch3 id=\"3-degisiklik-talepleri\">3. Değişiklik talepleri\u003C\u002Fh3>\n\u003Cp>İlk sürüm çıkmadan yeni istekler eklemek, projeyi en sessiz biçimde uzatan alışkanlıktır. Her istek tek başına küçüktür; toplamı ise ilk sürümü haftalarca öteler.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Yeni istekleri reddetmeyin, ama bir “sonraki faz” listesine yazın. İlk sürüme girmesi gerçekten şartsa, sürenin ve fiyatın ne kadar etkileneceğini işe başlamadan önce yazılı olarak öğrenin ve buna göre karar verin. Bunun ne kadar etkili olduğunu görmek için \u003Ca href=\"\u002Fblog\u002Fmvp-nedir\">MVP nedir\u003C\u002Fa> yazısında anlattığımız dilimleme mantığına bakabilirsiniz.\u003C\u002Fp>\n\u003Ch2 id=\"dis-bagimliliklar\">Dış bağımlılıklar\u003C\u002Fh2>\n\u003Ch3 id=\"4-entegrasyonlar\">4. Entegrasyonlar\u003C\u002Fh3>\n\u003Cp>Banka, kargo, ödeme sağlayıcısı, e-fatura entegratörü ya da muhasebe programı. Her entegrasyon, size hiçbir şey borçlu olmayan bir şirketin takvimine bağlıdır. Test ortamı gecikebilir, dokümantasyon eksik olabilir, onay süreci haftalar alabilir.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Entegrasyonları kapsamın en başında listeleyin ve her biri için test ortamı başvurusunu ilk hafta yapın. Mümkünse entegrasyonu ilk sürümün kritik yolundan çıkarın: önce dışa aktarma ya da elle aktarımla çalışan bir akış, entegrasyon hazır olduğunda otomatik bağlantı.\u003C\u002Fp>\n\u003Ch3 id=\"5-veri-kalitesi\">5. Veri kalitesi\u003C\u002Fh3>\n\u003Cp>Yıllar içinde elle düzeltilmiş Excel dosyaları, aynı müşterinin farklı yazımları, eksik kodlar. Veri göçü genelde projenin sonuna bırakılır ve orada sürpriz çıkarır.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Verinin gerçek halini, temizlenmiş şablonunu değil, ilk görüşmeye getirin. Deneme aktarımını projenin ortasında yapın, sonunda değil. Temizliğin kimin işi olduğunu baştan yazın.\u003C\u002Fp>\n\u003Ch2 id=\"unutulan-ve-sona-birakilan-isler\">Unutulan ve sona bırakılan işler\u003C\u002Fh2>\n\u003Ch3 id=\"6-yonetim-paneli-ve-raporlar\">6. Yönetim paneli ve raporlar\u003C\u002Fh3>\n\u003Cp>Kullanıcı ekranları üzerinde haftalarca çalışılır; ama kullanıcı tanımlamak, yetki değiştirmek, bir kaydı düzeltmek ya da ay sonu raporunu almak için gereken ekranlar kimsenin aklına gelmez. Bunlar sonda fark edildiğinde, ilk sürüm “neredeyse hazır” halde haftalarca bekler.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Kapsamı yazarken yalnızca işi yapan kullanıcıyı değil, sistemi yöneten kişiyi ve rakamlara bakan yöneticiyi de düşünün. Hangi raporlara her hafta gerçekten bakıldığını yazın; geri kalanını dışa aktarmaya bırakın.\u003C\u002Fp>\n\u003Ch3 id=\"7-sona-birakilan-test\">7. Sona bırakılan test\u003C\u002Fh3>\n\u003Cp>Bütün özellikler bittikten sonra test etmeye başlamak, bütün hataların aynı anda ortaya çıkması demektir. Hataların bir kısmı küçük, bir kısmı ise temel bir yanlış anlaşılmanın işaretidir ve o noktada düzeltmek pahalıdır.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Haftalık ya da iki haftalık aralıklarla çalışan bir sürüm isteyin ve sizin tarafınızda o sürümü gerçek bir işle deneyecek bir kullanıcı belirleyin. Haftada bir saat yeterlidir. Erken bulunan hata ucuzdur.\u003C\u002Fp>\n\u003Ch2 id=\"tek-gelistiriciye-bagimlilik\">Tek geliştiriciye bağımlılık\u003C\u002Fh2>\n\u003Cp>Projeyi tek bir kişinin bildiği, kodun onun bilgisayarında durduğu, dokümanın onun kafasında olduğu bir düzen, o kişi hastalandığında, izne çıktığında ya da ayrıldığında projeyi durdurur. Bu durum küçük ekiplerde ve serbest çalışanlarla yürütülen işlerde çok yaygındır ve genelde ancak bir şey ters gittiğinde fark edilir.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Önlem:\u003C\u002Fstrong> Kodun ilk günden sizin hesabınızdaki bir depoda tutulmasını, kurulum ve işletim dokümanının proje boyunca güncellenmesini ve en azından kritik kısımların ikinci bir kişi tarafından gözden geçirilmesini isteyin. Bu konuların sözleşmede nasıl yazılacağını \u003Ca href=\"\u002Fblog\u002Fyazilim-sozlesmesi-kaynak-kod-sahipligi\">yazılım sözleşmesi ve kaynak kod sahipliği\u003C\u002Fa> yazısında ele aldık. Depo ve hesaplar sizdeyse, en kötü durumda bile başka bir ekip işi devralabilir.\u003C\u002Fp>\n\u003Cp>Teklif aşamasında şu soruyu sormak da faydalı: projede çalışan kişi iki hafta ulaşılamaz olursa ne olur? Cevap “olmaz” ya da “başka biri bakar” gibi belirsiz bir cümleyse, o başka birinin kim olduğunu, projeyi ne kadar bildiğini ve koda erişimi olup olmadığını sorun. Net bir cevap, riskin gerçekten düşünüldüğünü gösterir.\u003C\u002Fp>\n\u003Ch2 id=\"gecikmeyi-erken-fark-etmenin-isaretleri\">Gecikmeyi erken fark etmenin işaretleri\u003C\u002Fh2>\n\u003Cp>Gecikmeler nadiren bir gecede ortaya çıkar; genelde haftalar öncesinden işaret verir. Aşağıdaki tablo, her sebebin erken işaretini ve ilk yapılacak şeyi özetliyor:\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Sebep\u003C\u002Fth>\n\u003Cth>Erken işaret\u003C\u002Fth>\n\u003Cth>İlk yapılacak\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Belirsiz kapsam\u003C\u002Ftd>\n\u003Ctd>“Bu ekran ne yapacaktı?” sorusu sık soruluyor\u003C\u002Ftd>\n\u003Ctd>Kabul kriterlerini yazılı hale getirmek\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Yavaş kararlar\u003C\u002Ftd>\n\u003Ctd>Aynı konu iki toplantıda üst üste kapanmıyor\u003C\u002Ftd>\n\u003Ctd>Tek karar verici ve açık kararlar listesi\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Değişiklik talepleri\u003C\u002Ftd>\n\u003Ctd>İlk sürümün tarihi her hafta biraz kayıyor\u003C\u002Ftd>\n\u003Ctd>Yeni istekleri sonraki faz listesine almak\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Entegrasyonlar\u003C\u002Ftd>\n\u003Ctd>Test ortamı erişimi hâlâ gelmedi\u003C\u002Ftd>\n\u003Ctd>Entegrasyonu kritik yoldan çıkarmak\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Veri kalitesi\u003C\u002Ftd>\n\u003Ctd>Deneme aktarımı hiç yapılmadı\u003C\u002Ftd>\n\u003Ctd>Projenin ortasında deneme aktarımı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Unutulan yönetim ve raporlar\u003C\u002Ftd>\n\u003Ctd>Yönetici henüz hiçbir ekran görmedi\u003C\u002Ftd>\n\u003Ctd>Yönetici ve rapor ihtiyacını kapsama eklemek\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sona bırakılan test\u003C\u002Ftd>\n\u003Ctd>Çalışan sürüm yerine durum raporu geliyor\u003C\u002Ftd>\n\u003Ctd>Haftalık çalışan sürüm ve test kullanıcısı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Tek kişiye bağımlılık\u003C\u002Ftd>\n\u003Ctd>Kod ve doküman sizin erişiminizde değil\u003C\u002Ftd>\n\u003Ctd>Depoyu ve dokümanı sizin hesabınıza taşımak\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Bir işaret daha var: durum raporlarının somut teslimler yerine yüzdelerle konuşması. “Yüzde seksen tamamlandı” cümlesi, kalan yüzde yirminin ne kadar süreceği hakkında hiçbir şey söylemez. Çalışan ve tıklanabilen bir sürüm, herhangi bir yüzdeden daha güvenilir bir ilerleme ölçüsüdür.\u003C\u002Fp>\n\u003Ch2 id=\"kesin-bir-tarihiniz-varsa\">Kesin bir tarihiniz varsa\u003C\u002Fh2>\n\u003Cp>Bazı projelerin gerçekten kaçırılamayacak bir tarihi vardır: bir sezon başlangıcı, bir denetim, biten bir sözleşme, açılacak bir şube. Bu durumda tarihi ilk görüşmede, nedeniyle birlikte söyleyin. Bir tarihe yetişmenin en güvenilir yolu genelde daha fazla kişi eklemek ya da daha uzun çalışmak değil, kapsamı kesmektir: o tarihte mutlaka olması gereken üç dört işi belirleyip gerisini sonraki faza bırakmak. Tedarikçiniz tarihin gerçekçi olmadığını düşünüyorsa bunu baştan söylemesi, projenin ortasında “biraz kaydı” demesinden çok daha değerlidir.\u003C\u002Fp>\n\u003Ch2 id=\"nereden-baslamali\">Nereden başlamalı?\u003C\u002Fh2>\n\u003Cp>Yeni bir projeye başlıyorsanız, yukarıdaki tabloyu bir kontrol listesi olarak kullanın ve her satır için “bizde bu nasıl işleyecek?” sorusunu baştan cevaplayın. Süren bir projede gecikme yaşıyorsanız, önce açık kararları listeleyin ve kapsamı yeniden kesin; çoğu zaman bu iki adım, eklenecek her geliştiriciden daha fazla zaman kazandırır. Süreyi kısaltan ve uzatan etkenlerin daha ayrıntılı bir listesini \u003Ca href=\"\u002Fyazilim-yaptirma\">yazılım yaptırma rehberimizde\u003C\u002Fa> bulabilirsiniz.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"\u002Fhizmetler\u002Fozel-yazilim-gelistirme\">Özel iş yazılımı\u003C\u002Fa> projelerimizi bu riskleri baştan yazıya dökerek ve her hafta çalışan bir sürüm göstererek yürütüyoruz. Planladığınız ya da takılmış bir projeyi konuşmak isterseniz \u003Ca href=\"\u002Filetisim\">iletişim sayfamızdan\u003C\u002Fa> bir görüşme ayarlayabilirsiniz.\u003C\u002Fp>\n",[6,9,12,15,18,21,24,27],{"id":7,"text":8},"gecikme-kod-yazarken-degil-kararlar-arasinda-birikir","Gecikme kod yazarken değil, kararlar arasında birikir",{"id":10,"text":11},"kapsam-ve-kararlar","Kapsam ve kararlar",{"id":13,"text":14},"dis-bagimliliklar","Dış bağımlılıklar",{"id":16,"text":17},"unutulan-ve-sona-birakilan-isler","Unutulan ve sona bırakılan işler",{"id":19,"text":20},"tek-gelistiriciye-bagimlilik","Tek geliştiriciye bağımlılık",{"id":22,"text":23},"gecikmeyi-erken-fark-etmenin-isaretleri","Gecikmeyi erken fark etmenin işaretleri",{"id":25,"text":26},"kesin-bir-tarihiniz-varsa","Kesin bir tarihiniz varsa",{"id":28,"text":29},"nereden-baslamali","Nereden başlamalı?",[31,34,37,40],{"q":32,"a":33},"Yazılım projesi geciktiğinde ekibe yeni geliştirici eklemek işe yarar mı?","Çoğu zaman kısa vadede yaramaz. Yeni gelen kişinin projeyi öğrenmesi zaman alır ve mevcut ekibin zamanını da tüketir. Gecikmenin sebebi kod yazma kapasitesi değil de kararlar, kapsam ya da dış bağımlılıklarsa, kişi eklemek sorunu çözmez.",{"q":35,"a":36},"Gecikmeyi erken nasıl fark ederim?","Haftalık çalışan sürüm görmüyorsanız, aynı konu iki toplantı üst üste karara bağlanmıyorsa ya da durum raporları somut teslim yerine yüzdelerle konuşuyorsa, gecikme büyük ihtimalle birikmeye başlamıştır.",{"q":38,"a":39},"Gecikmede sorumluluk kimde olur?","Duruma göre değişir. Tahmin hatası tedarikçinin, geciken kararlar ve veri müşterinin, üçüncü taraf onayları ise çoğu zaman ikisinin de dışındadır. Bu yüzden riskleri ve her iki tarafın sorumluluklarını baştan yazılı hale getirmek önemlidir.",{"q":41,"a":42},"Gecikmiş bir projeyi kurtarmak için ne yapılabilir?","İlk adım genelde kapsamı yeniden kesmektir: hangi işlerin ilk sürümde mutlaka olması gerektiğine bakıp gerisini sonraki faza ertelemek. Ardından açık kararlar listelenir, her birine bir sahip ve tarih atanır ve çalışan sürüm sıklığı artırılır.",1793978420861]