Sistem Geliştirme Projelerindeki 'Alevlenme' ile İlgili Hukuk Nedir?

Sistem geliştirme projesi, bir gecede başarılabilecek bir şey değildir ve çok sayıda insan, organizasyon, büyük miktarda para ve uzun süreli geliştirme süresi gibi birçok kaynağın yatırımı gerektirir. Bu makalede, sistem geliştirme projesindeki “yanma” fenomeninin, hukuki çerçeve içinde nasıl düzenlenebileceğini açıklarken, çözüm önerilerini de bir araya getireceğiz.

Projeler Neden “Alev Alır”

Bir IT sistemi, ne kadar büyük ölçekli bir proje olursa olsun, ancak çok sayıda oluşturulan program dosyası ve kaynak kodunun birikimi ile doğru bir şekilde işlev görebilir. Kullanıcı arayüzünden bakıldığında, işlemlerin basit ve özlü olduğu IT sistemlerinde bile, genellikle detaylı ve hassas bir yapıya sahip olduğunu hayal etmek zordur.

• Sadece teslim tarihi belirlenmiş, ancak özellikler ve gereksinimler belirsiz kalmış ve zaman geçmiştir
• Ekibin dikkati sadece şirket içi politika sorunlarına odaklanmış ve insan ilişkileri stresi nedeniyle birçok üye yarıda bırakmıştır
• PM başta olmak üzere yönetim kademesinde yetersiz müzakere yeteneği vardır ve üyelerden uygun raporlama, iletişim ve danışma talep edilmemektedir

Örneğin, belirli bir alev alma nedeni proje bazında çeşitli olabilir. Ancak hukuki açıdan bakıldığında, bir projenin alev alma nedenleri, birkaç farklı tip ile nispeten basit bir şekilde düzenlenebilir.

Yangın Tipi 1: Projenin Yarıda Kesilmesi Durumu

Sistem geliştirme sürecinde, projenin yarıda kesilmesinin tipik nedeni olarak, kullanıcı ve satıcı arasındaki iletişim eksikliği gösterilebilir. Aslında, bir sistem geliştirme projesi, satıcı tarafının sahip olduğu uzman teknik ve organizasyonel yeteneklerin yanı sıra, sonuçta bu sistemi kullanacak olan kullanıcı tarafının işbirliği ile gerçekleşir.

Bu nedenle, bir projeye karşı, her iki tarafın hangi rolleri üstleneceği konusunda belirsizliklerle proje ilerler ve belirli bir “iş yükü itme” durumu ortaya çıktığında, bu, projenin sorunsuz ilerlemesini engeller. Kullanıcı tarafının yükümlülükleri, satıcı tarafının yükümlülükleri ve her biri hakkındaki hukuki düşünceler için, lütfen aşağıdaki makalelere başvurun.

https://monolith.law/corporate/project-management-duties[ja]

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Her birinin hangi sorumlulukları taşıdığına dair ayrıntılı bilgileri yukarıdaki makaleleri kontrol ederek bulabilirsiniz, ancak buradaki konuşmanın ana noktası, bir sistem geliştirme projesinde, kullanıcı ve satıcının her birinin belirli bir sorumluluk taşıdığıdır. Genel bir ayrım olarak, gereksinim tanımlama, ekran vb. görünüm tasarımı (yani temel tasarım), kabul vb. kullanıcı tarafının işbirliği olmadan tamamlanmayacak bölümler, geçmiş kararlar ve yargı örnekleri tarafından kullanıcı tarafının işbirliği yükümlülüğünü kabul etmiştir.

Öte yandan, satıcı tarafı da, kullanıcı tarafının işbirliğini aldıktan sonra (ve aynı zamanda, yukarıda belirtilen türden işbirliği talep etme çabalarını gösterdikten sonra), projenin sorunsuz ilerlemesi ve engelleyici faktörlerin bulunması ve bunların giderilmesi için kapsamlı bir yükümlülük taşır.

Bu düşünce çerçevesinde, iç sistem olarak, kullanıcının içeriden yönetişimi uygulama yükümlülüğü ve satıcının dış uzman olarak uzmanlık ve teknik yeteneklerini sergileyerek görevini yerine getirme yükümlülüğünü her iki taraf da gösterir ve tüm anlaşmazlıkları adil bir şekilde ele almayı amaçlar. Mahkemeler bu tavrı sergilemektedir.

Ayrıca, bu tür “yarıda kesilme” durumlarının sıkça yaşandığı yer, kabul aşamasıdır. Kabul ile ilgili ayrıntılı açıklamaları aşağıdaki makalede bulabilirsiniz.

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

Bu tür durumlarda, bir kez anlaşmazlık yaşanırsa, geçmiş projelerin gelişimi, toplantıların içeriği vb. gibi objektif olarak doğrulanabilir kanıtlar önem kazanır. Bu nedenle, önceden kaydedilmiş belgelerin büyük bir önemi olacaktır. Kendi durumunuzu dezavantajlı hale getirmemek için, belge yönetiminin tamamlanması önemlidir. Sistem geliştirmedeki belge yönetiminin önemi hakkında daha ayrıntılı bir açıklama için, lütfen aşağıdaki makaleye bakın.

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

Yanma Türü 2: Kullanıcı Tarafından Kendi İsteğiyle İptal Edilmesi

