Yazılım ihtiyacınızı yazılımcıya nasıl anlatırsınız?

Yazılım ihtiyacını yazılımcıya anlatmak, özellik listesinden önce iki şeyi söylemektir: işin hangi koşullarda yürüdüğü ve sistemde açılan bir satırın neyi temsil ettiği. Söylenmeyen koşulu karşı taraf ürün kategorisinin varsayımından okuyor; ürün adı işinizin değil kategorinin koşulunu taşır. Birim yanlış anlatılmışsa sonradan eklenen hiçbir özellik onu düzeltmiyor; özellik satıra yazılır ama satırın sahibi değişmez.

Yazdığınız liste büyük ihtimalle eksik değil. Sorun, listenin tek başına okunduğunda bir ürün kategorisinin adını söylemesi: birbirine hiç benzemeyen iki sistem aynı maddeleri satır satır karşılayabiliyorsa, eklenecek yeni bir madde o boşluğu kapatmaz. Listeyi atmayın; sıraya koyun.

Özellik listesi ürünü adlandırır, işi anlatmaz

Hasta takibi, randevu, tedavi planı, fatura, raporlama. Bir diş kliniğinin yazacağı liste aşağı yukarı budur ve maddelerin hepsi doğrudur. Aynı listeyi genel amaçlı bir randevu yazılımı da madde madde karşılar, kliniğe kurulmuş bir sistem de. Fark listede değil, maddelerin hangi kaydın üstünde durduğunda.

Klinik bu düzeni genel amaçlı bir randevu yazılımıyla yürütüyordu. İstediği ayrı modüller değildi; tedavi planının, randevunun ve faturanın aynı hasta kaydı üzerinde durmasıydı. Liste doğruydu, ısmarlanan sistem yanlıştı. Bu cümlenin listeye yazılacak bir karşılığı da yok: “aynı kayıt üstünde dursun” bir özellik adı değil, kuruluş kararıdır. Kliniğin kaydının nasıl kurulduğu proje sayfasında duruyor; bu yazının baktığı yer neyin istendiği ile neyin ısmarlandığı arasındaki boşluk.

Listeye madde eklemek de bu boşluğu kapatmıyor. Kliniğin listesinde “tedavi planı” zaten yazılıydı. Eksik olan planın adı değil, planın randevudan bağımsız kendi başına duran bir kayıt mı, yoksa randevunun içine sıkıştırılmış bir alan mı olduğuydu. Liste madde adlarını taşıyor, maddelerin birbirine nasıl bağlanacağını taşımıyor; ne kadar uzarsa uzasın o bağı yazmıyor.

Ürün adının içinde saklı bir varsayım da olabiliyor. “Personel giriş çıkış takip sistemi” dendiğinde adın taşıdığı kategori sabit bir turnikeyi ve sabit bir sahayı varsayar. Şantiyede saha geçici, turnike kurulmuyor ve personel sahalar arasında dolaşıyor. Alıcı ürün adını söylediğinde farkında olmadan o varsayımı da söylemiş oluyor; söylediği şey işinin koşulu değil, kategorinin koşulu.

Bunun tersi de var. Bazı işlerde ürün kategorisinin adı işi gerçekten doğru anlatır ve liste tek başına yeter. Ama bunu bilmenin yolu yine listeye bakmaktan geçmiyor; işin koşulunu ve kaydını söyleyip sonra bakmaktan geçiyor.

İşin fiziksel koşulları: nerede, hangi cihazda, hangi bağlantıyla, kimin elinde

İşin koşulu dört soruyla anlatılır: nerede yapılıyor, hangi cihazda, hangi bağlantıyla, kimin elinde. Dördünün de cevabını zaten biliyorsunuz. Bilmediğiniz şey, bu cevapların söylenmesi gerektiği ve her birinin bir tasarım kararını kilitlediği.

“Nerede?” sorusunun cevabı “geçici sahada” olduğunda sabit donanım kararı baştan düşer. Turnike kurmak, şantiye kapandığında onu sökmek demektir. Şantiye personel takibinde kayıt bu yüzden personelin telefonunda alınıyor ve saha kapandığında geride sökülecek bir donanım kalmıyor.

