Sistem Geliştirmenin Tahmini Tutarının Sonradan Artırılması Mümkün mü?

Sistem geliştirme işi, hem sipariş veren kullanıcı tarafını hem de siparişi alan satıcı tarafını içine alan büyük bir iş gücü gerektirdiği için, herkesin aynı hızda projeyi ilerletmesi kolay bir iş değildir. Planlamanın son derece önemli olduğu bir iş olduğunu söylemeye gerek yoktur, ancak aynı zamanda sipariş veren kullanıcının uygun bilgileri toplayıp satıcıya açık bir şekilde iletebilmesi de her zaman mümkün olmayabilir. Geliştirme süreci belirli bir aşamaya geldiğinde, özellikle sonradan özelliklerin değiştirilmesi veya işlevlerin eklenmesi talep edildiğinde, bu ek maliyetlerin önceden belirlenen tahmini maliyetin üzerine eklenip eklenemeyeceği, işi alan taraf için oldukça önemli bir konudur.

Peki, bu tür haklar yasal olarak hangi durumlarda kabul edilir? Ayrıca, bu ek geliştirme ve işlev düzeltmeleri için ödenecek ücret neye göre belirlenir? Bu makalede, bu tür çeşitli soruları ele alıp düzenleyeceğiz.

Ek Geliştirme ve Fonksiyon Düzeltmeleri Ne Zaman Söz Konusu Olabilir?

Sistem geliştirme projelerinde, iş alındığında genellikle sözleşme türü ya bir taahhüt sözleşmesi ya da bir yarı vekalet sözleşmesi olur. Bu tür sözleşmelerde, işi alan tarafın yapması gerekenler (yani görevler) ve buna bağlı olarak alacakları ücret (yani haklar) bir çift olarak sözleşmede belirtilir. Dolayısıyla, ücretin belirlendiği iş kapsamına dahil olmayan işlerin sonradan eklenmesi durumunda, bu ek geliştirme veya fonksiyon düzeltmesi olarak kabul edilebilir. Tersine, iş kapsamına dahil olan durumlar için, işler başlangıçtaki özelliklere uygun (yani mevcut sözleşme çerçevesinde) olarak kabul edilir.

Not: Taahhüt sözleşmesi ve yarı vekalet sözleşmesi arasındaki farklar hakkında ayrıntılı bir açıklama başka bir makalede yapılmıştır.

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

Ancak, ekran üzerinde görünen fontun ince ayarları gibi her şeyi önceden belirlemek zorunda olursak, bunların hepsinin ek geliştirme olduğunu söylemek, sorunsuz ticareti ciddi şekilde engelleyebilir. Dolayısıyla, bu tür özelliklerin ayrıntılarına ilişkin tartışmaları da göz önünde bulundurduğumuzda, genel bir çizgi çekmek kolay olmayabilir. Ancak genel bir kılavuz sunacak olursak,

• Özellikler bir kez belirlendikten sonra, daha fazla ek özellik talep edildi
• Programın uygulaması zaten tamamlandıktan sonra, düzeltmeler talep edildi

gibi durumlarda, bu iddiaların hukuki olarak belirli bir geçerliliği olabileceği söylenebilir.

Ek Geliştirme ve Fonksiyon Düzeltmelerinin Tartışma Konusu Olduğu Dava Örnekleri

Onaylanmış Örnek: Temel Tasarımın Özelliklerini Sonradan Değiştirme Durumu

Aşağıdaki örnek, sonradan özelliklerin değiştirildiği bir durumu göstermektedir.

Yazılım geliştirme, ① gereksinim tanımlama, ② dış tasarım, ③ iç tasarım, ④ kaynak program oluşturma (program tasarımı, kodlama), ⑤ çeşitli testler (birim testi, kombinasyon testi, sistem testi) geliştirme süreçlerini takip eder (ortadan kaldırıldı) Başlangıç özellikleri (ortadan kaldırıldı) iç tasarım ve sonraki çalışmalarla gerçekleştirilir ve bu, bu dava geliştirme sözleşmesine dayalı ücret talep hakkı ve karşılık gelen iş kapsamı olarak kabul edilir.
Özellik değişikliği talebi, hukuki olarak, mütevekkilin başlangıç sözleşmesine dayalı iş kapsamını aşan yeni bir iş sözleşmesi başvurusu olarak kabul edilir ve bu durumda yüklenici ek iş ücreti sunmaz ve ek ücretin anlaşması olmadan ek işle ilgili işi tamamlarsa, mütevekkil ve yüklenici arasında belirlenmemiş bir ücretle yeni bir taahhüt sözleşmesi kurulmuş olur ve makul bir ek geliştirme ücreti ödeme yükümlülüğü doğar.

