Sistem Geliştirme Sözleşmesi Imzalarken Akılda Tutulması Gerekenler

IT sistemlerinin geliştirilmesi projelerinde yapılan sözleşmeler genellikle taahhüt sözleşmeleri ve yarı vekalet sözleşmeleridir. Hem kullanıcılar hem de satıcılar için, her tür sözleşmenin kullanılmasının avantajları ve dezavantajları vardır, ancak bu özellikleri ve sözleşme yaparken dikkat edilmesi gereken noktaları anlamak önemlidir. Bu makalede, IT sistem geliştirme hizmetlerindeki taahhüt sözleşmeleri hakkında açıklama yapacağız.

Sistem Geliştirme ve Taahhüt Sözleşmeleri

Taahhüt Sözleşmesi Nedir?

Taahhüt sözleşmesinin ne olduğunu anlamak için, öncelikle taahhüt sözleşmesinin kuruluş koşullarını doğrudan metinden kontrol etmek en önemli adımdır.

Madde 632

Taahhüt, taraflardan birinin belirli bir işi tamamlama sözü vermesi ve diğer tarafın bu işin sonucu için ücret ödeme sözü vermesi ile etkisini gösterir.

“İşin tamamlanması” en önemli anahtar kelimedir. Taahhüt sözleşmesinin tipik bir örneği, inşaat gerektiren bir binanın yapımıdır. Örneğin, belirli bir tarihe kadar bir ev veya bina inşa etmek, “işin tamamlanması” olarak kabul edilir ve borç yerine getirilmiş sayılır. Tersine, eğer inşaat ilerlemez ve teslim tarihi gecikirse, belirli koşullar altında, ifa gecikmesi olarak borç ifa etmeme sorumluluğu yüklenir. Ancak, eğer bir kez “işin tamamlanması” kabul edilirse, borç ifa etmeme sorumluluğu ortadan kalkar ve bundan sonra kusur garantisi sorumluluğu sorunu olur. Bu anlamda da, “işin tamamlanması” sonucuna büyük önem veren taahhüt sözleşmesinin özelliği budur. “İşin tamamlanması”nın ne zaman kabul edileceği hakkında aşağıdaki makalede detaylı bir açıklama yapılmıştır.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Taahhüt sözleşmeleri, sadece inşaat değil, büyük bir vizyon ve ayrıntılı planlama gerektiren sistem geliştirme projelerinde de sıklıkla kullanılır.

Taahhüt Sözleşmesi ve Yarı Vekâlet Sözleşmesi Arasındaki Fark Nedir?

Ayrıca, taahhüt sözleşmesinin “işin ‘tamamlanması'” sonucuna odaklanan bir sözleşme türü olduğunu anladığınızda, aynı zamanda yarı vekâlet sözleşmesinin özelliklerini de anlamaya başlarsınız. Bu, “tamamlanma” sonucuna değil, sürecin bir kısmına odaklanır. Örneğin, sonuç ne olursa olsun, işlemlerin uygun bir şekilde yürütülmesi durumunda ücret talep edilebilir (Madde 648, Fıkra 2) ve vekilin suçuna atfedilemeyen bir nedenle ifa yarıda kesilirse, bu orana göre ücret talep edilebilir (Madde 648, Fıkra 3).

Vekâlet sözleşmesi ve yarı vekâlet sözleşmesinin karşılaştırılması hakkında aşağıdaki makalede detaylı bir açıklama yapılmıştır.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Sistem Geliştirmede Neden Taahhüt Sözleşmesi Tercih Edilir?

Sistem geliştirme sözleşmelerinde, taahhütler çok sık kullanılır. Taahhütlerin sıkça kullanılmasının nedeni, işi sipariş eden kullanıcı tarafı ve işi alan satıcı tarafı için belirli avantajlarının olmasıdır.

Öncelikle, kullanıcı için işi taahhüt ile sipariş etmenin avantajı, borcun yerine getirilme koşullarının “işin tamamlanması” şeklinde kolayca netleştirilebilmesidir. Yani, (sonradan hatalar bulunsa bile, kusur garantisi sorumluluğu sorunu bir kenara bırakılırsa) “tamamlanmış” bir duruma gelmedikçe, ücret ödemesi genellikle yapılmaz. Bu, beklenenden daha fazla işçilik gerektiren veya süresi uzayan durumlarda, ödenecek ücretin artmasını istemeyen kullanıcılar için büyük bir cazibe olabilir. “Tamamlanmış” ürünlerle eşdeğer bir değişim olarak, sabit bir ücret ödemek, bütçe yönetimi açısından büyük bir kolaylık sağlar.

Öte yandan, işi alan satıcı tarafı için de, taahhüt ile sipariş almanın belirli avantajları olabilir. Taahhüt sözleşmesi, iyi bir şekilde ilerletilebilirse, yarı vekâlet sözleşmesinden daha büyük bir kar marjı sağlar.

