Bir Uygulama Geliştirmek Ne Kadar Sürer? [Proje Türüne Göre Dürüst Zaman Çizelgeleri]

Her yeni müşteriyle yaptığımız ilk görüşmede neredeyse her zaman şu soruyla karşılaşırız: "Bu ne kadar sürer?" Bu, son derece makul bir sorudur. Bütçeler buna bağlıdır. Yönetim kurulu kararları buna dayalı alınır. Lansman tarihleri bu yanıta göre açıklanır.

Dürüst yanıt — ve insanları hayal kırıklığına uğratan yanıt — zaman çizelgesinin neyi inşa ettiğinize, ne kadar net tanımlandığına, kararların ne hızda alındığına ve kapsamın bitirememize yetecek kadar sabit kalıp kalmadığına bağlı olduğudur. Bir müşteriye "altı ay" demek doğru olabilir. Aynı şeyi, belirsiz bir brifing ve değişen bir hedef çizgisiyle gelen bir sonraki müşteriye söylediğinizde kendinizi felakete hazırlıyorsunuzdur.

Bu rehberi yazdık çünkü gerçek rakamları hak ettiğinize inanıyoruz — belirsiz yanıtları değil. Proje türüne göre gerçek zaman aralıkları verecek, geliştirmenin aşamalarını ve her birinin gerçekten ne kadar sürdüğünü ele alacak, zaman çizelgelerini patlatan (ve kısaltan) spesifik faktörleri açıklayacak ve sabit bir son tarih ile yetersiz tanımlanmış bir brifing karşılaştığında ne olduğunu dürüstçe anlatacağız. Bu rehberin sonunda projenizin ne kadar süreceğine dair çok daha net bir fikre sahip olacak ve bu süreyi mümkün olduğunca kısa tutmak için neler yapabileceğinizi bileceksiniz.

---

Proje Türüne Göre Geliştirme Zaman Çizelgesi

Her proje farklıdır, ancak çoğu tanınabilir kategorilere girer. Aşağıdaki tablo, uygulamada gördüğümüz zaman çizelgelerini yansıtmaktadır — iyimser en iyi durumları veya felaket senaryolarını değil, bir projenin makul ölçüde iyi tanımlandığı ve deneyimli bir ekip tarafından yürütüldüğü durumlardaki gerçekçi aralığı. Her aralık, odaklanmış sprint'lerde çalışan tam bir teslimat ekibini (ürün müdürü, tasarımcı, en az iki geliştirici, bir KG mühendisi) varsayar.

Proje Türü	Tipik Zaman Çizelgesi	Neler Dahil	Temel Varsayımlar
Basit web uygulaması / dahili araç	6 – 12 hafta	CRUD arayüzleri, kullanıcı kimlik doğrulama, temel gösterge paneli, 2–3 entegrasyona kadar	İyi tanımlanmış gereksinimler, karmaşık iş mantığı yok, mobil uygulama yok
SaaS MVP	12 – 20 hafta	Çok kiracılı mimari, abonelik/faturalama, çekirdek özellik seti, yönetici paneli, katılım akışı	Özellik seti baştan onaylanmış, tek platform (web), eski sistem entegrasyonu yok
Mobil uygulama MVP	16 – 24 hafta	iOS veya Android (ya da her ikisi), temel ekranlar, anlık bildirimler, backend API, uygulama mağazası gönderimi	Yerel veya çapraz platform, gerçek zamanlı senkronizasyon yok, sıfırdan veya iyi belgelenmiş backend
Pazar yeri platformu	20 – 32 hafta	Alıcı ve satıcı akışları, ödemeler ve ödemeler, ilanlar, yorumlar, moderasyon araçları	İki taraflı kullanıcı modeli, ödeme entegrasyonu, düzenleyici karmaşıklık yok
Kurumsal platform	6 – 18 ay	Özel iş akışları, ERP/CRM entegrasyonu, rol tabanlı erişim, uyumluluk gereksinimleri, raporlama	Büyük paydaş grubu, aşamalı teslimat, entegre edilecek mevcut sistemler

