Yazılım geliştirme süresi ve maliyeti, en sık sorulan ama tek bir rakamla yanıtlanması en zor sorudur. Aynı başlık altındaki iki proje, örneğin iki "mobil uygulama", kapsamları yüzünden birbirinden çok farklı emek gerektirebilir. Bu yazıda bilerek rakam vermiyoruz; çünkü sağlıklı bir tahmin ancak kapsam netleştikten sonra yapılabilir. Onun yerine süre ve maliyeti hangi etkenlerin belirlediğini ve teklif istemeden önce neleri hazırlamanız gerektiğini anlatıyoruz.
Süre ve maliyeti belirleyen temel etkenler nelerdir?
Bir yazılımın emek miktarını belirleyen etkenler kabaca şunlardır:
- Kapsam: kaç ekran, kaç kullanıcı rolü, hangi işlemler ve ne kadar derin bir davranış isteniyor.
- Platform sayısı: Android, iOS, Windows ve web hedeflerinin her biri ayrı test ve yayın işi getirir.
- Entegrasyon: başka yazılımlarla, ödeme servisleriyle ya da cihazlarla bağlantı.
- Tasarım yoğunluğu: sade bir arayüz ile özel çizimli, hareketli, markaya özgü bir arayüz arasında ciddi fark vardır.
- Güvenlik ve yetki gereksinimleri: rol bazlı erişim, denetim kaydı, kişisel veri işleme kuralları.
- Veri taşıma: eski bir sistemden yeni sisteme veri aktarılacak mı?
- Test kapsamı: desteklenecek cihaz ve sürüm çeşitliliği.
- Belirsizlik ve değişiklik talepleri: baştan netleşmeyen ya da sonradan değişen istekler.
Bunlara bir de ekip yoğunluğu eklenir. Aynı işi yapan ekibin aynı anda kaç iş yürüttüğü, sürenin takvimdeki karşılığını değiştirir. Bazı işler doğası gereği sırayla yapılır; böyle işlerde ekibe kişi eklemek süreyi aynı oranda kısaltmaz.
Kapsam neden özellik sayısından fazlasıdır?
"Raporlama" tek kelimedir, ama arkasında çok farklı işler olabilir. Tek bir tablo göstermek ile tarih aralığı, filtre, grafik, dışa aktarma ve rol bazlı görünümü olan bir rapor ekranı aynı emeği gerektirmez. "Kullanıcı girişi" de öyledir: telefon numarası ve tek kullanımlık kod mu, e-posta ve parola mı, parola sıfırlama var mı, hesap silme var mı?
Küçük bir örnek: "kullanıcı bildirim alsın" cümlesi bir uygulamada yalnızca tek tip bir anlık bildirimi anlatabilir; bir başkasında ise kullanıcının hangi bildirimi alacağını seçebildiği, bildirimlerin zamanlanabildiği, e-posta ile de gönderildiği ve geçmişinin tutulduğu bir sistemi. Aynı cümle iki ayrı iş anlamına gelir. Tahminlerdeki en büyük sapma çoğu zaman buradan çıkar.
Bu yüzden özellik listesi tek satırlık maddelerden değil, davranışı anlatan açıklamalardan oluşmalıdır. Bir özelliği "ne yapar, hangi durumlarda ne olur" diye yazmak, tahmini gerçeğe yaklaştırır. Listenin nasıl çıkarılacağını yazılım projesi nasıl planlanır yazımızda adım adım anlattık.
Platform sayısı ve entegrasyonlar bütçeyi nasıl etkiler?
Birden fazla platform hedeflemek emeği çoğaltır, ancak oranı teknolojiye bağlıdır. Tek kod tabanıyla Android ve iOS için çalışmak ortak kodun yazımını tek yapar; ama her platformun testi, mağaza hazırlığı ve ince ayarı yine ayrı yürür. Hangi yaklaşımın hangi durumda mantıklı olduğunu Flutter mı yerel geliştirme mi yazısında ele aldık.
Entegrasyonda emek çoğu zaman bizim yazdığımız kısımda değil, karşı sistemin davranışını anlamakta ve test etmekte yatar. Karşı sistemin belgesi var mı, test ortamı sunuyor mu, ileride arayüzünü değiştirir mi? Bu soruların yanıtı planı etkiler. Firmanızdaki sistemlerle bağlantı kurulacaksa sistem entegrasyonu ve cihaz özelleştirme hizmetimiz bu işi kapsar. Entegrasyon planlanırken şu soruları sormak işi netleştirir:
- Karşı sistem hangi yöntemle veri veriyor ve alıyor (API, dosya aktarımı, veritabanı bağlantısı)?
- Test için güvenli bir ortam sunuyor mu, yoksa denemeler canlı veriyle mi yapılacak?
- Veri biçimleri iki tarafta aynı mı, yoksa dönüştürme gerekiyor mu?
- Karşı tarafın sorumlusuna ulaşılabiliyor mu ve sorun çıktığında kim çözecek?
Belirsizlik ve değişiklik talepleri neden pahalıdır?
"Ne istediğimizi tasarım sırasında göreceğiz" yaklaşımı mümkündür, ancak bunu baştan söylemek gerekir; çünkü belirsizlik, tahmin yerine aralık demektir. Belirsiz bir alan ne kadar çoksa tahmin o kadar geniş olur.
Belirsizliği azaltmanın pratik yolu, projenin başında kısa bir keşif çalışması yapmaktır: kritik riskleri belirlemek, belirsiz bir entegrasyonu ya da özelliği küçük ölçekte denemek, ekran taslaklarını netleştirmek. Keşif projeyi yavaşlatmaz; sonradan pahalıya mal olacak yanlış varsayımları erken yakalar.
Değişikliğin bedeli de projenin hangi aşamasında istendiğine bağlıdır. Tasarım aşamasında bir ekranı değiştirmek genellikle ucuzdur; yazılım geliştirilmiş, test edilmiş ve diğer ekranlarla bağlanmışken aynı değişiklik daha fazla emek ister. Bunun nedeni yalnızca yeniden yazma değil, etkilenen yerlerin yeniden test edilmesidir. Değişiklik taleplerini yazılı iletmek ve her birinin etkisini birlikte değerlendirmek bu yüzden önemlidir.
Süreyi kısaltmak neden önerilmez?
Süre, kapsama ve ekip yoğunluğuna göre değişir; bunu "daha hızlı" yapmanın yolu ise genellikle kalitenin başka bir yerden ödenmesidir. Süre kısaltmaya çalışmayı önermememizin nedenleri şunlardır:
- Sıkıştırılan ilk aşama test ve düzenlemedir; bu da hataların kullanıcıya ulaşması demektir.
- Yayından sonra bulunan bir hatayı düzeltmek, geliştirme sırasında bulunandan genellikle daha pahalıdır ve itibar maliyeti de taşır.
- Ekibi büyütmek süreyi doğrusal olarak kısaltmaz; yeni katılanın projeye uyumu ve iletişim yükü de ekler.
- Aceleyle yazılan kod, ileride bakım yükü olarak geri döner.
- Güvenlik ve yetki kontrolleri baskı altında ilk atlanan konulardandır.
Süre kısaltmanın bir başka gizli bedeli, kapsamın görünmeyen kısmının kesilmesidir. Kullanıcıların yalnızca ekranda gördüğü özellikler değil, hata durumlarının ele alınması, veri yedeği, günlük kaydı ve yetki kontrolleri de emek ister. Bunlar kesildiğinde yazılım ilk gün çalışır görünür, ama ilk beklenmedik durumda sorun çıkar.
Bir yazılımın süresini kısaltmak çoğu zaman işi küçültmeden mümkün değildir. İşi küçültmek ise sağlıklı bir yoldur: kapsamı azaltın, süreci değil.
Daha sağlıklı yol: kapsamı aşamalara bölmek
Takvim sıkışıyorsa en sağlam çözüm kapsamı küçültüp sürümlere bölmektir. İlk sürüm yalnızca olmazsa olmaz özellikleri içerir; geri kalanı gerçek kullanımdan gelen bilgiyle sonraki sürümlere dağıtılır. Böylece ilk işiniz erken çalışır, ek işler önceliğe göre eklenir.
Sürümlere bölmenin bir faydası daha vardır: her sürümde gerçek kullanıcıdan geri bildirim alınır ve sonraki kapsam bu bilgiye göre şekillenir. Böylece bütçe, kullanılmayacak özelliklere değil işe yarayanlara harcanır. Ayrıca bir sürüm bittiğinde elinizde çalışan bir ürün olur; her şeyin sonda bir arada teslim edildiği projelerdeki belirsizlikten kaçınırsınız.
Bir diğer yol, özel çözüm gerektirmeyen yerlerde sade çözümü kabul etmektir. Varsayılan olarak sade arayüzle çalışmamızın nedeni de budur: karışıklığı önlemek hem kullanıcıya hem projeye yarar. Hazır bir yazılımın ihtiyacın bir kısmını karşıladığı durumları özel yazılım mı hazır yazılım mı yazımızda değerlendirdik.
Teklif istemeden önce neleri hazırlamalısınız?
Ne kadar hazırlıklı gelirseniz, tahmin o kadar gerçekçi olur. Teklif görüşmesinden önce şunları toparlamanız yeterli bir başlangıçtır:
- Çözmek istediğiniz sorunun ve beklediğiniz sonucun kısa bir tarifi.
- Kullanıcı rolleri ve her birinin yapacağı temel işlemler.
- Hedef platformlar (mobil, masaüstü, web) ve bunların öncelik sırası.
- Mevcut yazılım ve cihazlar; bağlanılması gerekenler.
- Elinizde varsa ekran taslakları, örnek belgeler, benzer bulduğunuz uygulamalar.
- Önceliklerinizin sırası: hangisi olmazsa olmaz, hangisi sonra gelebilir?
Bütçe aralığınızı ya da zaman beklentinizi paylaşmak da yardımcı olur. Bu bilgi, kapsamın hangi bölümünün ilk sürüme sığacağına karar verirken kullanılır; amaç pazarlık değil, gerçekçi bir plan çıkarmaktır. Bütçe belliyse kapsamı ona göre biçimlendirmek, kapsam belliyse bütçeyi ona göre hesaplamaktan genellikle daha sağlıklıdır.
Bir teklifi değerlendirirken yalnızca tutara değil, neyi kapsadığına bakın; kapsamı dar tutulmuş bir teklif ilk bakışta cazip görünebilir. Hazırladığınız bilgilerle yazılım iletişim sayfamızdan bize ulaşırsanız, kapsamı birlikte netleştirerek tahmini gerçek verilere dayandırabiliriz.