Yazılım projesi nasıl planlanır sorusunun kısa yanıtı şudur: önce çözülecek sorunu, sonra kullanıcıyı, sonra özellikleri, en sonunda da aşamaları belirleyin. Plan, "ne istediğimizi biliyoruz" duygusunu yazıya dökülmüş, tartışılmış ve öncelik sırasına konmuş bir listeye çevirir. Bu yazıda ihtiyaçtan özellik listesine, oradan proje aşamalarına giden yolu, arayüzsüz yazılımların farkını ve sizin rolünüzü anlatıyoruz.
Planlamaya sorudan başlayın: yazılım hangi sorunu çözecek?
Yazılım taleplerinin çoğu bir çözümle başlar: "şu özellikleri olan bir program istiyoruz". Oysa plan, çözümden önce sorunun tarifini gerektirir. Üç kısa soruya yazılı yanıt vermek çoğu zaman iyi bir başlangıçtır:
- Bu iş bugün nasıl yapılıyor ve nerede aksıyor? (Elle tutulan tablolar, e-postalar, kâğıtlar, eski bir program.)
- Yazılımı kimler, hangi sıklıkla kullanacak?
- Başarıyı nasıl anlayacağız? (Örneğin elle yapılan bir kayıt işinin ortadan kalkması ya da bir raporun kendiliğinden çıkması.)
Küçük bir örnek verelim. Siparişlerini e-posta ve defterle takip eden bir atölye "sipariş takip programı istiyoruz" diyebilir. Üç soruya yanıt verildiğinde asıl sorunun belki siparişlerin kaybolması değil, hangi siparişin hangi aşamada olduğunun kimse tarafından bilinmemesi olduğu ortaya çıkar. Bu durumda çözüm, bir kayıt programından çok bir durum takip ekranı olabilir. Doğru sorun tarifi, doğru yazılımı belirler.
Bu yanıtların sayısal olması şart değildir, ama "işler daha iyi olsun" gibi ölçülemeyen bir hedef de plan için yetersizdir. Başarı ölçütünü baştan yazmak, proje sonunda "bitti mi?" sorusunu tartışmasız hale getirir.
İhtiyaçtan özellik listesine nasıl geçilir?
İhtiyaç bir cümledir, özellik ise bir iştir. Aradaki köprü kullanıcı senaryolarıdır: "Depo sorumlusu gelen malı sisteme girer ve stok kendiliğinden güncellenir" gibi, kimin neyi yaptığını ve sonucun ne olduğunu anlatan kısa cümleler. Her senaryodan bir ya da birkaç özellik çıkar.
Senaryoları yazarken şu başlıkları gözden geçirin:
- Roller: yönetici, çalışan, müşteri, dış sistem. Kim hangi ekranı görecek, hangi işlemi yapabilecek?
- Veri: hangi bilgi girilecek, nerede saklanacak, kimler görecek?
- Bildirim: bir işlem olduğunda kime, hangi yolla haber verilecek?
- Raporlama: kim hangi özeti, hangi aralıkla görmek istiyor?
- Hata durumları: veri eksik girilirse, bağlantı kopar ya da yetkisiz biri denerse ne olacak?
- Dış bağlantılar: firmada kullanılan başka yazılımlarla veri alışverişi gerekiyor mu?
Son madde özellikle önemlidir. Başka yazılımlarla konuşması gereken bir sistem, tek başına çalışan bir sistemden farklı planlanır. Bu konuyu sistem entegrasyonu ve cihaz özelleştirme hizmetimizde ele alıyoruz.
Kapsam ve öncelik: önce neyi yapmalı, neyi sonraya bırakmalı?
Özellik listesi tamamlandığında genellikle uzundur ve maddelerin hepsi aynı önemde değildir. Her özelliği üç gruptan birine yerleştirin:
- Olmazsa olmaz: bunlar olmadan yazılım işe yaramaz.
- Olursa iyi olur: kullanımı kolaylaştırır, ancak ilk gün gerekmez.
- Sonraya: fikir olarak değerlidir, ama ilk sürümü geciktirir.
İlk sürüm, birinci gruptan ve ikinci gruptan seçilmiş birkaç maddeden oluşur. Bu, yazılımı eksik bırakmak anlamına gelmez; gerçek kullanıma erken ulaşmak anlamına gelir, çünkü gerçek kullanım hangi sonraki özelliğin gerçekten gerektiğini gösterir.
Kapsam dışında kalanı da yazın. "Bu sürümde mobil uygulama yok" ya da "raporlar dışa aktarılmıyor" gibi açık cümleler, sonradan çıkacak "bunu zaten bekliyorduk" tartışmalarını önler. Kapsamın süre ve emekle ilişkisini yazılım geliştirme süresi ve maliyeti neleri etkiler yazımızda ayrıntılı anlattık.
Proje başladıktan sonra "madem şunu yapıyoruz, bunu da ekleyelim" cümlesi, kapsamın sessizce büyümesinin en yaygın yoludur. Her ek talep tek başına makul görünür; toplamı ise planı bozar. Çözüm talepleri reddetmek değil, her birini listeye yazıp önceliğini ve etkisini görmektir. Yeni bir madde eklenirken listeden bir şeyin çıkarılması ya da sonraki sürüme kaydırılması da seçeneklerden biridir.
Yazılım projesi hangi aşamalardan geçer?
Arayüzü olan bir yazılımda iş planımız beş aşamadan oluşur:
- Tasarım: ekran akışları ve arayüz çizilir, sizinle birlikte gözden geçirilir.
- Geliştirme: onaylanan tasarım çalışan yazılıma dönüştürülür; arka uç, veritabanı ve arayüz birlikte ilerler.
- Test: yazılım senaryolara göre denenir, hatalar ve eksikler listelenir.
- Düzenleme: bulunan hatalar giderilir, gerekli ince ayarlar yapılır.
- Yeniden inceleme: düzeltmelerin sorunları gerçekten çözdüğü ve yeni bir sorun doğurmadığı kontrol edilir.
Her aşamanın somut bir çıktısı vardır: tasarımda onaylanmış ekran akışları, geliştirmede çalışan bir sürüm, testte hata ve eksik listesi, düzenlemede giderilmiş maddeler, yeniden incelemede kapatılmış liste. Çıktısı belli olmayan bir aşama, ne zaman bittiği anlaşılmayan bir aşamadır; bu yüzden her aşamanın sonunda neyin teslim edileceğini baştan konuşmak gerekir.
Aşamalar birbirini izler, ama her biri kendi içinde döngüsel olabilir. Test sırasında bulunan bir eksiklik, tasarıma dönmeyi gerektirebilir. Geliştirme boyunca ilerleyişi ekran görüntüleriyle e-posta yoluyla bildiririz; geri bildiriminiz bir sonraki adımın yönünü belirler. Her aşamanın ne kadar süreceği kapsama ve ekip yoğunluğuna göre değiştiği için bu yazıda süre vermiyoruz.
Arayüzsüz yazılımda plan nasıl değişir?
Her yazılımın ekranı yoktur. Arka planda sessizce çalışan bir sistem yazılımı, bir veri aktarım servisi ya da bir entegrasyon katmanı kullanıcıya hiçbir pencere göstermeyebilir. Bu durumda Tasarım aşaması çıkar ve plan dört adıma iner: Geliştirme, Test, Düzenleme, Yeniden İnceleme.
Tasarım aşamasının olmaması planlamanın önemsiz olduğu anlamına gelmez. Tersine, ekranda "gör ve onayla" imkânı bulunmadığı için kabul ölçütleri daha belirleyici hale gelir. Arka plan yazılımında şu soruların yazılı yanıtı gerekir:
- Ne zaman ve hangi aralıkla çalışacak?
- Ürettiği veriyi nereye bırakacak?
- Bilgisayarı ya da sunucuyu yavaşlatmaması için hangi koşullar aranacak?
- Bir hata olduğunda bunu kim, nasıl fark edecek (günlük kaydı, bildirim)?
- Kurulum ve güncelleme nasıl yapılacak?
Somut bir örnek Ekran Kaydedici'dir: Windows'ta arayüzsüz çalışan, belirli aralıklarla ekran görüntüsü alıp bir depolama noktasında toplayan bir sistem yazılımı. Böyle bir yazılımda "diğer programların çalışmasını engellemesin" gibi koşullar baştan kabul ölçütü olarak yazılır ve test aşamasında sistem analizleriyle doğrulanır. Bu tür çözümler için masaüstü yazılım geliştirme sayfamıza da bakabilirsiniz.
Planlama sürecinde müşterinin rolü nedir?
İyi planlanmış bir projede müşteri seyirci değil, karar vericidir. Sürecin sağlıklı ilerlemesi için sizden beklediklerimiz şunlardır:
- Karar yetkisi olan bir muhatap belirleyin. Farklı kişilerden gelen çelişkili talepler plana en çok zarar veren şeylerdendir.
- Yazılımı gerçekte kullanacak kişileri sürece katın; kullanıcı çoğu zaman yöneticiden farklı şeyler ister.
- Geri bildirimi zamanında verin. Tasarım onayı bekleyen bir proje ilerleyemez.
- Değişiklik isteklerini dağınık değil, yazılı ve toplu iletin.
- Test aşamasında kendi iş verinizle deneyin; gerçek veri, örnek verinin göstermediği durumları ortaya çıkarır.
- Destek talebi bırakabileceğiniz kanalı öğrenin ve kullanın.
Bunların hiçbiri teknik bilgi gerektirmez. Sizden beklenen, işinizi yakından bilen kişi olarak "bu böyle çalışmaz, şöyle çalışır" diyebilmenizdir. Teknik karşılığı bulmak yazılım ekibinin işidir.
Çalışma biçimimiz buna göre kuruludur: tasarım ve işleyiş kararlarına canlı katılabilir, geliştirme aşamalarını e-postayla izleyebilir, destek talebi bırakabilirsiniz.
Planı yazılı tutun ve değişikliği yönetin
Plan sabit bir belge değil, güncellenen bir anlaşmadır. Kapsam belgesi, özellik listesi ve aşamalar yazılı tutulur. Değişiklik istendiğinde önce "bu eklemenin neyi etkilediği" yanıtlanır, sonra karar verilir. Küçük görünen bir ekleme bile test ve entegrasyon adımlarını etkileyebilir.
Önemli kararları ve nedenlerini de kayıt altında tutun. Aylar sonra "bu özelliği neden böyle yaptık" sorusu geldiğinde kararın gerekçesini bulabilmek, hem bakımı hem de olası tartışmaları kolaylaştırır. Bu kayıt uzun bir belge olmak zorunda değildir; tarihli birkaç satır yeterlidir.
Özetle: sorunu tanımlayın, senaryolardan özelliklere gidin, öncelik verin, aşamaları ve kabul ölçütlerini yazın, sürece katılın. Elinizdeki ihtiyaç için hazır bir yazılımın yeterli olup olmayacağını merak ediyorsanız özel yazılım mı hazır yazılım mı yazımızı okuyabilirsiniz. Projeniz için ilk planı birlikte çıkarmak isterseniz yazılım iletişim sayfamızdan bize yazın.