Agile Geliştirmeye İlişkin Hukuki ve Sözleşme Sorunları Nelerdir?

Sistem geliştirme sürecinde çeşitli metodolojiler bulunmaktadır. En klasik ve genel olanı Waterfall (Şelale) modelidir ve birçok sistem geliştirme hukuk kitabı da bu modeli temel alarak tartışılmaktadır. Bu makalede, kitaplardan ve benzeri kaynaklardan bilgi edinmesi zor olan Agile (Çevik) geliştirme modeline dayalı sistem geliştirme hakkında, hangi hukuki sorunların olabileceğini açıklıyoruz.

Agile Geliştirme Modeli ve Hukuk

Sistem Geliştirmede Modellerin Rolü

Sistem geliştirme projelerinde, genel ilerlemeyi takip etmek için bir çerçeve olarak geliştirme modelleri bulunmaktadır. Bu modellerin en bilineni, “Şelale Modeli”dir. Yani, bir nehirdeki suyun “yukarıdan” “aşağıya” doğru tek seferde akması gibi, gereksinim tanımlama, tasarım, uygulama, test gibi her aşamayı tek seferde tamamlama anlamına gelir. Bu model, işlemlerin tekrarını ve gereksiz işleri azaltmayı hedefler ve planlı bir şekilde işleri ilerletmek için uygundur.

Diğer yandan, Agile geliştirme modelinde, küçük programlar uygulanır ve test edilir. Bu küçük programların uygulanması ve test edilmesi süreci tekrarlandıkça, büyük bir sistem oluşturulur. Bu sistem geliştirme modellerinin daha detaylı açıklaması ve her iki geliştirme modelinin avantajları ve dezavantajlarının karşılaştırılması aşağıdaki makalede daha detaylı olarak ele alınmıştır.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Agile Geliştirme Modelinin Özellikleri

Agile geliştirme modelinin en büyük avantajı, hızlı bir şekilde gerçek işlere başlama yeteneğidir. Gereksinimlerin tanımlanması ve tasarım belgelerinin oluşturulması gibi “üst akış” işlemleri ve program uygulama işlemleri ayrılmamıştır, bu nedenle özelliklerin eklenmesi, düzeltmeler, özellik değişiklikleri gibi durumlara da dahil olmak üzere, esnek bir şekilde yönlendirme yapılabilir. Hukuki açıdan bakıldığında, Agile geliştirme modelini başarılı kılmak için özellikle önemli olan nokta, belge yönetimi ve değişiklik yönetiminin nasıl yapılacağıdır. Agile geliştirme modelinde, Şelale modeli kadar, roller ve sorumluluklar net bir şekilde ayrılmamıştır. Ayrıca, “yönetim” yerine uygulama ve başlama “hızına” odaklanan bir yöntem olduğu için, çeşitli tasarım belgeleri, özellik belgeleri, toplantı tutanaklarının eksikliği kolayca ortaya çıkabilir.

Daha da önemlisi, değişiklik yönetimi konusunda, Agile geliştirme modeli değişikliklere hızlı bir şekilde yanıt verme yeteneği nedeniyle, onay sürecini atlayarak, saha düzeyinde özellik değişikliği taleplerine yanıt verirken proje alev alabilir. Bu durumda, “sonradan değişikliklere hızlı yanıt verme” yeteneği, kendi başına bir proje riski haline gelebilir.

Agile Geliştirme Sürecinde Belge Yönetimi ve Değişiklik Yönetiminin Nasıl Yapılacağı

Belge Yönetiminin Önemi

Agile geliştirme modeline dayalı geliştirme projelerinde, hukuki açıdan endişe duyulan nokta, sözlü iletişimin birikmesi ve belge eksikliğine yol açmasıdır. Bu konuda, belge yönetiminin neden bu kadar önemli olduğu konusunda, aşağıdaki makalede detaylı bir açıklama yapılmıştır.

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

Bahsi geçen makalede, anlaşmazlıkların önlenmesi (yani “önleyici hukuk”) ve anlaşmazlık durumunda kanıtların korunması (yani “kriz yönetimi”) olmak üzere iki açıdan, sistem geliştirme projelerinde belge yönetiminin önemini açıklamaktadır.

İletişim Danışma Kurulu’nun Kurulması Belge Yönetiminde Etkilidir

Agile geliştirme modeli benimsendiğinde, su şelalesi modelinin aksine, önceden belirlenmiş net bir planın olmaması söz konusudur. Bu nedenle, sadece plan ve gerçekleşme arasındaki sapmayı yönetmek yeterli olmayıp, saha çalışmalarının mali ve zaman açısından maliyeti artırma riski vardır.

