Kod yazmadan önce iş modeli

Fonksiyonel Tasarım

Yazılımın neyi, kimin için ve hangi kurallarla yapacağını alan uzmanlarınızla birlikte netleştiriyoruz. Sonunda elinizde tıklanabilir bir prototip, yalın bir şartname ve gerekçeli bir tahmin olur.

  • Alan uzmanlarınızla event storming atölyeleri
  • Ortak dil ve sınırlandırılmış bağlamlar (DDD)
  • Kullanıcı hikâyeleri ve tıklanabilir prototip
  • Yalın şartname ve gerekçeli tahmin
event stormingOlaySipariş alındıStok ayrıldıSevk edildiKomutSipariş verStok ayırİrsaliye kesKuralStok yoksa bekleKredi limitiAynı gün sevk
Tanıdık durumlar

Zorluklarınız

Yazılım projelerindeki sorunların çoğu kod yazılmadan önce başlar. İhtiyaç belirsizse en iyi ekip de yanlış şeyi iyi yapar.

01Herkes ne istediğini biliyor ama her birim başka bir şey anlatıyor.

Satış, operasyon ve muhasebe aynı kelimeye farklı anlamlar yükler. Atölyelerde ortak bir sözlük çıkarıyoruz, yazılım da bu sözlükle konuşuyor.

02Önceki projede şartname yüzlerce sayfaydı, yine de yanlış şey yapıldı.

Uzun dokümanı kimse sonuna kadar okumaz. Kısa kullanıcı hikâyeleri ve tıklanabilir ekranlarla çalışıyoruz, yanlış anlaşılmalar kod yazılmadan ortaya çıkıyor.

03Aldığınız teklifler birbirinden çok farklı ve neye dayandıklarını bilmiyorsunuz.

Tahminimizi kapsamı belli kullanıcı hikâyelerine bağlıyoruz. Hangi kalemin neden o süreyi aldığını ve hangi varsayıma dayandığını satır satır görürsünüz.

04Projenin nereden başlayacağına karar veremiyorsunuz.

İşinizi bağlamlara ayırıp en çok değer üreten parçayı öne alıyoruz. İlk sürüm küçük olur, ama ilk günden işe yarar.

Neler yapıyoruz

Kapsamımız

Domain-Driven Design yaklaşımımız en çok bu aşamada görünür. İşinizi önce modelliyor, sonra yazılıma çeviriyoruz.

Event storming atölyeleri

Alan uzmanlarınızla iş süreçlerini olaylar üzerinden birlikte çıkarıyoruz. Kurallar, istisnalar ve darboğazlar ilk günlerde görünür olur.

  • Yüz yüze ya da çevrimiçi atölyeler
  • Olaylar, komutlar ve aktörler
  • Açık soruların listesi

Ortak dil ve bağlamlar

İşinizin kavramlarını tek bir sözlükte topluyor, sistemi sınırları belli bağlamlara bölüyoruz. Her bağlamın sorumluluğu nettir.

  • Ortak dil (ubiquitous language) sözlüğü
  • Bağlam haritası (bounded contexts)
  • Bağlamlar arası entegrasyon noktaları

Kullanıcı hikâyeleri

İhtiyaçları kim, ne yapmak istiyor ve neden sorularıyla yazıyoruz. Her hikâyenin ölçülebilir bir kabul kriteri vardır.

  • Rol bazlı hikâye haritası
  • Kabul kriterleri
  • Önceliklendirilmiş iş listesi

Tıklanabilir prototip

Ana ekranları ve akışları çalışan bir prototipte gösteriyoruz. Kullanıcılarınız kod yazılmadan deneyip yorum yapabilir.

  • Ana akışların taslak ekranları
  • Tıklanabilir prototip
  • Kullanıcı geri bildirim turu

Yalın şartname ve tahmin

Geliştirme ekibinin ihtiyaç duyduğu kadar doküman yazıyoruz. Tahmin, hikâye bazında ve varsayımlarıyla birlikte gelir.

  • Fonksiyonel şartname
  • Teknik ön mimari notu
  • Gerekçeli süre ve maliyet tahmini
Çıktılar

Teslim ettiklerimiz

Fonksiyonel tasarımın sonunda elinizde geliştirmeye hazır bir paket olur. Bu paketle geliştirmeyi bizimle de başka bir ekiple de yapabilirsiniz.

Tüm dokümanları düzenlenebilir formatta teslim ediyoruz. Prototip ve sözlük, proje boyunca güncel tutulacak ortak referans olarak kalır.

  • Event storming çıktıları ve süreç haritası
  • Ortak dil sözlüğü ve bağlam haritası
  • Önceliklendirilmiş kullanıcı hikâyeleri
  • Tıklanabilir prototip
  • Yalın fonksiyonel şartname
  • Gerekçeli süre ve maliyet tahmini
