Sistem Geliştirmede Yasal Açıdan Toplantı Tutanaklarının Nasıl Saklanması Gerektiği

Bir şirketin başka bir şirkete sistem geliştirmeyi devrettiği durumlarda, genellikle genel müdürler arasında kurumsal mühürlerle imzalanan sözleşmeler ve sorumlu kişinin hazırladığı gereksinim belgeleri, sonuçta neyi ve ne zaman yapacakları konusunda her zaman net olmayabilir. Sistem geliştirmenin çoğunda, sorumlu kişi düzeyindeki e-postalar, telefon görüşmeleri ve toplantılar, başlangıçta belirsiz olan özelliklerin belirlenmesi, durum değişikliklerine uygun özellik değişiklikleri, ek özellik talepleri ve ortaya çıkan sorunlarla ilgili işbirliği talepleri gibi konular günlük olarak ele alınmaktadır.

Sistem geliştirmeyi sorunsuz bir şekilde ilerletmek ve olası bir anlaşmazlık durumunda hazırlıklı olmak adına, bir sistem geliştirme projesinin düzgün bir şekilde yönetilmesi için belge oluşturma ve yönetme süreçleri önem kazanmaktadır.

Bu makalede, sistem geliştirme ilerleme toplantıları gibi durumlar için toplantı tutanaklarının ve toplantı materyallerinin nasıl saklanması gerektiği konusunda hukuki bir bakış açısıyla bilgi verilecektir.

Sistem Geliştirmede Belge Yönetiminin Neden Önemli Olduğu

Sistem geliştirme projelerinde, onay toplantılarındaki tartışmaların içeriği ve projenin ilerlemesi ve geçmişi hakkında kayıt tutmak, hukuki bir bakış açısından da son derece önemlidir. Bunun nedenleri arasında aşağıdaki iki noktayı belirtebiliriz.

Gelecekteki Anlaşmazlıkları Önlemek İçin

Sistem geliştirme, genellikle hem kullanıcı tarafını hem de satıcı tarafını içeren birçok tarafın dahil olduğu bir projedir. Dolayısıyla, kullanıcı ve satıcı tarafının, her birinin ne kadar rol üstlendiği ve neyi yükümlülük olarak kabul ettiği konusunda anlaşmazlık olması durumunda, projenin ilerlemesi aksayabilir.

Ayrıca, birçok kişinin dahil olduğu bir proje olduğu için, bakış açısını değiştirirsek, “herkesin söylediği şey biraz farklı ve kimin doğru söylediğini anlamak zor” gibi iletişim sorunları sıkça ortaya çıkabilir.

Her iki tarafın anlayışında bir anlaşmazlık olup olmadığını kontrol etmek için, oluşturulan anlaşmanın içeriğini yazılı hale getirmek anlamlıdır ve ayrıca tüm ilgili tarafların aynı belgeyi (her birinin kendi zamanlamasında) kontrol edebileceği bir belgeye dönüştürmek, tüm tarafların adımlarını eşitlemeye yardımcı olur.

Not olarak, anlaşmazlıkların önceden önlenmesi için hukuki bilginin kullanılması, önleyici hukuk uygulamaları olarak adlandırılır.

Anlaşmazlık Durumunda Önlem Almak İçin

Ayrıca, yukarıda belirtilen önleyici hukuk bakış açısına benzer bir bakış açısıyla, belge yönetiminin önemini açıklarken, gerçekten bir anlaşmazlık durumunda, “kriz yönetimi” noktasını da belirtmek mümkündür.

Bir tür sorun ortaya çıktığında ve projenin sonuçları ortaya çıkmadan önce proje durdurulduğunda veya başlangıçta belirlenen teslim tarihine yetişilemediğinde, bir mahkeme durumunu düşünelim. Hem kullanıcı tarafı hem de satıcı tarafı için, “ortaya çıkan durumla ilgili kendi argümanlarımız var” demek istesek bile, kayıtlar yazılı hale getirilmediyse, kendi argümanlarınızı kanıtlamak mümkün olmayabilir ve mahkemede dezavantajlı bir durumda olabilirsiniz.

Özellikle “teslim tarihine yetişemedi” sorununun kaynağına bağlı olarak, “sorunun ne zaman ve nasıl tespit edildiği”, “özellik değişikliği talebinin ne zaman geldiği”, “kullanıcı tarafından ek özellik talebine satıcının nasıl bir yanıt verdiği” gibi konular, mahkemenin sonucunu belirleyebilecek önemli tartışma noktaları olabilir. Eğer bu durumda “söyledim, söylemedim” gibi sorunlar ortaya çıkarsa, adil bir anlaşmazlık çözümü beklemek zorlaşabilir.

Sistem Geliştirme Toplantılarında Tutulması Özellikle Önemli Olan Toplantı Tutanakları Nelerdir?

Sistem Geliştirmedeki Toplantı Türleri