Osaka Bölge Mahkemesi, 29 Ağustos 2002 (Heisei 14) Kararı

“Karşılıklı ilişki”, “yeni sözleşme” gibi anahtar kelimeleri aklınızda tutmak, bu kararın anlaşılmasını derinleştirecek bir başlangıç noktası olacaktır.

Ayrıca, yukarıdaki kararda, başka bir çok ilginç nokta daha belirtilmiştir. Bu, düğmelerin yerleşimi veya yazı tipi gibi çok detaylı bölümlerin ince ayarının, burada bahsedilen özellik değişikliğine dahil olmadığıdır. İlgili bölüm aşağıdaki gibidir.

Yine de, yazılım geliştirme doğası gereği, dış tasarım aşamasında ekran üzerindeki yazı tipi veya düğmelerin yerleşimi gibi detayların belirlendiği bir durum değildir ve detaylar hakkında, özelliklerin belirlenmesinden sonra bile, taraflar arasındaki görüşmelerle bir dereceye kadar düzeltme yapılması normaldir. Bu durumu göz önünde bulundurarak, bu tür özelliklerin detaylandırılması taleplerinin bile özellik değişikliği olarak kabul edilmesi uygun olmaz.

Osaka Bölge Mahkemesi, 29 Ağustos 2002 (Heisei 14) Kararı

Kararda, “özelliklerin detaylandırılması” gibi ilginç bir kelime kullanıldı.

• Zaten belirlenmiş olan bir şeyi sonradan değiştirdiği durum
• Yaparken karar verilebilecek bir şey hakkında, bilerek karar vermeden ilerlediği durum

Yani, hukuki muamelelerin de farklı olması gerektiği düşüncesini ifade eden bir durum da söz konusu olabilir.

Diğer Onaylanan Örnekler

Ek olarak, kabul edilen durumlar arasında ek geliştirme ve işlev düzeltmeleri bulunmaktadır:

• İlk plana göre teslim edilen program sayısının yaklaşık iki katına çıktığı durum (Tokyo Bölge Mahkemesi, 22 Nisan 2008 (2008))
• Çalışma süresinin yaklaşık üç katına çıktığı durum (Tokyo Bölge Mahkemesi, 22 Ocak 2010 (2010))

Örneğin, bu tür bir düzenlemeye bakıldığında, çalışma süresinin uzatılmasının da geniş anlamda bir ek geliştirme olarak kabul edildiği ve belirli bir hukuki koruma sağlanabileceği görülmektedir.

“Ek Geliştirme Anlaşmaları ve Ücret Artışı” ile “İlk Sözleşmenin Yapılması” Farklı Konulardır

Bu konularla ilgili önemli bir nokta var ki,

1. “İki şirket arasında sistem geliştirme konusunda bir sözleşme (ilk sözleşme) resmi olarak yapıldı mı?” sorusu
2. “Bir kez resmi olarak yapılan sistem geliştirme konusunda, ek geliştirme anlaşması da ek olarak yapıldı mı?” sorusu

gibi durumlarda, mahkemenin karar verme kriterleri farklıdır. Açıkça söylemek gerekirse, mahkeme,

• 1. durumda katıdır (sözleşme belgesi olmayan durumlarda sözleşmenin yapıldığını kabul etmek zordur)
• 2. durumda ise nispeten hoşgörülüdür (ek geliştirme anlaşması belgesi olmasa bile, ücret artışını vb. esnek bir şekilde kabul eder)

diyebiliriz. 1. durum hakkında ayrıntılı bir açıklama başka bir makalede yapılmıştır.

https://monolith.law/corporate/system-development-contract[ja]

Reddedilen Örnek: Hukuki Açıdan Benzer Taahhüt İçeriklerinin Dahil Olduğu Durumlar

Ancak, öte yandan, ücret artışının kabul edilmediği dava örnekleri de mevcuttur. Aşağıda alıntıladığımız karar metnindeki durumda, sistem geliştirme konusunda bir kez hizmet sözleşmesi imzalandıktan sonra hizmetin içeriği değiştirildiği için, ücret artışının kabul edilip edilmeyeceği tartışılmıştır.

Bu davanın tartışma noktası, (1) davacının bu sözleşme kapsamında üstlendiği hizmetin içeriği nedir, (2) bu hizmet için davacı ve davalı arasında kapsamın genişletilip ücretin artırılacağına dair bir anlaşma yapıldı mı, (ortadan kaldırıldı), bu konulardır. (ortadan kaldırıldı)

