Kesin Zaman Taahhüdü

Teslim Tarihi Bizim İçin Bir Temenni Değil, İhlal Edilemez Bir Sözleşme Maddesidir

Yazılım sektörünün belirsizlik kültürünü reddediyoruz.

Bir ajansın müşterisine söz verdiği teslim tarihinin sarsılması, ajansın itibarına vurulan en sert darbedir. Yazılım sektörünün asırlık kronik hastalığı 'sürekli erteleme' bizim için zaten bir kabulleniş değil; doğrudan bir tarafa geçtiğimiz bir savaşın adıdır. Partnerfy ile çalıştığınızda size verdiğimiz takvim, bir 'tahmini öngörü' değil. Arkasında matematiksel hesaplamalar, satır satır risk analizi (Buffer Time), iki katmanlı yedekli ekip planı ve sözleşmeye yazılmış net bir tazminat maddesi var. Tahmin değil, taahhüt. Bu sayfanın geri kalanı; nasıl bu kadar emin konuşabildiğimizi tek tek açıklıyor. Eğer geçmişte bir teslim tarihinin sarsılmasıyla yaşadığınız hayal kırıklığı varsa, burada onunla bir daha karşılaşmayacaksınız.

'Belirsizlik' Yazılım Sektörünün Kabul Ettiği Bir Sessizlik

Bir an düşünün: kaç dijital ajans başkanı, bir yazılım proje teslim gününde 'aslında bir hafta gecikme olacak ama oluyor böyle' cümlesini sineye çekmek zorunda kaldı? Bu cümle, sektörde o kadar normalleşti ki, müşteriler bile beklemeye başladı. Beklemek bir alışkanlık oldu, alışkanlık bir kültür oldu. Bu kültürü kabul etmediğimiz noktada Partnerfy'ın çalışma prensibi başlıyor. Bir teslim tarihi söz konusu olduğunda, sahip olduğumuz tek hayat çizgisi 'matematiksel olarak doğrulanmış' tarihtir. Bir matematik hesabı yapılmadan tarih verilmez; verilen tarih de bir başka matematik hesabı yapılmadan değiştirilmez. Sektörün 'esnekliği' bizim 'disiplinimiz' karşısında geri çekilir.
'Belirsizlik' Yazılım Sektörünün Kabul Ettiği Bir Sessizlik

Bir Teslim Tarihi Üç Aşamadan Geçer

Hayali bir tarih vermek bir saatlik iştir. Matematiksel olarak doğrulanmış bir tarih vermek, üç aşamalı bir mühendislik sürecidir.

1. Analiz & Buffer Hesaplaması

Projenin teknik gereksinimlerini, mevcut sistemin durumunu ve dış bağımlılıkları (3. parti API, store onayı, mevzuat) en başta listeleriz. Her kalemin riski olasılığa göre çarpılır, sonuca yedek pay (Buffer Time) eklenir. Size hangi tarihi verdiyseniz ona güvenebilirsiniz çünkü o tarih artık 'matematiksel'.

2. Sprint Yönetimi

Projeyi 2 haftalık sprintlere böleriz; her sprint sonunda görünür bir çıktı vardır. Sapma görüldüğünde, bir sonraki sprintin başlangıcı değil, içinde bulunduğumuz sprint günü içinde devreye giren kontrol kapısı çalışır. Erken yakalama, takvimi kurtarır.

3. Final QA & Teslim

Son sprint biter bitmez kod, 100 maddelik kalite kontrolünden geçer. Hata payı sıfırlanan proje, taahhüt edilen gün ve saatte teslim edilir. Saat 23:59'a değil; iş gününün başlangıcına teslim ederiz.

Tarih Vermek Önce Bir Matematik İşidir

Tarih Vermek Önce Bir Matematik İşidir

Bir teslim tarihini matematiksel olarak hesaplamak şu üç şeyi yan yana koymak demektir: (1) projenin kapsamı, story-point ya da fonksiyon noktası olarak somut bir sayıya çevrilir; (2) ekibin geçmiş performansı (velocity), ortalama olarak sprint başına ne kadar iş bitirdiği veriyle ölçülür; (3) belirsizlik bölgelerine ayrılan Buffer Time — genellikle toplam takvimin %15 ile %25'i arasında — eklenir. Bu üç sayı çarpıştığında elimize çıkan tarih, 'yapabiliriz' değil; 'matematiksel olarak yapacağız' diyebileceğimiz bir tarihtir. İki ayrı senior mühendis aynı projeye baktığında aynı ya da çok yakın tarihleri verir — çünkü hesap herkese açıktır ve aynıdır.

Sayılar, taahhütlerin gerçek lakonik özetidir. Geçmiş projelerden topladığımız metrikler, takvim disiplinimizin sahada ispatlanmış halidir.

%97
Zamanında Teslim
Son 24 ayda
0
Mazeret Sayısı
Tazminat hep ödendi
8 Yıl
Aynı Disiplin
Hiç değişmedi

Bizim Dünyamızda 'Yetişmedi' Bir Cevap Değil, Bir İtiraftır

Sözleşmedeki tazminat maddesi: caydırıcı değil, otomatik bir kuraldır.

