Neyi Yapmıyoruz: Kapsamı Kesmek, Özellik Eklemekten Zordur

Bir yazılım projesinde en zor karar, listeye bir şey eklemek değil listeden bir şey çıkarmaktır. Eklemek herkesi mutlu eder: müşteri istediğini alır, ekip yeni bir şey yapar, satış tarafı anlatacak bir madde bulur. Çıkarmak ise birilerini hayal kırıklığına uğratır ve o an kimse kahraman olmaz. Buna rağmen bir ürünün kaderini belirleyen şey, çoğunlukla yapılmayanlar listesidir — çünkü yapılan her şey sonsuza kadar bakılacak, güncellenecek ve test edilecek bir yüktür.

Kapsam şişmesinin sinsiliği, tek tek bakıldığında her maddenin makul görünmesidir. 'Bir de şu rapor olsa', 'şuraya bir filtre koysak', 'bunu da yönetimden ayarlayabilsek' — hiçbiri saçma değildir. Toplandığında ise ortaya, hiçbir parçası tam olgunlaşmamış bir ürün çıkar. Yirmi özelliği orta hâlli yapan bir ürün, beş özelliği kusursuz yapan bir üründen daha az kullanılır; çünkü kullanıcı ortalamayı değil, en çok kullandığı beş şeyi hatırlar.

Bu yazı bir rehber değil, bir duruş. Kendi ürünlerimizde kapsamı neye göre kestiğimizi, hangi özellikleri kod tarafı hazır olduğu hâlde bilerek açmadığımızı ve 'yakında' demenin bize neye mal olduğunu anlatacağız. Katılmayabilirsiniz; ama bu kararların hepsi yayında olan ürünlerde uygulanıyor, teorik değil.

Her üründe, olmadığında ürünün var olmadığı bir çekirdek akış vardır. Bir işletme yazılımında bu, siparişin alınmasından hesabın kapanmasına kadar giden zincirdir; bir iş takip aracında, bir talebin kayda dönüşüp sahiplenilmesi ve kapanmasıdır. Çekirdek akışı belirlemenin pratik testi şudur: bu adım olmasa ürün hâlâ işe yarar mı? Cevap evetse o adım çekirdek değildir.

Bu ayrımı yaptığınızda kapsam tartışması kendiliğinden sadeleşir: çekirdek her kurulumda vardır, gerisi açılıp kapanabilir. Kendi işletme ürünümüzde tam olarak böyle yaptık — menü, sipariş, adisyon ve roller her kurulumda gelir; kalan modüller işletmenin tipine göre açılır. Küçük bir kafe üç modülle başlar, çok şubeli bir zincir aynı çekirdeğin üstünde büyür. Kimse kullanmayacağı kırk ekranın arasında gezinmez.

Bu yaklaşımın en önemli mimari sonucu, açma-kapama kararının tek bir yerde yaşamasıdır. Modülün açık olup olmadığı bilgisi ekranlara dağıtılmış küçük kontrollerle değil, tek bir kapı kararıyla verilir. Aksi hâlde altıncı ayda kimse hangi ekranın hangi koşulda görüneceğini bilemez ve 'kapalı' olduğu sanılan bir modül bir yerden sızmaya devam eder.

Bir özelliği ertelemek bilinçli bir karardır: yapılacak, ama şimdi değil. Es geçmek ise kararsızlıktır: konuşulmuş, sonuca bağlanmamış, kimse takip etmiyor. İkisi dışarıdan aynı görünür — özellik yoktur — ama biri planın parçası, diğeri borçtur. Ekip içinde bu ayrımı yazılı tutmak, altı ay sonra 'bunu neden yapmamıştık' sorusunun cevabını da saklamış olur.

Somut bir örnek: iş takip ürünümüzde dosya eki hâlâ yok. Depolama altyapısı kurulu ve çalışıyor; yani teknik engel değil. Ertelemenin sebebi tasarım: ekin hangi kayda nasıl bağlanacağı, boyut sınırının ne olacağı ve kimin hangi eki görebileceği kararları bitmemişti. Yarım kurulmuş bir ek sistemi, olmayan bir ek sisteminden daha zararlıdır — çünkü insanlar ona güvenip dosya yükler.

İkinci örnek ters yönde: bir ürün için üçüncü bir yönetim paneli açmamaya karar verdik. Talep vardı, mantıklıydı, yapılabilirdi. Ama ayrı bir panel demek ayrı bir giriş, ayrı bir dağıtım, ayrı bir tema ve ayrı bir yetki bakımı demekti — üstelik kullanıcısı zaten aynı kişiydi. Bu yüzden 'hiç yapılmayacaklar' kutusuna koyduk ve içerik ile talepleri var olan iki yüzeye dağıttık. Bu karar, ertelenmiş bir iş değil kapatılmış bir başlıktır.

Kapsam konuşmasının en pratik hâli üç kutudur: bu sürümde var, bu sürümde yok ama yol haritasında, hiç yapılmayacak. İki kutuyla çalışan ekipler üçüncüyü hep atlar ve en çok yanlış anlaşılma oradan çıkar. 'Hiç yapılmayacak' demek cesaret ister ama müşteriye en büyük iyiliktir; çünkü beklemediği bir şeyi beklemekten kurtulur ve gerekirse başka bir yolla çözer.

Üçüncü kutunun bir de iç faydası var: ekip enerjisini korur. Kapatılmamış her başlık, her toplantıda yeniden gündeme gelir ve her seferinde aynı tartışma yapılır. Karar verilip yazıldığında tartışma biter. Biz kapatılan başlıkların gerekçesini de yazıyoruz — çünkü altı ay sonra koşullar değişip başlık yeniden açılabilir ve o zaman eski gerekçe, yeni kararın girdisi olur.

Ürün sayfalarımızda henüz yapılmamış özellikleri açıkça 'yakında' diye işaretliyoruz. Bunun kısa vadede bir bedeli var: rakip bir listede o özellik işaretsiz durur, bizimkinde bir uyarıyla durur ve yan yana bakan biri bizi eksik sanabilir. Bu bedeli bilerek ödüyoruz, çünkü alternatifin faturası çok daha yüksek — var sanılan bir özelliğin yokluğu teslimden sonra ortaya çıktığında, tartışılan tek bir özellik değil bütün proje olur.

'Yakında' işaretinin ikinci faydası ekibin içindedir: liste, yol haritasının kendisi hâline gelir. Bir modül katalogda yakında olarak duruyorsa, onu yapmak bir gün birinin aklına gelmesine kalmaz; görünür bir borçtur. Bizim işletme ürünümüzün kataloğunda elli modül yayında, altı tanesi yakında işaretli — ve o altı madde, yol haritası toplantısının gündemini kendiliğinden oluşturuyor.

Bir sınır koyalım: 'yakında' bir tarih vaadi değildir ve öyle sunulmamalıdır. Tarih verilen bir söz tutulmadığında, hiç söz vermemekten daha kötüdür. Biz 'yakında' derken yol haritasında olduğunu söylüyoruz; hazır olduğunda da bunu duyurmayı iş biliyoruz. Belirsizliği saklamak yerine, belirsizliğin kendisini dürüstçe söylemek en sağlam pozisyon.

Kapsamı kesme kararı iş sahibinindir, ama seçenekleri geliştirici üretmelidir. Geliştirici 'bu üç haftalık iş' der; iş sahibi 'üç hafta bekleyemem, hangi yarısını iki günde alabilirim' der. Bu diyalog kurulmadığında iki kötü sonuçtan biri çıkar: ya her şey yapılır ve proje uzar, ya da geliştirici kendi kafasına göre keser ve işin en kritik parçası uçar.

Seçenek üretmenin pratik yolu, her isteği üç boyda sunmaktır: tam hâli, işi gören hâli ve geçici çözüm. Örneğin bir raporlama isteği için tam hâl esnek filtreli bir rapor motoru, işi gören hâl üç sabit rapor, geçici çözüm ise verinin dışa aktarılıp elektronik tabloda incelenmesidir. Üçünün maliyeti yan yana konduğunda karar, tartışma olmaktan çıkıp seçim hâline gelir.

Kapsam kesmeyi müşteriye önerip kendine uygulamamak kolay bir tuzaktır. Kendi kurumsal sitemizi kurarken de aynı disiplini uyguladık ve yayına aldıktan sonra iki ayrı sayfayı tamamen kaldırdık. Sebep, o sayfaların kötü olması değildi; içerikleri başka sayfalarda zaten daha iyi yerleşmişti ve ayrı birer sayfa olarak durmaları menüyü kalabalıklaştırıyordu.

Sayfa silmek, ürün özelliği silmekten psikolojik olarak daha kolaydır ama aynı mantığı taşır: her sayfa güncellenecek, çevrilecek ve tutarlı tutulacak bir yüktür. Dört dilde yayın yapan bir sitede bu yük dörde katlanır. 'Belki birileri arar' diye tutulan bir sayfa, yıllarca eskimiş hâliyle durur ve şirketi gerçekte olduğundan daha dağınık gösterir.

Bir projede tarih ve kapsam aynı anda sabitlenirse, esneyecek tek şey kalite olur — ve kalite esnediğinde bunu ilk fark eden müşteri olmaz, altı ay sonra bakım yapan ekip olur. Bu yüzden her projenin başında hangisinin sabit olduğunu açıkça konuşuyoruz: tarih mi önemli, kapsam mı? İkisine de 'ikisi de' cevabı verildiğinde, aslında hiçbiri sabitlenmemiş olur.

Tarih sabitse yöntem bellidir: kapsam sıralanır ve tarihe kadar yetişen kısım teslim edilir. Bunun çalışması için listenin önceliklendirilmiş olması ve en alttaki maddelerin çıkmasının kabul edilebilir olması gerekir. Kapsam sabitse tarih tahmin olmaktan çıkıp aralık hâline gelir; tek bir gün söylemek yerine 'şu iki hafta arasında' demek, hem daha dürüst hem daha yönetilebilir.

En kötü senaryo, tarihin sabit sanıldığı ama kimsenin kapsamı sıralamadığı projedir. Son iki hafta girildiğinde ekip, hangi maddenin çıkacağına yorgunluk anında karar verir — ve o an verilen kararlar genellikle en kolay çıkarılan maddeyi seçer, en az önemli olanı değil. Sıralamayı baştan yapmak, teslim haftasında kararı ekipten alıp önceden verilmiş bir plana devretmektir.

'Hepsini istiyorum' cümlesi bir talep değil, bir güvensizlik ifadesidir çoğu zaman: müşteri, sonradan eklemenin mümkün olmayacağını ya da pahalı olacağını düşünüyordur. Doğru cevap listeyi kısaltmaya çalışmak değil, sonradan eklemenin gerçekten mümkün olduğunu göstermektir. Modüler bir yapı, bu konuşmanın teknik karşılığıdır: 'bunu şimdi yapmayalım' cümlesi, ancak 'istediğin an açarız' ile birlikte inandırıcı olur.

İkinci yöntem, maliyeti özellik başına değil kullanım başına konuşmaktır. 'Bu rapor üç gün' demek soyut kalır; 'bu rapor üç gün ve ayda bir kez, tek bir kişi tarafından kullanılacak' demek kararı kendiliğinden verdirir. Rakamları yan yana koymak, tartışmayı ikna etmeye çalışmaktan çıkarıp birlikte hesap yapmaya çevirir.

Üçüncüsü, ilk sürümü bir söz olarak değil bir deney olarak sunmaktır. İlk sürüm yayına girdiğinde hangi ekranın gerçekten kullanıldığı görünür ve çoğu zaman herkesin ısrar ettiği bir özelliğin aslında kimse tarafından açılmadığı ortaya çıkar. Bu veriyi elde ettikten sonra yapılan kapsam konuşması, projenin başındakinden çok daha kolay geçer.

Bir maddeyi kapsamda tutup tutmamaya karar verirken sorduğumuz ilk soru şu: bu olmadan ürün çalışır mı? Cevap evetse madde ilk sürümde değildir. İkinci soru: bunu kaç kullanıcı, ne sıklıkla kullanacak? Ayda bir kez, tek bir kişi tarafından kullanılacak bir ekran genellikle bir ekran değil, bir dışa aktarım ya da bir istek satırıdır.

Üçüncü soru geri döndürülebilirlikle ilgili: bunu sonra eklemek pahalı mı? Veri modeline dokunan kararlar sonradan eklenmesi pahalı olanlardır; ekran ve rapor eklemek ucuzdur. Bu yüzden ilk sürümde veri modelini olabildiğince doğru kurmaya, ekran sayısını ise olabildiğince az tutmaya çalışırız. Yanlış ekran silinir; yanlış veri modeli göç ister.

