Konseptten Proje Planına — Yoğunlaştır, Sına, Yinele

İyi bir konsept neyin anlamlı olabileceğini açıklar. Sağlam bir proje planı ise sırada ne yapılacağına, ilerlemenin nasıl anlaşılacağına ve hangi varsayımın ne zaman yeniden sınanacağına karar verir.

İyi bir fikir ile iyi bir proje planı arasında yalnızca biçim farkı yoktur. Bir konsept ikna edici olabilir, birçok olasılık içerebilir ve yine de güvenilir uygulamayı yönlendirmek için fazla açık kalabilir. Proje planının görevi bu açıklığı azaltmaktır. Hedefleri kararlara, varsayımları sınamalara, bağımlılıkları sıraya ve riskleri somut tepkilere çevirir.

Birçok yapay zekâ projesi tam bu geçişte kırılganlaşır. Araştırma kapsamlıdır, konsept makul görünür ve sıradaki talimat şudur: "Şimdi bundan bir proje planı üret." Sonuç çoğu zaman uzun bir faz, görev ve tarih listesidir. Planlama gibi görünür; fakat henüz güvenilir bir proje mimarisi değildir. Plan ancak ilk taslağın kendisi de eleştirilip sınandığında sağlamlaşır.

Uygulama açık bir gelişim gösterir. Önce konsept problem alanı, araştırma, gereksinimler, alternatifler, mimari ve makullük kontrolü üzerinden metodik biçimde kurulur. Ardından bu konsept hedef, kapsam, gereksinimler, uygulanabilirlik, kaynaklar, risk, raporlama, uygulama ve değerlendirme mantığına bağlanır. Daha sonraki adımda ilk plan nihai cevap sayılmaz; kaynaklara, yöntem bilgisine ve gerçek yürütme biçimine göre kontrol edilir ve yeniden düzenlenir.

Temel bakış açısı şudur: Proje planı konseptin uzatılmış metni değildir. Konseptin nasıl uygulanacağına dair sınanabilir bir karardır.

Konsept ve plan farklı sorular sorar

Konsept şu sorulara odaklanır: Hangi problemi çözüyoruz? Çözüm kimin için? Hangi gereksinimler doğuyor? Hangi varyantlar mümkün? Hangi mimari makul?

Proje planı ise şunları sorar: Gerçekte ne yapılacak? Neler açıkça kapsam dışında? Önce hangi varsayımlar sınanmalı? Daha fazla yatırım yapmadan önce hangi kanıtlar gerekli? Hangi işler paralel ilerleyebilir? Hangi risk planı değiştirir? Kararı kim veya hangi sistem verebilir? İnsan ne zaman devreye girmeli?

Bu ayrım önemlidir. Konsept ilgili olasılıkları görünür kılmalıdır; plan ise onları azaltmalıdır. Konsept alternatifler taşıyabilir. Plan tüm alternatifleri aynı anda yürütemez. Önce hangi hipotezin test edileceğine ve hangi seçeneklerin bekletileceğine karar vermelidir.

İlk yoğunlaştırma adımı budur: olasılıklar önceliğe dönüşür.

Yoğunlaştırmak kısaltmak değil, karar vermektir

Bir plan yalnızca kısa olduğu için iyi olmaz. Yoğunlaştırma, konseptteki önemli her ifadenin operasyonel bir sonucu olması ya da açık bir varsayım olarak işaretlenmesi demektir.

Konseptte küçük ekipler için son derece kolay kullanılabilir bir uygulama hedeflendiğini düşünelim. Plan bunu yalnızca "kullanıcı dostu arayüz geliştir" görevine çevirmemelidir. Gereksinimin nasıl sınanacağına karar vermelidir: örneğin tek bir minimum kullanıcı yolunu tanımlamak, beş tipik görevi test etmek ve bu yol çalışmadan özellik eklememek.

"Güvenli olmalı" ifadesi "güvenlik uygula" görevine dönüşmemelidir; sınanabilir gereksinimler, sorumluluklar ve durdurma koşulları üretmelidir. "Ölçeklenebilir olmalı" ifadesi de beklenen yük ve eşikler bilinmeden büyük bir altyapı yatırımı anlamına gelmemelidir.

Dönüşüm zinciri şöyledir: Konsept ifadesi → planlama kararı → test ölçütü → sonraki eylem.