Burada birkaç noktayı açıklamak gerekir. Daha karmaşık projeler için aralıklar daha geniştir; bu, muğlak davrandığımız için değil, karmaşıklık ve organizasyonel faktörlerin gerçekten büyük farklılıklar yarattığı içindir. Daha önce bu deneyimi yaşamış, ayrıntılı bir ürün brifingine sahip ve 24 saat içinde tasarım kararı verebilen bir müşteri için inşa edilen bir pazar yeri, ürünü ekip geliştirirken hâlâ şekillendiren ilk kez kurucu olan biri için geliştirilenle kıyaslandığında daha hızlı lansmanı olacaktır. Her iki durum da meşrudur. Sadece farklı zaman çizelgeleri üretirler.

Kurumsal satır kasıtlı olarak geniş tutulmuştur — 6 ila 18 ay — çünkü kurumsal projelerde kapsam, entegrasyon karmaşıklığı ve kurumsal karar alma hızı en büyük farklılığı burada göstermektedir. Beş ayda kurumsal araçlar teslim ettik. Aynı zamanda, iyi kaynaklara sahip ekiplerin, benzer teknik karmaşıklıktaki platformlar üzerinde iki yıl sürdüğünü de gördük; çünkü satın alma, uyumluluk onayı ve paydaş uyumu aya aya takvime eklendi.

---

Yazılım Geliştirmenin 5 Aşaması ve Her Birinin Ne Kadar Sürdüğü

Bu zaman çizelgesinin içinde gerçekte neler olduğunu anlamak yardımcı olur — çünkü "geliştirme" tek bir şey değildir. Her birinin kendi çıktıları, bağımlılıkları ve başarısızlık biçimleri olan bir dizi aşamadır.

Aşama 1: Keşif — 2 ila 4 Hafta

Keşif, çoğu müşterinin atlamak istediği ve çoğu ajansın kötü uyguladığı aşamadır. Düzgün yapıldığında, tüm projedeki en yüksek kaldıraçlı yatırımdır.

Keşif aşamasında üç soruyu yanıtlamaya çalışıyoruz: Aslında hangi sorunu çözüyoruz? Başarı ölçülebilir terimlerle nasıl görünür? Ve planlamak zorunda olduğumuz riskler nelerdir? Paydaşlarla yapılandırılmış çalıştaylar düzenliyor, mevcut iş akışlarını haritalandırıyor, entegre edilmesi gereken sistemleri denetliyor ve ardından gelen her şey için gerçeğin temelini oluşturan bir ürün gereksinimleri belgesi üretiyoruz.

İyi tanımlanmış bir dahili araç veya MVP için iki hafta gerçekçidir. Birden fazla paydaş grubu, eski entegrasyonlar veya düzenleyici gereksinimler içeren her şey için dört hafta uygundur. Keşif daha fazla sıkıştırılamaz — kaybettiğiniz şey, aşağıdaki her şeyi daha hızlı kılan hassasiyettir.

Aşama 2: Tasarım — 2 ila 4 Hafta

Tasarım büyük ölçüde keşifle sıralı olarak ilerler, ancak pratikte ikisi çakışır. Bilgi mimarisi, wireframe'ler ve yüksek sadakatli kullanıcı arayüzü tasarımları üretiyoruz; bunları geliştirme ekibi tam olarak inşa ediyor — gevşek bir yorumlama ile değil.

Bu aşamanın hızı neredeyse tamamen tasarım kararlarının ne hızda onaylandığına bağlıdır. Bir tasarım için bir gün içinde evet veya hayır diyebilen tek bir müşteri paydaşı, iki haftanın iki hafta olarak kalması anlamına gelir. Düğme renkleri üzerinde rekabet eden görüşlere sahip beş kişilik bir komite ise iki haftalık tasarım çalışmasını beş haftaya çıkarır.

Figma'da bileşen tabanlı tasarım kullanıyoruz; bu, burada oluşturulan tasarım sisteminin geliştirme boyunca temettü ödemeye devam ettiği ve gelecekteki özellik çalışmasını önemli ölçüde daha ucuz hale getirdiği anlamına gelir.

Aşama 3: Geliştirme — 4 ila 24 Hafta (Proje Türüne Göre Değişir)

