MKB Juristen, özel hukuki belgeler hazırlamaktadır
Önemli sözleşmeleri, şartları ve diğer yasal belgeleri kendiniz bir araya getirmek veya kopyalamak en iyisi değildir. Bütçesi kısıtlı girişimcilere özel yasal çözümler, net maliyetler ve pratik açıklamalar sunuyoruz.
- Gümrük sözleşmeleri, şartlar ve koşullar ve yasal belgeler
- Bütçe dostu ve maliyetler konusunda baştan net bilgi veriyor
- Ücretsiz danışmanlık veya herhangi bir yükümlülük gerektirmeyen fiyat teklifi isteyin
Çevik yazılım geliştirme sözleşmesi hazırlamak, tek ve net bir şekilde tanımlanmış bir nihai ürün yerine, iş birliğinin temel kurallarını belirlemek anlamına gelir. Scrum ve sprintlerde kapsam kasıtlı olarak açık bırakıldığı için, sözleşme özellikle şu çerçeveler konusunda son derece net olmalıdır: nasıl çalışacağınız, hangi bütçeye kadar, sprint başına nasıl ödeme alacağınız, fikri mülkiyeti kimin edineceği, ek işleri nasıl ele alacağınız ve projeyi yarıda nasıl sonlandırabileceğiniz. Aşağıda standart bileşenler ve kaçınmak isteyeceğiniz tuzaklar yer almaktadır.
Kısa cevap
- Metodoloji. Scrum, sprint süresi, roller (ürün sahibi, ekip) ve toplantı zamanları.
- Bütçe ve zaman çizelgeleri. Sprint veya saat başına ücret, maksimum bütçe ve tahmini teslim süresi.
- Sprint başına kabul. Kabul kriterleri, yanıt süresi ve onayın sonuçları.
- Fikri mülkiyet düzenlemeleri. Hakların devri, mevcut yapı taşları ve açık kaynak kodlu yazılımlar üzerinde lisanslama.
- Ek işler ve sözleşmeden çıkış. Ne zaman ek iş sayılır ve sözleşme nasıl doğru şekilde feshedilir?
Çalışma yöntemlerini ve rolleri tanımlayın
Temelden başlayalım: Taraflar çevik bir yöntem kullanarak yazılım geliştiriyorlar. Hangi yöntem olduğunu açıklayın — genellikle Scrum — ve pratik düzenlemeleri belirleyin.
- Kısa süreli, bir ila dört hafta süren, sabit bir ritimle ilerleyen seriler.
- Ürün sahibi. Öncelikleri belirleyen ve karar alma yetkisine sahip olan kişi kimdir? Bu kişinin müsait olması şarttır; ürün sahibinin yokluğu çevik bir projeyi durma noktasına getirir.
- Ekip yapısı. Yüklenici hangi rolleri üstleniyor ve kişileri değiştirme yetkisine sahip mi?
- Toplantı. Sprint planlaması, değerlendirmesi ve geriye dönük incelemesi — ve kimlerin katıldığı.
Bütçe ve zaman çizelgeleri
Sabit bir ürün için sabit bir fiyat olmadığından, sözleşme iyi bir çerçeve içinde yapıldığında geçerliliğini korur veya kaybeder.
- Ücret. Sprint başına ekip ücreti veya rol başına saatlik ücret. Bu ücretin KDV dahil mi yoksa hariç mi olduğunu belirtin.
- Bütçe tavanı. Maksimum tutar veya sabit sayıda sprint. Uzatma taleplerinin yalnızca müşteriden gelen yazılı talimat üzerine geçerli olacağı konusunda anlaşma.
- Zaman Çerçevesi. Tahmini bir teslim süresi olup, zaman baskısı altında kapsamda sapma olabileceği ancak kaliteden ödün verilmeyeceği konusunda anlaşma sağlanmıştır.
- Faturalama. Genellikle sprint başına veya aylık olarak, kabul edilen işlere bağlı şekilde geriye dönük olarak düzenlenir.
Sprint başına kabul sayısı
Müşterinin her sprint için ayrı ayrı kabul etmesini sağlayın ve bunun ne anlama geldiğini somut olarak belirtin:
- Kabul kriterleri. Her sprint için önceden kararlaştırılan kriterler (tamamlanma tanımı).
- Yanıt süresi. Örneğin: Müşteri, on iş günü içinde gerekçeli bir ret cevabı vermediği takdirde, iş kabul edilmiş sayılır.
- Düzeltici işlem. Haklı bir diskalifiye durumunda ne olur? Bir sonraki sprint içinde, ek maliyet olmadan düzeltici işlem uygulanır.
Taksitli ödeme kabul süreci olmadan, ödemeler aksar ve bir şeyin "tamamlanıp tamamlanmadığı" belirsiz kalır.
Fikri mülkiyet
Bu, çoğu standart sözleşmenin yetersiz kaldığı konudur. Özel yazılımların telif hakkı, yaratıcısı olan tedarikçiye aittir ve otomatik olarak müşteriye geçmez.
- Devir. Müşteri, özel tasarım çalışmasına ilişkin haklarını elinde tutmak istiyorsa, sözleşmede bu hakların yazılı olarak açıkça devredilmesi gerekmektedir.
- Mevcut yapı taşları. Tedarikçiden gelen çerçeveler ve kütüphaneler genellikle aktarılmaz; bunlar için (süresiz) bir lisans geçerlidir.
- Açık kaynak kodlu. Açık kaynak kodlu bileşenler içerebileceğini ve ilgili lisans koşullarının geçerli olduğunu belirtin.
- Kaynak kod. Müşterinin tek bir tedarikçiye bağımlı kalmaması için kaynak kodu alması konusunda anlaşmaya varın.
Ek çalışma
Çevik metodolojide kapsam sürekli değiştiği için "bu ek bir iş mi?" sorusu mutlaka ortaya çıkacaktır. Bu soruyu net bir çizgiyle tartışmaktan kaçının:
- Anlaşmaya varılan bütçe ve zaman çerçevesi dahilinde kalan işler, içerik değişse bile, sprintlerin bir parçası olarak kabul edilir.
- Bütçenin artırılması, ek sprintler veya kararlaştırılan hedefin dışında yapılan çalışmalar ek iş olarak kabul edilir ve önceden yazılı onay gerektirir.
- Ek işlerin gerçekleştirilme hızını belirtin.
Çıkış ve fesih
Çevik metodolojide sprintler halinde çalıştığınız için, yarıda durmak gerçekçi bir durumdur. Bunu doğru şekilde ele alın:
- Bildirim süresi. Genellikle mevcut veya bir sonraki sprintin sonunda.
- Tamamlandı. Mevcut sprint tamamlandı ve ödemesi yapıldı.
- Aktarım. Kaynak kod, dokümantasyon ve ortamlara erişim aktarılıyor.
- Ödeme. O ana kadar kabul edilen tüm işler tamamlanacaktır; çıkış hakkının kullanılması nedeniyle herhangi bir ceza uygulanmayacaktır.
Örnek: Bir KOBİ hizmet sağlayıcısı bir planlama aracı sipariş etti ve dört sprintten sonra önceliklerin değiştiğini fark etti. Anlaşmada kaynak kod transferini içeren bir çıkış maddesi bulunduğu için, sözleşmeyi feshedebildi, teslim edilen işi yanında götürdü ve daha sonra başka bir tarafla devam edebildi. Bu madde olmasaydı, orijinal tedarikçiye bağlı kalacaktı.
Dürüst tavsiye
Çevik yazılım geliştirme sözleşmesi hazırlanırken risk, teknolojide değil, çerçevelerde yatar: bütçe, kabul, fikri mülkiyet, ek iş ve çıkış. Bu beş unsuru net bir şekilde göz önünde bulundurduğunuz sürece, maliyetler veya haklar kontrolden çıkmadan çevikliğin esnekliğini korursunuz.
Güvenilir bir tedarikçiyle ve sınırlı bir bütçeyle yürütülen küçük bir proje için, basit bir sipariş onayı ve sağlam şartlar ve koşullar genellikle yeterlidir; bu durumda, ayrıntılı bir çevik sözleşme ve hukuki danışmanlık gereksizdir. Ancak, önemli bir bütçe, uzun vadeli geliştirme veya iş açısından kritik hale gelen bir yazılım söz konusuysa, sözleşmenin hazırlanması veya gözden geçirilmesi gerekir. Fikri mülkiyet ve çıkış maddeleri, işler ters gittiğinde eksikliğini hissedeceğiniz unsurlardır.
Daha fazla bilgi edinmek veya hemen düzenlemek mi istiyorsunuz? Çevik yazılım geliştirme sözleşmesini inceleyin, öncelikle çevik yazılım geliştirme sözleşmesinin ne olduğunu okuyun ve çevik yazılım geliştirme sözleşmesinin hazırlanmasının maliyetini görün .
Sıkça Sorulan Sorular
Çalışma yöntemi (Scrum, sprint uzunluğu, roller), bütçe ve zaman çerçeveleri, sprint başına kabul edilen iş miktarı, fikri mülkiyet politikası, ek işler konusunda anlaşmalar ve bir çıkış politikası. Kapsam kasıtlı olarak açık bırakıldığı için, sözleşme öncelikle tek bir sabit nihai üründen ziyade bu çerçevelere odaklanmaktadır.
Sprint başına veya saat başına bir ücret ve bir bütçe tavanı veya sabit bir sprint sayısı belirleyin. Uzatma taleplerinin yalnızca yazılı talimat üzerine geçerli olacağı ve zaman baskısı altında kapsamda sapma olabileceği, ancak kaliteden ödün verilmeyeceği konusunda anlaşın. Bu şekilde, sınırsız maliyetler olmadan esnekliğinizi koruyabilirsiniz.
Her sprint için kabul kriterleri (tamamlanma tanımı), işin kabul edilmiş sayılacağı bir yanıt süresi ve haklı retler için bir çözüm mekanizması belirleyin. Son teslim tarihleri olmadan, işin tamamlanıp tamamlanmadığı belirsiz kalır ve ödemeler gecikir.
Özel çalışmalara ilişkin telif hakkı tedarikçiye aittir. Müşteri hakları edinmek isterse, sözleşmede bu hakların yazılı olarak açıkça devredilmesi gerekir. Lisans genellikle mevcut yapı taşları ve açık kaynak kodlu ürünler için geçerlidir. Ayrıca, müşterinin kaynak kodunu alacağı da kabul edilmelidir.
Anlaşmaya varılan bütçe ve zaman çerçevesi dahilindeki çalışmalar, içerik değişse bile sprintlerin bir parçasıdır. Ek bütçe, ek sprintler veya hedef dışı çalışmalar ek iş olarak kabul edilir ve önceden kararlaştırılmış bir ücret üzerinden yazılı onay gerektirir.
Bir bildirim süresi (genellikle mevcut sprintin sonunda), o sprintin tamamlanması ve ödemesi, kaynak kodunun, dokümantasyonun ve erişimin devri ve çıkış hakkını kullanmanın cezasız bir şekilde kabul edilen işin ödenmesi. Bu şekilde, tek bir tedarikçiye bağımlı kalmazsınız.
Hayır. Sınırlı bütçeli ve güvenilir bir tedarikçiye sahip küçük bir proje için, genel şartlar ve koşulları içeren bir sipariş onayı genellikle yeterlidir. Ancak, önemli bir bütçe, uzun vadeli geliştirme veya iş açısından kritik yazılımlar için, sözleşmenin ve özellikle fikri mülkiyet ve çıkış maddelerinin hazırlanması faydalı olacaktır.