Bu zincir ne kadar görünürse, hassas görünen fakat karar değeri düşük görev listelerine o kadar az yer kalır.

Baseline: Bu proje şu anda neyi temsil ediyor?

Görev üretmeden önce bir baseline gerekir. Yöntem eşlemesinde bu mantık hedef tanımı, scope/non-scope ve kısa proje özeti olarak görünür.

İyi bir baseline en az altı soruya cevap verir:

1. Proje hangi sonucu üretmeli?

2. Kimin için?

3. Neler açıkça kapsama dahil?

4. Neler açıkça kapsam dışında?

5. Hangi varsayımlar çökerse plan temel olarak değişir?

6. Sonraki faza geçmeyi hangi kanıt haklı çıkarır?

Non-scope dipnot değildir. Özellikle üretken yapay zekâ sistemleri sürekli yeni fikirler önerdiği için, net bir proje birkaç konuşmada ek özellikler koleksiyonuna dönüşebilir. Baseline gelişimi engellemez; gelişimin bilinçli bir değişiklik mi yoksa fark edilmeden büyüyen kapsam mı olduğunu görünür kılar.

Slice: Tamamlanmadan önce taşınabilirliği kanıtla

Baseline sonrasında, konseptin gerçekten taşıyıp taşımadığını gösterecek en küçük bütünlüklü parça belirlenir. Yöntem eşlemesinde buna Slice denir: taşıma testi, vertical slice ve uygulanabilirlik boşlukları.

Slice yalnızca teknik prototip değildir. En riskli varsayımları mümkün olduğunca erken sınamalıdır. Yapay zekâ destekli bir danışmanlık ürününde slice, tüm platformu kurmak olmayabilir. Müşteri girdisinden yapay zekâ analizine ve insan tarafından onaylanan öneriye kadar tek bir uçtan uca akışı çalıştırmak olabilir.

Ana soru şudur: Hangi küçük ama bütünlüklü deneyim, mimarinin temel olarak çalıştığını gösterebilir?

Bu yaklaşım, çekirdek varsayım kanıtlanmadan haftalarca özellik geliştirilmesini önler. Varsayım daha sonra çökerse proje verimli yürütülmüş olabilir; ama kötü yönetilmiştir.

Flow: İşi öğrenme bağımlılıklarına göre sırala

Klasik planlar işi çoğu zaman üretim zinciri gibi görür. Yapay zekâ projelerinde bazı işler yalnızca çıktı değil, sonraki adımı değiştiren yeni bilgi üretir.

Bu nedenle Flow yalnızca görev sırası değil, öğrenme sırasıdır. Bir sonraki kararın anlamlı olması için önce hangi soru yanıtlanmalı? Aynı sınanmamış varsayıma bağlı işler gereksiz yere paralel mi gidiyor? Hangi noktada review gerekir? Çok sayıda yarım işin dikkati bölmemesi için nerede WIP sınırı gerekir?

Yararlı bir akış şöyle özetlenebilir: Varsayım → test → kanıt → karar → sonraki iş bloğu.

Ajanlar ve otomasyonlar devreye girdiğinde bu daha da önemlidir. Ajan çok iş üretebilir. Sıra yanlışsa yalnızca yanlış işi daha hızlı üretir.

İlk proje planı bir hipotezdir

Uygulamadaki önemli örneklerden biri ilk planın hazırlanması değil, reddedilmesidir. Gerçek bir vakada konsept ve kaynaklardan uzun, klasik bir yol haritası üretildi; ancak gerçek uygulama biçimine uymadığı için kabul edilmedi. Roller, zaman mantığı, otomasyon ve insan kontrol noktaları yeniden düşünülmek zorunda kaldı.

Metodik ders nettir: Bir plan biçimsel olarak eksiksiz olup kavramsal olarak yanlış olabilir.

İlk planı hipotez olarak ele almak gerekir. Plan şunu iddia eder:

• bu sıra mantıklıdır,

• bu rol dağılımı çalışır,

• bu süre varsayımları gerçekçidir,

• bağımlılıklar yeterince bilinmektedir,

• riskler kontrol altındadır,

• kontrol noktaları yeterlidir.

Bunların herhangi biri yanlış olabilir. Planlama belirsizliği gizlemek değil, sınanabilir hâle getirmektir.