“Kimin elinde?” sorusunun cevabı “personel sahalar arasında dolaşıyor, sahada birden çok taşeron var” olduğunda kayıt kişiye ve sahaya birlikte bağlanıyor. QR kod kimin okuttuğunu, konum hangi sahada olunduğunu veriyor; ikisi tek bir giriş kaydında birleşiyor ve saha adı elle seçilmiyor. Bu bağ kayıt açıldığı anda kuruluyor. Sonradan “saha sütunu ekleyelim” denerek kurulamaz, çünkü eski kayıtların içinde konum yoktur.

“Hangi cihazda?” sorusunun cevabı “personelin kendi telefonu” olduğunda uygulama işletmenin koyduğu bir cihaza değil, çalışanın taşıdığı telefona kuruluyor. Cihazı işletmenin mi koyduğu, çalışanın mı taşıdığı başlı başına bir karar; onu uygulama mı, mobil site mi yazısında ayrıca ele aldık.

“Hangi bağlantıyla?” sorusunun cevabı çoğu zaman en geç söylenen cevap oluyor. Servis işinde teknisyen kazan dairesinde ya da asansör boşluğunda çalışıyor ve kapsama alanı orada bitiyor. Bu tek cümle söylenmediğinde kaydın ilk nerede yazılacağı açıkta kalır. Kaydın bağlantı yokken telefonda nasıl yazıldığı ve bağlantı dönünce ne olduğu çevrimdışı çalışan mobil uygulama yazısında duruyor; burada anlatılan yalnız koşulun kendisi.

Dört soru her işte ısırmıyor. Klinikte iş tek yerde ve sabit bilgisayarda yapılıyor, bağlantı diye bir sorun yok. Oradaki koşul zamansal: tedavi tek randevuda bitmiyor, haftalara yayılan seanslara bölünüyor ve arada değişiyor. “Bizde bağlantı sorunu yok” da bir cevaptır ve o da bir kararı kilitler. Sorun soruların cevapsız kalması değil, hiç sorulmamış olması: koşul söylenmediğinde karşı taraf onu ürün kategorisinin varsayılan koşulundan okuyor.

Sistemde bir satır neye karşılık gelir

İkinci cümle tek kalıpta söylenir: “Bizde bir kayıt bir …dır.” Cümlenin işi, sistemde açılacak bir satırın gerçek hayatta neye karşılık geldiğini adlandırmak. Kolay görünüyor, çünkü cevabı herkes biliyor sanıyor; oysa üç ayrı işte cevap ürün kategorisinin varsayılan kaydı çıkmadı.

Klinikte bir kayıt randevu değil, diş bazında kurulmuş ve sıralı seanslara bölünmüş tedavi planıdır. Plan randevudan bağımsız, kendi başına duran bir kayıt; her randevu planın belirli bir adımına bağlanıyor. Adım değişince ya da seans eklenince takvim de kayıyor.

Serviste bir kayıt müşteri değil cihazdır. Aynı adreste birden çok cihaz olabiliyor; alıcının söylemesi gereken cümle bu yüzden şu oluyor: “bizde bir kayıt bir cihazdır, müşteri değil”.

Parfüm mağazasında ürün kaydı kokudur ama satılan birim hacimdir. Fiyat ve stok hacme bağlanıyor; yeni bir hacim eklemek yeni bir ürün açmıyor, mevcut kokunun altına bir birim ekliyor. “Ürün” kelimesi burada iki ayrı kaydı birden örtüyor ve alıcı “parfüm sitesi” derken hangisini bir kayıt saydığını söylemiş olmuyor. Söylenmediğinde standart model her hacmi ayrı bir ürün sayar ve aynı koku katalogda birden çok kez görünür.

Bu cümlenin zor tarafı bilmemek değil, hiç söylememiş olmak. İşinizi yürütürken bir kaydın ne olduğunu adlandırmanız gerekmiyor; birim kâğıtta, dosya dolabında ya da kafanızda duruyor ve karşınızdaki herkes ne demek istediğinizi anlıyor. Yazılımcıya anlatırken ilk kez ad vermek gerekiyor, çünkü sistemde açılacak satırın bir adı olmak zorunda.

