Bir yazılım sözleşmesinde olması gereken yedi madde

Yazılım geliştirme anlaşmazlıklarının çoğu ihlal edilen bir şeye değil, hiç yazılmamış bir şeye dayanır. Sözleşme, proje ortasında ayrılık sonrası kodun kime ait olduğunu söylemiyordu, dolayısıyla teknik olarak kimse haksız değil - ve herkes sıkışmış durumda.

İşte bunu önleyen yedi madde.

Kısa yanıt

Yedi madde, ve her birindeki spesifik ifade, o başlığı taşıyan bir maddenin varlığından daha önemlidir.

Tetikleyici tarihle fikri mülkiyet ve kod sahipliği

En önemli madde ve kasten ya da kazara en sık belirsiz yazılan madde.

"Müşteri tüm iş ürününe sahiptir" koruyucu geliyor. Tetikleyici olmadan değildir: ne zamandan itibaren sahip? Bazı sözleşmeler mülkiyeti yalnızca "iş tamamlandığında" devreder - ki bu, dört aylık bir geliştirmenin ikinci ayında ilişki sona ererse gerçek bir soruna dönüşür, çünkü teknik olarak hiçbir şey tamamlanmamıştır.

Bunun yerine ne aramalı: her kilometre taşı ödemesinde devredilen mülkiyet, veya oluşturulur oluşturulmaz devredilip geliştiriciye portfolyo kullanımı için geri lisans verilmesi. İkisi de işe yarar. Belirsiz zamanlama yaramaz.

Açık kapsam istisnaları

Daha önce bir kapsam belgesinin neden istisnalar bölümüne ihtiyaç duyduğu hakkında yazmıştık, ve sözleşmenin de aynı spesifikliği taşıması gerekir, ona gevşekçe atıfta bulunması değil.

"Ekteki kapsamda tanımlandığı üzere MVP geliştirme", ekteki kapsamın kendisi neyin hariç tutulduğunu listelemiyorsa göründüğünden zayıftır - üçüncü taraf API maliyetleri, içerik, veri taşıma, belirtilen pencerenin ötesinde destek. Bu liste olmadan her iki taraf da kendi varsayımlarına döner, ve varsayımlar nadiren örtüşür.

Takvime değil, kilometre taşına dayalı ödeme

Tarihlere bağlı bir ödeme planı - 30 gün vade, sonra 30 gün sonra, sonra 30 gün daha - bir şey teslim edilmiş olsun olmasın öder. Bu, proje geri kalırsa elinizdeki tek gerçek kozu alır.

Kilometre taşlarına bağlı bir ödeme planı - çalışan giriş akışı, baştan sona çalışan çekirdek işlem, çalışır durumda yönetim paneli - ödemeyi yalnızca gerçekten doğrulayabileceğiniz bir şey karşılığında serbest bırakır. Bu tek değişiklik, bir müşteriyi sözleşmedeki neredeyse her maddeden daha fazla korur.

Tanımlı bir değişiklik talebi süreci

Kapsam değişecek. Nasıl olacağını söylemeyen bir sözleşme örtük olarak "olduğunda hallederiz" diyor, ki bu o anda daha fazla koza sahip olanın işine yarar - genellikle proje ortasında, ortak değiştirmenin pahalı olduğu anda siz değilsinizdir.

Madde açıkça belirtmeli: tanımlı kapsamın dışındaki bir değişiklik talebi, üzerinde çalışılmaya başlanmadan önce ayrıca ve yazılı olarak tahmin edilir ve fiyatlandırılır. Bu her iki tarafı da korur - geliştirici ücretsiz kapsam büyümesini üstlenmez, ve siz dahil olduğunu sandığınız bir şey için sürpriz fatura keşfetmezsiniz.

Tanımlı, açıkça sınırlandırılmış bir destek penceresi

"Lansman sonrası destek dahildir" bir madde değil, bir ifadedir. Nasıl sınırlandırılmış - kaç gün için, hangi tür sorunu kapsayarak, hangi yanıt süresiyle?

Mevcut işlevsellikteki hataların otuz günlük düzeltmesi makul ve yaygın bir temeldir. Bunun ötesindeki her şey - yeni özellikler, sürekli bakım, öncelikli yanıt süreleri - sözleşmede veya bağlantılı bir anlaşmada belirtilen ayrı, fiyatlandırılmış bir retainer olmalıdır, her iki tarafın sessizce yaptığı bir varsayım değil.

Fesih ve çıkış koşulları

Her sözleşme, ihtiyaç duyulmadan önce yazılı olarak yanıtlamalıdır: taraflardan biri proje bitmeden çıkmak isterse ne olur?

En azından: ihbar süresi, o noktaya kadar tamamlanan iş için ne borçlu olunduğu, ve mülkiyet koşullarının (bkz. birinci madde) erken fesihte de temiz biçimde geçerli olduğunun teyidi - sadece başarılı bir bitişte değil. Yalnızca temiz bir tamamlanmada ne olacağını anlatan bir sözleşme, anlaşmazlığa yol açması en muhtemel senaryoyu planlamamıştır.

Gizlilik ve yeniden kullanmama

Çoğu profesyonel sözleşmede standarttır, ama kurucuların kapsandığını varsaydığı ve çoğu zaman kapsanmayan spesifik şeyi kontrol etmeye değer: geliştiricinin sizin özel iş mantığınızı, verinizi veya tescilli yaklaşımınızı başka bir müşteri projesinde yeniden kullanmasını engelleyen bir madde - sadece işinizi kamuya açık konuşmama hakkındaki genel gizlilik değil.

Genel gizlilik sözleşmeleri sır saklamayı kapsar. Bu madde yeniden kullanımı kapsar, ki ürününüzün değeri bir şeyin nasıl çalıştığındaysa, sadece var olduğunda değil, asıl önemli olan versiyon budur.

Bu maddeler sözleşmede yoksa ne yapmalı

Çoğu ekleme, yeniden yazım değil. Açık mülkiyet tarihleri, kilometre taşı ödemeleri veya bir istisna listesi eklenmesine sert direnç gösteren bir ortak size imzadan sonra değil önce sahip olmaya değer bir bilgi veriyor - imzalamadan önce sorulmaya değer sorular aynı incelemenin sohbet versiyonunu ele alıyor.

Bu yedi maddenin hiçbiri istenmesi olağandışı veya agresif değil. Bunlar bir ilişkiyi tarif eden sözleşme ile ilişki ters giderse sizi gerçekten koruyan sözleşme arasındaki farktır.

Bir MVP geliştirmesi için sözleşme inceliyor ve koşullar hakkında ikinci bir görüş mü istiyorsunuz? Ayrıntıları gönderin - neyin eksik olduğunu söyleyelim. Fikri mülkiyet koşulları ve ödeme kilometre taşları dahil kendi sözleşme yapımız fiyatlarımızda açıklanmıştır.