Sistem Geliştirme Sipariş Veren Kullanıcıların Üstlenmesi Gereken İşbirliği Yükümlülüğü Nedir?

Sistem geliştirme işi, geliştirilen sistemin ne kadar büyük ölçekli olursa olsun, çok sayıda insan gücü ve iş saati gerektiren bir süreçtir. Dolayısıyla, burada sadece geliştirmeyi üstlenen tedarikçi (vendor) tarafı değil, aynı zamanda sistem geliştirmeyi sipariş eden kullanıcı (user) tarafının da belirli bir işbirliği yükümlülüğü bulunmaktadır.

Bu, normal sipariş ve teslimat ilişkisinden farklı bir durumdur. Örneğin, bir IT sistemi yerine özel dikim bir takım elbise siparişi verdiğinizde, sipariş veren müşteri (kullanıcı) tarafının özellikle “yükümlülük” taşıması gerekmez. “Yükümlülük” taşıyan taraf, genellikle siparişi alan terzi (tedarikçi) tarafıdır. Ancak, çok sayıda insan gücü ve iş saati gerektiren IT sistemlerinde, kullanıcının da tedarikçiye “işbirliği” yapması gerekmektedir.

Bu makalede, tedarikçiye bırakılamayacak kadar karmaşık olan sistem geliştirme konusunda, sipariş veren tarafın hangi yasal yükümlülüklere sahip olduğunu açıklıyoruz.

Kendi Sisteminiz Olduğu İçin, Her Şeyi ‘Tamamen Bırakmak’ Yeterli Olmaz

Bir sistem geliştirme projesi olsa bile, genellikle birçok kişi ve organizasyonun dahil olduğu durumlar olabilir. Kodlama teknolojisinde yetenekli mühendisler ve programcılar elbette önemlidir, ancak bu kişilerin çıktılarını tek bir sonuçta birleştirmek için proje yöneticisinin rolü de önemlidir.

Ancak, tedarikçi tarafının ne kadar yüksek teknik ve organizasyonel yeteneğe sahip olduğu önemli değil, sistem geliştirmeyi tedarikçi tarafının gücüyle tamamlamak mümkün değildir. Örneğin, yalnızca şirket içinde kullanılan şirket içi terimler veya şirkete özgü iş bilgisi gibi konular hakkında, tedarikçi tarafının tek taraflı çabalarıyla bile bilgi edinme olanağı yoktur. Büyük ölçekli bir sistem geliştirmesi söz konusu olduğunda, genel eğilim, bu sistemin kullanıldığı şirketin de birçok kişi ve işi barındıran büyük bir şirket olmasıdır. Sistemi geliştirme projesini başarıya ulaştırmak için, aslında bilgisayar işinden önce, bu tür iş mantığının düzenlenmesi genellikle büyük bir ağırlık taşır.

Dolayısıyla, kullanıcı tarafının “Ben bir IT uzmanı değilim” gerekçesiyle pasif olmaması, aksine aktif olarak bilgi sağlaması, projenin sorunsuz ilerlemesine yardımcı olabilir. Bu anlamda, kullanıcı tarafının bir sistem geliştirme projesindeki rolü aslında hiç de küçük değildir.

Önceki Kararlar Işığında Kullanıcı Tarafının İşbirliği Yükümlülüğü

Peki, somut olarak, bir sistem geliştirme projesinde, kullanıcı tarafının taşıdığı işbirliği yükümlülüğü nedir? Bu konuda, geçmiş kararlarda birçok ipucu bulunmaktadır.

Mahkemede, satıcı tarafının (davalı) teslim tarihindeki gecikme konusunda, kullanıcının (davacı) karar verme sürecindeki gecikmeler vb. nedeniyle, kullanıcının geliştirme sürecine olan işbirliği yükümlülüğü tartışma konusu olmuştur. Bu konuda mahkeme, kullanıcı tarafının işbirliği yükümlülüğünü ihlal ettiğine karar vermiş ve satıcı tarafının borç ihlali sorumluluğunu reddetmiştir. (Sözleşmenin feshi kabul edilmiş olsa da, burada da %60 oranında kusur indirimi uygulanmıştır.)