Üçünde de birim ürün adından değil işten okundu: klinikte plan, serviste cihaz, mağazada hacim. Hiçbiri o ürün kategorisinin varsayılan kaydı, yani randevu, müşteri ya da ürün değildi. Birimi siz söylersiniz; onu bir yazılımın kayıt düzenine oturtmak bizim işimiz. Bir ayrımın satılabilir bir birim mi yoksa yalnız bir gezinme yolu mu olduğunu fiyat ve stokla sınayan test varyant modelleme yazısında duruyor.

Bazı işlerde birimin adı alıcının dilinde hiç yoktur. Şantiyede kimse “bizde bir kayıt bir giriş-çıkış çiftidir” demez, “hak ediş” der. Cümle burada işin kaynağını söylemeli: hak ediş kaydın kendisi değil, kayıttan üretilen sonuçtur.

Yanlış anlatılan birim hiçbir özellikle düzelmez

Birim yanlış anlatıldığında eklenen her özellik yanlış satıra yazılır. Servis kaydı müşteri kartı olarak anlatılmışsa aynı adresteki cihazların geçmişi müşteri kartında birbirine karışır. Sonradan eklenen bir “cihaz” alanı yalnız yeni kayıtları etiketler; geçmiş kayıtlar müşteri satırının altında kalmaya devam eder. Özellik satıra yazılıyor, satırın sahibini değiştirmiyor.

Geçmişin cihazın altında nasıl durduğu AlgoKlima’nın proje sayfasında yazılı. Buradaki konu, birim yanlış anlatılsaydı ortaya ne çıkacağı.

İkinci arıza takvim tarafında görünüyor. Birim randevu olarak anlatılmışsa hastanın planın neresinde olduğu takvimden, hangi işlemin faturalandığı defterden, ay sonu tablosu bir başka yerden okunur. “Fatura modülü” eklemek faturayı hasta kaydına değil kendi defterine yazar. Fatura hasta kaydından çıkmadığı sürece eklenen modül bu sorunu çözmüyor.

Düzeltme bu yüzden bir özellik değil, satırın kendisinin değişmesidir. Klinikte plan randevudan bağımsız, kendi başına duran bir kayıt olarak kuruldu ve randevu ona bağlandı.

Sonradan düzeltmenin bedeli de yeni ekranda değil, biriken geçmişte duruyor. Yeni bir alan açmak kolaydır; o güne kadar yazılmış kayıtların hangi satırın altında durduğunu değiştirmek kolay değildir, çünkü eski kayıtlarda o bilgi hiç yoktur.

Her yanlış anlatım kalıcı değil. Yanlış anlatılan bir özellik sonradan düzelir: rapor aynı hasta kaydının farklı bir açıdan okunmasıdır ve bir sütun eklemek kaydı değiştirmez. Düzelmeyen ikisi koşul ve birim.

Dört iş, üç cümleyle yan yana

Aşağıdaki tablo dört işi yan yana koyuyor. İlk sütundaki cümleler kimsenin ağzından alınmış alıntı değil; ilk görüşmelerde duyduğumuz cümle şuna benziyor. Servis satırında alıcı hiç yok: AlgoKlima, geliştirmesini sürdürdüğümüz kendi ürünümüz ve oradaki ilk cümle sektörün ürüne verdiği ad.

Tablonun okunacak ekseni kaldırılan adım ya da korunan özellik değil, anlatım cümlesinin kendisi. İlk sütundaki dört cümlenin dördü de bir ürün kategorisinin adı; üçüncü sütundaki dört cümlenin hiçbiri o kategorinin varsayılan kaydı değil. Aradaki boşluk, listenin tek başına gönderildiğinde kapanmayan boşluk.

Tabloyu kendi işinizle okumak da mümkün. Dört satırdan hangisine benziyorsanız kendi cümlelerinizi aynı sırayla yazın: önce elinizdeki liste ya da ürün adı, sonra işin nerede ve kimin elinde yapıldığı, en sonunda bir kaydın neye karşılık geldiği. Üçüncü cümle ilk cümleyle çelişiyorsa o çelişki sizin işinizde duruyor ve yazılımcının duyması gereken şey tam olarak odur.