Yalnızca sezgiyle değil, kaynaklarla karşılaştır

İlk taslaktan sonra kalite çalışması başlar. Plan; konsept, araştırma temeli ve tekrar kullanılabilir yöntemlerle karşılaştırılır.

Üç kontrol katmanı özellikle yararlıdır:

Konsept sadakati: Plan gerçekten konsept gereksinimlerini mi uyguluyor, yoksa önemli hedefleri daha kolay planlanan görevlerle mi değiştirdi?

Kanıt sadakati: Hangi kararlar araştırmayla destekleniyor, hangileri modelin veya ekibin makul varsayımı olarak kalıyor?

Yöntem sadakati: Non-scope, uygulanabilirlik testi, review ritmi, risk tetikleyicisi ya da durdurma koşulu gibi tekrar eden koruyucular eksik mi?

Böylece önceki makalelerle bağlantı kurulur: bilgi tabanı yalnızca arşiv değildir; yöntem eşleme yalnızca iyi uygulamaları kaydetmek değildir. Her ikisi de somut planı sınamak için kullanılır.

Sınamak, aşırı planlamayı da fark etmektir

Yapay zekâ yeni bir aşırı planlama biçimini cazip hâle getirir. Model saniyeler içinde yüzlerce görev ve bağımlılık üretebildiği için ayrıntı kalite gibi algılanabilir. Oysa ayrıntı bazen belirsizliği gizler.

Bir plan, henüz kanıt olmayan kararları kesinleştirdiğinde aşırı planlanmıştır. Tipik işaretler:

• slice gereksinimi kanıtlamadan mimari kararı vermek,

• önkoşulları belirsiz fazlara ayrıntılı takvim yazmak,

• rolleri standart şablondan kopyalamak,

• aynı açık varsayıma dayanan çok sayıda işi paralelleştirmek,

• review veya stop gate olmadan büyük uygulama paketleri tanımlamak.

Sonraki ince ayar aşamasında uygulanabilir workflow ile teknik prototipin ayrılması bu nedenle önemlidir. Teknoloji, değeri destekleyen kanıt bulunduğunda uygulanmalıdır. Bu inovasyonu yavaşlatmak değil, teknik mümkünlük ile proje değerini karıştırmamaktır.

Yineleme, planın değişmesine izin vermektir

Değişemeyen plan çoğu zaman dondurulmuş bir varsayımdır. Yinelemeli planlama her hafta her şeyi yeniden yazmak değildir. Kararlı katmanlarla değişebilir katmanları ayırmaktır.

Amaç, sorumluluk mantığı, kalite kriterleri ve kaydedilmiş kararlar daha kararlı kalmalıdır. Sıralama, teknik uygulama, detay görevler, süreler ve hatta bazı çözüm varyantları yeni kanıtla değişebilir.

Rolling Waves yaklaşımı burada uygundur: sıradaki bölüm ayrıntılı planlanır, daha ilerideki bölümler daha kaba tutulur. Yeni bilgi geldikçe bir sonraki dalga somutlaşır.

Böylece kesinlik hak edildiği yerde kullanılır; gerçek belirsizliğin olduğu yerde esneklik korunur.

Gates takvim olayı değil, karar eşiğidir

Gate bir faz sonu toplantısı değildir. Önceden tanımlanmış kanıtla verilen karar eşiğidir. İyi bir gate dört sonuçtan birini üretebilir:

• devam: kanıt sonraki adımı destekler,

• yeniden çalışma: yön doğru, ama boşluklar kapanmalı,

• yeniden planlama: varsayım çöktü ve mimari değişmeli,

• durdurma: maliyet, risk veya değer devamı haklı çıkarmıyor.

Bu netlik agentik uygulamada kritik hâle gelir. Gate yoksa sistem yanlış yönde çok verimli çalışabilir. Gate varsa her adımı mikro yönetmeden özerklik sınırlandırılabilir.

Makale 07 bu bağlantıyı derinleştirecek: proje planlaması agentik yapay zekâyı neden gerçekten yönetilebilir hâle getirir? Makale 06'nın görevi temeli kurmaktır: karar ve kontrol noktaları planın içinde görünür olmalıdır.

İyi plan hem okunabilir hem yürütülebilir