Aslında, bu sözleşme, ücret miktarını davacının üstlendiği hizmet (taahhüt) için kesin bir karşılık olarak kabul eden bir taahhüt sözleşmesidir ve adım sayısı, birim fiyat vb. sadece davacının taahhüt ücretini hesaplarken iç belgelerdir ve adım sayısının artması gibi durumlar, taahhüt ücretiyle hiçbir ilgisi yoktur. (ortadan kaldırıldı)

Yukarıdaki tespitler doğrultusunda, davacının üstlendiği hizmetler 1987 yılı (Showa 62) 25 Şubat’ta değiştirildi ve sistem yönetimi, taahhüt iş maliyeti hesaplama ve yardımcı programların bir kısmı sınırlı hale getirildi ve geri kalanı davalının sorumluluğuna verildi. Ancak, değişiklik sonrası davacının hizmetleri, başlangıçtaki sözleşme kapsamındaki geliştirme hizmetleriyle aynıdır ve bu hizmetler için karşılık, bu davanın başlangıçta kesin ücret olarak kabul edilen ve taahhüt edilen hizmet ücretiyle tamamen kapsanmıştır.

Tokyo District Court, 12 Haziran 1995 (Heisei 7) Kararı

Bu kararda, hizmet sağlayıcının üstlendiği hizmetin içeriği değiştirilmiş olsa bile, bu geliştirme içeriği başlangıçtaki sözleşme kapsamında kalır ve başlangıçta vaat edilen ücretle kapsanması gereken bir şey olarak kabul edilmiştir.

Sonuç olarak, ücret miktarının hangi hizmetleri yapmayı öngörerek belirlendiği dikkate alınarak, bunun dışında kalan hizmetler için ek ücret taleplerinin kabul edileceği bir duruş olduğu düşünülebilir.

Ve sonuçta, ücretin hangi hizmetleri yapmanın karşılığı olduğu, sadece sözleşme ile değil, toplantı tutanakları gibi kanıtlarla da belirlenir. Toplantı tutanaklarının önemi hakkında aşağıdaki makalede ayrıntılı olarak açıklanmıştır.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Ek Geliştirme ve Fonksiyon Düzeltmelerinde Ücret Miktarı Nasıl Belirlenir?

Sistem geliştirme alanında, bir kez belirlendiği düşünülen özelliklerin sonradan değişmesi hiç de nadir bir durum değildir. Böyle bir durum her ortaya çıktığında, yeni bir yazılı sözleşme hazırlamak ve sözleşme işlemlerini ilerletmek gerçekçi olmayabilir. Eklemeler ve düzeltmeler gereken konular hakkında, özelliklerin içeriğini tekrar belirlemek ve bir anlaşma metni gibi bir şeyi topluca imzalamak mümkünse, bu tür prosedürlerin gerçekleştirilemediği ve projenin durduğu durumlarda ücret miktarını nasıl hesaplamalıyız?

Bu tür durumlarda başvurulması gereken madde olarak, aşağıda alıntıladığımız Ticaret Kanunu’nun 512. maddesi bulunmaktadır (altı çizili bölüm yazar tarafından çizilmiştir).

Ticaret Kanunu 512. Madde: Bir tüccar, işinin kapsamında başkası adına bir işlem yaptığında, makul bir ücret talep edebilir.

Bu maddede belirtilen ‘makul ücret‘ terimi, somut durumlara göre, sonuçta ne kadar olacağı sorun olmaktadır. Geçmiş yargı kararlarına bakıldığında, işin süresi, miktarı veya süresine orantılı olarak, maliyeti karşılaması gerektiği görüşü benimsenmiş gibi görünmektedir. Bu, sistem geliştirme işinin doğası gereği bir tür hizmet sektörü olması ve maliyetin temelde personel maliyeti olması nedeniyledir.

Dolayısıyla, Ticaret Kanunu’ndaki ‘makul ücret’ ifadesinin soyutluk derecesine rağmen, bu tür bir bağlamda ek ücret miktarını tahmin etmek, çok zor hesaplamalar gerektirmez. Aşağıda, bazı yargı kararlarına bakalım.

Vaka 1: İş Saatlerindeki Artışa Orantılı Olarak Ek Ücreti Kabul Eden Örnek

Bu durumdaki özellik değişikliğine dayalı geliştirme süresi, yukarıdaki toplam süre olan 257.5 kişi/gün olarak kabul edilmesi uygun olup, bunu kişi başı/gün başına geliştirme maliyeti olarak bu durumdaki geliştirme taahhüt sözleşmesi ile aynı olan 32,500 yen (Kısım 3’te, birim fiyat 650,000 yen [kişi başı/ay başına] olup, bir ayın çalışma günü 20 gün olarak kabul edildiğinde, kişi başı/gün başına geliştirme maliyeti 32,500 yen olur.) olarak dönüştürdüğümüzde, bu durumdaki özellik değişikliği talebine dayalı ek geliştirme maliyeti, 8,368,750 yen olarak kabul edilmesi uygun olur.