Bir sözleşme imzalandığı an, tarafların sadece niyetleri değil; o niyetin gerçekleşmemesi halinde bedellerin de yazılı hale geldiği bir andır. Partnerfy sözleşmesinde 'Gecikme Tazminatı' maddesi bizim için bir caydırıcı değil; eğer zamanı tutmadıysak otomatik devreye giren bir ekonomik kuraldır. 'Yetişmedi', 'Gözden kaçtı', 'Beklenmedik bir sorun çıktı', '3. parti API'dan dönüş gelmedi', 'Ekip arkadaşımız hastalandı' — bunların hiçbiri bizim dünyamızda mazeret olarak kabul edilmez. Çünkü hepsi takvimi yaparken zaten matematiksel olarak hesaplanmış olması gereken risk kalemleridir. Riskin gerçekleşmesi sürpriz değil; riskin tarafımızdan beklenmemiş olması, sözleşme açısından bir hatadır. Bir gecikme olursa, ajansınızın müşterisine karşı itibar kaybetmesindense, bedeli bizim ödememizi tercih ederiz. Bu tercih, bir sözleşme maddesi değil; bizim için gözden çıkarılamaz bir prensiptir.

Riski Sürpriz Olmaktan Çıkaran Üç Önlem

Bir riskin matematiksel olarak hesaba katılmaması, o riskin gerçekleştiğinde sürprize dönüşmesi demektir. Aşağıdaki üç önlem, hiçbir riski hesap dışına atmamızı engeller.

Buffer Time

Her takvim, kapsamın ötesinde belirsiz alanlara ek pay ayırarak hesaplanır. Tipik bir projede toplam takvimin %15-%25'i Buffer'a gider. Bu yedek, beklenmedikleri matematiksel olarak beklenilenler haline getirir.

Yedekli Ekip Planı

Her kritik rolün arkasında yedek bir uzman vardır. Bir backend mühendisinin hastalanması, takvimin sarsılma sebebi değil; aynı gün başka bir ismin devreye girme tetiğidir. Tek-kişiye bağımlı bir proje, bizim için fail-safe değildir.

Risk Listesi & Olasılık Çarpanı

Projeye başlarken bilinen tüm riskleri (3. parti API onayı, store reddi, mevzuat değişikliği, ekip yorgunluğu) listeler, her birine olasılık ve etki çarpanı atarız. Risk listesi statik değil; sprint sonu retrospektiflerinde yeniden ölçülür. Riskin doğrulanması sürpriz değil, sıradan iştir.

Sözleşmemizdeki 'Gecikme Tazminatı' Maddesi: Otomatik Devreye Giren Bir Kural

Eğer söz verdiğimiz tarihi tutmadıysak — Buffer Time'a rağmen, yedekli ekibe rağmen, sprint kontrol kapılarına rağmen — sözleşmedeki tazminat maddesi kendiliğinden devreye girer. Bu madde sayısaldır, önceden belirlenmiş bir formülle hesaplanır, ve günler ilerledikçe katlanarak büyür. Maddenin işleyişi şöyledir: ilk hafta gecikme, projenin sözleşme bedelinin %10'una karşılık gelir. İkinci hafta %20, üçüncü hafta %35. Dördüncü haftanın sonunda gecikme sürerse, sözleşme bedelinin tamamı iade edilir; üstüne ajansınızın müşterisine karşı uğradığı zararın bizim üzerimize kalan kısmı eklenir. Bu madde bir korkutma değil; takvim disiplinimizin dışsal ispatıdır. Bu kadar sert bir madde altında çalışmayı kabul edebilen bir teknoloji şirketi, tarihi hesaplarken matematiksel olmak zorundadır. Yani sertlik bizim üzerimizde; rahatlık sizin.
Sözleşmemizdeki 'Gecikme Tazminatı' Maddesi: Otomatik Devreye Giren Bir Kural

Bir Teslim Tarihi, Kalbinden Geçen Bir Söz Değil; İmzalanan Bir Sayıdır

İnançla değil, hesapla bağlanan bir taahhüt.

Yıllar içinde gördüğümüz şudur: yazılım sektöründe iyi niyet eksik değil; eksik olan disiplin. Bir geliştirici 'bu projeyi 6 haftada bitiririm' dediğinde, çoğu zaman gerçekten öyle olacağına inanır. Ama bir tarih, inançla değil hesapla bağlıdır. Bu yüzden Partnerfy'da takvim, projenin başlangıcında bir senior mühendisin niyetinden değil; bir formülün çıktısından doğar. O formül ekibin geçmiş velocity'sini, kapsamın somut sayısını, açık riskleri ve Buffer'ı bir araya getirir. Çıkan sayıyı sözleşmeye yazarız. Sizin için tek değişen şey şu: artık 'umarım yetişir' cümlesini ne biz duyarız, ne siz müşterinize. Çünkü 'yetişip yetişmeyeceği' bir umut meselesi değil; bir matematik meselesi. Onu da biz çözmüş oluruz.

Matematiksel Bir Takvim İçin İletişime Geçin

Aşağıdaki formu doldurun; projenizin kapsam ve risklerini anlamak için kısa bir ön görüşme yapalım. Bu görüşmenin sonunda elinizde matematiksel olarak hesaplanmış bir teslim tarihi olacak. 0850 259 30 04 numarasından da doğrudan ulaşabilirsiniz.

Aklınıza takılan sorular için bize her zaman ulaşabilirsiniz: [email protected]

Başvurunuz tarafımıza ulaştı!

Partnerlik başvurunuzu inceleyip en kısa sürede numaranız üzerinden size dönüş yapacağız.

🇹🇷+90

Şirket Türünüz Nedir?

Hangi konularda desteğe ihtiyacınız var?

500
1 1.000

Aylık olarak hedeflediğiniz tahmini müşteri sayısı (1 – 1.000)

Bölüm Tipi Seç

Eklemek istediğiniz bölüm tipini seçin

Eklendikten sonra Filament admin'den içeriği düzenleyebilirsiniz.

sonuç