Bu en uzun ve en değişken aşamadır. Geliştiriciler gerçek ürünü inşa ediyorlar; bu, backend API'ları, veritabanı mimarisi, frontend arayüzleri, üçüncü taraf hizmetlerle entegrasyonlar ve tüm bunların üzerinde çalıştığı altyapı anlamına gelir.

İki haftalık sprint'lerde çalışıyoruz; sonda tek büyük bir teslimat yerine her sprint sonunda işlevsel, test edilebilir yazılım teslim ediyoruz. Bu önemlidir çünkü gerçek ilerlemeyi görüyorsunuz, sadece durum güncellemelerini değil. Aynı zamanda, kapsam değişikliklerinin — ve neredeyse her zaman bazıları olur — bir kriz haline gelene kadar görünmez biçimde emilmek yerine kasıtlı olarak yönetilebildiği anlamına gelir.

Geliştirme süresi, ilk tablomuzdaki proje türü aralıklarının esas olarak yaşadığı yerdir. Basit bir dahili araç dört haftaya ihtiyaç duyabilir. Bir pazar yeri platformu on sekiz hafta gerektirebilir.

Aşama 4: Test — Geliştirmeyle Paralel Yürür

Test, geliştirme tamamlandıktan sonra gerçekleşen bir aşama değildir. Yapı boyunca paralel olarak sürekli devam eden bir faaliyettir. KG mühendislerimiz gereksinimler belgesinden test senaryoları yazar, her sprint çıktısını bunlara göre çalıştırır ve hataları birikmeden önce geliştirme döngüsüne geri besler.

Lansmandan önce uçtan uca test, sprint bazlı KG'nın üstüne genellikle bir ila iki hafta ek süre alır. Bu pazarlık konusu değildir. Üretimde bir hatanın maliyeti — kullanıcı güveninde, acil durum geliştirici süresinde, itibar açısından — onu test aşamasında yakalama maliyetinden büyüklük sırasıyla daha yüksektir.

Aşama 5: Dağıtım ve Lansman — 1 ila 2 Hafta

Modern bir web uygulamasını dağıtmak sadece bir düğmeye basmak değildir. Üretim altyapısının yapılandırılmasını, izleme ve uyarı sistemlerinin kurulmasını, son güvenlik kontrollerinin yapılmasını, gerektiğinde üretim verilerinin yerleştirilmesini ve hazırlamadan canlıya geçişi kullanıcılara mümkün olduğunca görünmez kılan bir lansman dizisinin yürütülmesini kapsar.

Mobil uygulamalar için bunun üstüne uygulama mağazası inceleme süresi de ekleyin. Apple App Store incelemesi şu anda standart gönderimlerde iki ila yedi gün sürmektedir, ancak belirli kategorilerdeki uygulamalar için bu süre daha uzun olabilir. Google Play genellikle bir ila üç gün içinde inceler, ancak yeni geliştirici hesapları daha uzun sürebilir.

---

Projelerin Beklenenden Daha Uzun Sürmesinin Nedenleri

Takvimin dışına çıkan her projenin bunun bir nedeni vardır. Deneyimimize göre, nedenler beş kategoride kümeleniyor — ve bunların çoğu, neye dikkat edeceğinizi bilirseniz önceden büyük ölçüde tahmin edilebilir.

Belirsiz veya Eksik Gereksinimler

Takvim aşımının en yaygın nedeni, ne inşa ettikleri açıkça tanımlanmadan önce inşa etmeye başlamaktır. Gereksinimler belirsiz olduğunda, geliştiriciler varsayımlarda bulunur. Bu varsayımlar test veya demo oturumlarında gözden geçirilir ve yanlış çıkar. Çalışma yeniden yapılır. Bu döngü, tüm yetersiz tanımlanmış özellikler boyunca haftaları yiyip bitirecek şekilde tekrar eder.

Çözüm, doğru keşiftir. Başlangıçta bir ek yük gibi hissettiriyor. Defalarca geri ödüyor.

Yavaş Müşteri Taraflı Karar Alma