Projenin ortasında, kullanıcı tarafından iptal edilme durumu da olabilir. Örneğin, yurtdışı ofisler dahil olmak üzere tüm personel yönetimini tek bir IT sistemi ile yönetmeye başladığınızı düşünelim, ancak şirketin yurtdışı genişleme stratejisi tamamen geri çekildi. Bu durumda, başlamış olduğunuz bu sistemin geliştirilmesi artık kullanıcı için gereksiz olabilir.

Aslında, bir şirkette kullanılan IT sisteminin nasıl oluşturulması gerektiği sorunu, “şirkette hangi işlemlerin olduğu” sorunu ile ayrılamaz. Dolayısıyla, organizasyon yapısı ve iş birimi yeniden düzenlemeleri, stratejik gözden geçirmeler gibi büyük değişikliklerin etkisi altında, gereken (veya gereksiz hale gelen) sistem gereksinimleri değişebilir.

Bu tür durumlar nedeniyle, projenin ortasında durdurulması durumunda da çeşitli hukuki sorunlar ortaya çıkabilir. Bu durumda genellikle, kullanıcının kendi isteği olduğu için, tamamlanma oranına göre ödeme talepleri gibi, tedarikçi tarafına da belirli hukuki haklar tanınır. Hangi tür sözleşmenin kabul edildiğine bağlı olarak, dayanak maddeler arasında farklılıklar olabilir, ancak içerik aşağıdaki gibi düzenlenebilir.

・Yapım Sözleşmesi Durumunda: Japon Medeni Kanunu 641 Madde
Japon Medeni Kanunu 641 Madde
→Yüklenici işi tamamlamadığı sürece, sipariş veren, her zaman tazminat ödeyerek sözleşmeyi iptal edebilir.
・Yarı Zamanlı Vekâlet Sözleşmesi Durumunda: Japon Medeni Kanunu 648 Madde 3 Fıkra (Duruma bağlı olarak, Japon Medeni Kanunu 651 Maddeye dayalı tazminat talebi de olabilir)
Japon Medeni Kanunu 648 Madde
→Vekâlet, vekilin kusurundan kaynaklanmayan bir sebep nedeniyle ifanın ortasında sona ererse, vekil, zaten gerçekleştirdiği ifanın oranına göre ücret talep edebilir.
Japon Medeni Kanunu 651 Madde
→1. Vekâlet, her iki tarafın da her zaman iptal edebilir.
→2. Taraflardan biri, diğer taraf için dezavantajlı bir zamanda vekâleti iptal ederse, bu taraf, diğer tarafın zararını tazmin etmelidir. Ancak, kaçınılmaz bir sebep varsa, bu durum geçerli olmayabilir.

Teslim Edilen Sistemin Eksikliklerinin Sonradan Ortaya Çıktığı Durumlar: Yanma Tipi 3

Kullanıcılar genellikle bir sistemin performansını ekran üzerindeki işlem hissiyatından anlarlar. Ancak, işi alan tarafın bakış açısından, asıl karmaşık olan şeyler genellikle veritabanı tasarımı veya tüm işlem yöntemlerini düşünerek test öğelerini belirlemektir.

Yani, başlangıçta sorunsuz çalışan bir sistem bile,

• Veri miktarı arttıkça işlem hızı yavaşlar.
• Günlük temel işlemlerde sorunsuz çalışan bir sistem, birkaç ayda veya birkaç yılda bir ortaya çıkan özel operasyonlarda hatalar oluşabilir.
• Yüzeyde, sonuçların doğru bir şekilde çıktı alındığı görülse bile, gerçekte mantık doğru olmayabilir. (Basit bir örnek vermek gerekirse, kullanıcıdan gelen 1+1 girişi karşısında, “2”nin doğru bir şekilde çıktı alındığı, ancak doğru hesaplama işleminin yapıldığı garanti edilmez. Her türlü hesaplama formülüne “2” çıktısını veren bir “mantık hatası”, genellikle sadece ekran işlemlerini yaparak bulunamaz. Bu anlamda, test sürecinde de belirli bir “teknik yetenek” gereklidir.)

Gibi durumlar gerçekten olabilir. Bu tür durumları hukuki bir bakış açısıyla analiz etmek gerekirse, olasılık olarak, tedarikçi tarafının proje yönetimi yükümlülüğünün ihlali, yani sivil hukuk anlamında eksik ifa sorunu olabilir.

Bu durumda, sözleşmede özellikle belirlenmiş bir düzenleme olmadığı takdirde, genellikle taahhüt sözleşmesi hükümleri geçerli olacaktır.

Bu durumda göz önünde bulundurulması gereken noktalar aşağıdaki gibi sıralanabilir.

https://monolith.law/corporate/defect-warranty-liability[ja]

Yukarıdaki gibi sıralanabilir.

Özet

Her bir sistem geliştirme projesi, çeşitli ve karmaşık aşamalardan geçerek ilerler. Ancak, hukuki açıdan bir projenin “alev alması” durumunda, bu makalede sunulan çerçeve, bir referans noktası oluşturur. Sistem geliştirme ile ilgili hukuki sorunlar, gerçekten çok çeşitli konuları içerir.

Ancak, sistem geliştirme işinin yapıcı düşünme yeteneği gerektirdiği gibi, buna bağlı risk yönetimi de, alanın genel görünümünü kaybetmemek suretiyle, daha yapıcı bir şekilde gerçekleştirilebilir.