Osaka Bölge Mahkemesi, Heisei 14 (2002) 29 Ağustos Kararı

“Kişi başı/gün başına” anahtar kelimedir. Ek ücretin hesaplanmasının temelinde, iş saatlerinin kullanıldığını göstermektedir.

Durum 2: Program Sayısına Orantılı Ek Ücretin Kabul Edildiği Örnek

Bu durumda, ek kısmı da dahil olmak üzere uygun ücret miktarını incelediğimizde, bir bilgisayar sisteminin geliştirilmesinin maliyetinin büyük bir kısmının teknisyenlerin personel maliyeti olduğunu ve bu personel maliyetinin genellikle oluşturulan programın miktarına orantılı olduğunu göz önünde bulundurarak, başlangıçtaki sözleşme miktarı olan 23,250,000 yen’i ikinci denetimde tamamlanan 206 program sayısına böleriz ve bu programın her biri için birim fiyat üzerinden üçüncü denetimden geçen 414 program sayısını çarparız ve bu miktar olan 46,725,728 yen (23,250,000 ÷ 206 x 414 = 46,725,728) uygun olarak kabul edilir.

Tokyo District Court, April 22, Heisei 17 (2005)

Birçok sayı ortaya çıkmış olabilir, ancak sakin bir şekilde okuduğunuzda karmaşık bir hesaplama yapılmadığını anlayabilirsiniz. Başlangıçtaki sözleşme içeriğine dayanarak, “her bir programın birim fiyatını ne kadar olarak tahmin ettiğimizi” doğruladıktan sonra, sadece “birim fiyat x miktar” şeklinde basit bir çarpma işlemi yapıyoruz.

Vaka 3: Sürenin Uzunluğuna Orantılı Ek Ücretin Kabul Edildiği Örnek

Ve, Jō 3 sözleşmesinde, davacının Heisei 17 yılı (2005) Ocak’tan Mart’a kadar olan 3 aylık süre zarfında yarı zamanlı olarak yaptığı çalışmanın karşılığı olarak, 60 milyon yen belirlenmiştir. Ancak, aynı yılın Nisan ayından itibaren ücretsiz olarak yapılan çalışmalar bulunurken, önceki yıl olduğu gibi, aynı yılın Mart ayına kadar olan süreye kıyasla, yeni dönemin başlamasıyla birlikte ders kaydı vb. sistemlerin çalıştırılmasıyla aynı yılın Nisan ayından itibaren iş yükünün artması beklenmektedir. Bu durumlar göz önüne alındığında, yukarıda belirtilen 3 aylık çalışmanın karşılığı olarak belirlenen 60 milyon yen temel alınarak, davacının Heisei 17 yılı (2005) Nisan’dan Eylül’e kadar olan 6 aylık çalışması için ücretin, 120 milyon yen olarak belirlenmesi uygun olacaktır.

Tokyo Bölge Mahkemesi, Heisei 22 yılı (2010) 22 Ocak Kararı

Yukarıdaki karar, uzatılan süre için de, basit bir orantı hesaplamasıyla ek ücretin hesaplanacağını belirtmektedir.

Özet

Yukarıda belirtildiği gibi, birkaç dava örneğini sıraladığımızda, programcı ve mühendislerin ek ücretlerinin hukuki durumu hakkında belirli bir düzenlilik ve ortak noktaların göründüğünü düşünüyoruz. Yani, temel bir ilke olarak, harcanan emek, (teslim edilen programlar gibi) formal iş yükü, çalışılan saatler veya süreler gibi nispeten objektif göstergelere dayanarak, mümkün olduğunca basit bir şekilde hesaplama yapma eğilimini görebiliriz.

Detaylı bir prosedür veya mükemmel bir iş yükü tahmininde başarısız olmuş olmamızdan dolayı, bu tür ek geliştirmelerin veya işlev düzeltmelerinin ortaya çıktığını düşünürsek, harcanan emek kadar, yapılan işin formal miktarı kadar, harcanan zaman kadar ek ücretin ortaya çıkması, belki de çok sıradan bir hikaye gibi görünebilir. Ancak, sonuçta hizmet sağlayıcı tarafından bakıldığında, müşterinin çıkarlarını önceliklendirirken bile işlerin yürütülmesini hedeflerken, bu tür hakların hukuki olarak kabul edilebilir olma olasılığının, belirli bir kriz yönetimi açısından anlamlı olabileceğini düşünmüyor musunuz?