Özelleştirilmiş yazılım projelerinin fiyatlandırılması sırasında, tarafların en sık birbirine uydurduğu ölçü birimi «insan-gün» : kaç mühendis, kaç gün çalışacak, birim fiyatı ne kadar. Bu model, talepler sabit ve teslimat sınırları net olduğunda işler; ancak sahada kurallar sıkça değişmeye başladığında, AI araçları kodlama verimliliğini yükselttiğinde ve taraf A hâlâ «insan sayısıyla» kabul ederse, çelişkiler patlar — taraf B, taleplerin yayıldığını hisseder, taraf A ise «insan sayısı artmadı, ama ürün de fazla değil» diye düşünür.
Politika sinyali: İnsan sayısından sonuç satmaya geçmek
Eylül 2026’da, Sanayi ve Bilgi Teknolojileri Bakanlığı, «Yapay Zeka + Yazılım» Özel Eylem Planı’nı yayımladı; bu belgede yazılım üretim modellerinde dönüşümü teşvik etmek, «Model Hizmeti», «Akıl Yürüten Sistem Hizmeti» gibi yaklaşımları geliştirmek çok kez vurgulanıyor ve 2028 yılına kadar öncelikli sektörlerde akıl yürütme sistemleri üzerine örnek uygulamalar geliştirilmesi açıkça belirtiliyor. Belge, özelleştirilmiş geliştirme sürecini reddetmiyor, ancak net bir yön gösteriyor: Yazılımın değerini ölçerken, giderek daha çok somut sonuçlara bakılıyor; yalnızca harcanan insan-gün miktarına değil. .
ERP, MES, CRM ve sektör özelindeki yönetim sistemleri üzerinde çalışan şirketler için bu, sözleşmelerde hâlâ yalnızca «XX kişi × XX gün» yazılması halinde, sistemin devreye alınmasının ardından «kod tamamlandı, ama işlevsel olarak kullanılamıyor» şeklindeki tartışmalara kolayca yol açabileceğini ifade ediyor. Daha sürdürülebilir bir yaklaşım, teslimatı kabul edilebilir işlevsel sonuçlara ayırarak yapmaktır. .
İş mantığı: Milestone’lar insan-günden daha somut olmalı
Proje ödemesini «aşama bazlı ödeme»den «milestone bazlı ödeme»ye yükseltmek; her milestone aynı anda dört koşulu karşılamalıdır:
- İşletme senaryosu : Kimler tarafından kullanılıyor, hangi işlemleri çözüyor (örneğin «depocu barkod okuyarak stok girişini gerçekleştiriyor» yerine «stok giriş modülünü tamamladı»).
- Veri kapsamı : Hangi ana veriler, durum alanları ve yetki sınırları söz konusu, numune alma kuralları nelerdir?
- Kabul scripti : Verilen test verileri üzerinden hangi süreçlerin tamamlandığı, hangi belge veya raporların üretildiği.
- İstisna işleme : Hata durumunda sistem nasıl uyar, kimin düzeltme yetkisi var, iz kaydı tutulup tutulmaması.
Bir milestone’in süresi 2–4 haftayı aşmamalıdır ; çok uzun olması «karanlık kutu geliştirme»ye geri dönmeye yol açabilir. Tipik bölünme örneği: Ana veriler ve yetkiler → Temel belge kapanışı → Raporlar ve hesaplaşma → Arayüz ve devreye alma geçişi.
Tasarım mantığı: Kapsam, değişiklikler ve «akıllı destek» sözleşmeye dahil edilmeli
AI destekli kodlama, otomatik test vakaları oluşturma, akıllı doküman doldurma gibi gelişmeler, aynı işlev için harcanan insan-gün miktarını değiştirebilir; ancak işleyişin karmaşıklığını otomatik olarak değiştirmez . Sözleşme ve talep spesifikasyonlarında ayrı bir bölüm önerilir:
- Kapsam taban çizgisi (Baseline) : Fonksiyon listesi + kapsama dışı unsurlar listesi (Out of Scope), değişiklikler mutlaka değişiklik formu ile yapılmalıdır.
- Değişiklik ücretlendirme kuralları : Yeni milestone’lar «senaryo + kabul scripti» temelinde değerlendirilir, insana eklenen günlükler değil.
- Akıllı destek sınırı : Hangi aşamalarda AI ile verimlilik artırılabilir (kod üretimi, doküman taslağı), hangilerinde el ile imza gereklidir (güvenlik, uyumluluk, dışarıya yönelik taahhütler).
- Bilgi birikiminin sahipliği : Süreç belgeleri, yapılandırma, scriptler kimin sorumluluğunda; teslimattan sonra bakım ve operasyon kesintilerinin önüne geçmek için.
Gelişim uygulaması: Kabul otomasyonu ve gözlemlenebilirlik
«Sonuç odaklı» yaklaşımı hayata geçirmek için teknik ekip üç şeyi desteklemeli:
- Kabul test vakalarının envanteri : Her milestone’a karşılık bir dizi otomatik veya yarı-otomatik test vakası; geri dönüşler tekrarlanabilir şekilde yürütülebilir.
- Çevre ve veri ayrılığı : UAT ortamındaki veriler yeniden ayarlanabilir, «yalnızca demo ortamında geçerli» olma riskini önlemek için.
- Gözlemlenebilir loglar : Kritik işlemler için denetim logları mevcuttur; anlaşmazlık durumunda kimin neyi değiştirdiğini takip etmek mümkün.
Projenin akıl yürütme sistemi veya kurallar motoru içerdiği durumlarda, kabulde rastgele kontrol mekanizması da eklenmelidir : Sınırda rastgele örnekler girilerek, cevap vermeme, manuel yükseltme, yetki engelleme gibi durumların tasarım doğrultusunda gerçekleşip gerçekleşmediği incelenir; yalnızca «sohbet edebiliyor» olmasına bakılmaz.
Üç yaygın tartışma türü ve önleme yolları
Birinci tartışma: «Tüm fonksiyonlar yapıldı, neden işlevsel olarak kullanılmıyor?» — Önleme: Milestone’lar pozisyon operasyonlarına ve eğitim kayıtlarına bağlanır; kabul sırasında sahada görev kontrolü yapılır, yalnızca sunum PPT’si değil.
İkinci tartışma: «Küçük bir talebi eklemek neden para gerektiriyor?» — Önleme: Değişiklik formunda etkilediği milestone, script ve süre açıklanır; iki tarafın imzası sonrası geliştirme başlatılır.
Üçüncü tartışma: «AI verimliliği artırdı, insan-günleri azaltabilir miyiz?» — Önleme: Sözleşmede «gerçekleştirme maliyeti» ile «işlevsel karmaşıklık» ayrımı yapılır; verimlilik kazancı toplam fiyatta veya süreçte görülebilir, ancak kabul standartları düşürülmez.
Pilot öneri: Bir kapalı döngü modülüyle başlayın
Tüm sistemin yeniden sözleşme yazmasını beklemek zorunda değilsiniz. 2–3 haftada kapalı döngü oluşturabilecek bir modülü seçin (örneğin stok giriş/çıkış, iş emri bildirimleri, harcama onayı), yeni şablonla ek protokol imzalayın: Senaryolar, scriptler, istisnalar, ödeme noktaları listelenir. Testten geçtikten sonra tüm proje için uygulamaya geçin. Başarının ölçüsü, Değişiklik formunun çekişme süresini azaltıp azaltmadığına, UAT’ın tek seferde geçme oranının yükselip yükselmediğine bakmak; taraf B’nin kaç insan-gün azalttığını değil. Pilot modül iyi seçilirse, tüm proje için sözleşme değişikliği daha ikna edici hale gelir. İnsan-günler bir gecede yok olmayacaktır, ancak «tek fiyatlandırma birimi»nden «maliyet tahmini referansı»na dönüşmektedir. Milestone’lar ve kabul scriptlerini sözleşmeye dahil etmek, «Yapay Zeka + Yazılım» ortamında özelleştirilmiş yazılımın hâlâ güvenilir sonuçlar verebilmesinin temel becerisidir.
İnsan-günler bir gecede yok olmayacaktır, ancak «tek fiyatlandırma birimi»nden «maliyet tahmini referansı»na dönüşmektedir. Milestone’lar ve kabul scriptlerini sözleşmeye dahil etmek, «Yapay Zeka + Yazılım» ortamında özelleştirilmiş yazılımın hâlâ güvenilir sonuçlar verebilmesinin temel becerisidir.Sabit toplam fiyat ve agil iterasyonla uyumlu çalışma
Milestone kabulü agil yaklaşımı hariç tutmaz: Her Sprint hâlâ gösterebilecek ilerlemeler sunabilir; ancak
Ödemeler ve resmi kabul daha büyük milestone’lara bağlıdır. Sabit toplam fiyat sözleşmelerinde özellikle «kapsam dondurma noktası» açıkça belirtilmelidir — hangi incelemeden sonra yeni talepler değişiklik formuyla ele alınır, sözlü ek fonksiyonlardan kaçınılmalıdır. Akıl yürütme sistemleri içeren modüller için, «kurallar sürümü + rastgele kontrol geçirme oranı» gibi ayrı milestone kabulleri önerilir; tüm siteyi birlikte devreye alma gibi genel yaklaşımlardan kaçınılmalıdır.
Sektör verilerine göre, yazılım projelerinin başarısızlığının yaklaşıküçte biri talep ve kabul kapsamının net olmamasından kaynaklanmaktadır; teknik gerçekleşme kendisinden değil. Önce «ne zaman tamamlandı»yı sözleşme içinde netleştirmek, AI’nın kaç programcı yerine geçtiğini tartışmaktan daha değerlidir. Bir sonraki proje değerlendirme toplantısında şöyle bir soru sorulabilir: Eğer yarın taraf B’nin tüm personeli izinli olsa, scriptlerimize dayanarak şu anki milestone’ın standardı sağlayıp sağlamadığını söyleyebilir miyiz — cevap verilemiyorsa, kabulün henüz netleştirilmediği anlamına gelir. Milestone’ların sözleşmeye dahil edilmesi, taraf B’yi zorlamak değil, iki tarafın aynı sayfada «bitirildi mi» konusunu tartışmasını sağlamak için yapılır. Bu husus, AI’nın verimlilik artışını daha belirgin yaptığı projelerde, daha erken açıklanmalıdır.