Bir yazılım projesi bazen aynı toplantıda müşteri portalı, mobil uygulama, raporlama, muhasebe entegrasyonu ve otomatik bildirim beklentileriyle başlar. Başlıkların her biri mantıklı görünebilir; fakat birlikte yazılmaları ilk sürümün sınırını açıklamaz. Hangi kullanıcının hangi işi tamamlayacağı ve bu işin mevcut sorunu nasıl azaltacağı belirlenmeden hazırlanan özellik listesi, teklif ve teslim sürecinde farklı yorumlara açık kalır.
Web Tasarım Sistemleri olarak web yazılım projelerinde ihtiyaç analizini, ekran adlarının toplandığı bir belgeyle sınırlamamayı öneriyoruz. İş akışı, kullanıcı rolleri, veri kaynakları, bağımlılıklar ve kabul koşulları birlikte ele alınmalıdır. MVP, bu çalışmanın ardından seçilen dar fakat kullanılabilir ilk kapsamı tanımlar. Bu rehber, genel yazılım geliştirme tanımından çok, işletmenin ilk sürüm için hangi kararları yazılılaştırması gerektiğine odaklanır.
Özellik İsteğinin Arkasındaki İş Problemini Bulun
Bize bir takip ekranı gerekiyor ifadesi çözüm önerisidir. Takibin neden zor olduğu henüz belli değildir. Kayıtlar farklı kanallardan mı geliyor, sorumlu kişi mi görünmüyor, durum bilgisi mi güncellenmiyor? Aynı ekran isteği bu sorunların her biri için farklı bir çalışma gerektirebilir. Analize mevcut sürecin örnekleriyle başlayın: Bir talep nereden geliyor, kim işliyor, hangi noktada bekliyor ve sonuç kime bildiriliyor?
İş problemini kısa bir cümleye dönüştürün: Servis taleplerinin sorumlusunu ve son durumunu tek yerde görmek istiyoruz. Ardından bu cümlenin hangi gözleme dayandığını kaydedin. Görüşmeler, örnek işlem kayıtları ve mevcut çalışma belgeleri kullanılabilir; kişisel verileri gereksiz yere çoğaltmayın. Kurumsal proje briefi, başlangıç bilgisini düzenlemeye yardımcı olur; ayrıntılı yazılım analizinin yerini tek başına almaz.
Kullanıcı Rollerini Gerçek Görevleriyle Tanımlayın
Yönetici ve kullanıcı şeklindeki iki genel başlık çoğu iş akışını açıklamaya yetmez. Talep açan kişi, talebi sınıflandıran koordinatör, işi üstlenen uzman ve raporu inceleyen sorumlu farklı amaçlara sahiptir. Her rol için en sık yapılan işleri ve ihtiyaç duyduğu bilgiyi yazın. Bir kişinin birden fazla rol taşıması mümkündür; buna rağmen rollerin işlem ve veri kapsamı ayrı tanımlanmalıdır.
Kullanıcı ihtiyacını yalnız toplantıya katılan yöneticilerin tahminiyle kesinleştirmeyin. GOV.UK kullanıcı ihtiyaçlarını araştırma rehberi, gerçek veya olası kullanıcıların mevcut işleri, sorunları ve hedefleri üzerinden araştırma yapılmasını önerir. Kamu hizmetleri için hazırlanan bu yaklaşım, işletme yazılımında da varsayımları görünür kılmak için kullanılabilir. Ancak her öneriyi aynı yöntem veya süreyle uygulamak zorunlu değildir; araştırmanın kapsamı projeye göre belirlenir.
Yetki ihtiyacını senaryoya ekleyin: Kullanıcı yalnız kendi talebini mi görecek, ekip sorumlusu bütün departmanı mı izleyecek? Bayi portalında rol ve erişim ayrımı, bu farkın kayıt düzeyinde nasıl düşünülmesi gerektiğini gösterir. Küçük ilk sürümde bile kimin hangi bilgiye erişebileceği belirsiz bırakılamaz.
Mevcut Akışı ve İstisnaları Aynı Haritada Gösterin
Bir işin başlangıcını, durumlarını ve bitişini çıkarın. Örneğin yeni talep, incelemede, atandı, tamamlandı ve kapandı durumları düşünülebilir. Bu adlar örnektir; işletmenin onaylı işleyişi farklı olabilir. Her geçişte işlemi yapan rolü, gerekli bilgiyi ve ortaya çıkan sonucu yazın. Tamamlandı ile kapandı farklı sorumluların kararını ifade ediyorsa tek duruma sıkıştırılmamalıdır.
Yalnız sorunsuz akışı çizmek yeterli değildir. Eksik bilgiyle gelen talep, yanlış kişiye atama, iptal, yeniden açma ve aynı işlemin iki kez gönderilmesi gibi durumları da konuşun. İstisnaların bir kısmı düşük sıklıkta olsa bile veri kaybı veya yanlış yetki sonucu yaratabilir. İlk sürümde hangilerinin destekleneceği, hangilerinde kontrollü bir manuel işlem kullanılacağı açıkça kararlaştırılmalıdır.
İhtiyacı Test Edilebilir Bir Kullanıcı Senaryosuna Çevirin
Bir senaryo, rolü, yapmak istediği işi ve beklediği sonucu anlatmalıdır. Koordinatör olarak yeni talepleri sorumlu kişiye atamak istiyorum; böylece hangi kaydın kimde beklediğini görebileyim ifadesi başlangıç olabilir. Ardından ön koşul, işlem adımları ve beklenen sonuç eklenir. Bu bilgi, ekranın görünüşünden önce davranışın tartışılmasını sağlar.
Her senaryonun küçük bir kabul listesi bulunmalıdır. Atama yapıldığında sorumlu kişinin değişmesi, işlemin kaydedilmesi ve yetkisiz kullanıcının aynı işlemi yapamaması ayrı kontrol noktalarıdır. Gelen talebin niteliği de ilk sürümün veri alanlarını etkiler. B2B teklif talebi sayfa yapısındaki soru yaklaşımı, yalnız form alanı eklemek yerine sonraki işin ihtiyaçlarını düşünmek için kullanılabilir.
- Rol ve amaç: İşlemi kim, hangi ihtiyacı karşılamak için yapacak?
- Ön koşul: Hangi kayıt, yetki ve bilgi hazır olmalı?
- Ana işlem: Kullanıcı hangi adımları tamamlayacak?
- Beklenen sonuç: Sistemde ve kullanıcının ekranında ne değişecek?
- Olumsuz durum: Eksik veri, yetkisizlik veya servis hatasında ne olacak?
MVP Kapsamını Tamamlanabilir Bir İş Etrafında Kurun
MVP, burada en az sayıda ekranı yapan bir demo anlamında kullanılmıyor. İşletmenin seçtiği temel görevi baştan sona tamamlayabilen ilk sürümden söz ediyoruz. Talep açılabiliyor fakat hiçbir sorumlu onu işleyemiyorsa, temel görev yarım kalmış olabilir. Buna karşılık talep açma, atama ve durum takibi çalışırken gelişmiş yönetim raporunun ertelenmesi tutarlı bir kapsam kararı olabilir.
İlk sürümün değerini koruyacak en küçük akışı belirleyin. Bunun için her özelliğe şu soruyu sorun: Bu olmadan seçilen kullanıcı görevini kabul edilebilir biçimde tamamlayabiliyor mu? Cevap evetse özellik sonraki sürüme alınabilir. Cevap, elle yapılacak bir işlem sayesinde evet oluyorsa, o işlemin sahibi, kapasitesi ve hata kontrolü de kapsamın parçasıdır. Görünmeyen manuel emek ücretsiz veya sınırsız kabul edilmemelidir.
Bu karar teknoloji seçimini de etkileyebilir. Daraltılan ihtiyaç hazır bir ürünle karşılanabiliyorsa özel geliştirme şart olmayabilir; özgün akış veya veri ilişkileri farklı bir çözüm gerektirebilir. Özel web yazılım ve hazır sistem karşılaştırması, bu noktada çözüm türünü değerlendirmek içindir. MVP seçimi, önceden kararlaştırılmış teknolojiyi gerekçelendirmek için kullanılmamalıdır.
Öncelikleri Değer, Risk ve Bağımlılıkla Birlikte Tartın
Bütün maddeleri zorunlu işaretlemek, önceliklendirme yapıldığı anlamına gelmez. Kullanıcı görevine katkı, yanlış yapılmasının etkisi, öğrenilmesi gereken belirsizlik ve başka işlerin ona bağımlılığı birlikte değerlendirilmelidir. Bir rapor görünür olduğu için öne çıkabilir; ancak onun verisini oluşturan işlem eksikse raporun geliştirilmesi ilerleme görüntüsü yaratmaktan öteye gitmeyebilir.
Basit bir karar kaydı kullanın: İlk sürümde, sonraki sürümde veya değerlendirme bekliyor. Her kararın yanında gerekçesi bulunsun. Özelliği ertelemek unutmak değildir; hangi koşul gerçekleşince yeniden ele alınacağı da yazılabilir. Örneğin belirli bir işlem hacmine ulaşıldığında otomasyon değerlendirmesi yapılması planlanabilir. Bu eşik işletmenin gerçek verisiyle belirlenmelidir; sektör geneli için uydurma bir rakam kullanılmamalıdır.
Öncelik toplantısında zaman ve maliyet etkisini de görünür tutun. İlk sürüme yeni bir iş eklendiğinde mevcut hangi işin erteleneceği veya ek kapasitenin nasıl sağlanacağı konuşulmalıdır. Küçük bir düğme gibi görünen istek, yeni bir onay rolü ve bildirim akışı gerektirebilir. Bu nedenle işi yalnız ekran boyutuyla tahmin etmeyin. Geliştirme, veri hazırlığı, test, kullanım açıklaması ve işletim sorumluluğu birlikte değerlendirilmelidir. Kapsam kaydına eklenmiş fakat bu etkileri konuşulmamış bir madde, onaylanmış teslim taahhüdü gibi kabul edilmemelidir.
En Riskli Varsayımı Geliştirme Başlamadan Sınayın
Bir ekranın beğenilmesi, iş akışının uygulanabilir olduğunu göstermeyebilir. Kullanıcı gerekli veriyi bulabiliyor mu, dış sistem gereken alanı sağlıyor mu, onay sorumlusu gerçekten o kararı verebiliyor mu? Bu sorulardan en kritik olanını seçerek küçük bir doğrulama yapın. Tıklanabilir prototip, örnek veriyle süreç yürütme veya teknik bağlantı denemesi farklı belirsizliklere cevap verir.
GOV.UK alpha aşaması rehberi, prototiplerle en riskli varsayımları sınamayı ele alır. Buradan yararlanırken prototip ile canlı ilk sürümü ayırmak gerekir. Bir fikri sınamak için hazırlanan arayüz, üretim ortamına uygun güvenlik, veri kalıcılığı ve işletim koşullarını otomatik olarak taşımaz. Prototipten öğrenilen sonuçlar, MVP kapsamını değiştirmek için kullanılmalıdır.
Veri Kaynağını ve Entegrasyon Sınırını Erken Netleştirin
Müşteri, ürün ve kullanıcı bilgilerinin hangi sistemde doğru kabul edildiği belirlenmelidir. Aynı müşteriyi iki sistemde farklı kodlarla tutmak, işlem eşleşmesini zorlaştırabilir. İlk sürümde mevcut verinin taşınması gerekiyorsa kayıt kalitesi, alan eşlemesi ve hatalı satırların nasıl ele alınacağı konuşulur. Ürün referanslı işlerde ürün kataloğu veri sözlüğü yaklaşımı, ortak ad ve birimlerin önemini gösterir.
Entegrasyon için yalnız bağlanacak sistemin adını yazmayın. Hangi veri, hangi yönde, hangi olayla ve kimin yetkisiyle aktarılacak? Dış sistem kullanılamadığında iş duracak mı, bekleyecek mi, yeniden denenecek mi? CRM ve ERP entegrasyonu planlama rehberi, bu kararları ayrı ele alır. Entegrasyonu ertelemek mümkünse bile ilk sürümdeki geçici aktarım ve mutabakat süreci tanımlanmalıdır.
Örnek veri paketi hazırlamak bu görüşmeyi somutlaştırır. Bir normal kayıt, zorunlu bilgisi eksik kayıt, aynı kişiyi temsil eden iki kayıt ve kullanımdan kalkmış bir ürün örneği seçilebilir. Yazılımın bunları nasıl ayırt edeceğini işletme tarafı açıklamalıdır. İlk yüklemede hatalı satırlar raporlanacak mı, işlem kısmen tamamlanabilecek mi, düzeltme sonrasında tekrar yükleme çift kayıt üretecek mi? Bu soruların cevabı bulunmadan veri aktarımını basit bir dosya yükleme işi olarak görmek, MVP kapsamındaki önemli bir bağımlılığı gizleyebilir.
Kabul Koşullarını ve Ortak Kalite Sınırını Ayırın
Bir özelliğin kabul koşulu, o işin beklenen davranışını açıklar. Ortak kalite sınırı ise bütün teslimlerin uyması gereken özellikleri tanımlar: Gerekli erişim kontrolünün bulunması, hataların anlaşılır ele alınması, veri kalıcılığının doğrulanması ve ilgili testlerin tamamlanması gibi. Dar kapsam seçimi, bu temel koşulları bilinçsizce dışarıda bırakmak için gerekçe yapılmamalıdır.
Scrum.org tamamlanma tanımı açıklaması, ortak kalite ölçütlerinin neyin tamamlandığı konusunda şeffaflık sağladığını anlatır. Bu kavramdan yararlanmak, projede Scrum uygulandığı iddiası değildir. İşletme ile geliştirme ekibi, kullanılan yöntem ne olursa olsun teslimin hangi koşullarda kabul edileceğini ortaklaştırmalıdır. Yazılımda kalite güvencesi, bu nedenle sona bırakılan tek bir kontrol turundan daha geniş düşünülmelidir.
Varsayımsal Servis Talebi Projesinde İlk Sürümü Seçin
Bir teknik servis işletmesinin e-posta ile gelen talepleri farklı listelerde izlediğini varsayalım. İlk hedef, talep sorumlusunu ve durumunu ortak bir yerde görebilmektir. Başlangıç beklentileri arasında müşteri girişi, teknisyen mobil uygulaması, otomatik görevlendirme ve ERP bağlantısı da vardır. Bu örnek gerçek bir müşterinin sonucu değildir; kapsam kararının nasıl yazılabileceğini göstermek için oluşturulmuştur.
İlk Sürüm ve Sonraki Adımlar İçin Karar Örneği
- İlk sürüm: Koordinatör talep açar, sorumlu atar ve durum geçmişini görür.
- İlk sürüm: Yetkili uzman kendi işini günceller; kapanış sorumlusu sonucu kontrol eder.
- İlk sürüm: Eksik bilgi ve iptal durumları, belirlenen kurallarla yönetilir.
- Sonraki sürüm: Müşterinin kendi hesabından başvurması, araştırma sonucuna göre değerlendirilir.
- Sonraki sürüm: Otomatik atama ve ERP bağlantısı, veri ve süreç doğrulandıktan sonra ele alınır.
Örnek bir kabul kaydı MVP-04 olarak adlandırılabilir: Koordinatör açık talebi yetkili uzmana atar; uzman kendi listesinden kayda ulaşır ve izin verilen durum değişikliğini yapar. Başka bir ekibin kullanıcısı aynı kayda erişmeye çalıştığında işlem reddedilir. Bildirim gönderilemezse atamanın kaybolup kaybolmadığı ve hatanın kime gösterileceği ayrıca kontrol edilir. Bu örnekte ekranın açılması tek başına başarı ölçütü değildir. Aynı kaydın iki kişinin eşzamanlı güncellemesiyle nasıl davranacağı da işletmenin iş kuralına göre kararlaştırılmalıdır; sessizce son yazanın kazanacağı varsayılmamalıdır.
Bu seçimin yeterli olup olmadığı kullanıcılarla ve iş sorumlusuyla kontrol edilmelidir. Taleplerin sisteme girilmesini sağlayacak kişi yoksa koordinatör odaklı çözüm çalışmayabilir. İlk sürümde elle yapılan adımların ne kadar iş yükü yarattığı da gözlenir. Plan, başta seçildiği için değişmez kabul edilmez; yeni kanıt geldiğinde gerekçesiyle yeniden değerlendirilir.
Takvim de bu kapsam üzerinden oluşturulur. Profesyonel teslim planında olduğu gibi, geliştirme işiyle veri hazırlığı ve onay beklemesi ayrılmalıdır. Dış sistem erişimi veya karar sorumlusu hazır değilse, yalnız kodlama süresini hesaplamak gerçekçi bir başlangıç tarihi vermez. Bağımlılıkların sahibi ve hazır olacağı koşul açıkça gösterilmelidir.
İlk Kullanımdan Sonra Ne Öğrenileceğini Baştan Yazın
MVP yayına çıktığında hangi sorulara cevap aranacağını belirleyin. Kullanıcı görevi tamamlayabiliyor mu, hangi adımda destek istiyor, durumlar tutarlı güncelleniyor mu, manuel geçişte bilgi kayboluyor mu? Sayısal ölçüm planlanıyorsa önce tanım ve veri kaynağı netleşmelidir. Sadece ekran ziyaretinin artması, iş probleminin çözüldüğünü göstermeyebilir.
Geri bildirimleri aynı listede toplamak yararlıdır; ancak hata, kullanım sorunu ve yeni özellik isteği ayrı kararlara yol açar. Revizyon süreci yönetimi bu ayrımı kayıt ve sorumlu kişiyle ilişkilendirir. İlk kullanımda öğrenilen her istek otomatik olarak bir sonraki sürüme alınmamalı; temel hedefe katkısı ve mevcut işlere etkisi yeniden değerlendirilmelidir.
Analizden Geliştirmeye Geçiş İçin Bir Karar Paketi Hazırlayın
Başlangıç paketi; problem tanımı, roller, temel akış, örnek veri, ilk sürüm listesi, kapsam dışı işler, bağımlılıklar ve kabul koşullarını birlikte içermelidir. Her başlığın tamamı kesinleşmek zorunda değildir; belirsiz kalan konular ve onları kimin çözeceği görünür olmalıdır. Belirsizliği gizlemek, sonraki teklif veya takvim görüşmesinde kesin bilgiye dönüşmesini sağlamaz.
Geliştirme sonunda hangi kanıtın aranacağını başlangıçta konuşun. Yayına alma kabul listesi, iş akışlarını doğrulanabilir senaryolara dönüştürmek için destek olabilir. Projenizin kullanıcı görevlerini, veri kaynaklarını ve ilk sürüm sınırını birlikte değerlendirmek için ihtiyaç analizinizi bizimle görüşebilirsiniz. İyi bir başlangıç, daha uzun özellik listesiyle değil; hangi işi, kim için ve hangi koşullarda tamamlayacağınızın açıklığıyla kurulur.
Bu makalenin uzunluğu 1797 kelimedir.
Bu makale 2026-10-22 tarihinde yayınlanmıştır.