İlk sürüme hangi özelliğin gireceğini fiyat değil kayıt belirler: bugün tutulmayan bir kaydı isteyen satır girer, tutulan kayıttan okunabilen çıktı girmez. Çizgi kaydın içinden değil, kayıt ile ondan türeyen çıktı arasından geçer; yarım kurulmuş kayıt küçük kapsam değil başka bir kayıttır. Diş kliniği CRM’inde randevu, tedavi planının belirli bir adımına bağlı açılıyor; sıra değişince takvim de onunla kayıyor.
İlk sürüm sorusu özellik listesine değil kayda sorulur
Bu yazı listeyi hazır kabul ediyor. Listenin nasıl kurulduğu, hangi cümlenin işin koşulunu söylediği ve bir kaydın neye karşılık geldiğini anlatan cümlenin nasıl yazıldığı ayrı bir konu: özellik listesini sıraya koyma ve kayıt birimi cümlesi orada duruyor. Burada birim veri olarak alınıyor. Sorulan soru bir sonraki soru: anlatılmış bir ihtiyacın ilk sürümü nereden kesilir.
Ölçüt tek bir soruyla çalışıyor ve listenin her satırına ayrı ayrı soruluyor. Bu satır bugün hiçbir yerde tutmadığınız bir kaydı mı gerektiriyor, yoksa zaten tuttuğunuz bir kayıttan okunabilecek bir çıktı mı? İki cevap iki ayrı kapsam kararı üretiyor ve ikisi de fiyat listesinde görünmüyor.
Somut olsun. Diş kliniği CRM’inde işe başlarken elde genel amaçlı bir randevu yazılımı vardı; saati tutuyor, tedavinin hangi aşamada olduğunu tutmuyordu. Bu yüzden üç ayrı bilgi üç ayrı yerden toplanıyordu: tedavinin gidişatı için takvime, faturalanan işlem için deftere, ay sonu tablosu için üçüncü bir yere bakılıyordu.
Bu tablo bir teklif listesine dönüştüğünde üç satır çıkıyor. Tedavi takibi bir satır, faturalama bir satır, raporlama bir satır. Üçü birbirinden bağımsız üç iş gibi duruyor, üçü ayrı ayrı fiyatlanıyor ve bütçe daraldığında ikisi kesiliyor. Kesme kararının verildiği yer burası, ve karar üç satırın gerçekten üç iş olduğu varsayımının üstünde duruyor.
Üç satırın birbirinden bağımsız görünmesinin sebebi de aslında aynı eksiklik. Bilgi tek yerde durmadığı için her çıktı kendi kaynağını arıyor ve kendi ekranını istiyor. Liste, sistemin bugünkü dağınıklığını satır satır kopyalıyor. Bu yüzden listeyi kısaltmak dağınıklığı kısaltmıyor; yalnız hangi dağınıklığın yeni yazılıma taşınacağını seçiyor.
Varsayım tutmuyor. Üç çıktı, tek bir eksikliğin üç ayrı belirtisi. Eksik olan bilgi şu: hangi dişe hangi işlemin hangi seansta yapıldığı hiçbir yerde durmuyordu. O bilgi hasta kaydına girdiğinde üçü de aynı yerden okunur hâle geliyor. Kurulan sistemde fatura hasta kaydından çıkıyor, raporlar aynı kaydı başka bir yüzünden okuyor, yönetici de planın hangi adımında olunduğunu tek yerden izliyor.
Bu yüzden ilk sürüm sorusu “hangi üç satırı keselim” değil. Soru şu: hangi tek kayıt kurulmadan bu üç satırın hiçbiri çıkmıyor. Cevabı bulmak listeyi kısaltmaz, listeyi yeniden sıralar.
Türetilebilen çıktı ayrı bir özellik olarak kurulmaz
Ölçütün birinci yarısı buradan çıkıyor. Bir çıktı, tuttuğunuz kayıttan hesaplanabiliyorsa ilk sürüme ayrı bir özellik satırı olarak yazılmaz. Kayıt kurulduğu anda o çıktı zaten oradadır; ekranı çizilir, hesabı yazılır, ama listede kendi bütçesi olan bağımsız bir kalem değildir.
Bu cümle sık yanlış okunuyor, o yüzden açık yazalım: ayrı kurulmaması yok olması demek değil. Klinikte fatura ilk günden kesiliyor. Faturayı üreten şey bir fatura özelliği değil, yapılan işlemin hasta kaydında duruyor olması. Uygulanan tedavi ile fatura kalemi aynı kaydın üstünde durduğu için ikisi arasında bir eşleştirme işi hiç doğmuyor. Raporlar da o kaydı okuyor; ay sonu için ikinci bir defter açılmıyor.
Tersini kurmanın bedeli kliniğin başlangıç tablosunda görülüyor. Yapılan işlem bir yerde, kesilen fatura başka yerde durduğunda ay sonu raporu elle birleştirmeye kalıyor. Türeyen bir çıktıyı ilk sürümde ayrı bir kalem olarak kurmak, o birleştirme işini yeni sisteme miras bırakmak oluyor. Kesilen bütçe tasarruf gibi görünüyor, ama asıl kesilen kaydın bütünlüğü.
Bir satırın türeyip türemediğini sınamak zor değil. O satırı besleyecek bilginin bugün nereden geldiğini sorun. Cevap “başka bir yerde tutulan bir kayıttan hesaplanabilir” ise satır türüyor demektir ve kendi bütçesine ihtiyacı yok. Cevap “bunu kimse yazmıyor” ise satır türemiyor; kaynağı ilk sürümde kurulmak zorunda. Sınamanın bakması gereken yer satırın adı değil kaynağı, çünkü “raporlama” iki durumda da aynı görünüyor.
Ölçütün bir sınırı var ve sınırı burada söylemek gerekiyor. Bu ölçüt, türeyecek bir kaydı olan işler için geçerli. Ortada tutulan bir defter yoksa ilk sürümün sınırı kayıt ile çıktı arasından çekilmiyor, başka bir soruyla kesiliyor: eklenen katman kâğıdın gördüğü işi mi sürdürüyor, yoksa onu aşıyor mu. Basılı kataloğu yazılıma taşırken kapsamın nereden kesildiği ayrı bir yazının konusu ve ölçütü de ayrı.
Sonraya bırakılamayan satır hangisidir
Ölçütün ikinci yarısı ilkinin tersi. İlk sürüme girmesi gereken şey, bugün hiçbir yerde tutmadığınız kayıttır. Klinikte bu, eski yazılımın hiç tutmadığı diş bazında tedavi planıydı: hangi dişe hangi işlemin yapılacağı, haftalara yayılan sıralı seanslara bölünmüş hâlde.
Tutulmayan kayıt tek başına girmiyor. Onunla birlikte listede madde olarak hiç görünmeyen bir şey daha giriyor: randevunun planın belirli bir adımına bağlanması. Hiçbir teklif listesinde “randevu ile plan adımı arasındaki bağ” diye bir satır yazmaz. Fiyatı yoktur, ekranı yoktur, demosu yoktur. Yine de o bağ olmadan plan kaydı yarım kalıyor, çünkü plan takvimle konuşamıyor.
Bağın çalışan hâli klinikte görülüyor. Plana yeni bir seans girdiğinde ya da sıra değiştiğinde takvim de o değişikliği alıyor ve hiçbir randevu artık geçerli olmayan bir adıma işaret etmiyor. Bağın kendi mekanizması, yani takvimin planı nasıl izlediği ayrı bir yazıda: randevunun tedavi planı adımına nasıl bağlandığı orada anlatılıyor. Kapsam kararı için gereken tek bilgi, o bağın bir kayıt özelliği olduğu.
Bağın neden sonraya bırakılamadığı da buradan çıkıyor. Bağ, kayıt açıldığı anda kuruluyor. İlk sürümde plansız açılmış bir randevunun hangi adıma ait olduğu sonradan açılacak bir alana yazılamıyor, çünkü o bilgi hiçbir randevu kaydına hiç yazılmıyor. Sonradan açılan alan geriye doğru veri üretmiyor; yalnız kendisinden sonrasını tutuyor. Aradaki fark küçük görünüyor, ama ilk sürümün ömrü boyunca biriken kayıtların hepsini kapsıyor.
Pazarlık edilemeyen satır bu yüzden listede en pahalı görünen satır değil. Kaydın kendisi ve bağı. İkisi listede genelde yan yana bile durmuyor: kayıt bir başlık olarak yazılıyor, bağ hiç yazılmıyor. Ölçütün işi tam olarak bu ikinciyi görünür kılmak.
Üç işte aynı ölçüt yan yana
Ölçütü kendi listenize uygulamadan önce üç ayrı işte nasıl durduğunu yan yana görmek işe yarıyor. Aşağıdaki tablonun ikinci ve dördüncü sütunu proje sayfalarında yazılı olanı taşıyor. Üçüncü sütun bu yazının okuması, yani ölçütün o satıra ne dediği. Hiçbir satır “şu özellik ikinci sürüme bırakıldı” demiyor. Üç işin hiçbirinde böyle bir karar belgeli değil; tablonun gösterdiği şey, çalışan sistemlerde kayıt ile kaydın okumasının nereden ayrıldığı.
| Listeye yazılan satır | Proje sayfasında ne var: tutulan kayıt mı, ondan türeyen çıktı mı | Ölçütün okuması: ilk sürüme ne girer | Çalışan hâlde ne görülüyor |
|---|---|---|---|
| Fatura ve raporlama (diş kliniği) | Türeyen çıktı: yapılan işlem hasta kaydında durduğu için fatura ve rapor aynı kaydın başka bir yüzü; ayrı defter yok | Ayrı özellik satırı olarak girmez. Giren şey türedikleri kayıt: diş bazında tedavi planı ve randevunun plan adımına bağı | Fatura hasta kaydından çıkıyor; planın hangi adımında olunduğu tek yerden izleniyor |
| İklim özeti (hava durumu sitesi) | Türeyen çıktı: ayrı bir veri kaynağı yok, arşivde biriken gün kayıtları üstünden hesaplanıyor | Bir sürüme tarihlenmez. Giren şey kaynak: bir kez yazılıp bir daha değişmeyen gün kaydı; özet arşiv biriktikçe gelir | Arşiv büyüdükçe özet kendini tazeliyor, elle güncellenmeyi beklemiyor |
| Optik form okuma (eğitim platformu) | Aynı çatı altında ek iş olarak geliştirilen araç; çıktısı platformun zaten tuttuğu sınav kaydına yazılıyor | Sonraya bırakılabilen satırın biçimi: var olan kayda yazar, yeni bir kayıt istemez | Öğrencinin işaretlemesi ile cevap anahtarı aynı sınav kaydında karşılaşıyor |
Üç satırın ortak yanı, ilk sütundaki ifadelerin hepsinin bir özellik adı gibi durması. “Faturalama”, “iklim özeti”, “optik form okuma”; üçü de bir teklif listesinde kendi satırını ve kendi bütçesini isteyecek ifadeler. Arkalarında duran şey ise her seferinde bir kayıt: hasta kaydı, gün kaydı, sınav kaydı. İlk sürüm kararının bakması gereken sütun ikincisi.
Tabloyu kendi listenizle okumak da mümkün. Satırlarınızı yazın, her birinin altına o satırın okuduğu kaydı yazın. Altı boş kalan satır varsa ilk sürüme girmesi gereken satır o değil, boş bıraktığınız yer.
Kapsamı kısmak ile kaydı eksik kurmak aynı şey değildir
“Kaydı ilk sürüme al” cümlesi kolayca “kaydın bir kısmını al” diye okunuyor. Bütçe baskısı altında bu okuma çok makul görünüyor, çünkü bir şeyi kestiği için kapsam kısmak gibi duruyor.
Yanlış kesme çizgisi genelde şu cümleyle çekiliyor: tedavi planını ikinci sürüme bırakalım, şimdilik randevuya bir not alanı koyarız. Cümle bütçeye uyuyor ve teslim takvimini kısaltıyor. Yaptığı şey ise başka. Kliniğin terk ettiği düzeni yeni sistemin ilk gününe yazıyor: saati tutan, tedavinin hangi aşamada olduğunu tutmayan bir kayıt. Yazılım değiştirme sebebi zaten oydu.
Kesme çizgisi kayıt ile çıktı arasından geçiyor, kaydın içinden geçmiyor. Bir kaydın yarısını kurup öbür yarısını sonraya bırakmak o kaydı küçültmüyor, başka bir kayıt kuruyor. Not alanı olan bir randevu kaydı, tedavi planı kaydının ucuz hâli değil. Farklı bir şey ve farklı bir geçmiş biriktiriyor.
Yanlış anlatılmış bir birimin sonradan neden düzelmediği ayrı bir soru. Burada söylenen daha dar bir şey: kesme çizgisinin nereden geçtiği.
Kısma listesini yaparken işe yarayan bir sıra var. Önce her satırın hangi kayda dokunduğunu yazın. Hiçbir kayda dokunmayan satırlar birinci kısma turunun konusu. Bir kaydın alanlarını azaltan satırlar ikinci turun konusu, çünkü alan sonradan açılabiliyor. Kaydın kimliğini ya da bağını değiştiren satırlar hiçbir turun konusu değil. Bu sıra listeyi dokunduğu yere göre diziyor.
Peki bütçe gerçekten yetmiyorsa nereden kısılır? Kayıt yapısına dokunmayan yerlerden. Ekran sayısı, panel düzeni, rapor sütunları, hangi bildirimin ilk sürümde çıkacağı; bunların hepsi sonradan değişebiliyor, çünkü hiçbiri kaydın kimliğine dokunmuyor. Hangi kararın geri alması pahalı, hangisinin ucuz olduğu ayrı bir yazının konusu ve kapsam kısarken bakılacak liste orada.
Bir özet neden sürüm takvimine yazılmaz
Aynı ölçüt bambaşka bir işte başka bir yüzünü gösteriyor. Günlük hava durumu sitesinde iklim özeti diye bir okuma var: bir yerin geçmiş günlerinin toplu olarak ne söylediği. Bu okuma ayrı bir veri kaynağına bağlı değil. Arşivde biriken gün kayıtları üstünden hesaplanıyor ve arşiv büyüdükçe kendini tazeliyor.
Buradan çıkan sonuç kapsam kararına doğrudan bağlanıyor. Türeyen bir çıktının zamanını bir sürüm takvimi belirlemiyor; kaynak kaydın birikimi belirliyor. “İklim özetini sonraki sürüme koyalım” cümlesi hiçbir şeyi ertelemiyor, çünkü ertelenen şey bir özellik değil bir hesap. Hesap, kaynağı olduğu gün çalışıyor. Kaynağı yoksa hiçbir sürümde çalışmıyor.
İlk sürüme giren şey burada da tutulan kayıt: bir kez yazıldıktan sonra değişmeyen gün kaydı. Sitede ileriye bakan on beş günlük tahmin de var, geriye bakan arşiv de; ikisinin neden ayrı tutulduğu tahmin, arşiv ve özetin nasıl ayrıldığını anlatan yazıda duruyor. Kapsam açısından önemli olan tek sonuç şu: gün kaydı ilk günden tutulmuyorsa özet ikinci sürümde de çıkmıyor.
Klinikten farkı da tam burada. Klinikte kaynak kayıt ilk hastayla birlikte doluyor ve çıktı hemen okunabiliyor. Hava durumu tarafında kaynak zamanla birikiyor, dolayısıyla çıktı ilk gün ince, sonra kalınlaşıyor. İki durumda da kapsam kararı aynı: kaynağı ilk sürüme koy, okumayı takvime bağlama.
Sonradan gelen özellik yeni kayıt açmaz, var olanın üstüne yazar
Okurun asıl korkusu genelde şu: sonraya bıraktığım şey bir daha eklenemezse ne olacak. Bu korkunun cevabı “her şey eklenebilir” değil. Eklenebilen şeyin belirli bir biçimi var ve o biçim tanınabiliyor.
Vipkurum optik okuma aracı o biçimin örneği. Araç, aynı çatı altında geliştirilen ek işlerden biri ve platform sınav kaydını zaten tutuyordu. Aracın ürettiği sonuç ayrı bir yere değil, o sınav kaydına yazılıyor. Öğrencinin işaretlediği cevaplar ile cevap anahtarı orada karşılaşıyor.
Bu yazının okuması şu: gelen araç yeni bir kayıt istemedi, var olan kaydın üstüne yazdı. Sonraya bırakılabilen satırın biçimi tam olarak bu. Gelen özellik, biriken kayıtların hâlihazırda taşıdığı bilgiyle yetinebiliyorsa gelebiliyor ve geldiğinde o güne kadarki kayıtlar yerinde kalıyor.
Tersi de aynı ölçütle okunuyor. Sonradan gelen bir özellik, biriken kayıtlarda hiç bulunmayan bir bağa ihtiyaç duyuyorsa o özellik ertelenmiş değil; altındaki kayıt eksik kurulmuş. Bu durumda yapılan iş bir önceki bölümün konusu: kaydın yeniden kurulması. Ayrım listeye bakarak yapılamıyor, çünkü iki durum da listede aynı görünüyor. Ayrımı yapan tek şey, kaydın ne tuttuğu.
Listenizi bu ölçütle bir kez okumak, bütçe onu sizin yerinize okumadan önce yapılabilecek en ucuz iş. Her satıra tek soru: tutulan bir kayıt mı, o kaydın okuması mı. Aynı ölçütle kurulmuş işleri yönetim yazılımları ve web yazılım sayfalarında görebilirsiniz.
