Sistem geliştirmede değişiklik yönetiminin nasıl yapılacağına dair hukuki bakış açısı

Sistem geliştirme projelerinde, kullanıcıların önceden açıkladığı içeriklerin, işin ilerlemesi sürecinde sonradan değiştirilmesi durumu sıklıkla karşılaşılan bir durumdur. Bu nedenle, işi alan bir tedarikçi olarak, bir kez sonuçlandırılan bir sözleşme hakkında bile, sonradan sözleşme içeriğinin değiştirilmesi gerekebileceği durumları olabilir.

Bu makalede, planlandığı gibi ilerlemeyen sistem geliştirme projelerine hukuki bir bakış açısıyla yaklaşıyoruz ve sonradan yapılan “değişiklikler” fenomenini nasıl ele alınması gerektiğini açıklıyoruz.

Sistem Geliştirme Projeleri Neden Sonradan “Değiştirilir”?

Sistem Geliştirme, Satıcı ve Kullanıcıların Ortak Çalışmasıdır

Sistem geliştirme genellikle, planlama ve teklif aşamalarından geçtikten sonra, geliştirme gereksinimleri tanımlanır ve bir sözleşme imzalanır. Sözleşme imzalandıktan sonra, çeşitli tasarımların ardından, tasarıma uygun bir şekilde uygulama yapılır ve son olarak bir test yapılır ve bu genel akışı takip eder. Ve tüm süreç boyunca, işi alan satıcının sistem geliştirme uzmanı olarak geniş bir yükümlülük taşıması beklenirken, kullanıcı tarafından da belirli bir işbirliği yükümlülüğü beklenir. Yapılacak sistemin hangi özelliklere sahip olması gerektiği (yani gereksinim tanımlama), ekran görünümü ve kullanım hissi (yani temel tasarım) ve gereksinimlere uygun bir şeyin olup olmadığının kontrolü (yani test veya kabul) gibi aşamalarda özellikle, kullanıcı işbirliği önemli hale gelir. Sistem geliştirmede, kullanıcının taşıdığı yükümlülükler hakkında genel bir açıklama, aşağıdaki makalede detaylı olarak ele alınmıştır.

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

İşbirliği Yükümlülüğü Var Ancak, Kullanıcılar Genellikle Değişiklik Talep Eder

Ancak, sistem geliştirme uzmanı olmayan bir kullanıcının, her zaman planlı bir şekilde, sistem geliştirme için gerekli bilgileri eksiksiz ve kapsamlı bir şekilde satıcıya iletebileceğini söylemek mümkün değildir. Gerçekte, detaylı ve titiz bir işlem olduğu için, hangi gerçeklerin sonraki aşamalarda belirleyici bir anlam taşıyabileceği gibi konular, kullanıcı tarafından da öngörülemeyebilir. Bu nedenle, ironik bir şekilde, önemli gerçekler genellikle daha sonra ortaya çıkar. Bu durumdan dolayı, gerçek projelerde, “üst akıştan alt akışa kadar kesintisiz” ideal olmasına rağmen, sonradan çeşitli değişikliklerin yapılacağı varsayımı altında, “değişiklik yönetimi”nin nasıl yapılacağı önemli hale gelir.

Değişiklik Yönetim Belgesi Nedir?

Değişiklik Yönetim Belgesi’nin Kullanıldığı Durumlar

Değişiklik Yönetim Belgesi, kullanıcıların bir satıcıya, önceden yapılan açıklamaların dışında, özelliklerin değiştirilmesi veya işlevlerin eklenmesi talebinde bulunurken kullandığı bir belgeyi ifade eder. Daha önce belirtildiği gibi, gereksinim tanımlama veya temel tasarım gibi aşamalarda, kullanıcılar da satıcının işlerine yardımcı olma yükümlülüğü taşır, ancak sonraki süreçlerde farklı talepler ortaya çıkabilir.

Değişiklik Yönetim Belgesi’nin gerekli olduğu durumlar arasında örneğin,

• Gereksinim tanımlama veya temel tasarım aşamasında bir şeylerin gözden kaçması ve sonradan işlev eklemek için talepte bulunulması
• Geliştirme sürecinde, iş politikalarının gözden geçirilmesi ve özellik değişikliğinin gerekli olması

gibi durumlar düşünülebilir.

Ayrıca, işlev ekleme veya özellik değişikliği gibi konularla ilgili olarak, işi alan tarafın en çok merak ettiği şey, tahmini maliyetin yasal olarak değiştirilip değiştirilemeyeceğidir. Bu konuda, ayrı bir makalede detaylı bir açıklama yapılmıştır.

