Yeniden çalışmayı engelleyen spesifikasyon kısıtları ve yapılmayacaklar

Neden kısıtlar atlanmış spesifikasyonlar yeniden çalışmaya yol açar

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:

• Neler sabit (son tarih, bütçe, ekip, inceleme düzeni)?
• Teknik olarak neler sabit (yığın, barındırma, veri konumu)?
• Uygulamanın ne yapmaması gerekiyor (yapılmayacaklar)?
• Tüm planı yeniden açmadan neler değişebilir?

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 vs yapılmayacaklar: bir dakikada fark

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 sayılanlar nelerdir

Kısıt, gerçek bir karar alınmadan değişmeyecek olan zorunluluktur.

Örnekler:

• “6 haftada lansman yapmamız gerekiyor.”
• “Bütçe 15.000$ ile sınırlı.”
• “Veri ikametgahı için sadece AB'de çalışmalı.”
• “Frontend React, backend Go, veritabanı PostgreSQL olmalı.”

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ılmayacaklar sayılanlar nelerdir

Yapılmayacak, açıkça “bunu yapmıyoruz” demektir; faydalı gibi görünse bile. İlk sürümü korur.

Örnekler:

• “v1'de mobil uygulama yapılmayacak; sadece web.”
• “Lansmanda çoklu dil desteği yok.”
• “Gerçek zamanlı sohbet yok; e-posta bildirimleri yeterli.”

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.

Bir cümle ile başla ve küçük başarı tanımı ekle

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:

• “Bağımsız eğitmenler için öğrencilerin ders rezervasyonu yapıp hatırlatıcı almasını sağlayan basit bir web uygulaması.”
• “Küçük bir klinik için personelin bugünkü randevuları kontrol edip temel ziyaret notu girebildiği mobil uygulama.”

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:

• Bir eğitmen haftalık müsait zamanlarını birkaç dakikada ayarlayabilir.
• Bir öğrenci aramaya veya e-postaya gerek kalmadan seans rezervasyonu yapabilir.
• Her iki taraf da onay ve hatırlatma alır.
• Eğitmen telefon ve dizüstünde net bir günlük takvim görebilir.

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.

Sabit proje kısıtlarını yazın (zaman, bütçe, kişiler)

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:

• Son tarih ve kilometre taşları: lansman tarihi ve 2–3 kontrol noktası (spec onayı, prototip onayı, ilk sürüm hazır). İlk sürüme nelerin dahil olduğunu belirtin.
• Bütçe: sert bir üst sınır mı yoksa hedef aralığı mı. Nelerin dahil olduğunu söyleyin (geliştirme, tasarım, test, barındırma, destek) ki sonra yeniden tartışmayın.
• Kişiler ve kullanılabilir zaman: kim inceleme yapıyor ve ne kadar hızlı cevap veriyor. Yavaş geri bildirim gerçek bir kısıtlamadır.
• Karar sahibi: takaslar çıktığında evet veya hayır diyebilecek kişi.

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”.

Sabit teknik kısıtları yazın (yığın ve barındırma)

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.

Yığını kilitleyin (gerçekten değişmeyecekleri)

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:

• Web/UI: X kullanılmalı (neden), veya X/Y kullanılabilir (karar sahibi)
• Backend: X olmalı (neden) ve belirli bir API stili sunmalı (REST veya GraphQL)
• Veritabanı: X olmalı ve çok kiracılılık şimdi gerekli mi
• Mobil: native/Flutter olmalı veya “v1'de yok”
• Geliştirme ve teslim: kaynak kodu dışa aktarımı gerekiyor mu, gerekli ortamlar (dev/stage/prod)

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, bölgeler ve veri kuralları (düz dil)

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.

Kapsamı korumak için yapılmayacaklar ekleyin

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.

İlk sürümde ne inşa edilmeyecek

İnsanların genelde içinde olduğunu varsaydığı özelliklerle başlayın. Basit bir rezervasyon uygulaması için örnek:

• v1'de yönetici portalı yok (sadece temel personel araçları)
• v1'de çoklu dil veya lokalleştirme yok
• Çevrimdışı mod veya senkronizasyon yok
• Karmaşık paneller yok (sadece basit haftalık özet)
• v1'de entegrasyonlar yok (ödeme, takvim, e-posta araçları)

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.

Ne için optimize etmeyecek veya neyi desteklemeyeceksiniz

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)”.

Her şeyi yeniden açmadan nelerin değişebileceğine karar verin

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ışı:

• Herkes öneride bulunabilir, ama bir onay sahibi vardır.
• Değişiklikler belirlenmiş bir düzende (günlük veya haftalık) gözden geçirilir.
• Her onaylanan değişiklik tek cümleyle spes'e yazılır.
• Bir değişiklik zaman ya da maliyeti etkiliyorsa bir takas sunulmalıdır.

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.”

Spes'inize kopyalayabileceğiniz adım adım format

İ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.

Kopyala/yapıştır formatı (boşlukları doldurun)

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ı.)

Hızlı bitirme için 5 adımlı iş akışı

1. İlk önce tek cümleyi ve üç sonucu yazın. Bunları bitiremiyorsanız, özellikleri belirlemeye hazır değilsiniz.
2. Sabit kısıtları doldurun: son tarih, bütçe, ekip, yığın ve barındırma bölgesi.
3. Koruyucu olmak için yapılmayacakları ekleyin. “Yapma” listesini yazın.
4. Açık soruları sahibini belirterek listeleyin.
5. 15 dakikalık kısa bir inceleme yapın, sonra versiyonu kilitleyin. Bundan sonra değişiklikleri gündelik editler yerine yeni talepler olarak ele alın.

Sonrasında sürprizlere yol açan yaygın tuzaklar

Ç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.

Bu tuzakları önlemenin hızlı yolları

Spesinize kısa bir not ekleyin ve beş noktayı cevaplayın:

• Neler sabit (son tarih, bütçe aralığı ve kimin inşa ettiği)
• Teknik olarak neler sabit (yığın, barındırma, zorunlu güvenlik kuralları)
• Açıkça neler dahil değil (3–5 net yapılmayacak)
• İlk sürüm için “bitti” ne demek (bir ölçülebilir sonuç)
• Tüm spes'i yeniden açmadan nelerin değişmesine izin var

Herhangi bir kod üretmeden önce hızlı kontrol listesi ve sonraki adımlar

İnşa başlamadan önce “ne sabit?” sorularına uzun bir dokümanı karıştırmadan yanıt verebilmelisiniz.

Hızlı kontrol:

• Son tarih, bütçe aralığı ve kimlerin (veya kimin olmadığını) çalışabileceğini bulabiliyor musunuz?
• Teknik seçimler sabit olarak yazılmış mı, reddedilen teknolojiler belirtilmiş mi?
• Barındırma açıkça belirtilmiş mi, bölge ve basit veri kuralları (veri nerede kalmalı, hangi sınırlar geçilemez) net mi?
• Kapsam kaymasını engelleyen kısa bir yapılmayacaklar listesi var mı?
• Nelerin değişebileceği ve değişiklikleri kimin onaylayacağı net mi?

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:

1. Kısıtları ve yapılmayacakları özelliklerden önce spes'in en üstüne koyun.
2. Değişiklikleri onaylayacak kişilerle kısa bir planlama turu yapın. Yapılmayacakları yüksek sesle onaylayın; sessizlik genellikle anlaşmazlık demektir.
3. İlk versiyonu küçük yinelemelerle inşa edin, sonra öğrendikçe spes'i sıkılaştırın.

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.