Sistem geliştirme projelerinde, çeşitli toplantılar sürekli olarak planlanır ve ilerler. Bu durum, birçok kişinin projeye dahil olduğu düşünüldüğünde hiç de şaşırtıcı değildir. Programcılar ve mühendisler, işlerinin ilerlemesini düzenli olarak kontrol etmek için toplantılar düzenler. Ayrıca, uygulanan kodun bakım ve güvenlik açısından herhangi bir sorunu olup olmadığını kontrol etmek için, gerçek kodu gözden geçirme toplantıları da yapılır.

Ek olarak, sadece geliştirme ekibindeki kişilerin toplantıları değil, şirketin yönetim kurulu üyeleri veya yetkili sorumluların toplantıları da olabilir. Bu durumda, toplantı genellikle projenin genel yönünü ve politikalarını belirlemeye yöneliktir. Bu tür toplantılar, genellikle “Steering Committee” (Yönlendirme Komitesi) olarak adlandırılır.

Özellikle Dikkat Edilmesi Gereken Toplantı: Yönlendirme Komitesi

Sistem geliştirme sürecinde, farklı pozisyonlardaki kişilerin ve farklı amaçlara yönelik çeşitli toplantılar düzenlendiği daha önce belirtildi. Ancak, hukuki açıdan bakıldığında, özellikle önem verilmesi gereken toplantı Yönlendirme Komitesi’dir. İlerleme ve inceleme toplantılarına kıyasla, Yönlendirme Komitesi, çeşitli anlaşmazlıkların önlenmesi ve anlaşmazlık durumunda alınacak önlemler açısından belgelendirme önemini tam olarak anlamalıdır. Bunun nedenleri şunlar olabilir:

1. Yönlendirme Komitesi, yönetici düzeyindeki kişilerin düzenlediği bir toplantı olduğu için, genellikle önemli kararların alındığı bir toplantıdır ve kullanıcılar ile tedarikçilerin algıları hukuki açıdan önemlidir.
2. Personel düzeyindeki toplantılar genellikle, toplantı içeriğinin çeşitli tasarım ve özellik belgelerine yansıtılacağı bir durumdur ve belge eksikliği sorunu gerçekçi olarak beklenmez. (Ancak, eğer bu belgeler bile yetersizse, bu durumda da iyileştirme gereklidir.)

Yukarıdaki noktaları örnek olarak verebiliriz.

Steering Komitesi Toplantı Tutanaklarına İlişkin Yargı Kararları

Aşağıda, Steering Komitesi toplantı tutanaklarının, gerçek bir dava sürecinde, önemli bir kanıt olarak ele alındığı bir durumu tanıtacağız. Aşağıda alıntıladığımız karar metni, bir sistem geliştirme projesinin yarıda kalması durumunu ve tedarikçi tarafının proje yönetimi yükümlülüğünün ihlal edildiği bir durumu ele alıyor. Toplantı tutanaklarının içeriği, tedarikçi ve kullanıcıların başlangıçtaki anlayışını gösteren bir unsur olarak, dava sürecinde çok büyük bir önem taşıdı.

Tedarikçi, Steering Komitesi toplantı tutanaklarına dayanarak bu sistem geliştirme sürecini kabul etme konusunda, tutanakların içeriğinin kullanıcı tarafından düzeltildiğini ve işin gerçek durumunu tam olarak yansıtmadığını belirtti. Ancak, Steering Komitesi, bu sistem geliştirme sürecinde üst düzey yönetim kararlarını almak amacıyla kurulmuş bir yapıdır ve tedarikçi ve kullanıcıdan her ikisi de, bu sistem geliştirme sürecinin uygulama sorumluları katılmış ve genel değerlendirme, program ve iş ilerlemesi, önemli konuların kararlaştırılması gibi konuları ele almışlardır. Ve bu konuların tartışıldığı ana noktalar, toplantıdan sonraki iş gününün sabahına kadar tedarikçi tarafından tutanak haline getirilmiş, tutanak veritabanına kaydedilmiş ve bu tutanaklarla toplantının son kararları kaydedilmiştir. Tutanakları onaylarken, tedarikçi ve kullanıcı, tutanakların işi kaydetme anlamını tam olarak anlamış ve içeriği ve ifadesini gözden geçirerek, toplantının gerçek durumunu yansıtan bir şey olarak, içeriği onaylamıştır. Özellikle tedarikçi, sistem geliştirme işini yapan bir kişi olduğu için, bu tür bir tutanak oluşturma anlamını ve yöntemini doğal olarak iyi bilir. Dolayısıyla, onaylanan tutanaklar, Steering Komitesi’nin iş durumunu yansıtan bir şey olarak ele alınmalıdır ve özel bir durum kabul edilmedikçe, işin ilerleme içeriği vb. hakkında, orada belirtilen içeriğin o tarihte Steering Komitesi tarafından genel olarak kabul edildiği kabul edilmelidir.

Tokyo Yüksek Mahkemesi, Heisei 25 (2013) 26 Eylül