https://monolith.law/corporate/increase-of-estimate[ja]

Bu tür sonradan tahmini artışlar yapılırken, tahminin içeriğinin uygunluğunu değerlendirmek için temel oluşturan şey Değişiklik Yönetim Belgesi’dir. Daha sonra artırılan tahminlere dayanarak talepte bulunulurken, taraflar arasında anlaşmazlık çıkmaması için (veya anlaşmazlık çıktığında kendi argümanlarınıza ikna edici bir güç kazandırmak için), Değişiklik Yönetim Belgesi’nin oluşturulması önemlidir.

Değişiklik Yönetim Belgesi’nde Yer Alması Gereken Bilgiler

Peki, yasal olarak, Değişiklik Yönetim Belgesi’nde hangi bilgilerin yer alması gerekiyor? Değişiklik Yönetim Belgesi’ni kullanarak, özellik değişikliği veya işlev ekleme taleplerine yanıt verme mekanizması artık genel olarak yaygın olarak kabul edilmiştir. Bu nedenle, Ekonomi Bakanlığı Model Sözleşmesi gibi, devlet kurumlarının sunduğu sözleşme maddelerinin taslaklarını kontrol ederek, hangi bilgilerin kayıt olarak saklanması gerektiği genellikle anlaşılır.

(Değişiklik Yönetim Prosedürü)
Madde 37 A veya B, karşı taraftan Madde 34 (Sistem Özellikleri Belgesi’nin değiştirilmesi), Madde 35 (Ara Malzemelerin Kullanıcı Tarafından Onaylanması), Madde 36 (Belirsiz Konuların Ele Alınması) temelinde bir değişiklik teklif belgesi aldığında, bu belgenin alındığı tarihten itibaren ○ gün içinde, aşağıdaki bilgilerin yer aldığı bir belge (bundan sonra “Değişiklik Yönetim Belgesi” denir.) karşı tarafa verilir ve A ve B, Madde 12’de belirtilen İletişim Danışma Kurulu’nda bu değişikliğin kabul edilip edilmeyeceği konusunda görüş alışverişinde bulunur.
① Değişikliğin adı
② Teklifin sorumlusu
③ Tarih
④ Değişikliğin nedeni
⑤ Değişikliğin detayları, değişikliğe ilişkin özellikler dahil
⑥ Değişiklik için maliyet gerekiyorsa, bu miktar
⑦ Değişiklik çalışmalarının programı, değerlendirme süresi dahil
⑧ Değişikliğin bu sözleşme ve bireysel sözleşme koşullarına (çalışma süresi veya teslim tarihi, hizmet bedeli, sözleşme maddeleri vb.) etkisi

Doğrudan metni okuyarak, önerilen maddeleri kontrol ederseniz, daha fazla açıklamaya gerek kalmaz. Sonradan “söyledim/söylemedim” sorununu önlemek için, değişikliğin ayrıntılarını ve sürecini detaylı ve somut bir şekilde kaydetmek gerektiğidir.

Bu tür bilgileri belirttikten sonra, satıcı ve kullanıcıların her ikisinin de yöneticileri veya onaylayıcıları tarafından imzalanması veya mühürlenmesi gibi bir set oluşturulur. Bu, bir dava durumunda bile, sözleşme ile aynı anlama gelecektir.

Değişiklik Yönetimi Hakkında Bilmeniz Gerekenler

Değişiklik Yönetimi Genellikle Görev Yönetimi ile Birlikte Yapılmalıdır

Değişiklik yönetim belgesi oluşturmanın amacı, değişiklik geçmişini yöneterek projeyi başarıya ulaştırmak (veya başarıya ulaşılamadığı durumlarda, haksız sorumluluk takibinden kaçınmak) olabilir. Bu hedefe ulaşmak için, değişiklik yönetim belgesinin oluşturulması genellikle görev yönetim listesinin oluşturulması ve güncellenmesi ile birlikte yapılır. Yani, değişiklik geçmişi değişiklik yönetim tablosunda yönetildikten sonra, bu kabul edilen değişiklikler gelecekte ele alınması gereken görevler olarak görev yönetim listesine dahil edilir.

Değişiklik Müzakerelerinin Nasıl Yapılacağını Belirlemenin de İyi Olacağı

Değişiklik yönetiminin nasıl yapılacağına dair sadece, değişiklikler hakkındaki müzakerelerin nasıl yapılacağına dair de bir düzenleme yapmak, değişikliklerin sorunsuz bir şekilde ele alınmasını sağlayabilir. Bu nokta, özellikle Agile geliştirme gibi, çeşitli değişikliklerin sonradan yapılacağı varsayılan geliştirme yöntemlerini kullananlar için önemlidir. Pratikte, değişiklik yönetimi hakkında bir müzakere talebi olduğunda, karşı tarafın ne zaman müzakereye yanıt vermesi gerektiği gibi konuları belirleyen örnekler sıkça görülür.

Değişiklik Müzakereleri ve Dürüstlük Yükümlülüğü

Her iki tarafın da bir kez anlaştığı bir sözleşmeyi, sonradan değiştirmek söz konusu olduğunda, bu esasen yeni bir sözleşme yapmak anlamına gelir. Sözleşmenin kişinin özgür iradesine dayandığı düşünüldüğünde, prensip olarak, satıcının değişiklik sözleşmesine uyma yükümlülüğü yoktur. Ancak, bu tür hakların aşırı vurgulanması durumunda, gerçekten sistem geliştirme projelerinin sorunsuz ilerlememesi endişesi olabilir.

Bu nedenle, pratikte sıkça, sözleşme metninde “değişiklik müzakerelerine dürüstçe yanıt verme yükümlülüğü” gibi bir ifade belirtilir ve satıcının değişikliğe dürüstçe yanıt vermemesi durumunda tazminat talep edilebileceği belirtilir.

Örneğin, aşağıdaki gibi bir ifade kullanılabilir (Aşağıda, maddenin örneğini yayınlıyoruz. Bağımsız İdari Kuruluş Bilgi İşlem Teşvik Kurumu’nun resmi olarak oluşturduğu “ff Temel / Bireysel Sözleşme Modeli Temel Sözleşme Taslağı”ndan alıntı yapılmıştır).

Madde 4, Fıkra 3: Değişiklik müzakerelerinde, değişikliğin konusu, değişikliğin yapılıp yapılamayacağı, değişikliğin bedel ve teslim süresine etkisi vb. konular incelenir ve değişikliğin yapılıp yapılmayacağı konusunda her iki taraf da dürüstçe müzakere eder.

Değişiklik Yöntemi Hakkında Düzenleme

Daha önce belirtildiği gibi, değişiklik yaparken, her seferinde değişiklik hakkındaki müzakereleri düzenlemek hukuki olarak “güvenli” olacaktır. Ancak, küçük ölçekli bir proje söz konusu olduğunda, değişiklikler hakkındaki müzakerelerin nasıl yapılacağını belirlemeye gerek olmayabilir. Bu durumda, müzakere hakkındaki düzenlemeyi koymak yerine, müzakereler olmaksızın değişiklik yönetim belgesine kullanıcı ve satıcıların her ikisinin de sorumlu kişilerinin imza ve mühürlerini koymak gibi bir yöntem düşünülebilir. Sadece sözlü anlaşma ile kolayca değişiklik yapılabilir hale getirilirse, değişikliğin yapıldığı ya da yapılmadığı belirsizleşebilir ve bu durum daha sonra büyük bir sorun haline gelebilir. Bu nedenle, belge yönetimi titizlikle yapılmalıdır.

Her ne kadar, her seferinde değişiklik yönetimi için ayrı bir belge hazırlamanın bile zor olabileceğini ve esnek bir yanıt verme ihtiyacını daha çok önemseyebileceğinizi düşünebilirsiniz. Bu tür durumlarda, toplantı tutanaklarına değişiklikler hakkındaki konuları belgelemek gibi bir yöntem düşünülebilir. Sistem geliştirme toplantılarının tutanaklarının nasıl tutulacağı konusunda aşağıdaki makalede detaylı bir açıklama yapılmıştır.

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

Özet

Sık sık özellik değişikliklerinin yapıldığı alanlarda, çeşitli sorunlar ve anlaşmazlıkların riskiyle yan yana gelme eğiliminde olabiliriz. Ancak, bu tür esneklik gerektiren durumlarda, sadece ‘yönetimin önemi’ni vurgulamak, gerçekçi önlemler almayı zorlaştırabilir.

İş dünyasında talep edilen hız ile olası bir duruma karşı nasıl hazırlıklı olunacağı arasındaki dengeyi nasıl sağlayacağımız sorunu, şirketin durumu ve projenin içeriğine bağlı olarak en iyi çözümün farklı olabileceği düşünülmektedir. Bu makaledeki gibi içerikleri göz önünde bulundururken, her şirketin ve projenin kendi uygun yöntemlerini araştırma tutumu da önemli olacaktır.