Örnek bağlam haritası
bağlam: Sipariş
  olay: SiparişOluşturuldu
  olay: SiparişOnaylandı
bağlam: Stok
  olay: StokRezerveEdildi
bağlam: Faturalama
  olay: FaturaKesildi
Sözümüz

Taahhütlerimiz

  1. İşi bilen kişilerle çalışırız

    Atölyelere süreci her gün yaşayan çalışanlarınızı da davet ederiz. Masada anlatılan süreçle sahadaki süreç çoğu zaman farklıdır.

    • Saha ve ofis birlikte
    • İstisnalar baştan konuşulur
  2. Okunacak kadar doküman yazarız

    Şartname, geliştiricinin ve sizin kullanacağınız kadar uzun olur. Gerisini prototip ve hikâyeler anlatır.

    • Kısa ve güncel
    • Her hikâyede kabul kriteri
  3. Tahmini gerekçesiyle veririz

    Her kalemin süresini ve dayandığı varsayımı yazarız. Kapsamı daraltmak isterseniz neyin çıkacağını birlikte seçeriz.

    • Hikâye bazında tahmin
    • Açık varsayımlar
  4. Çıktılar sizindir

    Tasarım paketinin tüm hakları size aittir. Geliştirme için başka bir ekiple çalışmaya karar verirseniz paketi olduğu gibi devredebilirsiniz.

    • Düzenlenebilir formatlar
    • Bağımlılık yok
Nasıl çalışıyoruz

Yaklaşımımız

Süreler orta ölçekli bir iş uygulaması için tipiktir. Kesin planı ilk görüşmeden sonra paylaşıyoruz.

  1. Keşif görüşmesi

    1–2 gün Teknik lider

    Hedefi, kullanıcıları ve kısıtları dinliyoruz. Atölyelere kimin katılacağını ve hangi konuların konuşulacağını birlikte belirliyoruz.

  2. Event storming

    1–2 hafta Teknik lider + kıdemli geliştirici + alan uzmanlarınız

    Süreci olaylar üzerinden modelliyoruz. Ortak dil ve bağlam haritası bu atölyelerden çıkar.

  3. Hikâyeler ve prototip

    2–3 hafta Teknik lider + front-end geliştirici

    Kullanıcı hikâyelerini yazıyor, ana akışları tıklanabilir prototipe döküyoruz. Kullanıcılarınızla bir geri bildirim turu yapıyoruz.

  4. Şartname ve tahmin

    1 hafta Teknik lider

    Yalın şartnameyi, ön mimari notunu ve gerekçeli tahmini teslim ediyoruz. Sonucu bir toplantıda birlikte gözden geçiriyoruz.

Sonraki adımlar

Tamamlayıcı hizmetler

Sık sorulanlar

Fonksiyonel tasarım hakkında sorular

Fonksiyonel tasarım ne kadar sürer?
Kapsama göre değişir. Orta ölçekli bir iş uygulamasında birkaç hafta sürer. İlk görüşmeden sonra atölye sayısını ve toplam süreyi yazılı olarak bildiriyoruz.
Geliştirmeyi de sizinle yapmak zorunda mıyız?
Hayır. Tasarım paketi size aittir ve başka bir ekibin de kullanabileceği şekilde hazırlanır. Pek çok müşterimiz geliştirmeye bizimle devam ediyor, ama bu bir şart olarak konmaz.
Domain-Driven Design bilmemiz gerekiyor mu?
Gerekmiyor. Atölyelerde sizin kelimelerinizle konuşuyoruz. Teknik terimleri biz taşıyoruz, siz işinizi anlatıyorsunuz.
Atölyelere kimler katılmalı?
Karar verici bir yönetici, süreci her gün yaşayan birkaç çalışan ve varsa bilgi işlemden bir kişi yeterli. Her oturumu ilgili birimle sınırlı tutuyoruz, kimsenin gününü boşa harcamıyoruz.
Tahmin sabit fiyatlı teklife dönüşebilir mi?
Evet. Kapsam netleştiği için geliştirme aşamasına sabit fiyatlı teklif verebiliyoruz. Kapsamın değişmesini bekliyorsanız sprint bazlı çalışmayı öneriyoruz.
Başlayalım

Projenizi kod yazmadan önce birlikte modelleyelim.

Bize projenizi kısaca anlatın. Hangi atölyelere ihtiyaç olduğunu ve tasarımın ne kadar süreceğini ilk görüşmede konuşalım.

  • Kodu yazan ekiple doğrudan görüşme
  • Atölye planı ve süre önerisi
  • Tasarım çıktıları size ait