Teklif, POC ve Değişiklik Etki Zinciri

Önceki vaka dersinde Arven için açıklanmış olgular ile kurgusal sabah raporu senaryosunu ayırdın; iş sonucu, aday gereksinim ve mimari alternatifleri bir ADR taslağına bağladın. Şimdi bu taslağın satış çıktısına nasıl dönüştüğünü ve yeni bir bilgi geldiğinde hangi artefaktların yeniden açıldığını işleyeceksin. Sabah raporu gecikmesi yalnız eğitim alıştırmasıdır; Arven'in kanonik müşteri şartı değildir. Seçeneklerden birinin teknik olarak umut verici görünmesi de teklif, fiyat veya satın alma onayı anlamına gelmez. Yaklaşık 28 dakika anlatı, 33 dakika değişiklik uygulaması, 15 dakika kontrol planla. Dersin çıktısı teklif metni, BoM/TCO, compliance matrix, POC raporu ve karar kaydı arasında izlenebilir bir değişiklik matrisi olacak. Farklı dosyalarda aynı kararın farklı sürümleri bulunursa müşteri sunumunu durdurup sürüm çatışmasını çöz. Bu yalnız belge temizliği değildir: yanlış sürüm, müşteriye başarılmamış bir kabiliyeti taahhüt edebilir.

Bir mimari seçenek BoM'a girdiğinde her satırın ihtiyaca, kapasite varsayımına ve yapılandırma sürümüne izi olmalı. Alıştırma için A seçeneği uygulama sorgusunu iyileştiriyor, B seçeneği altyapı kapasitesi ekliyor olsun. B'nin iki düğüm sayısını yazmadan önce ölçülen yük, N+1 kuralı, DR etkisi, lisans metriği, destek süresi ve geçiş maliyetini doğrula. BoM yalnız donanım listesi değildir; lisans, bakım, kurulum, eğitim, test ortamı ve olası çift işletim dönemi TCO'yu etkiler. Üç yıllık maliyet kıyasında tüm seçeneklerde aynı dönem, para birimi, vergi yaklaşımı ve indirim varsayımı kullanılmalı. Sahipliği belirsiz maliyeti sıfır yazma; UNKNOWN veya koşullu aralık göster. Teklif metni teknik tasarımın sınırlarını açıklar: hangi iş yükleri kapsanıyor, hangi performans veya kurtarma sonucu hangi varsayımla ölçülecek, müşteri hangi veriyi sağlayacak? Henüz ölçülmemiş rapor süresini kesin kazanım olarak yazma. Maliyet farkı yüksekse yalnız ucuz görünen seçeneğe geçme; iş sonucu, işletim yükü ve risk etkisini aynı tabloda göster.

POC satış gösterisi değil, açık bir mimari veya iş hipotezini sınama aracıdır. Microsoft'un mimar ve iş yükü ekipleri arasındaki çalışma rehberi POC'nin tasarım kararını bilgilendirdiğini, POC kodunun üretime hazır sayılmaması gerektiğini vurgular. Arven alıştırmasında hipotez 'ek kapasite rapor bitişini iyileştirir' ise tek bir hızlı demo bu iddiayı doğrulamaz. Test öncesi baseline, veri hacmi, yük profili, uygulama sürümü, ortam farkı, tekrar sayısı, başarısız koşu ve gözlemciyi kaydet. Aday kabul ölçüsü müşteri iş hedefinden türemeli; örneğin iş günü öncesi bitiş saati henüz onaylanmadıysa onu sen belirleyip başarı diye işaretleme. Testin hangi alternatifleri ayırdığı da açık olsun. Yalnız B seçeneğinin iyi çalıştığını göstermek A seçeneğinin daha düşük maliyetle aynı hedefi sağlayamayacağını kanıtlamaz. Çevresel farklar, veri örneklemesi ve ağ gecikmesi sonucu etkileyebilir. POC kapsamını üretim güvenlik, işletim ve DR kabulüyle karıştırma.

Test sonucunu teklif iddiasına bağlayan satırda ham ölçüm, yorum, kapsam sınırı ve karar etkisini ayır. Diyelim kurgusal POC üç koşuda hedef süreyi karşıladı. Bu sonuç yalnız test edilen yük ve ortam için teknik fizibiliteyi destekler; gerçek Arven iş yükü, DR, lisans veya sözleşmesel SLA hakkında otomatik garanti değildir. Ölçüm başarısızsa raporu saklamak yerine hipotezi, veri kalitesini ve mimari alternatifi yeniden ele al. Teklifte 'kanıtlandı' sözcüğü kullanılacaksa hangi kabul ölçüsü, kaç koşu ve hangi müşteri gözlemcisiyle doğrulandığı yazılmalı. POC öncesi iddia v1, POC sonucu v2 arasında iz tutulmalı; v1 sessizce değiştirilmez. POC sırasında yeni bağımlılık keşfedilirse HLD, BoM, TCO, risk ve compliance satırları yeniden taranır. Bir pilot ayrıca operasyon ekibi, gerçek kullanıcı, izleme, rollback ve devir kabiliyetini araştırabilir; iyi POC pilotun yerine geçmez. GOV.UK hizmet faydası ölçümü rehberinin önerdiği gibi maliyet ve faydanın ölçüm planı baştan belirlenirse sonraki karar daha anlaşılır olur; bu kamu hizmeti çerçevesi Arven için bağlayıcı süreç değildir.

