Bir teklif ayrıntılı olup asıl kararı yine de saklayabilir. Bir projede ekranlar ve entegrasyonlar tek tek anlatılmıştı, fakat source code, production hesapları ve deployment key'lerinin kime ait olacağı yazılmamıştı. Procurement sorana kadar belirsizlik sürdü, çünkü önceki bütün konuşmalar feature'lara odaklanmıştı.
Teknoloji partneri, satışı zorlaştıranlar dahil belirsizlikleri imzadan önce azaltmalıdır. Değerli sorular sınırları görünür olmaya zorlar.
Hangi varsayımların yapıldığını sorun
Her teklif veri kalitesi, karar hızı, içeriğin hazır olması, entegrasyon erişimi, trafik, compliance, browser ve cihaz desteği hakkında varsayım taşır. Bunları yazılı liste isteyin. Sonra hangisi yanlış çıkarsa fiyat veya takvimi en çok değiştireceğini sorun.
Her şey dahil cevabı endişe vericidir. Karmaşık işin mutlaka kenarları vardır. Partnerin incelemediği sistemlere dayanarak sabit söz vermesi de uyarıdır. Dependency listesi olmayan güven, risk payının fiyata saklandığını veya change request'e ertelendiğini düşündürür.
Güçlü cevap bilinen scope'u, discovery sorularını ve exclusions alanını ayırır. Her bilinmeyenin hangi kanıtla kapanacağını da söyler.
Her operasyon varlığının sahibini sorun
Repository, cloud hesabı, domain, analytics, model hesabı, app-store kaydı, design source dosyası ve vendor sözleşmesinin sahibi belli olmalı. Production credential müşteri kontrolündeki altyapıda yaşamalı veya belgeli devir yolu bulunmalı. Stüdyonun erişimi ürünü yeniden kurmadan kaldırılabilmeli.
İlişkinin bittiği gün ne olacağını sorun. Başka ekip deploy edebilir, secret rotate edebilir, veri restore edebilir ve açık incident'ları anlayabilir mi? Hangi dokümantasyon ve handover dahildir? Süreklilik iyi niyete veya bir çalışanın laptopuna bağlıysa risk zaten vardır.
Sahiplik maintainability ile aynı değildir. Source code hukuken devredilmiş olsa bile environment, runbook ve karar geçmişi yoksa pratikte kullanılamaz.
Başarısızlığın nasıl anlaşılacağını sorun
Partner implementation öncesinde başarı ölçüsünü ve stop koşulunu adlandırmalıdır. AI feature için eval vakaları, kabul edilemez hata türleri ve zayıf sonuç planı gerekir. Commerce için checkout dışındaki operasyon senaryoları, performans işi için field metric ve test koşulları tanımlanır.
Feedback bize söyler cevabına dikkat edin. Feedback değerlidir, fakat go, no-go veya redesign eşiğinin yerini tutmaz. Defect, scope değişikliği ve incident'ın sözleşmede nasıl ayrıldığını da sorun. Her beklenmedik sonuç yeni scope sayılıyorsa teslimat riski bütünüyle alıcıya taşınmıştır.
Hangi işe hayır dendiğini dikkatle dinleyin
Clodron'da hayır işin parçasıdır. Web ürün gereksinimi karşılıyorsa native app'e hayır deriz. İstisnaların sahibi yoksa AI automation'a hayır deriz. Geniş credential taşıyan production agent'a ve eval olmadan model değişikliğine hayır deriz. Normal database güven modelini çözüyorsa Web3 önermeyiz. Küçük yüzeyi olgun göstermek için design system kurmayız.
Bunlar evrensel yasaklar değildir. Etkileyici ama gereksiz build'den projeyi koruyan partner davranışına örnektir. Hiç hayır demeyen stüdyo, çalışan ürün yerine ilk scope'u büyütüyor olabilir. Partnerden kendi faturasını düşüren yakın tarihli bir öneri isteyin.
Cevapları bu hafta anlaşmaya koyun
İmzadan önce assumptions, exclusions, acceptance, ownership, environments, security sorumluluğu, üçüncü taraf bedeli, change control, support ve exit başlıklarını içeren kısa karar sayfası oluşturun. Önemli her sözü sözleşme veya statement of work içindeki yere bağlayın.
Yalnızca sales değil, delivery lead de incelesin. Genellikle, sonra veya duruma bağlı gibi cevapları adı belli owner ve karar noktasına dönüştürün. Partnerin müşteriden neye, ne zaman ihtiyaç duyduğunu kaydedin.
Hedef her olayı öngören sözleşme değildir. Kötü haberin gidecek yeri olan çalışma ilişkisidir. Partnerin imzadan önce söylediği önemlidir. Yazıya dökmeye razı olduğu ise daha güçlü sinyaldir.