Konudan problem alanına — Bir fikir nasıl çalışılabilir bir proje sorusuna dönüşür?
İyi yapay zekâ projeleri neden bir çözümle değil, anlamaya yetecek kadar geniş ve çalışmaya yetecek kadar sınırlı bir problem alanıyla başlar?

Birçok proje yön veriyormuş gibi görünen bir cümleyle başlar: "Bir uygulama yapmak istiyorum." "Şirkette yapay zekâ kullanmak istiyoruz." "Otomatik bir sisteme ihtiyacım var." "Portföyümü yeniden kurmak istiyorum." Bu cümleler önemlidir; çünkü enerji ve hareket yaratırlar. Ama sağlam proje çalışması için henüz yeterli değildirler.
Bir fikir aynı anda üç farklı şeyi taşıyabilir: algılanan bir problem, istenen bir gelecek durumu ve zaten tercih edilmiş bir çözüm. Asıl risk bu karışımdadır. Çözüm çok erken sabitlenirse, sonraki araştırma kolayca zaten yapmak istediğimiz şeyi doğrulayan bir faaliyete dönüşür. Problem fazla geniş tanımlanırsa proje olasılıklar içinde kaybolur. Fazla dar tanımlanırsa da önemli alternatifler daha görülmeden dışarıda bırakılır.
Kanıtlanmış bir metodoloji bu nedenle konsept ve proje planından önce ayrı bir çalışma adımı koyar: Başlangıç sorusu önce bir problem alanına dönüştürülür. Ancak bundan sonra araştırma, gereksinimler, fikir alanı, varyant değerlendirmesi, mimari taslak, makullük kontrolü ve sonunda konsept gelir.
Problem alanı bu yüzden akademik bir ara egzersiz değildir. Projenin gerçekte hangi dünyaya bakacağını belirlediğimiz yerdir.
Bir konu henüz proje sorusu değildir
"Müşteri hizmetlerinde yapay zekâ" bir konudur. "Müşteri hizmetleri için yerel yapay zekâ" artık bir çözüm yönüdür. "Destek ekibimiz tekrarlanan müşteri sorularını, hassas müşteri verilerini gereksiz yere dış sistemlere göndermeden nasıl daha hızlı yanıtlayabilir?" ise çalışılabilir bir proje sorusudur.
Fark uzunlukta değil, yapıda bulunur.
Konu bir alanı adlandırır. Fikir çoğu zaman buna bir niyet ekler. Proje sorusu ise somut bir değişimi, bağlamı ve araştırılması gereken noktayı tanımlar. Birden fazla çözümü açık bırakırken bilgi toplamaya yetecek kadar belirgindir.
Bu ayrım yapay zekâ ile çalışırken özellikle önemlidir. Dil modelleri çözüm yönlendirmelerine çok iyi tepki verir. "X için bir yapay zekâ uygulaması" isterseniz kısa sürede bir uygulama mimarisi alırsınız. "Y için bir ajan" isterseniz bir ajan tasarımı gelir. Bu yararlı olabilir — fakat ancak uygulama ya da ajanın gerçekten doğru form olup olmadığı daha önce netleşmişse.
Çalışılabilir proje sorusu bu nedenle tipik bir hataya karşı koruma sağlar: İlk fikrin biçimi otomatik olarak asıl problem kabul edilmez.
Problem alanı ilk çözümden daha büyüktür
Problem alanı, karar için önemli olabilecek koşulları, gerilimleri ve açık soruları içerir. Bilinçli olarak daha sonra seçilecek çözümden geniş tutulur.
Örneğin bir kişi "sosyal medya için yapay zekâ ajanı" istiyor olsun. Çok erken proje planlaması hemen görevler üretebilir: platformları bağla, paylaşım takvimi oluştur, prompt kütüphanesi kur, onayları otomatikleştir. Oysa gerçek problem alanı bambaşka olabilir:
• Sorun içerik eksikliği değil, net konumlandırma eksikliği olabilir.
• Sorun otomasyon eksikliği değil, güvenilir kalite kontrolünün olmaması olabilir.
• Sorun hız değil, tutarsız kaynaklar olabilir.
• Sorun fikir eksikliği değil, ham malzemeyi marka uyumlu içeriklere dönüştüren iş akışının olmaması olabilir.
• Hukuki, organizasyonel veya itibari sınırlar tam otomasyonu zaten anlamsız kılabilir.
Bu farklar görünür hâle geldiğinde anlamlı soru ortaya çıkar: Tam olarak ne iyileşmeli, kim için, hangi koşullarda ve daha sonra bu iyileşmenin gerçekleştiğini nasıl anlayacağız?
Problem alanı yaratıcılığı bastırmaz. Yaratıcılığa yön verir.
Başlangıç sorusu: İlk işe yarar kesit
Konsept zinciri bir başlangıç sorusuyla başlar. Bu sorunun kusursuz olması gerekmez. İlk görevi, projenin yalnızca bir ürün isteği olarak tanımlanmasını önlemektir.
İyi bir başlangıç sorusu mümkün olduğunca az çözüm ve mümkün olduğunca çok gözlem içerir. "Şirketim için nasıl bir yapay zekâ ajanı kurarım?" yerine "Hangi tekrarlanan iş akışları bugün ciddi zaman tüketiyor ve bunların hangileri kabul edilebilir riskle kısmen otomatikleştirilebilir?" daha güçlü bir başlangıçtır.
İkinci formülasyon daha fazla anlamlı yolu açık tutar. Belki daha sonra ajan en iyi çözüm olur. Belki küçük bir otomasyon yeterlidir. Belki asıl sorun veri kalitesidir. Belki yeni yazılımdan önce süreç değişikliği gerekir.
Başlangıç sorusunun amacı doğru yolu anında söylemek değildir. Doğru araştırmayı başlatmaktır.
Bir cümleden problem alanına
Bir başlangıç sorusu ancak farklı perspektiflere ayrıldığında problem alanına dönüşür. Bunun için beş boyut özellikle kullanışlıdır.
1. Etkilenen kişiler
Problemi günlük hayatta kim yaşıyor? Sonuçla kim çalışacak? Kim onay vermek zorunda? Çözüm başarısız olursa kim olumsuz etkilenir?
Projeyi sipariş eden kişi, problemi günlük işte yaşayan kişiyle aynı olmayabilir. Bu fark gereksinimleri kökten değiştirebilir.
2. Mevcut durum
Bugün somut olarak ne oluyor? Gecikmeler, hatalar, sürtünme, maliyet veya belirsizlik nerede oluşuyor? Hangi geçici çözümler zaten kullanılıyor?
Mevcut durum yapay zekâdan söz etmeden açıklanabilmelidir. Bu iyi bir testtir. Problem sadece istenen teknoloji üzerinden anlatılabiliyorsa çoğu zaman henüz temiz biçimde tanımlanmamıştır.
3. Değişim hedefi
Projeden sonra ne farklı olmalı? Daha hızlı mı? Daha ucuz mu? Daha güvenli mi? Daha anlaşılır mı? Daha tutarlı mı? Daha ölçeklenebilir mi? Daha yaratıcı mı? Belirli kişilere daha az bağımlı mı?
Değişim hedefi çözüm değildir. Birden fazla varyantla ulaşılabilecek yönü tarif eder.
4. Çerçeve koşulları
Hangi kaynaklar, süreler, sistemler, yetkinlikler, veri kümeleri, sorumluluklar ve bağımlılıklar zaten var?
Çerçeve koşulları rahatsız edici engeller değildir. Projeyi gerçek kılarlar.
5. Sınırlar
Problemin açıkça hangi kısmı bu projenin dışında? Bu aşamada ne çözülmeyecek? Hangi kararlar bilinçli biçimde sonraya bırakılacak?
Sınır olmadan problem alanı kolayca dünyanın genel açıklamasına dönüşür. Sınırla birlikte çalışılabilir hâle gelir.
İyi sorular aynı anda hem açar hem sınırlar
Bu ilk bakışta çelişkili görünür. İyi bir proje sorusu, ilk çözüm daha baştan sabitlenmeyecek kadar açık olmalıdır. Aynı zamanda araştırma ve planlama keyfîleşmeyecek kadar dar olmalıdır.
Bunun için iki hareket gerekir.
İlk hareket ıraksamadır: Konuyu açarız. Gözlenen problemi başka hangi nedenler açıklayabilir? Hangi paydaşlar farklı görür? Hangi alternatifler var? İlk fikrin içinde hangi varsayımlar gizli?
İkinci hareket yakınsamadır: Alanı sınırlarız. Bu proje için hangi alt soru belirleyici? Hangi perspektifler gerçekten gerekli? Hangi koşullar pazarlık konusu değil? Neyi bilinçli biçimde dışarıda bırakıyoruz?
İyi bir problem alanında her iki hareket de gerçekleşmiştir. Sadece açılmak sonsuz analize, sadece daralmak tünel görüşüne yol açar.
Gizli kesinlikler yerine hipotezler
Birçok proje fikri, aslında varsayım olan ifadeleri gerçekmiş gibi kullanır.
"Müşterilerimiz chatbot istiyor."
"Çalışanlar manuel araştırmada çok fazla zaman kaybediyor."
"Yerel model daha ucuz olur."
"Otomasyon kaliteyi artıracak."
Bu cümlelerin hepsi doğru olabilir. Ama sınanmadan önce hipotez olarak ele alınmalıdır.
Bu önemli bir yöntem farkıdır. Hipotezin yanlış çıkmasına izin vardır. Gizli kesinlik ise bütün projeyi doğrulama yönünde iter.
Problem alanı için küçük bir hipotez listesi yararlı olur:
# HİPOTEZLER
H1: Gözlenen problem bir projeyi haklı çıkaracak kadar sık oluşuyor.
H2: Varsaydığımız neden gerçekten önemli.
H3: Etkilenen kişiler problemi benzer biçimde yaşıyor.
H4: Teknik bir müdahale durumu iyileştirebilir.
H5: İyileşme ölçülebilir ya da en azından izlenebilir biçimde değerlendirilebilir.Bu liste proje çalışmasını bilimsel araştırmaya dönüştürmez. Sadece hangi ifadelerin henüz sınanması gerektiğini görünür yapar.
Varsayım, bilgi ve açık soruları ayır
Etkili adımlardan biri problem alanını üç sütuna bölmektir:
Biliyoruz: Gözlem, veri veya güvenilir kaynaklarla zaten desteklenen noktalar.
Varsayıyoruz: Makul görünen fakat henüz kontrol edilmemiş noktalar.
Öğrenmemiz gerekiyor: Daha sonraki karar için eksik olan bilgiler.
Bu ayrım uzun bir yapay zekâ çıktısının kanıtlanmış bilgi gibi kullanılmasını önler. Aynı zamanda serinin 3. makalesine doğrudan geçiş hazırlar: Deep Research artık genel bir "her şeyi araştır" komutu değil, somut bilgi boşluklarının hedefli biçimde işlenmesidir.
Böylece önemli bir sıra oluşur: Problem alanı araştırmanın cevaplaması gereken soruları tanımlar. Araştırma sonradan geriye dönük biçimde hangi probleme sahip olmak istediğimizi belirlememelidir.
Odak, dışarıda bıraktıklarımızla oluşur
Bir proje yalnızca içine aldıklarıyla değil, bilinçli olarak dışarıda bıraktıklarıyla netleşir.
Örneğin Non-Scope şu şekilde olabilir:
• şirketin tamamının otomasyonu yok;
• tüm eski sistemlerin taşınması yok;
• onaysız otonom yayın yok;
• yeni marka stratejisi yok;
• ilk prototipte özel teknik geliştirme yok;
• konsept aşamasında nihai sağlayıcı kararı yok.
Bu dışlamalar zayıflık değildir. Projenin öğrenme değerini korur.
Aynı anda çok fazla problem çözülürse daha sonra neyin neden çalıştığını veya neden başarısız olduğunu anlamak güçleşir. Net bir kapsam ise neden-sonuç ilişkisini daha görünür yapar.
Problem tanımından proje sorusuna
Bu çalışmanın sonunda problem alanı beş özelliği taşıyan bir soruya yoğunlaştırılmalıdır.
Bağlama bağlıdır
Değişimin hangi ortamda gerçekleşeceğini söyler.
Çözüm açısından açıktır
Cümle daha baştan uygulama, ajan, model, platform veya sağlayıcıyı zorunlu kılmaz.
Bir değişim isteği içerir
Neyin iyileşmesi gerektiği anlaşılır.
Sınanabilir
Daha sonra bir varyantın soruyu ikna edici biçimde cevaplayıp cevaplamadığı değerlendirilebilir.
Sınırlıdır
Soru mevcut proje içinde ele alınabilecek kapsamı taşır.
Pratik formül şöyledir:
[Mevcut durum / problem] durumunu
[etkilenen kişiler / kullanım bağlamı] için
[istenen etki] oluşacak biçimde,
[önemli koşullar] altında,
[kritik istenmeyen etki / non-scope] olmadan
nasıl değiştirebiliriz?Bu formül zorunluluk değildir. Bir testtir. Unsurlar doldurulamıyorsa problem alanı muhtemelen henüz yeterince net değildir.
Örnek: "Bir yapay zekâ uygulaması istiyorum"dan proje sorusuna
Başlangıç fikrimiz şu olsun:
"Müşterilerim için bir yapay zekâ uygulaması geliştirmek istiyorum."
Fikir zaten "uygulama" çözümünü içeriyor; fakat problem hakkında çok az şey söylüyor.
Adım 1: Gözlem
Müşteriler sık sık benzer sorular soruyor ve ekip müsait olmadığında yanıt bekliyor.
Adım 2: Etkilenen kişiler
Müşteriler, destek ekibi ve gerektiğinde karmaşık vakaları devralan uzman birimler.
Adım 3: Hedef
Basit sorular daha hızlı yanıtlanmalı, ama karmaşık danışmanlığın kalitesi düşmemeli.
Adım 4: Varsayımlar
Soruların anlamlı bir bölümünün tekrarlandığını ve güvenilir yanıt kaynaklarının hazırlanabileceğini varsayıyoruz.
Adım 5: Sınırlar
Bireysel sözleşmeler hakkında otonom karar yok; karmaşık durumlarda kişisel danışmanın yerini alma yok.
Yoğunlaştırılmış proje sorusu
"Doğrudan destek saatleri dışında tekrarlanan müşteri sorularını, karmaşık vakaları veya bireysel kararları insan danışmanlığından çıkarmadan nasıl daha hızlı yanıtlayabiliriz?"
Artık uygulama sadece olası varyantlardan biridir. Yöntemsel değer tam olarak burada bulunur.
Yapay zekâ problem alanını genişletebilir — ama ona sahip olmamalıdır
Üretken yapay zekâ kör noktaları bulmak için güçlüdür. Paydaş perspektifleri simüle edebilir, karşı sorular üretebilir, alternatif nedenler önerebilir veya fazla dar problem tanımını eleştirebilir.
Ama yapay zekâ problem alanının sahibi değildir. Organizasyona, örtük deneyim bilgisine veya kararın gerçek sonuçlarına doğrudan erişimi yoktur. Bu nedenle görevi problemi nihai biçimde tanımlamak değil, insanın problemi görünür kılmasına yardım etmektir.
Örneğin şu çalışma soruları yararlıdır:
Proje fikrimin içinde hangi varsayımlar gizli?
Gözlenen problemi açıklayabilecek üç alternatif neden nedir?
Hangi paydaşlar problemimi muhtemelen farklı tarif ederdi?
Formülasyonumda hangi çözümü zaten varsayıyorum?
Bu sorunun dört ila sekiz hafta içinde çalışılabilir olması için hangi sınırlar eksik?
Üç çözüm varyantı arasında karar vermeden önce hangi bilgileri bilmem gerekir?Bu sorular yapay zekâyı kâhin olarak değil, perspektif motoru olarak kullanır.
Problem alanı yaşayan bir çalışma nesnesidir
Yaygın hata, problem tanımını bir kez yazıp bir daha bakmamaktır. Oysa burada kullanılan konsept mantığında geri dönüş döngüleri yöntemin açık bir parçasıdır.
Araştırma, varsayılan nedenin önemsiz olduğunu gösterebilir. Gereksinimler bir çatışmayı görünür yapabilir. Bir varyant kapsamın fazla geniş olduğunu ortaya çıkarabilir. Makullük kontrolü başlangıç sorusunu değiştirebilir.
Bu, yönsüz çalışmak değildir. Tam tersine, değişiklikleri gerekçelendirilebilir hâle getirir.
Bu yüzden iyi bir problem alanının sürümleri olabilir:
• v0.1: ilk problem hipotezi;
• v0.2: paydaş perspektiflerinden sonra;
• v0.3: temel araştırmadan sonra;
• v0.4: gereksinimler ve non-scope sonrasında;
• v1.0: konsept ve varyant çalışması için yeterince stabil.
Böylece "fikrimizi değiştirdik" ifadesi izlenebilir bir öğrenme hareketine dönüşür.
Problem alanı ne zaman yeterince iyidir?
Kusursuz olmayacaktır. Amaç çalışılabilirliktir.
Aşağıdaki sorular cevaplanabiliyorsa problem alanı yeterince olgunlaşmıştır:
• Somut olarak ne gözlüyoruz?
• Kim etkileniyor?
• Ne değişmeli?
• Hangi nedenler sadece hipotez?
• Neyi zaten biliyoruz?
• Karar açısından hangi bilgi boşlukları önemli?
• Hangi sınırlar geçerli?
• Projenin açıkça dışında ne var?
• Bir sonraki araştırmayı hangi proje sorusu yönlendirmeli?
• Daha sonra bu soruyu ikna edici biçimde cevapladığımızı nasıl anlayacağız?
Bu noktalar netse Deep Research hedefli biçimde başlayabilir. Daha önce yapılan ek araştırma çoğu zaman sadece daha fazla malzeme üretir.
Derinlikten önce netlik
Yapay zekâ çok hızlı biçimde çok derine gitmeyi cazip kılar. Dakikalar içinde uzun pazar analizleri, teknik mimariler veya proje planları üretebiliriz. Fakat yanlış soru üzerinde derinlik ilerleme değildir.
Problem alanı bu nedenle dikkat için bir filtredir. Hangi soruların gerçekten önemli, hangilerinin yalnızca ilginç olduğunu belirler.
Asıl üretkenlik, düşünülebilecek her perspektifi araştırmaktan gelmez. Projenin önce hangi belirsizliği azaltması gerektiğini bilmesinden gelir.
Bir sonraki makale tam burada başlar: Deep Research artık tek bir düğme veya uzun bir rapor değil; hedefli sorular, kaynaklar, ara sonuçlar ve takip araştırmalarından oluşan bir zincirdir.
Çalışma kâğıdı: Konudan çalışılabilir proje sorusuna
1. Konunu bir cümlede yaz
Henüz çözümü açıklama. Sadece alanı ve algıladığın değişim ihtiyacını tanımla.
2. Aklına gelen ilk çözümü ayrıca yaz
Bilinçli biçimde ayrı tut. Sonra geri dönebilir; fakat problem alanını domine etmemeli.
3. Mevcut durumu açıkla
Bugün somut olarak ne oluyor? Genel değerlendirmeler yerine gözlenebilir durumlar yaz.
4. Etkilenen kişileri ve perspektifleri belirle
Problemi kim yaşıyor, kim karar veriyor, sonucu kim kullanıyor ve riski kim taşıyor?
5. Bilgi, varsayım ve açık soruları ayır
Üç sütun oluştur. Daha önce gerçek gibi kullandığın varsayımları özellikle işaretle.
6. Üç hipotez formüle et
Projenin anlamlı kalması için hangi varsayımların yeterince doğru çıkması gerekir?
7. Scope ve Non-Scope belirle
Bu proje neyi çözmeli? Neyi açıkça çözmemeli?
8. İki alternatif proje sorusu yaz
Birini biraz daha geniş, diğerini daha dar yaz. Hangisinin daha iyi araştırma ve daha iyi karar üreteceğini karşılaştır.
9. Bir çalışma sorusu seç
Gerekirse şu formülü kullan:
[Mevcut durum / problem] durumunu
[etkilenen kişiler / kullanım bağlamı] için
[istenen etki] oluşacak biçimde,
[önemli koşullar] altında,
[kritik istenmeyen etki / non-scope] olmadan
nasıl değiştirebiliriz?10. İlk bilgi boşluğunu tanımla
Daha fazla planlamaya geçmeden önce hangi tek sorunun araştırılması gerekir?
Yansıtma
Şimdiye kadar çok erken varsaydığım çözüm: _____________________________________________________________
Sınamam gereken en önemli varsayım: _________________________________________________________________
Projeyi sonunda çalışılabilir hâle getiren sınır: ______________________________________________________
İndirilecek tüm materyaller — konu özeti ve çalışma kâğıdı:
0 yorum
● Yorumlar yükleniyor…