Kod yazmadan önce: Mentorual'da kararları netleştirmek

01Neden koddan önce

Mentorual; mentörlük, uygunluk, randevu ve kurum yönetimi akışlarını aynı ürün içinde ele alan bir proje. Mentör, üye, kurum ve yönetici rolleri var; deneyim web, mobil ve yönetim tarafına dağılıyor. Bu projedeki rolüm ürün analizi, gereksinimler ve tasarım hazırlığı. Çalışma şu an analiz ve tasarım hazırlığı aşamasında ilerliyor, yani anlatabileceğim bir kod tabanı yok. Anlatabileceğim şey, kod yazılmadan önce verilmesi gereken kararlar ve bunların neden bu kadar ağırlık taşıdığı.

Birden fazla rolün ve kurumun bulunduğu bir üründe aynı işlemin farklı ekranlarda tutarlı davranması gerekiyor. Bir randevunun mentör tarafında nasıl göründüğü, üye tarafında hangi durumlardan geçtiği, kurum tarafının buna nereden dahil olduğu gibi sorular cevapsız kalırsa, bu cevapları geliştirme sırasında herkes kendi başına vermek zorunda kalır. Bence ürünlerdeki tutarsızlığın en yaygın kaynağı tam olarak bu: kötü kod değil, hiç konuşulmamış kararlar.

02Gereksinimden ekran ailesine

Hazırlık paketinin parçaları gereksinimler, kullanım senaryoları, ekran aileleri ve rol-yetki analizi. Bunları ayrı belgeler gibi düşünmek kolay, ama asıl değer aralarındaki bağda. Bir gereksinim en az bir kullanım senaryosunda karşılık bulmalı, her senaryo belirli ekranlarda yaşamalı, her ekran da kimin neyi görebildiği ve yapabildiği sorusuna bağlanmalı. Bu zincirin bir halkası koptuğunda, ya yapılmayan bir iş ya da kimsenin istemediği bir ekran ortaya çıkıyor.

Ekran ailesi kavramını bu yüzden faydalı buluyorum. Ekranları tek tek listelemek yerine benzer davranışı paylaşanları bir arada düşünmek, tekrar eden kararları bir kez vermeyi sağlıyor. Liste, detay, form ve onay gibi kalıplar farklı rollerde tekrar ettiğinde davranışın da aynı kalması beklenir. Web ve mobil aynı aileyi farklı ölçülerde sunabilir, ama kural aynı kalmalı.

gereksinim
  -> kullanım senaryosu
    -> ekran ailesi (web / mobil / yönetim)
      -> rol-yetki satırı
        -> kabul koşulu

03Rol-yetki matrisi bir tablo değil, bir sözleşme

Rol-yetki matrisi ilk bakışta satırları roller, sütunları işlemler olan bir tablo gibi görünüyor. Ben onu daha çok bir sözleşme olarak görüyorum: analiz, tasarım ve geliştirme arasında “kim neyi yapabilir” sorusunun tek cevabı. Mentör, üye, kurum ve yönetici gibi rollerin olduğu bir yapıda bu cevabın ekranlara, servislere ve testlere aynı şekilde yansıması gerekiyor.

Matrisi düşünürken en çok işe yarayan soru bence “bu işlem hangi durumda kimin elinde” sorusu. Yetki çoğu zaman yalnızca role değil, kaydın durumuna ve kurum bağlamına da bağlı. Bu ayrımları erkenden yazıya dökmek, ileride bir ekranın neden bir düğmeyi gösterip diğerinin göstermediği tartışmasını baştan kesiyor.

Bir akışın nerede bittiğini bilmeden o akışı doğru kurmak zor.

04MVP ile sonraki sürümleri ayırmak

Bu çalışmada MVP ve sonraki sürüm kapsamları ayrıldı. Kâğıt üzerinde basit görünen bu ayrım aslında en zor kararlardan biri. Her özellik önemli görünür; asıl soru, ilk sürümün tek başına anlamlı bir ürün olup olmadığı. Benim bu tür ayrımlarda kullandığım ölçüt şu: bir rolün temel işini baştan sona tamamlayabilmesi için gereken en kısa yol hangisi, ve bu yolun dışında kalanlar sonraki sürüme taşınabilir mi.

Ayırmanın görünmeyen bir yanı da var. Sonraki sürüme bırakılan bir özellik unutulmuş sayılmaz; ilk sürümün akışlarını, ileride o özelliğin gelmesini zorlaştırmayacak biçimde düşünmek gerekir. Kapsam dışı bırakmak, onu hiç düşünmemek anlamına gelmiyor.

05Kararları kayda almak

Hazırlık paketinin en az görünen ama bence en kalıcı parçası, ürün kararlarının kayda alınması. Bir kararın ne olduğu kadar neden verildiği de önemli. Aylar sonra biri “bu neden böyle” diye sorduğunda cevabın birinin hafızasında değil yazılı bir kayıtta olması, aynı tartışmanın tekrar tekrar yapılmasını önlüyor.

Kabul koşulları da bu kaydın uzantısı. MVP kapsamı, ekran gereksinimleri ve kabul koşulları arasında izlenebilirlik kurmak, bir işin “bitti” sayılma ölçütünü önceden belirlemek demek. Geliştirme başladığında bu ölçütler hem uygulayan hem gözden geçiren için ortak bir dil oluşturur.

06Analiz de üretimin bir parçası

Bu projede en çok üzerinde durduğum düşünce, ürünü netleştirmenin de üretimin bir parçası olduğu. Kod yazılmayan bir aşama kolayca “hazırlık” diye küçümsenebiliyor. Oysa kimin hangi işlemi yapabildiği, bir akışın hangi durumda sona erdiği ve ilk sürümün tam olarak neyi kapsadığı sorularının cevabı, yazılacak kodun büyük kısmını belirliyor. Bu cevaplar olmadan başlayan bir geliştirme, aynı soruları daha pahalı bir yerde cevaplamak zorunda kalıyor.