Geliştirme ekiplerinin bir temposu vardır. Bu tempo, müşteri girdisi olmadan alınamayacak bir kararla karşılaştığında — bir tasarım onayı, bir kopya revizyonu, kullanıcıların nasıl segmentlere ayrıldığına ilişkin bir politika sorusu — ve bu karar bir gün yerine beş günde geri döndüğünde, tüm sprint ayarlanır. Bunu bir projedeki on karara çarpın ve tek bir satır kod yanlış olmadan iki ila dört hafta eklemiş olursunuz.

Bu, müşterilere yönelik bir eleştiri değildir. Meşgul kurucuların ve operasyonel liderlerin başka işleri vardır. Ama bu, zamanın nereye gittiğinin dürüst bir muhasebesini sunmaktadır.

Entegrasyon Karmaşıklığı

Üçüncü taraf sistemlerle entegrasyon, dışarıdan göründüğünden neredeyse her zaman daha zordur. Kötü belgelenmiş API'lar, korumalı alan ile üretim ortamlarında farklı davranan, beklenmedik şekilde hız sınırlayan veya tutarsız veri şekilleri döndüren sistemler geliştirme süresine eklenir. Eski sistemler — ERP'ler, eski CRM'ler, özel veritabanları — genellikle hiç resmi API'ye sahip değildir ve özel ara katman yazılımı veya dönüşüm katmanları gerektirir.

Entegrasyon riskini keşif aşamasında değerlendiriyoruz. Ancak bir kısmı, ancak bir geliştirici sisteme gerçekten bağlandığında ve gerçek istekler göndermeye başladığında ortaya çıkıyor.

Geliştirme Ortasında Kapsam Değişiklikleri

"Sadece şunu ekleyebilir miyiz..." yazılım geliştirmede en pahalı cümledir. Her değişikliğin her zaman büyük olduğu için değil, birikmelerinden dolayı. Altıncı haftada eklenen bir özellik, ikinci haftada tamamlanan veri modelinin yeniden düşünülmesini gerektirebilir. Onuncu haftada eklenen yeni bir kullanıcı türü, uygulamadaki her ekrana yerleştirilmiş varsayımları bozabilir.

Kapsam değişiklikleri özünde kötü değildir — gereksinimler gelişir, pazarlar değişir, şeyler öğrenilir. Ancak bunların, zaman çizelgesi ve maliyet üzerindeki gerçek etkilerini hesaba katan resmi bir değişiklik süreci aracılığıyla yönetilmesi gerekir. Bunlar gayri resmi olarak emildiğinde, takvim görünmez biçimde uzar ve sonra aniden.

Keşfedilmemiş Teknik Kısıtlamalar

Bazı kısıtlamalar ancak inşaat başladıktan sonra ortaya çıkar: test edilenden farklı bir kullanıcı arayüzü etkileşimini işleyen bir mobil tarayıcı, test verileriyle iyi performans gösteren ancak üretim yükü altında kötüleşen bir veritabanı sorgusu, entegrasyon ortağının API'sinin özel bir geçici çözüm olmadan karşılayamayacağı bir güvenlik gereksinimi. Bunlar planlama hataları değil — karmaşık yazılım inşa etmenin doğasında var olan belirsizliktir. İyi ekipler bunları spike'lar ve prototipleme yoluyla erken aşamada yakalar. Daha az deneyimli ekipler, bunları on dördüncü haftada keşfeder.

---

Bir Projeyi Gerçekten Hızlandıran Şeyler

Bir projeyi hızlandıran faktörler, yavaşlatanların ayna görüntüsüdür — ancak uygulanabilir oldukları için bunları açıkça belirtmek değerlidir.