“İşin tamamlanması”nın borcun yerine getirilmesi için bir gereklilik olduğu düşünüldüğünde, işi alan taraf açısından da, “tamamlama” sürecinde, malın maliyetine (sistem geliştirme durumunda, çoğunlukla personel maliyeti) ne kadar harcandığı önemli değildir. Bu şekilde, kar marjını artırmak isteyen satıcılar ve bütçe yönetimini kolaylaştırmak isteyen kullanıcılar arasında bir denge vardır, bu yüzden sistem geliştirmede taahhüt sözleşmeleri genellikle tercih edilir.

Sözleşme İmzalarken Dikkat Edilmesi Gerekenler

Elbette, kullanıcı ve satıcı her iki taraf için de sözleşmenin avantajları olsa da, özellikle satıcılar için, düşüncesizce sözleşme imzalamanın riskleri de vardır. Öncelikle, “işin tamamlanması” borcun yerine getirilmesi için gereklidir, bu da ürün tamamlanmadan genellikle borç yerine getirme sorumluluğundan muaf olunmayacağı anlamına gelir. Satıcı tarafının tahmin hataları nedeniyle, zarar edilse bile hala teslimat için zaman harcamak zorunda kalınması gibi sorunlar sıkça yaşanır.

Peki, sözleşme imzalamak için, sözleşme metninde nelere dikkat etmek gerekiyor? Aşağıda bunları tek tek inceleyelim.

Sistem gereksinimlerini ve kabul testi koşullarını önceden belirlemek

Sözleşmede önemli olan şey, “işin tamamlanması” koşullarını belirginleştirmektir. Genellikle, burada bahsedilen “işin tamamlanması” gereksinimleri, gereksinim tanımlama aşamasındaki anlaşma içeriğini ifade eder. Ancak pratikte, geliştirme süreci ilerledikçe, sonradan değişiklik yapılması gerekebileceği için, “işin tamamlanması” gereksinimleri de değişken olabilir. Bunlar da dahil olmak üzere, özellikle değişiklik geçmişinin belgelenmesi önemli olarak kabul edilir. Aşağıdaki makalede, hukuki bir bakış açısıyla, sistem geliştirme projelerinde değişiklik yönetiminin nasıl yapılacağı açıklanmaktadır.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Ayrıca, bu konuyla ilgili olarak, kullanıcı tarafının “kabul testi” hakkında da önceden anlaşma yapmak, sonraki sorunları önlemek için etkilidir. Ürünü teslim etmek istesek bile, kullanıcı tarafındaki yetkilinin ulaşılamaması veya cevap alınamaması gibi durumlar doğal olarak beklenir. Kabul testinin sonucunun belirsiz bir durumda bırakılmaması için, kabul testi için belirli bir tarih belirlemek yararlıdır. Bu, “varsayılan kabul maddesi” olarak adlandırılan bir şeydir, ancak bu konuda aşağıdaki makalede açıklama yapılmaktadır.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Telif hakkının transferi hakkında önceden anlaşma yapmak

Bir diğer sıkça sorun olan konu, telif hakkının transferidir. Telif hakkı, “oluşturan kişi” yani sistem geliştirme durumunda satıcı tarafının elde ettiği bir hak olmasına rağmen, hakların doğası gereği transfer veya devir de mümkündür. Bu nedenle, telif hakkını kullanıcıya devredip devretmeme konusunda da önceden anlaşma yapmak, sonradan sorun olmasını önleyebilir. Telif hakkının aidiyeti ve transferi hakkında aşağıdaki makalede detaylı bir açıklama yapılmaktadır.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Diğer Dikkat Edilmesi Gerekenler

Ayrıca, özellikle vekâletname benzeri unsurları dahil etmeden, sözleşmeyi bir sözleşme olarak imzalamak istiyorsanız,

• Ücreti çalışma saatine bağlı olmaktan çıkarın
• Sözleşme başlığında “Sözleşme” ifadesini belirtin
• Kusur garantisi sorumluluğu maddesini belirtin
• Ödemenin, sonuç veya ürün karşılığında eşdeğer bir değişim olduğunu belirtin

gibi noktalara dikkat etmek iyi olacaktır.

Unutmayın, sözleşme başlığına “Sözleşme” yazıldığında, her şeyin sözleşme olacağı gibi basit bir düşünceye sahip olmak yanıltıcıdır. Pratikte, başka bir şirketin sözleşme şablonu, içeriğin sözleşme mi yoksa vekâletname mi olduğu konusunda dikkatsiz bir şekilde kullanılır. Bir dava gibi durumlarla karşılaşıldığında, başlık metni gibi yüzeyel unsurlardan çok, sözleşme metninin genel içeriği ve önceki ticari uygulamalar gibi daha somut konular önemlidir. Bu noktaya da dikkat etmek önemlidir.

Özet

Yukarıdaki noktaları göz önünde bulundurduğunuzda, taahhüt üzerine yapılan sözleşme işlemleri daha kolay ve uygun bir şekilde gerçekleştirilebilir. Ayrıca, “ihale” kelimesi, taahhüt tipi bir sözleşme olsun, yarı vekâlet tipi bir sözleşme olsun her ikisinde de kullanılır. Ayrıca, “iş ihalesi” terimi genellikle taraflar arasında yarı vekâlet sözleşmesi olduğu niyeti olduğunda kullanılır. Bu tür ince terim farklılıklarını da dikkate almak daha iyi olacaktır.