Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Discovery'den Delivery'ye: One-Pager, PRD ve Kararın Backlog'a Dönüşmesi
İyi bir one-pager ya da PRD iki soruya cevap verir: neden yapıyoruz ve başarılı olduğumuzu nasıl anlayacağız. Bookstore'un sepet terk çalışmasının tek sayfalık dokümanını problem, hedef outcome, success metric, non-goal, risk ve açık soru bölümleriyle yazıyor; kararı uçtan uca dilimlere bölünmüş backlog item'larına çeviriyor ve geliştiricinin PRD review'da sorması gereken soruları konuşuyoruz.
Deneyle Karar Vermek: A/B Test, Feature Flag ve İstatistiksel Tuzaklar
Bir A/B testi, örneklemi deneyden önce hesaplanıp sonuna kadar beklendiğinde güvenilirdir. Bookstore'un kargo ücreti hipotezini Microsoft.FeatureManagement variant flag'iyle test ediyor; kol başına 3.954 sepet gerektiğini, SRM kontrolünü, 2,24 puanlık farkın güven aralığını ve her gün bakıp erken durmanın etkisiz A/A deneylerinde yanlış pozitif oranını %5'ten %32'ye çıkardığını C# çıktısıyla görüyoruz.
Product Metric'lerini Kodda Ölçmek: Angular ve ASP.NET Core ile Event Tracking ve Cohort Analizi
Product metric'leri, kodda yaşayan bir event taxonomy ile başlar: object_action adları, izinli property listesi ve şema sürümü. Angular'da consent'e saygılı bir AnalyticsService, ASP.NET Core Minimal API ve EF Core ile bir event tablosu yazıyor; SQL Server'da haftalık retention cohort'unu ve sıralı activation funnel'ını gerçek sorgu çıktısıyla hesaplıyor, KVKK/GDPR açısından dikkat edilecekleri ve hazır araç ile kendi tablon arasındaki farkı konuşuyoruz.
Product Metric'leri: North Star, HEART ve AARRR
İyi bir product metric'i karar verdirir: North Star müşteriye sağlanan value'yu tek sayıda özetler, input metric'leri ekiplerin haftalık hareket ettirebileceği kaldıraçlardır, guardrail'ler optimizasyonun yan etkisini yakalar. Bookstore için bir metric ağacı kuruyor; HEART ve Goals-Signals-Metrics ile guest checkout'u, AARRR ile müşteri yaşam döngüsünü ölçüyor, leading/lagging ve vanity metric farkını konuşuyoruz.
Roadmap Hazırlamak: Feature Takvimi Yerine Now-Next-Later ve Outcome Roadmap'leri
Ay ay feature listeleyen bir roadmap, en az bilgi olan anda verilmiş sözlerden oluşur ve her yıl kayar. Vision, strateji, roadmap ve backlog hiyerarşisini; Now-Next-Later'ın belirsizlik kolonlarını, satırları problem ve ölçü olan outcome roadmap'ini Bookstore'un 2027 ilk yarı roadmap'i üzerinden; paydaşa güven aralığıyla anlatmayı ve Shape Up'ın appetite ve betting table fikirlerini konuşuyoruz.
Prioritization Framework'leri: RICE, MoSCoW, Kano ve Cost of Delay
Tek bir prioritization framework'ü her işi doğru sıralamaz: RICE etki/efor oranını görür ama zamanı göremez, CD3 aciliyeti görür ama CoD tahminine dayanır. TypeScript ile Bookstore'un altı işini iki yöntemle sıralıyor; ödeme SDK güncellemesinin RICE'ta son, CD3'te ilk çıktığını ve tek bir confidence değerinin sıralamayı nasıl değiştirdiğini görüyor, MoSCoW, Kano, WSJF ve teknik borcun puanlanmasını konuşuyoruz.
Product Discovery: Continuous Discovery, Kullanıcı Görüşmesi ve Opportunity Solution Tree
Product discovery bir faz değil, ekibin müşterileriyle en az haftada bir temas kurduğu sürekli bir pratiktir. İyi görüşmenin geçmiş davranışı sorduğunu, Opportunity Solution Tree'nin outcome, opportunity, solution ve assumption test seviyelerini Bookstore'un sepet terk ağacı üzerinden; fake door, concierge ve prototip testlerini, dual-track'te geliştiricinin feasibility spike ve throwaway prototipteki yerini anlatıyoruz.
Output Değil Outcome: Problem Tanımı, Hipotez ve Jobs to Be Done
Ekibe output (feature) değil outcome (davranış değişikliği) hedefi verilmeli: output kontrol edilir ama sonucu garanti etmez, impact ise ekipten çok uzaktır. Bookstore'un %66,7'lik sepet terk problemini çözüme atlamadan çerçeveliyor; dört parçalı problem tanımını, yanlışlanabilir hipotez formatını, guardrail'i, Jobs to Be Done fikrini ve job story ile user story farkını konuşuyoruz.
Product Management Nedir? Product Manager, Product Owner ve Project Manager Farkı
Product management, doğru şeyi inşa etmekle ilgilenir: project bir kapsamı bir tarihe teslim eder, product ise bitmeden value üretir. Product Manager'ın bir iş rolü, Product Owner'ın Scrum'da bir accountability, Project Manager'ın zaman-kapsam-bütçe rolü olduğunu; Cagan'ın dört riskini, feature factory ile empowered team farkını ve geliştiricinin feasibility'deki yerini Bookstore'un kampanya talebi üzerinden konuşuyoruz.
Scrumban ve Kanban Guide for Scrum Teams: Scrum'a Flow Eklemek
Scrum'a flow eklemek için Sprint'i bırakmak gerekmez: Kanban Guide for Scrum Teams, Scrum Guide'ın hiçbir parçasını değiştirmeden DoW, WIP limit'i ve dört flow metric'ini Sprint Planning, Daily Scrum, Review ve Retrospective'e ekler. Ladas'ın geçiş yolu olarak tarif ettiği Scrumban'ı, bugünkü gevşek kullanımını ve destek, platform, ürün ekipleri için Scrum, Kanban ya da ikisi birlikte seçimini konuşuyoruz.
Kanban'da Aktif Yönetim ve İyileştirme: Blocker, Aging ve Flow Review
Flow'u aktif yönetmek; board'u her gün sağdan sola ve en yaşlı item'dan başlayarak okumak, blocked işi eskale etmek, expedite'i sınırlamak ve bottleneck'i veriyle bulmaktır. Bookstore verisinden CFD bantlarını C# ile hesaplıyor, Code Review'ın Temmuz'da nasıl darboğaz olduğunu, Theory of Constraints adımlarıyla nasıl çözüldüğünü (p85 16 günden 11 güne) ve sıradaki constraint'in deploy ritmi olduğunu görüyoruz.
Service Level Expectation ve Monte Carlo: "Ne Zaman Biter?" Sorusuna Olasılıkla Cevap
Tek item için cevap SLE'dir ("%85 olasılıkla 14 gün"); çok item için geçmiş günlük throughput'tan örneklem alan bir Monte Carlo simülasyonu. Bookstore verisiyle 10.000 çalıştırma yapan C# kodu, 30 item'ın %50 olasılıkla 25 Kasım'da, %85 olasılıkla 6 Aralık'ta biteceğini söylüyor. Percentile'ı doğru yönden okumayı, stakeholder'a anlatmayı ve tahminin hangi koşullarda yanıldığını konuşuyoruz.