Koşul cümlesinin biçimi de sabit değil. İki işte cihaz ve bağlantı üzerinden kuruluyor, klinikte zaman üzerinden, mağazada müşterinin karar anındaki durumu üzerinden. Dört sorudan hangisinin ısırdığı işe göre değişiyor; hepsinin ısırması gerekmiyor.

Bu ikisini söyleyince neyi söylemeniz gerekmez

Koşul ve birim anlatıldığında listeden madde düşüyor.

“Hak ediş modülü” istenmez. Giriş-çıkış çifti birim olarak anlatıldığında hak ediş ayrı bir hesap tablosunda tutulmuyor, eşleşen kayıtlardan üretiliyor; aynı personelin farklı sahalardaki çalışması ayrı ayrı toplanıyor. “Saha seçme ekranı” da istenmez. Koşul “personel sahalar arasında dolaşıyor” diye anlatıldığında saha adı konumdan geliyor, kimse listeden saha seçmiyor.

“Fatura modülü” ve “raporlama modülü” istenmez. Yapılan işlem hasta kaydının üstünde durduğu için fatura da rapor da aynı kaydın farklı bir açıdan okunması oluyor; ayrı bir defter açmaya gerek kalmıyor. Kliniğin en başta istediği şey de buydu.

“Çevrimdışı çalışsın” ise bir özellik maddesi değil, koşul cümlesinin kendisi. Kapsama alanının kazan dairesinde bittiği söylendiğinde kaydın telefonda yazılması istenen bir eklenti olmaktan çıkıp tasarımın başlangıç noktası oluyor.

Hangi kaydın kaynak, hangisinin ondan üreyen olduğuna sistemin ilk günü karar veriliyor; bu kararın nerede verildiği mimari önce gelir yazısında duruyor. Bu bölümün gösterdiği tek şey, üreyen maddelerin anlatım yükünün dışına düşmesi.

İlk görüşmeye ne götürürsünüz

Elle tutulur hazırlık şu: bir iş gününü anlatın. Personel sabah hangi sahaya gidiyor, giriş kâğıt puantaja mı yazılıyor, hafta içinde başka şantiyeye geçiyor mu, ay sonunda kimin nerede ne kadar çalıştığı nasıl toplanıyor, itiraz gelince dayanak ne. Bu anlatım dört soruyu da birim cümlesini de kendiliğinden taşıyor ve içinde “PDKS” kelimesi hiç geçmiyor.

Gün tek başına yetmiyor. Yılda bir yaşanan durumlar, bir itiraz ya da bir denetim, günün içinde görünmez. Bu yüzden anlatıma “ay sonunda ne toplanıyor” ve “itiraz gelince dayanak ne” soruları ekleniyor. İkisi de kaydın hangi işi göreceğini, günün kendisinden daha net söylüyor.

Bir de hiçbir özellik listesine yazılmayacak koşullar var. Parfüm mağazasında müşteri ürünü koklayamadan karar veriyor ve alışverişin bir bölümü hediye için yapılıyor. Bunlar işin koşulu ve bir özellik listesinde kendilerine yer bulamıyorlar.

Sonra tek cümle: “Bizde bir kayıt bir …dır.” Şantiyede bu cümle “kim, hangi sahada, ne kadar kaldı” oluyor. Özellik listesi bu ikisinden sonra geldiğinde karşı taraf onu bir ürün adı olarak değil, koşulun ve birimin üstüne yazılacak maddeler olarak okuyor. Listenin işi değişmiyor, sırası değişiyor.

İşin hangi koşulda yapıldığını ve sizde bir kaydın neye karşılık geldiğini anlattığınızda, geri kalan her şey bu iki cümlenin üstüne yazılıyor. Koddan önce verilen bu kararların nerede durduğunu sistem mimarisi sayfasında, aynı kaydın canlı bir sistemde nasıl yürüdüğünü iş süreç takibi sayfasında anlattık.