• Geliştirme başlamadan önce net, yazılı gereksinimler. Bir slayt destesi değil. Kullanıcı hikayeleri, kabul kriterleri ve herkesin onayladığı açıklamalı wireframe'ler içeren bir gereksinimler belgesi. Bu, en büyük yeniden çalışma kaynağını ortadan kaldırır.
• Müşteri tarafında özel bir ürün sahibi. Ürün kararları almak için yetkili, günlük olarak erişilebilir, günler yerine saatler içinde soruları yanıtlayabilen tek bir kişi. Deneyimimize göre bu tek faktör, neredeyse diğer her şeyden daha fazla proje temposunu etkiler.
• Hazır bileşen kütüphaneleri ve tasarım sistemleri. Her projede kimlik doğrulama, rol tabanlı izinler, bildirim sistemleri, ödeme akışları gibi yaygın unsurların sıfırdan tasarlanmasına gerek kalmamasını sağlayan yeniden kullanılabilir frontend bileşen kütüphaneleri ve backend modülleri bakımını yapıyoruz.
• Aşamalı teslimat ve tanımlanmış MVP kapsamı. İlk gönderilebilir sürümün neler içereceği konusunda önceden anlaşmak — ve geri kalanı gelecekteki bir iş birikimine bırakmak — çoğu projeyi durduran kapsam kaymasını önler. Kullanıcıların eline bir şeyi daha hızlı geçirirsiniz; bu da sonraki aşamaları daha iyi kılan gerçek geri bildirim üretir.
• Deneyimli, kıdemli ağırlıklı bir ekip. Kıdemli mühendisler mimari kararları ilk seferinde doğru verir. Riskleri gerçekleşmeden önce tespit ederler. Test etmesi ve genişletmesi daha kolay kod yazarlar. Günlük maliyeti daha yüksektir. Toplam proje maliyeti, genç ağırlıklı ekiplerin ürettiği yeniden çalışmayı üretmedikleri için düzenli olarak daha düşüktür.

---

Zaman Çizelgesi Karşılaştırması: Ajans vs. Serbest Çalışan vs. Şirket İçi Ekip

Zaman çizelgesini teknik faktörler kadar şekillendiren kararlardan biri, kimin inşa edeceğidir.

Çalışma Türü	Tipik Başlangıç Süresi	Geliştirme Hızı	Tipik Güçlü Yönler	Tipik Riskler
Yazılım Ajansı	2 – 4 hafta (oryantasyon)	Hazır hale geldikten sonra hızlı — tam ekip mevcut	Tam yetenek yığını, yönetilen teslimat, hesap verebilirlik	Daha yüksek günlük ücret, birden fazla müşteriyle çalışabilir
Serbest Çalışan / Bağımsız Geliştirici	1 – 2 hafta	Daha yavaş — bir kişi, sıralı görevler	Düşük maliyet, doğrudan iletişim	Tek başarısızlık noktası, sınırlı kapasite, geliştirme dışı becerilerde boşluklar
Şirket İçi Ekip	3 – 6 ay (işe alım)	Kurulduğunda en hızlı, oluşturulması en yavaş	Derin ürün bilgisi, tam erişilebilirlik	Yüksek sabit maliyet, ölçeklenmesi zor, işe alım zaman alır

İlk ürünü veya yeni bir platformu inşa eden çoğu şirket için, bir ajans çalışan bir uygulamaya giden en hızlı yoldur. Neden basittir: ekip zaten vardır. Bir tasarımcı, bir backend geliştirici, bir frontend geliştirici ve bir KG mühendisini ayrı ayrı işe almanıza gerek yoktur — etkileşiminizin ilk gününden itibaren zaten birlikte çalışıyorlar, yerleşik süreçleriyle.

Serbest çalışanlar, tek bir disiplinin gerektiği küçük, sıkı kapsamlı projeler için iyi sonuç verebilir. Ancak tek bir geliştirici aynı anda ürün yöneticisi, tasarımcı, full-stack mühendisi ve KG mühendisi olamaz — ve ciddi uygulamaların çoğu bunların hepsine ihtiyaç duyar.

Şirket içi ekipler, bir ürünü gönderdikten, süregelen geliştirme ihtiyaçlarınız olduğunda ve sabit genel gideri haklı kılabildiğinizde mantıklıdır. Henüz işe almadığınız bir şirket içi ekiple yeni bir ürün inşa etmek, çoğu şirketin karşılayamayacağı bir takvim riskidir.

---

Önce MVP Stratejisi

Takvim konusunda endişeli olan müşterilere verdiğimiz en tutarlı tavsiyelerden biri şudur: her şeyi bir anda inşa etmeye çalışmayın.

