Pek çok yazılım projesi “Bir uygulama istiyoruz” ya da “Bir satış sistemine ihtiyacımız var” gibi bir cümleyle başlar ve konuşma hemen ekranlara, teknolojilere ve fiyatlara geçer. Yarı yolda ise en başta sorulması gereken sorular gündeme gelir; bunun sonucunda aşamalar gecikir, maliyet artar ve her taraf anlaşmayı kendi bildiği gibi yorumlamaya başlar.
Aşağıdaki beş soruyu yazılım geliştirici değil, işletme sahibi yanıtlar; bunu herhangi bir yazılım firmasıyla görüşmeden önce de yapabilirsiniz. Bunun için teknik bilgiye değil, işinizi tanımaya ve işin günlük ayrıntılarını bilen kişilerle birlikte ayıracağınız sakin bir zamana ihtiyacınız vardır.
Projeler neden yanlış yerden başlar?
İşletme sahibi ne istediğini belirlemeden fiyat teklifi istediğinde, her firma boşluğu kendi varsayımlarıyla doldurur. Sonuçta birbiriyle karşılaştırılamayan teklifler gelir: Biri tek şube için küçük bir sistem varsayar, diğeri muhasebe, depo ve tüm şubelerle bağlantı kurulacağını varsayar.
Sorun tekliflerle sınırlı da kalmaz. Yazılı olmayan varsayımlar proje ilerledikçe değişiklik taleplerine dönüşür; her değişiklik talebi de zaman, maliyet ve neyin “zaten anlaşılmış” olduğu üzerine bir tartışma demektir. Birkaç soruyu önceden yanıtlamak, bu gri alanı bir anlaşmazlığa dönüşmeden daraltır.
Üstelik sistemi geliştiren firma işinizi sizin kadar tanımaz. Sipariş döngüsünde ya da indirimlerin onaylanmasında size apaçık görünen bir şey, yazılmadıkça firmanın aklına gelmeyebilir.
Beş soru
Tam olarak hangi sorunu çözüyoruz?
“Bir uygulama istiyoruz” ifadesi bir sorunu değil, önerilen bir çözümü anlatır. Sorun işin diliyle yazılır: Siparişler şubeler arasında kayboluyor, faturalar gecikiyor ya da müşteri siparişinin ne durumda olduğunu bilmiyor. Sorun açıkça ifade edildiğinde, önerilen her çözüm için tek bir ölçüt kalır: Bu sorunu çözüyor mu, çözmüyor mu?
İyi bir yanıt kısa ve somuttur; sorunun araçlar üzerindeki değil, iş üzerindeki etkisini anlatır. Diyelim ki bir dağıtım şirketi “Satış temsilcileri için bir uygulamaya ihtiyacımız var” diyor. Sorular sorulduğunda ise siparişlerin depoya dağınık telefon görüşmeleri ve mesajlarla ulaştığı; bu yüzden bazılarının eksik sevk edildiği, bazılarının da tam bir gün geciktiği ortaya çıkıyor.
Bu tanımdan yola çıkılabilir; çünkü satın alınmak isteneni değil, olup biteni anlatır. Bu tanımı yazarken sorunun bir kısmının, kodlamaya hiç başlamadan bir süreci değiştirerek çözülebileceğini de fark edebilirsiniz.
Sistemi kimler kullanacak ve bugün nasıl çalışıyorlar?
Her kullanıcının iş günü farklıdır: resepsiyon görevlisi, muhasebeci, saha satış temsilcisi ve yönetici. Tek bir rol için tasarlanıp diğer rolleri görmezden gelen bir sistem kısmen kullanılır; ardından kenarda tutulan tablolar yeniden devreye girip boşluğu doldurur.
İyi bir yanıt, her rolün bugün işini nasıl yaptığını anlatır; WhatsApp grupları ve kenarda tutulan Excel tabloları gibi geçici çözümler de buna dâhildir, çünkü bu çözümler resmî prosedürlerde görünmeyen gerçek gereksinimleri ortaya çıkarır. Çalışma koşullarının kendisini de gözden kaçırmaz: Satış temsilcisi sahada cep telefonundan mı çalışıyor, şubelerde internet bağlantısı her zaman var mı?
Varsayalım ki şirketin muhasebecisi, her akşam ödemelerle faturaların mutabakatını yaptığı kendine ait bir tablo tutuyor. Bu tablo işin hiçbir resmî tanımında yer almıyor, ama açık bir gereksinimdir: Yeni sistem bu mutabakatı o tablo olmadan yapmayı mümkün kılmalıdır.
İlk aşamada neyin çalışması gerekir?
İstediğiniz her şeyin ilk sürümde olması gerekmez. Eklenen her madde ilk gerçek kullanıma giden yolu uzatır ve ekibinizin sistemi bir sunumla değil, gerçek işle değerlendireceği anı erteler.
İyi bir yanıt gereksinimleri ikiye ayırır: olmadan canlıya geçilemeyecek olanlar ve bekleyebilecek olanlar. Bu ayrımı belirleyen soru basittir: Bu madde olmazsa günlük iş durur mu?
Diyelim ki şirket sipariş girişi, sevkiyat takibi, ayrıntılı satış raporları ve bir müşteri sadakat programı istiyor. Sipariş girişi ve sevkiyat takibi vazgeçilmezdir; ayrıntılı raporlar ve sadakat programı ise kullanım oturana ve onlara olan ihtiyaç netleşene kadar bekleyebilir.
Projenin başarılı olduğunu nasıl anlayacağız?
Üzerinde anlaşılmış bir ölçüt yoksa projenin değerlendirilmesi kişiden kişiye değişen izlenimlere dönüşür. Yönetici sistemi başarılı bulur, muhasebeci ise sistemin işe yeni adımlar eklediğini düşünür; ikisinin de tartışmayı bitirecek bir dayanağı yoktur.
İyi bir yanıt, iş içinde gözlemlenebilecek bir ya da iki ölçüt belirler: aylık raporun hazırlanma süresi, elle takip gerektiren sipariş sayısı ya da stok sayımında ortaya çıkan farklar. Bu ölçütlerin bugünkü değerini de projeye başlamadan önce kaydeder; çünkü bir başlangıç noktası olmadan hiçbir iyileşme ölçülemez.
Varsayalım ki aylık satış raporunun hazırlanması, tabloların toplanıp düzeltilmesiyle şu anda iki iş günü sürüyor. Buradaki başarı ölçütü açıktır: raporun doğrudan sistemden alınması ve rakamlarının, elle düzeltme gerekmeden hesaplardakiyle örtüşmesi.
Bizim tarafımızda kim karar verecek?
Her yazılım projesi, işletme tarafında soruları karara bağlama ve her aşamayı onaylama yetkisine sahip bir kişiye ihtiyaç duyar. Kararlar, son sözü kimin söyleyeceği belli olmadan birkaç kişiye dağıldığında incelemeler gecikir ve değişiklik talepleri birikir.
İyi bir yanıt tek bir kişinin adını verir; bu kişinin neye tek başına karar vereceğini, neyi yönetime taşıyacağını belirler ve ona proje için gününden artakalan zamanı değil, gerçekten ayrılmış bir zaman tanır. Örneğin karar sahibi operasyon müdürü olsun: İş kurallarını ve ilk aşamanın önceliklerini o onaylar, genel müdüre yalnızca bütçeyi ya da teslim tarihini değiştiren konuları taşır.
Ona bir vekil belirlemek de faydalıdır; böylece karar sahibi bir seyahat ya da beklenmedik bir yoğunluk nedeniyle bulunmadığında proje durmaz.
Yanıtları tek sayfalık bir dokümana dönüştürün
Yanıtlarınızı, teklif istediğiniz her firmayla paylaşacağınız kısa bir dokümanda toplayın. Bu doküman teklifleri karşılaştırılabilir kılar, çünkü herkes aynı anlayıştan yola çıkar. Ayrıca hangi firmanın işinizle ilgili sorular sorduğunu, hangisinin yalnızca teknolojiden söz etmekle yetindiğini de çabucak gösterir.
Doküman için özel bir şablona ya da teknik bir dile gerek yoktur. Şunları içermesi yeterlidir:
- Sorunun, işin diliyle ve tek paragrafta tanımı.
- Kullanıcılar, rolleri ve bugün nasıl çalıştıkları.
- İlk aşamada neyin olması gerektiği ve neyin ertelenebileceği.
- Üzerinde anlaşılan başarı ölçütü ve bugünkü değeri.
- Karar sahibi ve her aşamayı kimin gözden geçireceği.
- Bilinen kısıtlar: istenen teslim tarihi, yaklaşık bütçe ve bağlanması gereken mevcut sistemler.
Dokümanı, şirketinize yeni katılmış bir çalışanın anlayacağı bir dille yazın. Okuyan kişi anlamak için sözlü bir açıklamaya ihtiyaç duyuyorsa, dokümana daha fazla sayfa değil, daha açık bir paragraf gerekir. Varsa fatura, takip tablosu ya da kâğıt sipariş formu gibi gerçek örnekleri de, gizli kısımlarını kapattıktan sonra ekleyin.
Fiyat teklifi istemeden önce kontrol listesi
- Sorun, bir teknoloji adı ya da uygulama biçimi anılmadan işin diliyle yazıldı.
- Sistemi kullanacak her rol, bugünkü çalışma biçimiyle birlikte listelendi.
- Tablolar ve mesaj grupları gibi bugünkü geçici çözümler belirlenip kaydedildi.
- İlk aşamanın maddeleri, bekleyecek maddelerden ayrıldı.
- Başarı ölçütü belirlendi ve bugünkü değeri kaydedildi.
- Karar sahibi belirlendi ve projeye ayıracağı zaman üzerinde anlaşıldı.
- Bilinen kısıtlar yazıldı; henüz bilmedikleriniz de yazıldı.
Dokümandan keşif toplantısına
Yanıtların eksiksiz ya da kesin olması şart değildir; dürüst olmaları ve henüz bilmediklerinizi göstermeleri yeterlidir. Çünkü doküman konuşmanın yerini tutmaz; konuşmanın başlangıç noktasıdır.
ITS olarak her projeye kodlamadan önce iş analiziyle başlıyoruz; iş analizinin ilk adımı da keşif toplantısıdır. Bu toplantıda yanıtları işi bilen kişilerle birlikte gözden geçirir, ilk anlatımda görünmeyen istisnaları ve durumları sorarız. Ardından üzerinde anlaştıklarımızı, tahmin edilebilecek ve hayata geçirilebilecek yazılı bir kapsama dönüştürürüz.
İşe dair net bir soruyla başlayan bir proje, bir ekran listesiyle başlayan projeye göre anlaşmazlığa daha az açıktır.
Bu beş soru projenin başarısını garanti etmez; ama projelerin aksamasına sık yol açan nedenleri, proje başlamadan ele alır: sorunun belirsiz olması, bazı kullanıcıların unutulması, kapsamın şişmesi, bir ölçütün olmaması ve kararların dağınık olması. Yanıtlarınızı gözden geçirmek isterseniz, durumunuzu teknolojiden önce iş açısından ITS ekibiyle görüşebilirsiniz.
İlgili hizmetİş analizi ve ürün danışmanlığı