Mahkemenin duruşu, tedarikçi ve kullanıcının anlaşmasıyla oluşturulan toplantı tutanaklarının, bunların “kanıt” olarak belirli bir varsayım gücüne sahip olabileceği şeklindedir. Başka bir bakış açısından, tutanaklara çok rahat bir şekilde kayıt yapılırsa, bu durumun doğrudan bir kanıt olma riski olduğu ve bu konuda dikkatli olunması gerektiği söylenebilir.

Toplantı Tutanaklarında Hangi Detayların Kaydedilmesi Gerekir?

Toplantı tutanakları, bir dava durumunda kanıt olarak (veya dava olmasa bile, taraflar arasında sonraki müzakereleri sorunsuz bir şekilde ilerletmek için) önemli bir anlam taşır. Peki, tam olarak, toplantı tutanağında hangi bilgilerin belgelendirilip kaydedilmesi gerekiyor? Aşağıda bunları düzenliyoruz.

Tedarikçi Tarafından Kaydedilmesi Gereken Hususlar

Tedarikçi tarafı, bir projeye, sistem geliştirme uzmanı olarak proje yönetimi yükümlülüğü taşır. Bu yükümlülüğün tam olarak ne olduğu aşağıdaki makalede detaylı olarak açıklanmıştır.

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

Bu yükümlülüğü göz önünde bulundurarak, tedarikçi tarafının özellikle kaydetmesi gerekenler şunlardır:

1. Her bir geliştirme sürecinin tamamlandığı gerçeği ve tarihi
2. Kullanıcı tarafından alınan özellik değişiklikleri, ek özellikler gibi taleplere verilen yanıtların geçmişi
3. Kullanıcının kendi durumları nedeniyle, geliştirme işlerinin ilerlemesi durduğunda, işbirliği talep etmek için alınan önlemler ve bu sürecin geçmişi

Bunlar örnek olarak verilebilir.

Not: Yukarıdaki 3. madde ile ilgili olarak, örneğin kullanıcı tarafının kabul testi yapmaması durumunda tedarikçi tarafının düşünmesi gereken konular aşağıdaki makalede açıklanmıştır. Aşağıdaki makalede, tedarikçi tarafının kullanıcının kabul testini ne kadar işbirlikçi bir şekilde gerçekleştirdiği konusunda, mahkemenin kararının büyük ölçüde değişebileceği, gerçek karar metinlerine atıfta bulunarak açıklanmıştır.

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

Kullanıcı Tarafından Kaydedilmesi Gereken Hususlar

Ayrıca, tabii ki, kullanıcılar da kendi iç sistemlerini kullanacaklarından, sistem geliştirmede tedarikçinin geliştirme işlerine karşı belirli bir işbirliği yükümlülüğü taşırlar. Bu yükümlülüğün genel içeriği aşağıdaki makalede açıklanmıştır.

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

1. İstenilen özellikler, ekran görünümü vb., kullanıcı tarafından tedarikçiye iletilmesi gereken bilgilerin geçmişi
2. Tedarikçi tarafının sürecinde ortaya çıkan çeşitli sorunların geçmişi (örneğin, ekip üyelerinin ani ayrılışı veya tedarikçi tarafının yetersiz araştırması nedeniyle geliştirme sürecinin gecikmesi ve bu durumun nedenleri vb.)

Yukarıdaki 2. madde ile ilgili olarak, özellikle beklenmedik sorunlara kolayca yol açabilen durum, eski sistemin kaldırılması ve yeni sistemin geliştirilmesinin aynı anda ilerletilmesi gibi durumlardır. Eski sistemin verilerinin yeni sisteme taşınması sırasında özellikle sorunlar ortaya çıkabilir, ancak bu tür sorunlarla ilgili hukuki sorunların ayrıntılı açıklaması aşağıdaki makalede yapılmıştır.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Özet

Yukarıdakiler, hukuki bir bakış açısıyla sistem geliştirme alanındaki toplantı tutanaklarının nasıl tutulması gerektiğine dair bir rehber olacaktır. Pratik bilgilerin yanı sıra, ‘hukuk’, ‘sistem geliştirme’ ve ‘belge yönetimi’ gibi konuların bağlantısına dair farkındalığı da artırmak önemlidir. Sistem geliştirme, birçok kişi ve organizasyonu içine alarak büyük ölçekli ticari işlemlere kolayca dönüşebilen bir süreç olduğu için, bu sürece bağlı çatışmaların önlenmesi ve yönetilmesi önemlidir. Ve hukuki bir bakış açısıyla, kanıtların korunmasının gerekliliği, herkesin objektif olarak doğrulayabileceği ‘belgelerin’ varlığının büyük bir önem taşıdığını gösterir.

Kuşkusuz, tüm etkileşimlerin ve projenin ilerleyişinin tamamen dilimize çevrilmesi hem büyük bir yük oluşturacak hem de gerçekçi olmayacaktır. Ancak, hukuki açıdan önemli olan konuların ne olduğunu belirlemek ve bu önemli konuları uygun bir şekilde belgelemeye devam etmek, hukuk uzmanı olup olmadığına bakılmaksızın, iş dünyasındaki herkes tarafından geniş çapta bilinmesi gereken bir noktadır.