Önce MVP stratejisi, uygulamanızın gerçek kullanıcılara gerçek değer sunan en küçük sürümünü tanımlamak ve önce bunu inşa etmek anlamına gelir. Genellikle proje türüne bağlı olarak 8 ila 14 hafta sürer. Tam vizyon dokuz aya kadar inşa edilebilir. On iki haftada kullanılabilir bir şey teslim etmek, takvim yönetiminin ötesine geçen nedenlerle dokuz aylık tam yapıya karşı üstünlük sağlar.

Birincisi, tüm bütçeyi harcamadan önce gerçek kullanıcı geri bildirimi alırsınız. Çekirdek değer önerisi olduğunu düşündüğünüz özellik, kullanıcıların pek dokunmadığı bir şey olabilir. İkincil olarak gördüğünüz şey, her destek görüşmesinde sordukları konu olabilir. Bunu on dördüncü haftada bilmek, ardından gelen her sprint'in şeklini değiştirir.

İkincisi, yanlış şeyi inşa etme riskini azaltırsınız. Çoğu ilk ürün, ilk konsept ile ürün-pazar uyumu arasında önemli ölçüde evrimleşir. Kullanıcılara ulaşan on iki haftalık bir MVP, sizi akıllıca evrimleşme konumuna koyar. Kullanıcılara ulaşan dokuz aylık tam yapı, sizi olabilecek noktadan dokuz ay geride bırakır — ve hâlâ aynı evrimi gerektirir.

Üçüncüsü, paydaşlara ilerlemeyi kanıtlar. İster yatırımcılar, ister bir yönetim kurulu, ister dahili kullanıcılar ya da ödeme yapan müşteriler olsun, gerçekten giriş yapabilecekleri bir şey, bir Gantt şeması ve bir durum güncellemesinden farklı bir ağırlık taşır. Güven inşa eder, geri bildirim çeker ve ivme yaratır.

Neredeyse her yeni ürün etkileşimini önce MVP etrafında yapılandırıyoruz. Hedef her zaman sizi gönderilebilir bir şeye ulaştırmak, ardından gerçek dünya verisinin avantajıyla oradan yinelemektir.

---

Sabit Son Tarihler ve Maliyetleri

Bazen son tarih müzakere edilemez. Düzenleyici yürürlük tarihi. Konferans duyurusu. Kendi müşterinizle sözleşmeli bir kilometre taşı. Tarih sabit olduğunda, baskıyı genellikle emen değişkenler — kapsam, maliyet ve kalite — kasıtlı olarak yönetilmek zorundadır.

Proje yönetimi gerçekliği, bazen demir üçgen olarak adlandırılan kavramda özetlenir: hızlı, ucuz veya kaliteli olabilir — ve genellikle ikisini seçebilirsiniz. Hız sabit olduğunda, başka bir şeyin vermesi gerekir.

Ek kaynaklar aracılığıyla takvimi sıkıştırmak belirli bir noktaya kadar işe yarar. Bir frontend kısıtlamalı yapıya ikinci bir frontend geliştiricisi eklemek zamanlamayı kısaltabilir. Ancak bir tavanı vardır — beş geliştiricinin tek bir geliştiricinin olduğu bir projeye eklenmesi onu beş kat hızlandırmaz. Yazılım geliştirmenin paralel olmayan kısımları ve koordinasyon yükü kazançları sınırlandırır. Ayrıca bir maliyeti de vardır: her ek kıdemli geliştirici anlamlı günlük ücret maliyeti ekler ve çalışmalarını entegre etmek için harcanan süre kendi ek yükünü getirir.

Azaltılmış kapsam aracılığıyla takvimi sıkıştırmak en güvenilir kaldıraçtır. Son tarih değiştirilemez olduğunda, müşterilerle yaptığımız görüşme her zaman şudur: çekirdek lansman değerini tehlikeye atmadan sonraki bir sürüme ne erteleyebiliriz? Bu, dürüst önceliklendirme gerektirir, iyimserlik değil. Planlamada vazgeçilmez hissettiren özellikler, genellikle kullanıcıların ilk birkaç ay için yaşayabileceği şeyler olarak çıkıyor.

