Sistem Geliştirmede Teknik Özellik Belgesinde Olmayan Fonksiyonlar Yasal Olarak Ne Kadar Uygulanmalıdır?
Şirketlerde kullanılan IT sistemlerini geliştiren projeler, genellikle önceden belirlenmiş özelliklere göre oluşturulur. Ancak, bir yandan, bir tedarikçinin sistem geliştirme uzmanı olarak geliştirme görevlerini tamamen üstlendiğini düşünürsek, belirtimlerde yazılı olanları sadece mekanik olarak uygulamanın, kullanıcı tarafının beklentilerini düşürmeyeceği muhtemeldir. Bu makalede, “Belirtimlerde belirtilmeyen ancak geliştirme amacı göz önünde bulundurulduğunda, uygulamanın gerektiği programlar” hakkında, bu yükümlülüğü ne ölçüde üstlenmeliyiz konusunu açıklıyoruz.
Şartname Dışı Uygulamaların Yol Açtığı Hukuki Sorunlar
Tedarikçinin Görevlerinde Takdir Yetkisi Gereklidir
Sistem geliştirme gibi projelerle ilgili sözleşmeler ve bunlara bağlı çeşitli hukuki sorunların büyük özelliklerinden biri, işi alan tedarikçinin büyük bir takdir yetkisine sahip olmasıdır.
İlgili Makale: Sistem Geliştirmede Proje Yönetimi Görevleri Nedir?[ja]
Yine de, burada bahsedilen “takdir yetkisi”, sistem geliştirme sürecinin tamamına uygulanabilir bir durum değildir. Her bir süreci detaylandırdıktan ve daha ince görevlere ayırdıktan sonra, basit işlere yakın işlerin arttığı durumlar olabilir. Ancak genel olarak, bu tür görevlerin ayrıntılı hale getirilmesinden önce, yani üst akış süreçlerinde ne kadar ilerlerse, büyük bir takdir yetkisi olmadan işlerin yürütülmesi zorlaşır. Üst akış süreçlerinin, sözleşme türü olarak genellikle yarı vekâletle iyi uyum sağlamasının nedeni de bu noktada bulunabilir.
İlgili Makale: Sistem Geliştirmede Taahhüt Sözleşmesi ve Yarı Vekalet Sözleşmesinin Farkları[ja]
Takdir Yetkisi, Sıkı Geliştirme Süreçleri İçinde de Gösterilmelidir
Ancak, sistem geliştiren bir tedarikçinin büyük bir takdir yetkisine sahip olduğunu söylesek bile, müşterinin taleplerini “plansız” bir şekilde kabul etmek, sonraki süreçlere büyük zararlar verebilir. Bir IT sistemi, ince parçaların bir araya gelmesiyle oluştuğu için, yüzeyde küçük bir değişiklik olarak görünen bir durum bile, geliştirici tarafından bakıldığında önemli bir iş yükü değişikliği gerektirebilir. Ayrıca, sistem geliştirme spesifikasyonlarının değiştirilmesi konusunda, değişiklik durumlarının yönetim şeklini hukuki bir bakış açısıyla açıkladığımız aşağıdaki makaleler bulunmaktadır. Aşağıdaki makaleler, değişiklik yönetimi hakkında açıklamalar içerirken, teknisyenlerin bakış açısından spesifikasyon değişikliklerinin iş üzerinde ne kadar büyük bir etkisi olabileceğini de tartışmaktadır.
İlgili Makale: Hukuki Bakış Açısından, Sistem Geliştirmede Değişiklik Yönetiminin Nasıl Yapılması Gerektiği[ja]
Şartnamelere Takılı Kalmadan, Uzman Olarak Yapılması Gereken Nedir?
Sistem geliştirme projelerini sorunsuz bir şekilde ilerletmek için, geliştirme gereksinimlerini önceden tanımlamak ve buna göre planlı bir şekilde ilerlemek önemlidir. Öte yandan, önceden tanımlanmış gereksinimlere göre, sadece söylenenleri yapmak, sistem geliştirme uzmanı olarak tam bir rol oynayamayacağınız durumlar da olabilir. Bu tür bir ikilem içinde, “şartnamelerde belirtilmemiş olsa bile, uygulanması gereken şey nedir?” sorusu ortaya çıkar.
Yasal yükümlülükler, şartname ve sözleşme belgelerinin ‘amacı’na göre belirlenir
Uygulanması gereken içerik, sözleşme veya şartname belgelerinde belirtilmemiş olsa bile, yine de bu belgelerin ‘amacı’ yani ‘hangi anlam ve niyetle, bu şekilde bir düzenleme yapıldığı’ noktasından belirlenir. Aşağıda, bazı dava örnekleri ile birlikte inceleyelim.
Yükümlülüğün Reddedildiği Yargı Kararı Örneği
Aşağıda alıntılanan yargı kararı örneğinde, bir tedarikçinin geliştirdiği sistem, geçici olarak çalıştırıldıktan sonra, gerekli olan bazı özelliklerin eksik olduğu gerekçesiyle sözleşmenin feshini talep ederek bir anlaşmazlığa yol açmıştır. Kullanıcı tarafından eksik olduğu iddia edilen özellik “verinin otomatik güncelleme özelliği” idi ve bu özelliğin, söz konusu sistemin ana satış noktası olduğu iddia edildi. Ancak, mahkeme bu yükümlülüğü kabul etmedi.
Yukarıdaki tespitler doğrultusunda, bu sözleşme ve temel tasarım belgesi ile ayrıntılı tasarım belgesinde, ③ özelliğinin bu sistemin geliştirme hedefi olduğunu gösteren bir ifade bulunmamaktadır.
Davacı, ③ özelliğinin, davalının davacıya karşı bu sistemin ana satış noktası olduğunu iddia eder ve bu özelliğin gerekliliğini vurgular, ancak eğer bu iddia doğruysa, bu durumun sözleşme vb. belgelerde açıkça belirtilmesi gerekmekteydi ve böyle bir durum olmadan, bu özelliğin geliştirilmesinin kabul edildiğini düşünmek zordur.
Tokyo District Court, February 18, Heisei 21 (2009)
Bu karar, kesinlikle basit bir şekilde sadece sonucu çıkarırsak, “Tasarım belgesinde belirtilmemişse, olmayan bir şeyi yapmak zorunda değilsiniz” şeklinde de ifade edilebilir. Ancak daha doğru bir ifadeyle, bu tasarım belgesinin veya sözleşmenin belirtilip belirtilmediği gibi biçimsel gerçekler yerine, bu belgelerin “amacı” göz önünde bulundurularak bir karar verildi. Yani, “Tasarım belgesi veya sözleşmeye belirtilmemiş bir neden düşünüldüğünde, bu belirtinin karşılık gelen anlaşmasının da olmadığını düşünmek makuldür.”
Yazılı Olmasa Bile Uygulama Yükümlülüğünün Kabul Edildiği Yargı Kararları
Öte yandan, sözleşme veya teknik özelliklerde belirtilmemiş olsa bile, uygulama yükümlülüğünü kabul etmek gerektiğine dair yargı kararları da bulunmaktadır. Aşağıda alıntıladığımız yargı kararı, ilaç kullanım geçmişini yönetmek için bir sistem geliştirme konusunda, mevcut sistemden yeni sisteme veri aktarımı gerçekleştirilemediği ve bu nedenle yeni sistemin kullanılamadığı, kullanıcı tarafının sözleşmeyi feshettiği bir durumu ele almaktadır. Ancak, tedarikçi taraf, veri aktarımının iş kapsamının dışında olduğunu belirterek durumu tartışmaya açmıştır.
Yeni bir sistemin geliştirilmesi genellikle, mevcut sistemin kaldırılması ve verilerin aktarılması gibi işlemleri içerir. Bu tür işlemlerin önemi ve bununla ilgili hukuki sorunlar hakkında, aşağıdaki makalede detaylı bir açıklama yapılmıştır.
İlgili Makale: Eski Sistemden Yeni Sisteme Geçişte Karşılaşılan Hukuki Sorunlar[ja]
Mevcut sistemde zaten 50.000’den fazla hasta verisi saklanmaktaydı ve davacı, bu verileri kullanarak işlemleri verimli hale getirmeye çalışıyordu. Dolayısıyla, hasta verilerinin mevcut sistemden bu sisteme aktarılamaması durumunda, eczane işlemlerinde aksaklıkların yaşanacağı açıktır ve davacı temsilcisi de bunu doğal olarak fark etmiş olmalıdır. Ve bu sözleşmenin imzalanmasından önce, davacı temsilcisinin, davalı temsilcisine veri aktarımının mümkün olup olmadığına dair sorular sorduğu, davalı temsilcisi tarafından da kabul edilmiştir (ortada)… Davacı temsilcisi, 50.000’den fazla hasta verisini elle girmesi gerekeceği olasılığının yüksek olduğunu fark ederken, bu sistemin uygulanmasına karar vermesi oldukça zordur. Ayrıca, yukarıdaki (1) İ’de belirtildiği gibi, davalı, mevcut sistemin ilaç geçmişi verilerini bu sisteme aktaramadığı için, bu verileri kağıda basıp, bunları PDF dosyasına aktarma gibi işlemler yapmaktadır. Sözleşmede veri aktarımının önceden belirlenmediği halde, davalının bu tür zahmetli işlemleri hizmet olarak gerçekleştirdiğini düşünmek oldukça zordur.
Tokyo District Court, November 18, 2010 (Heisei 22)
Burada da önemli olan, sözleşmenin amacı ve sözleşme maddelerinin “amacı”dır. Eğer veri aktarımını iş kapsamının dışında olduğunu kabul ederek her iki taraf da sözleşmeyi imzalarsa, kullanıcı ve tedarikçinin her ikisinin de doğal olmayan bir niyetle sözleşmeyi imzaladığına dair bir durum ortaya çıkar. Yani, kullanıcının büyük miktarda el işçiliğini kabul ettiği ve tedarikçinin de bundan sonra kullanıcının işlerinde aksaklıklara neden olacağını bilerek projeye başladığı anlamına gelir, bu da son derece mantıksız bir durum olur.
Her İki Karardan Anlaşılanlar
Veri aktarımı konusunda, sözleşme veya teknik belgede bir ifade olmamasına rağmen, uygulama yükümlülüğünün kabul edilmesinin ardında, bir faktör olarak, “veri”nin, ekran görünümünde belirgin olmayan bir konu olduğu düşünülebilir. Önceki paragraftaki “zorunlu işlev eksikliği”, başlangıçta sistem ekranı veya görünümünde doğrudan belirgin olan bir şeydir. Bu nedenle, bir sistem geliştirme acemisi olsanız bile, teknik belgedeki eksiklikleri bulmak pek zor olmayacaktır. Öte yandan, veri aktarımı sorunu, bir sistem geliştirme acemisi için sürecin önemi, işin zorluğu ve iş yükü gibi konuların farkında olmayabilir. Bu nedenle, tedarikçi tarafının bu konuyu uzmanlıkla ve sorunsuz bir şekilde yönetmesi gerektiği düşünülebilir.
Bu şekilde düşünüldüğünde, teknik belge veya sözleşmedeki eksiklikler, kullanıcının “işbirliği yükümlülüğü” ile de yakından ilgili bir sorun olarak görülebilir. Yani, kullanıcının sözleşme imzalama ve teknik belge oluşturma sürecinde gerçekten “işbirliği yükümlülüğünü” yerine getirip getirmediği sorunu. Sistem geliştirme projelerinde, kullanıcının yerine getirmesi gereken hukuki yükümlülükler hakkında genel bir açıklama aşağıdaki makalede detaylı olarak ele alınmıştır.
İlgili Makale: Sistem geliştirme sipariş veren kullanıcının taşıdığı işbirliği yükümlülüğü nedir?[ja]
Yukarıdaki makaleyi de kontrol ederseniz, ekran ve zorunlu işlevlerin belirlenmesi gibi kullanıcı işbirliği taleplerinin büyük olduğu alanlar ve veri aktarımının gözden kaçırılması durumunda, durumun büyük ölçüde farklı olduğunu anlamak daha kolay olacaktır.
Şartnamede Olmayan Bir Geliştirmenin Ücreti Nasıl Düşünülmeli?
Bu makalenin konusuyla ilgili olarak, şartnamede olmayan bir şeyi yaptığınızda, ek ücret talebinin hukuki olarak kabul edilip edilemeyeceği noktası da merak konusu olabilir. Ek ücret talebinin mümkün olup olmadığı ve mümkünse tahmini tutarın nasıl hesaplanacağı konularında ayrıntılı açıklamalar aşağıdaki makalede bulunmaktadır.
İlgili Makale: Sistem Geliştirme Tahmin Tutarının Sonradan Artırılması Mümkün mü?[ja]
Yukarıdaki makalede, ücret ve karşılık gelen iş kapsamını aşan işlerin olup olmadığının önemli olduğunu belirtiyoruz. Yani, bu makale ile ilgili olarak, başlangıçta şartnamede yer almayan bir şeyin geliştirilmesi (bu makaledeki olumsuz örnek) durumunda, tedarikçi yanıt verirse, burada ek bir ücret talep edilebilir.
Özet
Sistem geliştirmede, bir tedarikçinin üstlenmesi gereken rol, bir yandan sözleşme ve şartname içeriğine göre belirlenir. Ancak, bir uzman olarak yüksek düzeyde güvene dayanarak görevlendirildikleri göz önüne alındığında, gerçek durumun her zaman formüle dayalı olarak belirlenmediği de anlaşılır. Ancak, bu iç gerçeği anlamak için de, hukukun büyük bir rol oynadığını anlamamız gerekiyor.
Category: IT
Tag: ITSystem Development