Bu bilgisayar sistem geliştirme sözleşmesi, özelleştirilmiş bir sistem geliştirme sözleşmesi olduğundan, bu tür bir özelleştirilmiş sistem geliştirme sözleşmesinde, satıcı (satıcı) tek başına sistemi tamamlayamaz. Bu nedenle, kullanıcı (kullanıcı) geliştirme sürecinde, iç görüşlerini doğru bir şekilde ayarlayıp görüşlerini birleştirmeli, hangi özellikleri istediğini açıkça satıcıya belirtmeli, satıcı ile birlikte, istenen özellikler üzerinde çalışmalı, sonunda özellikleri belirlemeli, ayrıca, ekran ve formaları belirlemeli, sonuçları kabul etmeli vb. rolleri paylaşmalıdır.

Tokyo District Court, March 10, 2004 (Heisei 16)

Bu karar, sistem geliştirmenin kullanıcı tarafıyla ortak bir çaba olduğunu belirtmenin yanı sıra, “hangi noktalarda işbirliği yapılması gerektiği” konusunda da açıklama yapmaktadır. Bu, oldukça aydınlatıcı görünmektedir.

Deneme amaçlı, yukarıdaki karar metnini, sistem geliştirme IT terimlerine çevirelim.

Bu şekilde düzenleyebiliriz. Bunların hepsi, IT sistemine olan uzmanlığın ne kadar gelişmiş olursa olsun, kullanıcının işbirliği olmadan tek başına yapılamaz. İstenen özellikler veya ekran düzeni gibi şeyler temelde kullanıcı tarafından belirlenmelidir ve ayrıca istenen şeyin gerçekleştirilip gerçekleştirilmediği de yalnızca kullanıcı tarafından kontrol edilebilir.

Ayrıca, satıcıya proje yönetimi yükümlülüğü yüklendiği gibi, kullanıcıya da işbirliği yükümlülüğü yüklendiğinden, kullanıcının yukarıdaki süreçlerde işbirliği yükümlülüğünü ihlal ederse, tersine, satıcı tarafından kullanıcıya borç ihlali veya haksız fiil temelinde tazminat talep edilebileceği düşünülebilir.

Sonradan Talep Edilen Özellik Değişiklikleri Nasıl Yorumlanır?

Sistem geliştirme projelerinin kullanıcılar ve satıcılar arasında ortak bir çalışma olduğunu varsayarsak, buradan daha ileri bir tartışmaya geçeriz. Bu, “Kullanıcıların sonradan özellik ekleme veya düzeltme talep etmesi ve bu durumun teslim tarihini zorlaştırması durumunda, sorumluluk kimin üzerine olacak?” sorusudur.

Sistem geliştirme genellikle gereksinim tanımlaması ile başlar ve temel tasarım, ayrıntılı tasarım, üretim (program uygulaması), test gibi sıralamalarla, olabildiğince geri dönüş olmadan ilerlemeyi hedefler (genellikle Waterfall Modeli olarak adlandırılır). Ancak, bazı durumlardan dolayı, önceki aşamada bir eksiklik olduğu ortaya çıktığında, geri dönüşlerin oluşması da sıkça karşılaşılan bir durumdur.

Bu tür durumlarda, teslim tarihinin tutturulamaması durumunda nasıl düşünmeliyiz? Geçmişteki kararları incelediğimizde, ek işlerin ortaya çıkış zamanlamasına bağlı olarak sonuçlarda farklılıklar olduğu görülebilir.

Ek İşlerin Dış Tasarım ve Diğer Özelliklerin Belirlenmesinden Önce Talep Edildiği Durumlar

Yukarıda belirtilen kararda, temel tasarım aşamasında (program uygulama aşamasından önce) kullanıcıdan alınan ek geliştirme talepleri hakkında, bu tür taleplerin kendilerinin özellikle işbirliği yükümlülüğü ihlali olmadığı belirtilmiştir.

Kullanıcıların satıcılara karşı, temel tasarım aşamasında sistemle ilgili çeşitli taleplerde bulunması, bu tür sistem geliştirme süreçlerinde doğaldır ve ayrıca, uzmanlık bilgisi olmayan davacı kullanıcı için, bu taleplerin ek ücret veya teslim tarihi erteleme gibi şeyleri gerektirip gerektirmediği, iş sürecine engel olup olmadığı gibi şeyleri doğru bir şekilde değerlendirmek zordur. Bu nedenle, davacı kullanıcı, ek ücret veya teslim tarihi erteleme gibi talepleri kendiliğinden sınırlamalıydı gibi bir durum söz konusu olamaz. Aksine, davacı kullanıcı ek ücret veya teslim tarihi erteleme gibi taleplerde bulunduysa, proje yönetim yükümlülüğü taşıyan davalı, davacı kullanıcıya bu durumu bildirmeli, talebin geri çekilmesi veya teslim tarihi erteleme gibi konuları tartışmalı ve geliştirme çalışmalarının aksamamasını sağlamalıdır.