Kalite borcu kabul ederek takvimi sıkıştırmak, kimsenin konuşmak istemediği ancak pek çok projenin örtük olarak aldığı seçenektir. Test süresini kesmek, kod incelemesini atlamak, uygun hata işleme olmadan göndermek — bunlar kısa vadede günler kazandırabilir ve uzun vadede aylara mal olabilir. Bu baskının oluştuğunu gördüğümüzde müşterilerle açık sözlü oluyoruz, çünkü teknik borç taşıma kararının bilinçli olarak verilmesi gerekir, üretimde keşfedilmemeli.

---

Cyberbeak'te Zaman Çizelgelerini Nasıl Planlıyoruz

Şeffaflığın daha iyi çalışma ilişkileri kurduğuna inandığımız için kendi sürecimiz hakkında doğrudan konuşacağız.

Her proje, yazılı bir kapsam belgesi, önceliklendirilmiş bir özellik iş birikimine ve sprint bazında ayrılmış takvim tahminine sahip yapılandırılmış bir keşif aşamasıyla başlar. Takvim, iyimser bir varsayım üzerine kurşun kalemle yazılmış tek bir tarih değil — kilometre taşları olan, bağımlılıkları açıkça işaretlenmiş ve risk azaltma yaklaşımlarıyla birlikte belgelenmiş tanımlanan risklerle sprint bazında bir plandır.

Sprint düzeyinde tampon oluşturuyoruz — genellikle her sprint kapasitesinin yüzde on ila on beşi — genel zamanlamayı bozmadan yazılım geliştirmede doğasında var olan bilinmeyenleri emmek için. Bu dolgu değildir; dürüst planlamadır. Gevşek olmadığını iddia eden projeler, bu gevşekliği test aşamasından veya entegrasyon çalışmasından ödünç alıyorlar ve her zaman faizle geri ödüyorlar.

Müşterilerle haftalık kilometre taşı incelemeleri yapıyoruz. Bunlar, bir ilerleme tablosundan okuduğumuz durum toplantıları değildir. İnşa edilenleri demo yaptığımız, ne geldiğini gözden geçirdiğimiz, plandan sapan her şeyi işaret ettiğimiz ve nasıl yanıt verileceği konusunda ortak kararlar aldığımız çalışma oturumlarıdır. Bir özellik tahmin edilenden daha uzun sürüyorsa, bunu son tarihten önceki son haftada değil, o haftanın toplantısında söylüyoruz.

Proje ortasında ortaya çıkan kapsam eklemeleri için bir değişiklik kontrol süreci kullanıyoruz. Bu, kendi başına bürokratik bir süreç değildir. Orijinal takvimi dürüst tutmanın yoludur. Her değişiklik talebi, belgelenmiş bir etki değerlendirmesi alır: kaç ek gün, maliyet nedir, mevcut sprint planından ne yerinden edilir. Bu, değiş tokuşu görünür kılar ve müşteri bunu kabul edip etmeyeceğine karar verir.

Son olarak, teknik riski açıkça takip ediyoruz. Keşif sırasında, en fazla sürpriz üretme olasılığı yüksek entegrasyonları, veri yapılarını ve uç durumları tespit ediyoruz. Projenin erken dönemlerinde spike'lar — kısa, zaman sınırlı araştırmalar — planlıyoruz; bu varsayımlar yük taşıyan hale gelmeden önce onlarla ilgili varsayımlarımızı doğrulamak için. Bu, bunları planlamayan projelerde zaman çizelgelerini batıran keşfedilmemiş kısıtlamaları yakalar.

---

Sıkça Sorulan Sorular

Daha Fazla Ödersem Daha Hızlı Teslim Edebilir misiniz?

