"Bizde şöyle yürüyor" cümlesi neden yazılıma dönüşmüyor

Bir işletme kendi sürecini anlatırken normal günü anlatır. Oysa yazılımın zorlandığı yer normal gün değil, ayın üç gününde olan istisnadır. Gereksinim toplamanın gerçek işi, kimsenin anlatmayı akıl etmediği o istisnaları görünür kılmaktır.

Toplantı odasında herkes memnun ayrılır. Süreç anlatılmıştır, ekran taslakları konuşulmuştur, takvim çıkarılmıştır. Sonra geliştirme başlar ve üç hafta içinde aynı cümle tekrar tekrar duyulur: "Ha, onu söylemedim mi? O müşteride biraz farklı ilerliyor." Sorun kötü niyet ya da dikkatsizlik değil. İnsan kendi işini anlatırken zihnindeki kısa yolu anlatır. Ayrıntı, o kısa yolun altında kalır.

Süreç anlatımı neden hep sadeleşir

Bir işi yıllardır yapan kişi, o işi artık adım adım düşünmez. Sabah gelen talebi görür, ne yapılacağını bilir, yapar. Bunu birine anlatması istendiğinde beyni otomatik olarak özetler: talep gelir, teklif hazırlanır, onaya gider, gönderilir. Dört adım. Gerçekte ise o dört adımın arasında onlarca küçük karar vardır.

Bu kararlar anlatılmaz çünkü anlatan kişi için karar bile sayılmazlar. "Müşteri eski müşteriyse fiyat listesinin ikinci sütununa bakarım" cümlesi, onu söyleyen kişi için bir kural değil, refleks. Refleksler sorulmadıkça dile gelmez. Yazılım ise refleksle çalışmaz; her dallanmanın yazılı olmasını ister.

Sonuç şu olur: teslim edilen sistem anlatılan süreci doğru kurar ama işletmenin gerçek gününü karşılamaz. Kullanıcı sisteme bakar, "bu bizim işimize uymuyor" der. Uymayan şey aslında sistem değil, sistemin dayandığı eksik tariftir.

Anlatılmayan bilginin dört tipik kaynağı

Eksik kalan gereksinimler rastgele dağılmaz. Neredeyse her projede aynı dört yerden çıkar.

Herkesin bildiği varsayılan adımlar

Şirket içinde o kadar yerleşmiş kurallar vardır ki kimse bunları bir kural olarak görmez. Belirli bir müşteri grubuna vade uygulanmaması, belirli bir üründe her zaman numune gönderilmesi, belirli bir depodan çıkan malın ikinci kez tartılması. Bunlar tarif edilmez çünkü "zaten herkes bilir". Yeni gelen bir çalışanın ilk haftasında hangi soruları sorduğuna bakmak, bu grubun iyi bir haritasıdır.

Kişiye özel çözümler

Her ekipte, sistemin boşluğunu kendi yöntemiyle kapatan biri vardır. Kendi Excel'inde ikinci bir liste tutar, telefonunda not alır, masasında bir defter bulundurur. Bu çözümler resmi süreçte görünmez ama iş onlarsız yürümez. Süreç anlatımında da geçmezler, çünkü anlatan kişi bunları "benim kendi işim" sayar. Oysa oradaki defter, sistemin karşılamadığı gerçek bir ihtiyacın kanıtıdır.

Kâğıt üzerinde kalmış prosedür

Bir yanda yazılı prosedür vardır, diğer yanda uygulanan iş. İkisi çoğu zaman aynı değildir. Prosedürde üç onay basamağı yazar, pratikte iki tanesi atlanır ya da sonradan toplu olarak imzalanır. Yazılım prosedüre göre kurulursa, kullanıcı ilk günden sistemi engel olarak görür ve dolanma yolu arar. Yazılım uygulanan işe göre kurulursa bu kez denetim tarafı açıkta kalır. Doğru yaklaşım, bu farkın projenin başında görünür hâle gelmesi ve hangi tarafın esas alınacağının bilinçli olarak seçilmesidir.

Departmanların farklı anlatımı

Aynı sürecin satış, üretim ve muhasebe tarafından anlatımı çoğu zaman üç ayrı sürece benzer. Satış için sipariş, müşterinin onay verdiği andır. Üretim için iş emrinin düştüğü andır. Muhasebe için faturanın kesildiği andır. Üçü de haklıdır ama tek bir sistemde "sipariş" tek bir şey olmak zorundadır. Bu tanım farkı erken yakalanmazsa, sistem canlıya çıktıktan sonra raporlar birbirini tutmaz ve kimse nedenini bulamaz.

Gereksinim nasıl toplanır: anlatmak yerine göstermek

Toplantı odasında toplanan gereksinim, hafızadan toplanan gereksinimdir. Hafıza sadeleştirir. O yüzden toplama işinin ağırlığı odadan sahaya kaymalıdır.

İşi izleyin. Süreci anlatan kişinin yanına oturup gerçek bir talebi baştan sona takip etmek, saatlerce süren anlatımdan daha fazla bilgi verir. İzlerken en değerli an, kişinin durup düşündüğü andır. O duraklama bir karar noktasıdır ve o karar noktası büyük ihtimalle hiçbir yerde yazılı değildir.

