Bir kurum yeni bir sistem projesine başladığında talepler hızla birikir: Her departman ihtiyaç duyduğunu, her yönetici de istediği raporu ekler. Sonunda ilk sürüm, daha kimse kullanmadan aylar alacak uzun bir listeye dönüşür.
Sorun şu ki bir sistem ancak gerçek kullanımla değerlendirilebilir. Kullanım geciktikçe, gerçekte neyin eksik olduğunu ve neyin yalnızca kâğıt üzerinde istendiğini fark etmek de gecikir. Bu yazıda ilk sürümün kapsamını nasıl belirlediğimizi, neyin bekleyeceğini ve talepte bulunanları kaybetmeden nasıl “sonra” diyebileceğinizi anlatıyoruz.
Sancılı tek bir süreç, baştan sona
İyi bir ilk sürüm her departmana biraz dokunmaz; tek bir süreci eksiksiz kapsar. Bugün en çok gecikmeye, hataya ya da tekrarlanan işe yol açan süreci seçer, onu ilk adımdan son adıma kadar kurarız; böylece o süreçte çalışan ekip, kenarda tutulan tablolara ve mesajlara ihtiyaç duymaz.
Diyelim ki bir dağıtım şirketi, satış temsilcileri, depo ve muhasebe arasında kaybolan siparişlerle uğraşıyor. Bu durumda ilk sürüm sipariş döngüsünü kapsar: giriş, onay, depoda hazırlama, sevkiyat ve fatura kesme. Bordroyu, demirbaşları ya da satın almayı kapsamaz; ama sipariş döngüsünün baştan sona sistem içinde işlemesini sağlar.
Bir sürecin yarısını kapsayan bir sürüm, diğer yarısını Excel’de bırakır; ekip iki ayrı yerde çalışmak ve verileri iki kez girmek zorunda kalır. Bu da ekibin yeni sisteme güvenini kaybetmesinin en kısa yollarından biridir.
Hangi sürecin seçileceği de yalnızca yönetimin değil, işi yapanların da katıldığı bir karardır. Yönetim sorunun etkisini raporlarda görür; çalışanlar ise saatlerin gerçekte nerede kaybolduğunu bilir.
Neyin gireceğine nasıl karar veriyoruz?
Süreci seçtikten sonra önerilen her maddeyi dört soruyla değerlendiririz:
- Etki: Bu madde olmazsa süreç durur mu ya da elle yapılan işe geri mi döner?
- Bağımlılık: Olmazsa olmaz başka maddeler buna dayanıyor mu? Örneğin kullanıcı yetkileri, her onay ekranından önce gelir.
- Risk: Projenin son günlerinde ortaya çıkmak yerine erkenden test edilmesi gereken belirsiz bir iş kuralı ya da hassas bir hesaplama içeriyor mu?
- Veri hazırlığı: İhtiyaç duyduğu veriler mevcut ve temiz mi? Düzensiz bir müşteri listesine dayanan bir madde, ne kadar iyi kodlanmış olursa olsun aksar.
Etki sorusuna “evet” yanıtı veren bir madde çoğunlukla ilk sürüme girer. Hazır olmayan verilere ihtiyaç duyan bir maddeyi ise ertelemek ve veriler hazır hâle gelene kadar veri taşıma ve temizleme işine paralel olarak başlamak daha uygun olabilir.
Varsayalım ki satış müdürü, satış temsilcilerinin prim hesabının ilk sürüme girmesini istedi. Prim hesabının olmaması sipariş döngüsünü durdurmaz; ama bu hesap, ilk sürümün toplamaya başlayacağı satış verilerine dayanır. Makul karar, bu maddenin beklemesi ve geliştirilene kadar primlerin satış raporundan elle hesaplanmasıdır.
Neler bekler?
Ertelemek reddetmek değildir. Bu, maddenin gerçek kullanımdan daha net bilgiler edinildiğinde geliştirileceğine dair bir karardır. Genellikle bekleyen üç tür madde vardır.
Henüz kimsenin okumadığı raporlar
Yöneticiler başlangıçta çok sayıda rapor ister; oysa işe yarayan raporlar, insanlar gerçek verileri gördüğünde, haftalar süren kullanımın ardından belli olur. İlk sürümde, bugün karar almak için kullanılan raporlardan oluşan kısa bir liste ve sürecin kendisi için basit bir gösterge paneli yeterlidir.
İstenen her rapor için şunu sorun: Bu raporla hangi karar alınacak ve bu kararı kim alacak? Bu soruya yanıt bulamayan bir rapor, kimse bir şey kaybetmeden bekleyebilir.
Geçici olarak elle yürütülen nadir istisnalar
Diyelim ki ayda bir ya da iki kez döviz cinsinden bir sipariş geliyor. Bunun için eksiksiz bir işleyiş kurmak, sağlayacağı tasarruftan daha pahalıya gelebilir; bu yüzden hacmi netleşene kadar yazılı bir prosedürle elle yürütülebilir. Önemli olan, istisnanın bilinmesi ve yazılı olması; tesadüfe bırakılmamasıdır.
Aynısı indirimlerdeki ya da uzak bölgelere yapılan sevkiyatlardaki özel durumlar için de geçerlidir. Bu durumların her biri, ne sıklıkla yaşandığına dair bir notla iş listesine (backlog) kaydedilir; beklediğinizden daha sık tekrarlanırsa bir sonraki sürüm için aday olur.
Elle başlayabilecek bağlantılar
Muhasebe sistemiyle ya da haricî bir kargo platformuyla bağlantı kurmak faydalıdır; ama işin içine kendi takvimi ve kısıtları olan bir taraf daha girer. Başlangıçta düzenli aralıklarla bir dosya dışa aktarılıp diğer sisteme yüklenebilir; otomatik bağlantı ise veriler ve biçimleri oturduktan sonra kurulur. Bu erteleme, bağlantının gerçekte neye ihtiyaç duyduğunu da ortaya çıkarır: hangi alanların aktarılacağını, ne sıklıkla aktarılacağını ve farkları kimin kontrol edeceğini.
Kimseyi kaybetmeden “sonra” nasıl denir?
Bir madde talep edip “Şimdi değil” yanıtını alan kişi, talebinin unutulmasından endişe eder. Bu yüzden karar tek başına yetmez; talep sahibi, talebinin nereye gittiğini ve ne zaman yeniden ele alınacağını görebilmelidir.
Açıkça duyurulan bir erteleme, belirsiz bir sözden daha kolay kabul görür. “Kullanım hacmini gördükten sonra geliştirilecek, aylık toplantıda yeniden gözden geçireceğiz” cümlesi, talep sahibini “Bakacağız” cümlesinden daha çok rahatlatır.
- Her ertelemeyi yazılı bir gerekçeye bağlayın: verinin olmaması, kullanım hacmini görme ihtiyacı ya da henüz geliştirilmemiş bir maddeye bağımlılık.
- Önceliğe göre sıralanmış, herkesin görebildiği tek bir iş listesi tutun; ertelenen her madde bu listede talep edenin adıyla yer alsın.
- Canlıya geçişin ardından listenin gözden geçirileceği bir tarih belirleyin; bu, iptal edilmeyen düzenli bir gözden geçirme olsun.
- Talep sahibine bu arada ne olacağını açıklayın: geçici olarak elle yürütülecek prosedürü ve bunu kimin uygulayacağını.
Ertelenen maddelerin gereksinimleri açıkça yazılmışsa, bunlara daha sonra başlamak kolaylaşır ve tartışmayı baştan açmak gerekmez. Bu gereksinimlerin nasıl yazılacağını “Yanlış anlaşılmayan sistem gereksinimleri nasıl yazılır?” başlıklı yazımızda anlattık.
Kabul ve kullanımın ilk haftaları
İlk sürüm, süreç gerçek verilerle baştan sona sistem içinde işlediğinde ve her kullanıcı hikâyesi için üzerinde anlaşılan kabul kriterleri karşılandığında kabul edilir. Testlerin, sistemi kullanacak kişiler tarafından, özenle düzenlenmiş deneme verileriyle değil, kendi gerçek işlerinden örneklerle yapılmasını tercih ederiz.
Canlıya geçişin ardından ilk haftalar gelir; bu haftalarda gerçekte neyin eksik olduğu, neyin istendiği hâlde kullanılmadığı ve ekranlarda ya da kurallarda neyin değiştirilmesi gerektiği ortaya çıkar. Her geri bildirimi aynı iş listesine kaydedin, ertelenen maddelerle birlikte önceliklendirin ve her birini geldiği anda geliştirmeye girişmeyin. Geri bildirimleri kimin toplayıp kimin önceliklendireceğini canlıya geçişten önce kararlaştırın; böylece bunlar yazılım geliştiricilere her yönden doğrudan ulaşmaz.
Varsayalım ki ekip ikinci haftada, depo çalışanlarının sipariş hazırlama listesini her sabah elle yazdığını fark etti. Bu, hiçbir toplantıda gündeme gelmemiş bir gözlemdir ve bir sonraki sürümde, yöneticilerden birinin canlıya geçişten önce istediği bir rapordan daha öncelikli hâle gelebilir.
Ekibin eski tablolara kendiliğinden dönmeyi bırakması ve iyileştirme taleplerinin yalnızca yönetimden değil, kullanıcıların kendilerinden de gelmesi, ilk sürümün başarılı olduğunu gösteren işaretler arasındadır.
Hızlı karar rehberi
İlk sürüme bir madde eklemeden önce onu şu kurallardan geçirin:
- Seçilen süreç o olmadan tamamlanamıyorsa girer.
- Yokluğu, ekibi aynı süreç için iki ayrı yerde çalışmaya zorluyorsa girer.
- Yetkiler, müşteri verileri ve stok kalemleri gibi temel maddeler ona dayanıyorsa girer.
- Test edilmesi gereken hassas bir hesaplama ya da belirsiz bir iş kuralı içeriyorsa erkenden girer.
- Verileri hazır değilse bekler; verilerin hazırlanmasına paralel olarak başlanır.
- Hangi karar için kullanılacağı henüz belirlenmemiş bir raporsa bekler.
- Yazılı bir prosedürle elle yürütülebilecek nadir bir istisnaysa bekler.
- Düzenli bir dosya dışa aktarımıyla başlayabilecek bir bağlantıysa bekler.
İyi bir ilk sürüm tek bir sorunu baştan sona çözer ve ekip onu gerçekten kullanır.
Küçük bir ilk sürüm bir taviz değil, geri kalanı geliştirilmeden önce herkesin gerçek kullanımdan öğrenmesinin bir yoludur. Kapsamını belirlemek de kodlamanın değil, iş analizinin bir parçasıdır. Durumunuzu ITS ekibiyle görüşebilirsiniz; ilk sürümünüzün hangi süreçle başlayacağını keşif toplantısında birlikte belirleyelim.
İlgili hizmetİş analizi ve ürün danışmanlığı