Belirli bir noktaya kadar evet — ancak net sınırlarla. Ek bütçe, daha büyük bir ekibi finanse edebilir; bu da daha fazla çalışmayı paralel hale getirebilir ve zamanlamayı sıkıştırabilir. Ancak yazılım geliştirmenin doğasında sıralı bağımlılıklar vardır: kaç geliştirici mevcut olursa olsun, bazı şeyler diğerleri tamamlanmadan başlayamaz. Kaynaklar eklemek, gerçek anlamda paralelleştirilebilir çalışmanın bulunduğu frontend veya backend kısıtlamalı yapılarda en çok yardımcı olur. Belirli bir ekip büyüklüğünün ötesinde, ek kişi sayısı çıktı eklemesinden daha hızlı koordinasyon yükü ekler. Ek yatırımın tarihinizi gerçekten öne alıp alamayacağı konusunda her zaman dürüstçe tavsiyede bulunacağız.

Proje Ortasında Gereksinimleri Değiştirirsem Ne Olur?

Gereksinimler değişecektir. Bunu bekliyoruz ve sürecimiz bununla başa çıkıyor. Önemli olan, değişikliklerin sprint planına kabul edilmeden önce resmi bir etki değerlendirmesinden geçmesidir. Değişikliğin ne olduğunu, kaç gün eklediğini, maliyetinin ne olduğunu ve neyi yerinden ettiğini belgeliyoruz. Kabul edip etmeyeceğinize siz karar verirsiniz. Gayri resmi olarak emilen değişiklikler — "sadece küçük bir şey" — projelerin hiç kimsenin zamanın nereye gittiğini tam olarak bilmeden haftalar kaybetme şeklidir.

Test Süre Ekler mi?

Test, proje boyunca geliştirmeyle paralel yürür; bu nedenle insanların bazen varsaydığı gibi geliştirmenin üzerine süre eklemez. Lansmandan önceki uçtan uca test aşaması — genellikle bir ila iki hafta — başından itibaren zaman çizelgesine dahil edilir. Bir son tarihe ulaşmak için testi atlamak veya sıkıştırmak, bir projenin alabileceği en pahalı kararlardan biridir. Üretimde kritik bir hatanın maliyeti, kullanıcı güveni ve acil mühendislik süresi açısından, test takviminden kazanılan herhangi bir şeyi nadiren haklı kılar.

Uygulama Mağazası Onayı Ne Kadar Sürer?

Apple App Store incelemesi şu anda çoğu uygulama için iki ila yedi iş günü sürmektedir; ancak belirli hassas özelliklere sahip uygulamalar veya yeni geliştirici hesapları daha uzun sürebilir ve redler — yeniden gönderim gerektiren — ek süre ekler. Google Play incelemesi genellikle bir ila üç gün sürer. Uygulama mağazası inceleme süresini mobil proje zaman çizelgelerimize dahil ediyoruz ve lansman tarihini ötelemeden standart döngüdeki bir reddi ve yeniden gönderimi karşılayacak yeterli tamponla gönderiyoruz.

Gerçek Projelerde En Çok Gecikmeye Ne Neden Olur?

Dürüst deneyimimizde: yavaş geliştiriciler değil, yavaş kararlar. Projenin takvimin dışına çıkmasının en yaygın nedeni teknik değildir — tasarım onaylarını, müşterilerden içerik, sistemlere erişim, dahili olarak anlaşılmamış olduğu ortaya çıkan iş kurallarının onayı veya zaten inşa edilmiş çalışmayı yeniden düşünmeyi gerektiren stratejik yön değişikliğini beklemektir. İkinci en yaygın neden, planlamada göründüğünden daha belirsiz olan gereksinimlerdir. Her ikisi de, keşfe doğru başlangıç yatırımı ve proje boyunca müşteri tarafından doğru müsaitlik taahhüdüyle büyük ölçüde önlenebilir.

---

Bir proje için zaman çizelgesi planlamaya çalışıyorsanız ve bir aralıklar tablosundan daha spesifik bir şey istiyorsanız, yapabileceğimiz en faydalı şey ne inşa ettiğinizi birlikte konuşmaktır. Belirsiz bir zaman çizelgesini gerçekçi bir zaman çizelgesine dönüştüren soruları soracağımız ücretsiz bir saatlik kapsam belirleme görüşmesi sunuyoruz — ve projenizin büyük olasılıkla ne kadar süreceğini ve neden süreceğini dürüstçe gösteren bir değerlendirme sunuyoruz.

Ekibimizle iletişime geçin ve oradan devam edelim.