Bu nedenle, sorumlu kişinin proje ilerlemesini düzgün bir şekilde sağlamak için düzenli iletişim danışma toplantıları düzenlemesi etkili bir önlem olabilir. Küçük ölçekli geliştirme durumunda, düzenli iletişim danışma toplantıları düzenlemek yerine, sorumlu kişilerin zaman zaman bir araya gelmesi genellikle tercih edilir. Ancak, Agile geliştirme modelinde, toplantılarda zamanında ele alınmayan konuların riski genellikle daha yüksektir. Bu nedenle, düzenli iletişim danışma toplantılarının düzenlenmesi, sözleşme belgelerine dahil edilmesi güvenli olacaktır. Kuralların belirlenmesi konusunda, Japon Ekonomi Bakanlığı model sözleşmesi aşağıdaki gibi belirtilmiştir.

(İletişim Danışma Kurulu’nun Kurulması)

Madde 12 A ve B, işin tamamlanana kadar ilerleme durumu, risk yönetimi ve raporlama, A ve B tarafından ortak çalışma ve her birinin görev dağılımının uygulanma durumu, sistem özelliklerinin belirlenmesi, sorunların tartışılması ve çözülmesi ve diğer işlerin sorunsuz bir şekilde yürütülebilmesi için gereken konuları tartışmak üzere, İletişim Danışma Kurulu’nu düzenler. Ancak, (ortadan kaldırıldı).

2. İletişim Danışma Kurulu, prensip olarak, her bir sözleşmede belirlenen sıklıkta düzenli olarak düzenlenir ve buna ek olarak, A veya B’nin gerekli olduğunu düşündüğü durumlarda düzenlenir.

3. İletişim Danışma Kurulu’na, A ve B’nin sorumluları, baş sorumlular ve sorumlu kişinin uygun gördüğü kişiler katılır. Ayrıca, A ve B, İletişim Danışma Kurulu’nda gereken kişilerin katılımını talep edebilir ve diğer taraf, makul bir neden olmadıkça, buna uymalıdır.

4. B, İletişim Danışma Kurulu’nda, A ve B arasında ayrıca belirlenen formatta bir ilerleme yönetim raporu hazırlar ve sunar ve bu ilerleme yönetim raporuna dayanarak ilerleme durumunu kontrol eder ve gecikme durumunun olup olmadığını, gecikme durumunun nedenini ve çözümünü, bu bölümde belirlenen ilerleme yapısının değişikliğinin (personel değişikliği, artış, azalış, yeniden taahhüt edilen değişiklikler vb.) gerekip gerekmediğini, güvenlik önlemlerinin uygulanma durumunu, her bir sözleşmenin değiştirilmesi gereken durumların olup olmadığını, her bir sözleşmenin değiştirilmesi gereken durumların olması durumunda içeriğini ve diğer konuları gerektiği gibi tartışır ve kararlaştırılan konuları, devam eden incelemeleri ve devam eden inceleme konularının olduğu durumlarda inceleme programını ve incelemeyi yapan tarafları belirler.  

(Aşağıdaki 5., 6. ve 7. maddeler atlanmıştır.)

İletişim Danışma Kurulu’nun varlığına, sözleşme maddeleri ile belirli bir meşruiyet sağlanmış ve diğer ad hoc toplantılardan farklı bir anlam yüklenmiştir.

Değişiklik Yönetiminde İletişim Toplantılarını Kullanma Yolu

Ayrıca, Agile geliştirmede, her iki tarafın başlangıçta anlaştığı konuların sonradan değiştirilmesi bir ön koşul olur. Bu nedenle, sonradan yapılan özellik değişikliklerinin durumunu nasıl yöneteceğimiz de çok önemlidir.

Bu durumda, iletişim toplantıları düzenli olarak yapıldığında, değişiklik yönetimi ve uygulama yöntemleri de çok daha sorunsuz hale gelir. Örneğin, değişiklik görüşmeleri iletişim toplantılarında yapılır ve bir tarafın değişiklik görüşmesi talebinde bulunması durumunda, diğer tarafın bu görüşmelere katılma yükümlülüğü sözleşmeye dahil edilir. (Aşağıda, Japon Ekonomi, Ticaret ve Sanayi Bakanlığı’nın (METI) model sözleşmesinden bir hüküm alıntılanmıştır.)

(Değişiklik Yönetimi Prosedürü)