Kurgusal müşteri görüşmesinde raporun yalnız iş günü değil ay sonu kapanışında çok daha büyük veriyle çalıştığı açıklansın. Bu yeni bilgi de eğitim senaryosudur; Arven'in kanonik gerçeği değildir. Değişikliği önce kaynak, konuşan rol, tarih, belgenin yetkisi ve teyit statüsüyle kaydet. Yeni veri hacmi doğrulanınca aday gereksinim ve test profili değişebilir. Baseline'a göre alınmış POC sonucu yeni yükü temsil etmiyorsa 'başarılı' bayrağı aynı kalamaz; yeni koşu veya açık sınırlama gerekir. ADR'deki seçenek puanı, HLD veri yolu, BoM kapasitesi, lisans metriği, üç yıllık TCO, risk, compliance, teklif kapsamı ve proje takvimi etkilenebilir. Hepsinin değişmesi zorunlu değildir; her satır için etkileniyor, etkilenmiyor ve bilinmiyor kararını gerekçeyle yaz. Özellikle 'etkilenmiyor' kararının da kanıtı olmalı. Eski tasarım v1 silinmez; yeni v2 ile neyin ve neden değiştiği gösterilir. Müşteri kararına sunulan teklif hangi sürümün geçerli olduğunu belirtir.

PMI'nin bütünleşik değişiklik kontrolü çerçevesi kapsam, takvim ve maliyet baselinelarının birlikte değerlendirilmesini açıklar. Bunu Arven'in sözleşmesine otomatik süreç hükmü olarak taşıma; değişiklik etki taraması için yöntem olarak kullan. Talep geldiğinde 'küçük bir sayı düzeltmesi' diyerek tek dosyayı değiştirmek hatalıdır. İstek sahibi ve yetkisi, değişiklik nedeni, etkilenen gereksinim ID'leri, tasarım/BoM/TCO farkı, teklif geçerliliği, POC tekrar ihtiyacı ve karar makamı tek değişiklik kaydında görünmeli. Örneğin daha büyük ay sonu yükü B seçeneğinde ek lisans maliyeti yaratabilir ama A seçeneğinde sorgu optimizasyonunun faydasını artırabilir. Ölçüm olmadan hangisinin kazanacağını söyleme. Teklif müşteriye gönderilmişse iç satış ve teknik liderler yeni sürümün dış iletişimini koordine etmelidir; eski fiyat ve yeni kapsamı birlikte dolaşıma sokma. Değişiklik müşteri tarafından yalnız sözlü söylendiyse, resmi şartname ve teklif bağını güncellemeden önce açıklama/teyit iste. Yetkili teyidi gelmezse koşullu senaryo olarak kıyas yap, kesin taahhüde dönüştürme.

Karar toplantısına tek sürümlü paket gir: müşteri iş hedefi ve onay statüsü, açık gereksinim listesi, seçenek karşılaştırması, ADR, HLD, BoM/TCO, compliance matrix, POC sonucu, risk ve değişiklik kaydı. Bu pakette 'POC geçti' ve 'teklif gönderilebilir' farklı kararlardır. Teknik kanıt yeterli olsa bile lisans hakkı veya bütçe belirsizse koşullu teklif, ek doğrulama ya da durma kararı gerekebilir. Compliance satırında desteklenmeyen iddiayı Compliant işaretleme; Gap veya TBD ile açıklama ve telafi seçeneğini göster. Karar makamları da ayrılmalıdır: mimari öneriyi teknik lider, ticari marjı satış/yönetim, iş hedefini müşteri sahibi, sözleşmesel kabulü yetkili satın alma temsilcisi değerlendirebilir. Aynı kişinin hepsini otomatik onayladığını varsayma. Paketin özetinde bir sayfalık değişiklik v1→v2 matrisi yer alsın: hangi yeni kanıt geldi, hangi alternatif etkilendi, maliyet veya takvim farkı nedir, hangi karar bekliyor? Ayrıntılı ekler bu özetin iddialarını desteklesin. Açık şartlar kapanana kadar kesin ürün veya performans garantisi vermek teknik dürüstlük ilkesini bozar.

Karar sonrası işi öğrenene değil gerçek uygulama ve müşteri ekiplerine devredecek gibi yaz. Her açık şartın sahibi, tarihi, doğrulama yöntemi ve durdurma eşiği görünür olmalı. Pilot yapılacaksa üretim güvenliği, gözlemlenebilirlik, rollback, veri koruma ve operasyon rolü ayrı kabul maddeleri olarak hazırlanır. Microsoft mimar iş birliği rehberi tasarımın uygulama sırasında yineleme gerektirdiğini ve teknik borcun belgelenmesini önerir; tasarım dokümanını tek seferlik teslim olarak ele alma. Arven alıştırmasında POC başarı raporu üretim runbook'u değildir. Yetkili müşteri başlangıç saatini değiştirirse kabul testi ve teklif sözü yeniden gözden geçirilir. Teklif kararının üç meşru sonucu vardır: kanıtla ilerle, tanımlı şartlarla ilerle veya kanıt/uyum açığı kapanana kadar dur. 'Şartla ilerle' boş bir güvence cümlesi değildir; risk taşıyıcısı ve son tarih yazılır. Sonraki ders karar kurulu simülasyonunda bu paketi savunacak, çelişkili sorulara kanıt sınırını koruyarak yanıt vereceksin. Başarılı teslim her dosyanın dolu olması değil, kararın hangi kanıta, varsayıma ve yetkiye dayandığının anlaşılmasıdır.