Dördüncü ve en sık atlanan soru: bunu kim bakacak? Her özellik, yazıldıktan sonra da yaşamaya devam eder — güncellenir, test edilir, bozulduğunda düzeltilir. Bakım sahibi belli olmayan bir özellik, birkaç yıl içinde kimsenin dokunmaya cesaret edemediği bir bölgeye dönüşür. Kapsam kararı verirken yalnız yapım maliyetine bakmak, buzdağının görünen kısmına bakmaktır.

Kapsamın yazılı olması şart, ama uzun olması şart değil. Otuz sayfalık bir şartname genellikle iki tarafın da tam okumadığı, uyuşmazlık çıktığında ise avukat gibi taranan bir metne dönüşür. Bir sayfalık kapsam belgesi ise her toplantıda birlikte okunabilir: üç kutu (bu sürümde var / yol haritasında / hiç yapılmayacak), her kutuda maddeler ve her maddenin yanında tek cümlelik kabul kriteri.

Bu belgenin en önemli özelliği canlı olmasıdır. Kapsam proje boyunca değişir — değişmesi de normaldir; anormal olan, değişikliğin belgeye yansımamasıdır. Bir madde eklendiğinde hangi maddenin çıktığını aynı belgede göstermek, 'her şeyi istiyoruz' konuşmasını kendiliğinden dengeleyen mekanizmadır. Ekleme her zaman bir yer değiştirmedir.

Bir de tarih koyun: belgenin son güncellenme tarihi. Kapsam belgesinin en tehlikeli hâli, herkesin farklı bir sürümüne bakmasıdır. Tek bir adreste yaşayan, tarihli ve üstünde birlikte konuşulan bir sayfa; e-postayla dolaşan beş farklı kopyadan her zaman iyidir.

İlk sürüm yayına girdikten sonra kapsam kaçınılmaz olarak büyür; mesele büyümesi değil, neye göre büyüdüğüdür. En sağlıklı girdi kullanımdır: hangi ekran açılıyor, hangi liste boş kalıyor, hangi işlem yarıda bırakılıyor. İkinci girdi destek kayıtlarıdır — aynı sorunun üç kez sorulması, bir özellik talebinden daha güçlü bir sinyaldir.

Büyümenin en tehlikeli biçimi, tek bir kullanıcının ısrarıyla eklenen özelliklerdir. Bir kişi için yazılan ekran, herkesin menüsünde durur ve herkesin bakım yükü olur. Bunun yerine sorulacak soru şudur: bu ihtiyacı var olan bir yapının içinde çözebilir miyiz? Çoğu zaman cevap evettir — bir filtre, bir dışa aktarım ya da bir ayar, yeni bir ekrandan daha iyi çözer.

Son olarak, büyüme kadar küçülmeyi de planlayın. Yılda bir kez kullanılmayan ekranları kaldırmak, ürünü hafif tutmanın tek yoludur; aksi hâlde menü her yıl uzar ve yeni kullanıcı için öğrenme eşiği yükselir. Silmek eklemekten zordur ama ürünün yaşlanmasını engelleyen tek işlem odur.

Kapsamı kesmek, ürünü küçültmek değil odaklamaktır. Çekirdek akışı belirleyip gerisini modüler hâle getirmek, ertelenenle es geçileni ayırmak, üçüncü kutuyu — 'hiç yapılmayacak' — konuşmaya dahil etmek ve yapılmayanı açıkça işaretlemek; bunların hepsi ürünü daha küçük değil, daha güvenilir yapıyor. Az söyleyip fazlasını yapmak, çok söyleyip azını yapmaktan her zaman iyidir.

Bu duruşun bedelini biz de ödüyoruz: ürün sayfalarımızda 'yakında' yazan maddeler var ve karşılaştırmalı bakan biri bunu eksiklik olarak okuyabilir. Buna rağmen değiştirmeyi düşünmüyoruz. Bir projeye başlarken en çok konuşulması gereken şeyin ne yapılacağı değil ne yapılmayacağı olduğuna inanıyoruz — ve bu konuşmayı birlikte yapmaya hazırız.