Gerçek belge örneği isteyin. "Teklif formunuz nasıl?" sorusunun cevabı ile masadan alınan son on teklifin kendisi aynı şey değildir. Gerçek belgelerde el yazısı notlar, çizilmiş satırlar, boş bırakılmış alanlar, kenara iliştirilmiş uyarılar bulunur. Bunların her biri bir gereksinimdir. Özellikle boş bırakılan alanlara bakın: doldurulmayan alan ya gereksizdir ya da doldurulması imkânsızdır; ikisi de bilmeniz gereken bir şeydir.

Uç durumları açıkça sorun. Normal akış zaten kolay anlatılır. Asıl bilgi kenarlardadır: müşteri siparişin yarısını iptal ederse, mal eksik gelirse, fiyat sevkiyattan sonra değişirse, aynı ürün iki farklı isimle kayıtlıysa, iki kişi aynı anda aynı kaydı açarsa. Bu soruların cevabı çoğu zaman "öyle bir şey olmuyor" diye başlar ve birkaç saniye sonra "ha, aslında geçen ay olmuştu" diye devam eder.

"Peki ya olmazsa" sorusunu her adımda tekrarlayın. Onay gelmezse ne olur? Sorumlu kişi izindeyse kim bakar? Sistem cevap vermezse iş durur mu, elle mi yürür? Bu soru, sürecin sessiz varsayımlarını tek tek açığa çıkarır. Çoğu yazılım projesinde canlı sonrası yaşanan tıkanmalar, tam olarak bu soruların sorulmamış olmasından doğar.

Süreç haritası, kelime listesi ve senaryolar

Toplanan bilginin bir yerde durması gerekir. Uzun anlatı metinleri bu iş için zayıftır; kimse okumaz ve kimse üzerinde anlaşmaz. Üç basit çıktı çoğu proje için yeterlidir.

• Süreç haritası: Kutular ve oklar. Her dallanma görünür olmalı; "bazen şöyle olur" cümlesi haritada ayrı bir ok demektir.
• Ortak kelime listesi: Sipariş, teklif, cari, parti, sevkiyat gibi terimlerin tek bir tanımı yazılır ve tüm departmanlar bu tanımı onaylar. Bu liste, ileride raporların tutmaması sorununun panzehiridir.
• Senaryolar: "Şu durumda şu olur" biçiminde yazılmış somut örnekler. Soyut kural yerine somut vaka, herkesin aynı şeyi anladığını kontrol etmenin en hızlı yoludur.

Yazılı kabul kriteri neden pazarlık değil, koruma

Kabul kriteri, bir işin "bitti" sayılması için nelerin doğru çalışması gerektiğinin önceden yazılmış hâlidir. Çoğu işletme bunu geliştiriciyi bağlayan bir belge sanır. Aslında iki tarafı da korur.

Yazılı kriter olmadığında "bitti" tanımı kişiye göre değişir. Geliştirici için ekran çalışıyorsa bitmiştir; kullanıcı için kendi günlük işini o ekranla yapabiliyorsa bitmiştir. Bu iki tanım arasındaki boşluk, projelerdeki gecikmelerin ve gerginliğin büyük bölümünü üretir.

İyi bir kabul kriteri soyut değildir. "Sipariş ekranı düzgün çalışacak" bir kriter değildir. "Stokta olmayan bir ürün siparişe eklendiğinde sistem uyarı verir ve yetkili kullanıcı onaylarsa kayıt tamamlanır" bir kriterdir. Test edilebilir, tek anlamı vardır ve kimin ne bekleyeceğini önceden söyler.

Kriterler ayrıca kapsam tartışmasını sağlıklı hâle getirir. Proje ortasında yeni bir ihtiyaç çıktığında "bu zaten kapsamdaydı" ile "bu ek iş" arasındaki tartışma, yazılı bir metin varsa dakikalar sürer. Yoksa haftalar sürer ve ilişkiyi yıpratır.

Değişecek olması, yazmamanın gerekçesi değil

Sık duyulan bir itiraz vardır: süreç zaten değişecek, o zaman baştan detaylı yazmanın anlamı ne? Değişeceği doğrudur. Ama değişimi yönetebilmek için önce bir başlangıç noktasının kayıtlı olması gerekir. Neye göre değiştiğini bilmediğiniz bir şeyin değişimini takip edemezsiniz.

Pratik yol, her şeyi en baştan yazmaya çalışmak değil, en riskli parçayı önce netleştirmektir. Hangi süreç en çok istisna barındırıyorsa, hangi konuda departmanlar farklı konuşuyorsa, hangi adımda para ya da sevkiyat hareket ediyorsa oradan başlanır. Sakin ve tek yollu adımların ayrıntısı sonraya bırakılabilir.

Kısaca

• İşletmeler süreçlerini anlatırken normal akışı anlatır; yazılımın zorlandığı yer istisnalardır.
• Anlatılmayan bilgi genellikle dört yerdedir: herkesin bildiği varsayılan adımlar, kişiye özel çözümler, uygulanmayan prosedürler ve departmanların farklı tanımları.
• Gereksinim odada değil sahada toplanır: işi izleyin, gerçek belge örneği isteyin, uç durumları ve "peki ya olmazsa" sorusunu sorun.
• Süreç haritası, ortak kelime listesi ve somut senaryolar, uzun anlatı metinlerinden daha işe yarar.
• Yazılı ve test edilebilir kabul kriteri, "bitti" tanımını kişiye göre değişmekten çıkarır ve kapsam tartışmasını kısaltır.