Uygulama spesifikasyonlarında kısıtları ve yapılmayacakları nasıl yazacağınızı öğrenin; böylece yeniden çalışma hızla azalır. Sabit yığın, bütçe, son tarih ve neyin değişebileceği için basit bir format kullanın.
Yeniden çalışma, bir şeyin çalıştığı ama proje için yanlış olduğu durumda ortaya çıkar. Ekipler ekranları yeniden yapar, mantığı yeniden yazar, veriyi taşır veya bir özelliği yeniden inşa eder çünkü kritik bir karar geç ortaya çıkar.
Bu genellikle tanıdık şekillerde görünür: yanlış kullanıcı rolleri varsayımıyla bir akış yeniden inşa edilir; mobil destek beklendiği halde belirtilmediği için ekranlar yeniden tasarlanır; “denetim geçmişine ihtiyacımız var” ifadesi birinci sürümden sonra gelince veri modeli değişir; bir entegrasyon müşterinin üçüncü taraf bir servisi kullanamamasıyla değiştirilir; veya uyumluluk ya da bölge kuralları yüzünden uygulama barındırma değişmek zorunda kalır.
Kısıtların eksik olması ileride sürpriz kararlar yaratır. Bir spesifikasyonda “bir CRM inşa et” yazdığınızda onlarca soru açıkta kalır: kim kullanacak, hangi platformlar önemli, hangi güvenlik kuralları uygulanacak, neler kapsam dışında kalmalı, gerçek bütçe ve zaman çizelgesi nedir. Yanıtlar kod varken gelirse proje iki kez öder: bir kez inşa etmek, bir kez de geri almak için.
Basit bir örnek: bir kurucu “randevular + hatırlatıcılar” ister. İlk hafta e-posta hatırlatıcıları gönderilir. İkinci hafta SMS gerektiği söylenir, ama SMS ülkesinde yasak veya bütçeyi aşar. Şimdi hatırlatma sistemi yeniden tasarlanır, ekranlar değişir ve testler yeniden başlar. Yeniden çalışma kötü kodlamadan değil, geç gelen kısıtlardan kaynaklanır.
Amaç, kod yazılmadan veya üretmeden önce gidip gelmeleri azaltmaktır. Elle kod yazın veya sohbet tabanlı bir inşa aracı kullanın, çıktı sadece verdiğiniz kuralları izleyebilir. Kurallar geç geldiğinde çalışma kayar ve yeniden yapılır.
Bu uzun bir doküman yazmak hakkında değil. Hafif bir spesifikasyon, önemli yerlerde katı olabilir. Erken aşamada şu sorulara yanıt vermelidir:
Kısıtlar ve yapılmayacaklar önce yazıldığında, bunlar birer koruyucu bariyer gibi davranır. Daha az sürpriz, daha az yeniden inşa ve daha net kararlar elde edersiniz.
Kısıtlar, projenizin uyması gereken sabit kararlardır. Onları görmezden gelirseniz işi iki kez yaparsınız, çünkü gönderilemeyecek bir yönde inşa edersiniz.
Yapılmayacaklar, açıkça bazı şeyleri inşa etmeme seçimidir. Bunları atlarsanız, spec sessizce “küçük” ekstralarla büyür. Bu şekilde ekranları, akışları ve veri modellerini yeniden yapmak zorunda kalırsınız.
Hızlı bir kural: kısıtlar nasıl inşa edeceğinizi sınırlar; yapılmayacaklar neyi inşa etmeyeceğinizi sınırlar.
Kısıt, gerçek bir karar alınmadan değişmeyecek olan zorunluluktur.
Örnekler:
Bir kısıt gerçekse, tartışılamayacak bir cümle olarak yazın. Birisi “belki” diyebiliyorsa, henüz kısıt değildir.
Yapılmayacak, açıkça “bunu yapmıyoruz” demektir; faydalı gibi görünse bile. İlk sürümü korur.
Örnekler:
Yapılmayacaklar negatiflik değildir. Pahalı sapmaları önlerler. Örneğin, “v1'de özel roller yok” demek, veritabanı ve UI tasarımını zorlayan izin kenar durumlarından haftalar kazandırabilir.
Detay sayfalar yazmadan önce, projeyi duvara çivileyecek bir cümle yazın. Karşılaşacağınız takaslarda herkesin hizalanmasını sağlar.
İyi bir tek cümle şunu yanıtlar: bunun için kim ve ana işi ne olmalı?
Örnek tek cümleler:
Sonra küçük bir başarı tanımı ekleyin: gerçek bir kullanıcının proje bittiğinde başarması gereken 3–5 sonuç. Bunları özellik değil, kullanıcı sonuçları olarak yazın.
Eğitmen rezervasyon örneği için:
Henüz metrikler yoksa, başarıyı kelimelerle tanımlayın. “Hızlı” belirsizdir, ama “telefonda hızlı hissetmeli” yine de faydalıdır. “Kolay” belirsizdir, ama “kurulum için çağrı gerekmez” daha nettir. Sayıları daha sonra ekleyebilirsiniz.
Bu bölümü kısa tutun. Sonraki her şey için bağlam oluşturur: ne doğru olmalı, ne olmamalı ve ne değişebilir.
Yeniden çalışma genellikle zaman çizelgesi ve karar süreci sadece birinin kafasında kaldığında başlar. Özellikleri ve ekranları tanımlamadan önce proje kısıtlarını spesifikasyona koyun.
Bunları düz, test edilebilir ifadelerle yazın:
Basit bir örnek:
“İlk sürüm 30 Mayıs'a kadar yayınlanmalı. Giriş, temel müşteri listesi ve aylık bir rapor içerir. v1'de entegrasyon yok. Bütçe ilk ay barındırma dahil 8.000$ ile sınırlıdır. İncelemeler hafta içi 24 saat içinde yapılır. Ürün sahibi Sam, kapsam değişikliklerini onaylar.”
Geri bildirim hızı kendi satırını hak eder çünkü nasıl güvenle ilerleyebileceğinizi kontrol eder. Paydaşlar sadece haftada bir inceleme yapabiliyorsa, spes daha küçük sürümlere ve daha az kenar durumuna öncelik vermelidir.
Gerçekçi bir inceleme düzeni seçin: aynı gün geri dönüş, hafta içi 24–48 saat, yalnızca haftalık toplantı veya (nadiren) “geri bildirime gerek yok”.
Teknik kısıtları erken yazmazsanız, insanlar boşlukları varsayımlarla doldurur. Bu, iş başladıktan sonra ekranların, migrationların veya entegrasyonların yeniden yapılmasına yol açar.
Sabit olanı ve sadece tercih olanı belirtin. “Tercih React” ile “React olmalı çünkü dahili bileşen kütüphanemize bağlıyız” aynı şey değildir. Her karar için bir cümle yeterlidir.
Tüm uygulama için açık olun: web, backend, veritabanı ve mobil. Bir parça esnekse, bunu söyleyin ve bir sınır koyun (ör. “v1'de mobil web-only”).
Yazmak için basit bir yol:
Sonra kaçınılmaz entegrasyonları listeleyin. Sistemleri adlandırın (ödeme, e-posta, analiz, CRM) ve sert limitleri not edin. Örnekler: “Faturalama için Stripe kullanılmalı”, “E-posta mevcut sağlayıcımız üzerinden gönderilmeli”, “Analitik kişisel veri izlememeli.” Kimlik doğrulama sabitse (SSO, Google, şifresiz) bunu da belirtin.
Barındırma seçimleri mimariyi değiştirir. Uygulamanın nerede çalışması gerektiğini ve nedenini yazın: “Almanya'da çalışmalı”, “Veri AB içinde kalmalı” veya “Küresel olarak çalışabilir”.
Uyumluluk ihtiyaçlarınız varsa somut tutun: saklama süresi, silme kuralları ve denetim gereksinimleri.
Örnek: “Kayıtları 7 yıl sakla, doğrulanmış bir istekte 30 gün içinde sil, bir kaydı kim görüntülediğinin denetim kaydını tut ve yalnızca hastaların yaşadığı ülkede dağıt.” Bu satırlar, yayına hazır olduğunuzda yaşanacak geç sürprizleri engeller.
Yapılmayacaklar, bir spesin koruyucu bariyerleridir. İlk sürümde ne inşa edilmeyeceğini, ne desteklenmeyeceğini veya neyin kusursuz hale getirilmeyeceğini söyler. Bu, sürprizleri azaltmanın en hızlı yollarından biridir; çünkü birçok “küçük” istek daha sonra gelir ve sessizce tüm planı değiştirir.
İyi bir yapılmayacak, bir ekip arkadaşının kapsam kaymasını tek bir cümlede fark edebileceği kadar spesifik olmalıdır. Ayrıca zaman bağlı olmalıdır. “v1'de yok” “bunu yapmayacağız” demekten daha nettir.
İnsanların genelde içinde olduğunu varsaydığı özelliklerle başlayın. Basit bir rezervasyon uygulaması için örnek:
Bunlar kötü özellikler değildir. Pahalı özelliklerdir. Yazmak, ilk sürümü odaklı tutar.
Ayrıca büyük zincirleme işe yol açan “detay” maddelerini de belirtin: roller, izinler ve kenar akışları. “Özel roller yok. Sadece iki rol: Owner ve Member.” Bu tek satır haftalar kazandırabilir.
Ekipler sık sık özellik olmayan yapılmayacakları unuturlar. Bunlar daha sonra acı verici yeniden çalışmalar olarak çıkar.
Ne için optimize etmeyeceğinizi belirleyin. Örneğin: “1M kullanıcı için performans optimize etmeyeceğiz. v1'de haftalık 500 aktif kullanıcıya kadar varsayım yapıyoruz.”
Ayrıca hangi platformların test edilmeyeceğini not edin, böylece testler gerçekçi kalır: “Internet Explorer desteklenmez”, “Tablet için özel düzen yok” veya “Giriş sadece e-posta ve parola ile (SSO yok, sihirli link yok)”.
Spec, küçük kararların evrilmesine izin verdiğinde daha güvenli hissedilir. Sadece sabitleri yazarsanız, her yeni fikir bir tartışma olur. Kısa bir “değişebilir” listesi, insanlara bütünü yeniden başlatmadan ürünü iyileştirme alanı verir.
Pratik olun. Genelde bir çalışan sürümlerden sonra öğrenilecek küçük şeyleri kapsayın, büyük yeni özellikleri değil. Yaygın esnek öğeler: UI metinleri, küçük akış değişiklikleri, raporlama sütunları, isimlendirme (roller, durumlar, kategoriler) ve temel düzen tercihleri.
Sonra değişikliklerin nasıl kabul edileceğine karar verin. Basit bir onay kuralı yoksa “hızlı ince ayarlar” gizli kapsam kaymasına dönüşür.
Çoğu küçük ekip için işe yarayan basit bir iş akışı:
Ana kural: esnek değişiklikler sabit kısıtları bozamaz. Eğer yığın React + Go + PostgreSQL olarak kilitlendiyse, “değişebilir” bir istek backend'i değiştirme talebine dönüşemez. Son tarih sabitse, “değişebilir” yeni bir modül ekleyip iki hafta daha istemek anlamına gelmemelidir.
Herkesin kabul edeceği bir takas notu ekleyin. Örnek: “Yeni bir kullanıcı rolü eklerseniz, gelişmiş raporlama faz 2'ye ertelenir.”
İyi bir spesifikasyon, seçenekleri genişletmek yerine sınırlamakla başlar. Bu format, kuralları yazmadan kimsenin inşa etmeye başlamasını engeller.
Dokümanınızın başlığı olarak bunu kullanın:
SPEC v0.1 (date)
Owner:
Reviewers:
1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]
2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]
3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]
4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]
5) Open questions
- Q: [question]
Owner: [name]
Due: [date]
6) Lock rule
- After review: changes require: [what approval looks like]
(Bu kod bloğu tercüme edilmemiştir; olduğu gibi bırakıldı.)
Çoğu sürpriz şans eseri değildir. Spes farklı yorumlara açık bırakıldığında ortaya çıkar.
Yaygın bir tuzak, hedeflerle çözümleri karıştırmaktır. Ekipler ekranlara ve akışlara doğrudan atlayıp sabit olanları (son tarih, bütçe, yığın) yazmayı atlar. Sonuç, kısıtlara uymayan şık bir UI planıdır.
Bir diğer tuzak belirsiz yapılmayacaklardır. “Ekstra özellik yok” sıkıymış gibi görünür ama biri “sadece bir rapor daha” dediğinde işe yaramaz çünkü spesifik istekleri engellemez."
Gizli bütçe veya “yumuşak” son tarih de kapsam bombasıdır. Gerçek bütçe 5.000$ ise ama spes 50.000$ gibi görünüyorsa ekip yanlış şeyi inşa eder. Rahatsız edici sayıları sayfaya koyun.
Entegrasyonlar ve veri sahipliği de sessiz sürprizlere yol açar. “Stripe ile bağlan” dediğinizde hangi olayların, hangi alanların ve kimin veriyi yöneteceğini tanımlamazsanız aynı kararları tekrar tekrar vereceksiniz.
Son bir tuzak da inşa sırasında kısıtları değiştirmektir ve takası adlandırmamaktır. “Sadece web”den “web artı mobil”e geçmek veya “Postgres kullan”dan “en ucuz neyse onu kullan”a dönmek planı değiştirir. Değiştirebilirsiniz, ama kapsamı, zaman çizelgesini veya kalite beklentilerini güncellemelisiniz.
Spesinize kısa bir not ekleyin ve beş noktayı cevaplayın:
İnşa başlamadan önce “ne sabit?” sorularına uzun bir dokümanı karıştırmadan yanıt verebilmelisiniz.
Hızlı kontrol:
Bunlardan biri eksikse, ilk inşa olacaktır ama gerçek ikinci inşa hayat bulacaktır.
İlerlemenizi kaybetmeden kötü kararlara kilitlenmemenizi sağlayacak sonraki adımlar:
Eğer Koder.ai (koder.ai) kullanıyorsanız, “Planning Mode” ile birlikte temiz bir kısıtlar ve yapılmayacaklar bölümü platformun yığınıza, barındırma bölgenize ve kapsamınıza uygun bir ilk taslak üretmesine yardımcı olur. Öncelikler değişirse, snapshot ve rollback özellikleri stabil bir temel kaybetmeden değişiklikleri denemenizi sağlar.
Erken yazılmış bu kurallar sayesinde özellik tartışmaları kolaylaşır çünkü herkes hangi şeylerin sabit kalması gerektiğini ve nelerin oynanabileceğini bilir.
Rework, çalışan bir şey inşa ettiğiniz ama proje açısından yanlış olduğu için yayınlanamadığı durumdur. Genellikle kritik kısıtlar başta belirtilmediğinde ortaya çıkar; ekip makul varsayımlarda bulunur ve sonra bu varsayımlar yanlış çıkar.
Önce gerçekten değişmeyecek olanları yazın: son tarih, bütçe üst limiti, barındırma bölgesi, zorunlu teknoloji yığını ve uyumluluk gereksinimleri. Ardından, insanların sessizce kapsamı genişletmemesi için kısa bir yapılmayacaklar bölümü ekleyin.
Kısıtlar nasıl inşa edeceğinizi sınırlar — ör. “AB içinde çalışmalı” veya “React ve PostgreSQL kullanılmalı”. Yapılmayacaklar ise ne inşa edilmeyeceğini sınırlar — ör. “v1'de mobil uygulama yok” veya “başlangıçta özel roller yok”.
Test edilebilir bir cümle olarak yazın; tercihten ziyade net bir karar olun. Birisi “belki” diyebiliyorsa ve bunu kimse zorlayamıyorsa, henüz gerçek bir kısıtlama değildir ve açık soru olarak ele alınmalıdır.
İlk sürüm için başarıyı tanımlayan 3–5 kullanıcı sonucu seçin; uzun bir dokümana gerek yok. Bu sonuçlar, ekibin hangi özelliklerin gerçekten gerekli olduğunu ve hangi taleplerin reddedilebileceğini belirlemesini sağlar.
Mobil destek, roller ve izinler, denetim geçmişi, veri yerleşimi ve entegrasyonlar sıklıkla gizli kısıtlamalardır. Bunları başta ortaya koyarsanız ekranların yeniden tasarlanmasını, veri modelinin değişmesini veya sağlayıcıların değiştirilmesini önlersiniz.
Açık ve zaman bağlı olun; ör. “v1'de yok” veya “tablet desteklenmeyecek”. “Ekstra özellik yok” gibi belirsiz ifadeler kapsam kaymasını durdurmaz çünkü spesifik bir isteği engellemez.
Kimin değişiklikleri onayladığını, geri bildirimlerin ne kadar sürede döneceğini ve isteklere nasıl bakılacağını yazın. Yavaş geri dönüş gerçek bir kısıtlamadır çünkü güvenle iterasyon yapma kapasitenizi etkiler.
Bunları açık sorular olarak listeleyin; her birinin bir sahibi ve son teslim tarihi olsun. Etkilenen alan inşa edilene kadar başlamayın. Eğer başlamak zorundaysanız, kullandığınız varsayımı açıkça not edin ki sonradan karışıklık olmasın.
Planlama aşamasında kısıtları ve yapılmayacakları kilitleyerek ilk taslağın yığını, bölge ve kapsamla uyumlu olmasını sağlayın. Öncelikler değişirse, anlık geri alma (snapshots/rollback) gibi özellikler stabil bir temel kaybetmeden deneme yapmanıza yardımcı olur; gerektiğinde kaynak kodu dışa aktarmak taşıma veya devretme için kolaylık sağlar.