Madde 37, Taraflardan biri, diğer tarafın (ortadan kaldırılan) değişiklik teklifini aldığında, bu alım tarihinden itibaren ○ gün içinde, aşağıdaki konuları içeren bir belge (bundan sonra “Değişiklik Yönetim Belgesi” olarak anılacaktır.) sunar ve taraflar, Madde 12’de belirtilen İletişim Toplantısında bu değişikliğin kabul edilip edilmeyeceği konusunda görüş alışverişinde bulunur. (Aşağıda, belirtilen konular hakkında daha fazla bilgi verilmiştir.)

Yukarıdaki hükümün ana noktaları aşağıdaki gibi özetlenebilir:

• Değişiklik taleplerini kabul etme yöntemini “Değişiklik Teklif Belgesi” adlı bir formatla standartlaştırma
  
• Teklif belgesini aldıktan sonra, bunun hakkında görüşme yapılacak tarihe bir süre belirleme → “◯ gün içinde” gibi bir ifade yerine, “hemen” gibi bir ifade kullanmayı düşünebilirsiniz.
  
• Değişikliğin kabul edilip edilmeyeceği konusunda görüş alışverişinde bulunulacak yerin “İletişim Toplantısı” adlı bir toplantıya standartlaştırma
  

Yani, “değişiklik talebinde bulundum, bulunmadım”, “değişikliğin kabul edilip edilmeyeceği konusunda yanıt verdim, vermedim” gibi algı farklılıklarını önlemek için prosedürün yöntemini açıkça belirlemektedir.

Dürüstlük Yükümlülüğü ve İyi Niyet İlkesine Olan Anlayış Sorgulanıyor

Bu zamana kadar, “İletişim Konseyi”, “Değişiklik Müzakereleri” gibi kontrat maddelerinin modellerini tanıttık. Ancak, bunların temel anlayışı için önemli olan şey, “Dürüstlük Yükümlülüğü” ve “İyi Niyet İlkesi” gibi konular olacaktır. Aslında, Agile geliştirme modeli, sipariş veren ve siparişi alan arasındaki güven ilişkisi olmadan ilerlemekte zorlanabilir. Çünkü, gerçek işe başlama hızını ön planda tutar ve başlama süreci genellikle minimuma indirilir. Bu nedenle, karşı tarafa “Dürüstlük Yükümlülüğü” getiren maddeleri eklemek de iş uygulamalarında yaygınlaşmaktadır.

Madde 4, Fıkra 3: Değişiklik müzakerelerinde, değişikliğin konusu, değişikliğin olabilirliği, değişikliğin bedel ve teslim süresine etkisi vb. konuları göz önünde bulundurarak, her iki taraf da değişikliği gerçekleştirip gerçekleştirmeyeceği konusunda dürüstçe müzakere eder.

Bu, başlangıçta güven ilişkisine dayanarak ilerleyen müzakerelerde, aniden “Sözleşme değişikliğine uymak ya da uymamak tamamen teklif alınan tarafın özgürlüğüdür ve zorunlu olarak uyma yükümlülüğü yoktur” gibi, şekilci hukuk teorileriyle karşı tarafı aldatan bir yaklaşımı önlemek içindir. Sistem geliştirmenin yanı sıra, bu, özel kişiler arasındaki işlemleri düzenleyen hukuk ilkelerini de yansıtır.

Sivil Kanun Madde 1, Fıkra 2

Hakların kullanılması ve yükümlülüklerin yerine getirilmesi, iyi niyet ve dürüstlük ile gerçekleştirilmelidir.

Hukuk, her zaman sadece “sözleşme metninin içeriği” veya “maddenin ifadesi”ne önem vermez. Özellikle karşı tarafın olduğu işlemlerde, gerçek “iyi niyet” ve “dürüstlük” unsurlarını dahil ederek esnek bir şekilde kullanılmalıdır. Hukuki olarak yüklenen “yükümlülük” kavramının, her zaman “sözleşme” prosedürüne dayanmadığı konusunda, aşağıdaki makalede de detaylı bir açıklama yapılmıştır.

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

Özet

Agile geliştirme modeline dayalı sistem geliştirme projelerinde, işlemlerin ve yönetim yapısının düzensiz bir şekilde gevşekleşme riskini anlamak elbette önemlidir. Ancak, sadece bu yeterli olmayıp, ‘iyi niyet ilkesi’ gibi hukukun esnek özelliklerini de anlamak ve bunları iş uygulamalarında kullanma tutumu da önemlidir.