AKILTA / PAID DISCOVERY

Karmaşık projelerde geliştirmeye başlamadan önce problemi, kapsamı, bağımlılıkları ve doğru ilk sürümü netleştiriyoruz.

Özel yazılım, SaaS, web, commerce, AI, migration veya entegrasyon işi sabit teklife girecek kadar net değilse discovery ayrı bir çalışma olarak kullanılır. Amaç daha fazla doküman üretmek değil; belirsizliği azaltıp uygulanabilir bir karar ve bounded next step çıkarmaktır.

Discovery uygunluğunu değerlendirelim
UNCERTAINTY MAP01—06
01OUTCOMEİş sonucu
02USERSRol · ihtiyaç
03WORKFLOWAkış · istisna
04DATAKaynak · sahiplik
05DEPENDENCYAPI · provider · access
06DECISIONScope · architecture · next step

Bu bir build sözü veya kesin bütçe/takvim garantisi değildir; teklif vermeden önce hangi bilinmezliklerin çözülmesi gerektiğini gösterir.

01 / WHEN

Scope bilinmiyorsa tahmin üretmek yerine önce karar verilebilir hale getiririz.

01

Birden fazla çözüm yolu varsa

Hazır platform, özel geliştirme, entegrasyon veya süreç değişikliği arasında doğru sınır henüz belli değilse.

02

Mevcut sistem bilinmiyorsa

Legacy yapı, teknik borç, veri modeli, erişim veya provider bağımlılıkları görülmeden değişiklik maliyeti hesaplanamıyorsa.

03

Yeni ürün henüz şekilleniyorsa

SaaS/MVP fikrinde kullanıcı, kritik use case ve ilk sürümün acceptance kriterleri yeterince net değilse.

04

Risk ve entegrasyon yüksekse

Ödeme, kişisel veri, AI, ERP/CRM, migration veya kritik üçüncü taraf sistemleri scope kararını etkiliyorsa.

02 / QUESTIONS

Discovery’nin işi tüm soruları sonsuza kadar cevaplamak değil, build kararını etkileyen soruları çözmektir.

Analiz derinliği proje riskine göre değişir. Gereksiz enterprise planlama yapmadan, maliyet veya mimariyi gerçekten değiştiren bilinmezliklere odaklanırız.

  1. 01Hangi sonucu üretmeli?Kullanıcı ve iş sonucu
  2. 02Kim, ne zaman kullanacak?Rol · izin · context
  3. 03Hangi veri gerekli?Kaynak · kalite · hassasiyet
  4. 04Neye bağlı?API · provider · access
  5. 05Nerede hata maliyeti yüksek?Risk · approval · fallback
  6. 06İlk sürüm ne kadar dar olabilir?Scope · acceptance · learning

03 / OUTPUTS

Çıktı, development’ın başlayıp başlamayacağına ve nasıl başlayacağına karar vermeyi kolaylaştırmalı.

01

Problem & current-state map

İş hedefi, mevcut workflow, aktörler ve kritik sistem yüzeylerinin ortak görünümü.

02

Requirements & acceptance

Karar için yeterli fonksiyonel gereksinimler, kritik edge case ve doğrulanabilir acceptance kriterleri.

03

Architecture options

Uygun platform/özel geliştirme sınırı, entegrasyon yaklaşımı ve önemli trade-off’lar.

04

Risk & dependency register

Erişim, provider, veri, güvenlik/privacy, migration veya operasyon bağımlılıklarının görünür listesi.

05

Bounded implementation plan

İlk release’in sınırı, sıralama mantığı ve sonradan doğrulanacak backlog alanları.

06

Go / change / stop recommendation

Discovery sonucunda her projenin build’e dönüşmesi gerekmez; başka yaklaşım daha doğruysa bu karar da geçerli çıktıdır.

04 / BOUNDARY

Discovery, development işiyle aynı şey değildir.

Discovery’nin amacı build’e yeterli karar zemini oluşturmaktır. Kod, tam UI üretimi, migration, production deployment, hukuki görüş veya formal security audit ancak ayrıca scope edilirse dahil olur. Sonraki build Akilta ile devam etmek zorunda değildir; teslim edilecek çıktı kapsamı teklifte açıkça belirtilir.

DISCOVERYKarar, kapsam, risk, plan
BUILDAyrı uygulama kapsamı
OPERATEAyrı işletim/bakım modeli

05 / PROCESS

Kanıt topla → seçenekleri daralt → karar üret.

  1. 01IntakeHedef · mevcut bilgi
  2. 02Access / evidenceSistem · veri · doküman
  3. 03AnalysisWorkflow · dependency · risk
  4. 04OptionsTrade-off · architecture
  5. 05DecisionScope · acceptance
  6. 06Next stepProposal · phased plan · stop

06 / FIT

Discovery, belirsizlik gerçek kararları etkilediğinde değerlidir.

İyi uyum

  • Birden fazla sistem veya ekip birbirine bağlıysa
  • Özel yazılım / SaaS ilk sürümü belirsizse
  • Migration veya entegrasyon riski scope’u değiştiriyorsa
  • Sabit teklif için kritik bilgi eksikse

Discovery gerekmeyebilir

  • İş küçük, sınırı ve acceptance kriteri zaten netse
  • Teknik bağımlılık veya önemli bilinmezlik yoksa
  • Hazır bir service route ihtiyacı doğrudan karşılıyorsa
  • Amaç yalnız ücretsiz fikir/teklif toplamaksa

07 / COMMERCIAL RULE

Ücret ve kapsam, çözülmesi gereken belirsizliğin derinliğine göre teklif seviyesinde belirlenir.

Discovery ücretli bir profesyonel çalışma olarak konumlanır. Süre, toplantı sayısı, teslimat listesi ve ücret; proje girdileri, incelenecek sistemler ve karar için gereken analiz derinliği görüldükten sonra teklifte açıkça tanımlanır.

08 / FAQ

Discovery başlamadan önce.

Discovery neden ücretli?

Karmaşık projede gereksinim analizi, sistem inceleme, seçenek değerlendirme ve uygulanabilir scope üretimi başlı başına profesyonel çalışmadır. Amaç yalnız satış görüşmesi değil, kullanılabilir karar çıktısı üretmektir.

Discovery sonrası Akilta ile geliştirmeye devam etmek zorunda mıyım?

Hayır. Teslim edilen çıktıların kullanım sınırı sözleşmede tanımlanır; uygun olduğunda başka ekip için de uygulanabilir karar zemini üretmek hedeflenebilir.

Discovery kesin bütçe ve teslim tarihi verir mi?

Amaç daha güvenilir scope ve plan üretmektir, ancak üçüncü taraf bağımlılığı veya sonradan ortaya çıkan bilinmezlikler mutlak garantiye izin vermeyebilir. Teklif varsayımları ve açık riskler görünür yazılır.

Her büyük proje discovery gerektirir mi?

Hayır. Gereksinim, veri, mimari ve acceptance zaten yeterince netse doğrudan scoped delivery mümkün olabilir. Discovery bir ritüel değil, belirsizliği azaltma aracıdır.

09 / START

Projeyi tarif etmek zor geliyorsa, muhtemelen önce doğru soruları netleştirmemiz gerekiyor.

Mevcut hedefi, bildiğiniz sistemleri ve en büyük bilinmezliği kısaca anlatın. Discovery gerçekten gerekli mi, yoksa doğrudan başka bir service route mu daha doğru, birlikte ayıralım.

Discovery uygunluğunu değerlendirelim