Tokyo District Court, March 10, 2004 (2004)

Bu kararda, kullanıcı tarafının da belirli bir işbirliği yükümlülüğü olduğu kabul edilirken, kullanıcının kesinlikle bir sistem geliştirme uzmanı olmadığı hususunun dikkate alınması gerektiği belirtilmiştir. Yani, bir sistem geliştirme uzmanı olmayan bir kullanıcının, sistem içeriğinin belirlenmesine kadar olan süre zarfında, (bazı durumlarda bile sipariş verme konusunda deneyimsiz olabilir) taleplerini parça parça ve küçük miktarlarda sunması normaldir ve özellikle bu taleplerin teslim tarihini gözden geçirmeyi gerektirecek durumlar için “kendi başına farkına varmalı” gibi bir beklenti aşırıdır.

Yine de, burada satıcıya yüklenen yükümlülük, temelde teslim tarihinin ertelenmesi gibi taleplerde bulunma (veya teslim tarihi değiştirilemiyorsa, ek taleplerin tamamen geri çekilmesini önerme) gibi iletişim çabalarını ifade eder. Dolayısıyla, kullanıcının tüm taleplerini kabul ettikten sonra, ilk belirlenen tarihte teslim etme yükümlülüğünün tamamını içerdiği anlamına gelmez, bu nedenle bu konuda dikkatli olunmalıdır.

Ek İşlerin Üretim veya Test Aşamasından Sonra Talep Edildiği Durumlar

Yukarıdaki kararın içeriğini tersine çevirirsek, özelliklerin zaten belirlendiği bir durumda ek geliştirme ne sonuç verirdi, bunu aynı zamanda bir dereceye kadar tahmin edebiliriz. Bu durumda, bu tür taleplerin kabul edilmesi zor olacaktır. Evet, kullanıcı ve satıcı arasında, geliştirme işine ilişkin anlayışta büyük bir fark vardır, bu durum özellikler belirlenmeden önce de, belirlendikten sonra da değişmez.

Ancak, özellikler belirlendikten sonra sipariş içeriğini değiştirmek veya eklemek, işlerin yeniden yapılmasını gerektirebilecek bir durumdur. Bu tür durumlarda, teslim tarihinin gecikmesi hakkında “müşteri olduğu için taleplerde bulunması doğaldır” şeklinde savunma yapmak genellikle zordur. Dahası, çok sayıda özellik değişikliği veya özellik ekleme, sonradan ortaya çıkan bir durum, baştan beri tamamlanmış olması gereken temel tasarım gibi üst düzey süreçlerde bile kullanıcı tarafının işbirliği yükümlülüğünün ihlal edildiği sorusunu gündeme getirir.

Bu nedenlerle, özellikler bir kez belirlendikten sonra yapılan özellik değişiklikleri, bunun sonucunda oluşan teslim tarihi gecikmelerini satıcı tarafının sorumluluğu olarak kabul etmek gerçekçi değildir. Yukarıda belirtilen karar metninden, bu tür bir anlamın da aynı anda çıkarılması uygun olacaktır.

Ayrıca, bu tür kararlar, sadece sözleşme metni değil, sistem geliştirme ilerlemesine uygun toplantı tutanakları gibi kanıtlarla da verilme eğilimindedir. Toplantı tutanakları hakkında ayrıntılı bir açıklama aşağıdaki makalede bulunabilir.

İlgili Makale: Sistem Geliştirmede Toplantı Tutanaklarının Hukuki Açıdan İncelenmesi[ja]

Özet: Gereksinim tanımlamanın kullanıcı süreci olduğunu unutmamak önemlidir

Gereksinim tanımlama, tedarikçi tarafının yeteneklerini sergileme noktası olmasına rağmen, öncelikle kullanıcı tarafının işi olduğunu akılda tutmak önemlidir. Bu, kendi şirketinizin kullanacağı bir sistem olduğundan, dış uzmanların yardımıyla oluşturulmuş olsa bile, hukuki olarak kendi şirketinizin yönetişiminin geçerli olduğu ve olması gereken bir alan olduğunu varsayabiliriz.

Kullanıcı tarafı geliştirme sürecine işbirlikçi olmazsa, proje alev alsa bile, mahkemelerin kullanıcı tarafına da sert bir görüş sunabileceği olasılığının farkında olmalısınız.