Planın iki hedef kitlesi vardır. İnsanlar yapının neden böyle olduğunu anlamalıdır. Uygulayıcılar — insanlar, ekipler, otomasyonlar veya ajanlar — ne yapacaklarını bilmelidir.

Her önemli iş bloğu en az şu öğeleri taşımalıdır:

Hedef: Hangi durum elde edilmeli?

Girdi: Hangi bilgi veya önkoşul gerekli?

Eylem: Hangi iş yapılacak?

Çıktı: Hangi somut sonuç oluşacak?

Kontrol: Yeterli kalite nasıl anlaşılacak?

Karar: Sonraki adımı kim veya ne serbest bırakacak?

Fallback: Kontrol başarısız olursa ne olacak?

Bu yapı görev listesini küçük karar birimlerine dönüştürür. Birlikte yalnızca projeyi anlatan değil, onu yöneten bir plan oluştururlar.

Geçişte yedi tipik hata

1. Konsept yalnızca görevlere bölünür. Karar ve doğrulama ölçütleri eksiktir.

2. Tüm fikirler kapsama alınır. Plan öncelik vermez, biriktirir.

3. En riskli varsayım geç test edilir. Gerçek uygulanabilirlik kanıtından önce çok iş yapılır.

4. Takvimler alışkanlıktan kopyalanır. Gerçek ekip, otomasyon ve yürütme modeli dikkate alınmaz.

5. Ayrıntı kanıtın yerini alır. Plan kesin görünürken önemli önkoşullar belirsizdir.

6. Review toplantıdır, karar değildir. Devam, yeniden çalışma, yeniden planlama veya durdurma kriterleri yoktur.

7. Plan onaydan sonra öğrenmeyi bırakır. Yeni bilgi kaydedilir ama planı değiştirmez.

Planlama döngüsü

KONSEPT
  ↓
BASELINE: hedef, scope, non-scope, varsayımlar
  ↓
SLICE: en riskli varsayımları erken sına
  ↓
FLOW: işi öğrenme bağımlılıklarına göre sırala
  ↓
PLAN TASLAĞI
  ↓
KARŞI KONTROL: konsept + kaynaklar + yöntem bilgisi
  ↓
GATE VE KRİTERLERİ KESKİNLEŞTİR
  ↓
SONRAKİ PLANLAMA DALGASI
  ↺

Döngü bir belge bittiği için sona ermez. Bir faz için, sorumlu biçimde ilerlemeye yetecek kanıt oluştuğunda duraklar.

Onaydan önce sekiz soru

1. İstenen sonuç, faaliyet listesinden daha net mi?

2. Scope ve non-scope açık mı?

3. En riskli varsayım yeterince erken test ediliyor mu?

4. Taşınabilirliği gösterecek küçük ama bütünlüklü bir slice var mı?

5. Bağımlılıklar alışkanlığa değil öğrenme mantığına göre mi sıralı?

6. Her önemli gate için önceden tanımlı ölçüt var mı?

7. Planın hangi bölümleri kanıta dayanıyor, hangileri hâlâ hipotez?

8. Planın ne zaman ve neden değişmesi gerektiği açık mı?

Bu sorular yanıtlanamıyorsa çözüm çoğu zaman "daha çok ayrıntı" değildir. Daha iyi bir planlama kararı gerekir.

Planlama kontrollü yoğunlaştırmadır

Konseptten proje planına geçiş, fikir ile uygulama arasındaki idari köprü değildir. Projenin her şeyi biliyormuş gibi davranmadan kendini bağladığı andır.

İyi konsept olasılıkları açık tutar. İyi plan onları sorumlu biçimde azaltır. Önce hangi varsayımın sınanacağını, hangi işin onu izleyeceğini, hangi kanıtın gerektiğini ve sonraki kararın ne zaman doğacağını belirler.

Bu nedenle plan kalitesi görev sayısıyla ölçülmez. Kalite, belirsizliği sınanabilir kararlara ne kadar iyi dönüştürdüğüyle ölçülür.

Bu aynı zamanda AI Project Engineering'in bir sonraki aşamasının temelidir: ancak bu yapıya sahip bir plan varsa agentik yapay zekâya anlamlı özerklik verilebilir.

İndirilecek tüm materyaller — konu özeti ve çalışma kâğıdı: