--- title: "Sürüm Yönetimi: Bir Mühendislik Alışkanlığının Değerleme Karşılığı" description: "Sürüm yönetimi, bir yatırım incelemesinde araç seçimi olarak değil, kurumun ürettiği her çıktının kim tarafından, hangi gerekçeyle ve hangi onayla değiştiğini geriye doğru ispatlayabilme kapasitesi olarak değerlendirilir. Bu kapasitenin belgesiz kalması, teknik ekibe duyulan güveni değil, şirketin kurucudan bağımsız tekrarlanabilirliğini zayıflatır ve değerlemeye iskonto, escrow ya da earn-out yapısı üzerinden yansır." url: https://www.beirek.com/tr/blog/version-control-due-diligence-valuation canonical: https://www.beirek.com/tr/blog/version-control-due-diligence-valuation published: 2026-07-09 modified: 2026-07-09 category: "Teknoloji ve Mühendislik" category_url: https://www.beirek.com/tr/blog/category/technology-engineering language: tr-TR reading_time_minutes: 8 publisher: BEIREK LLC publisher_url: https://www.beirek.com license: "© BEIREK LLC — citation with attribution and link permitted" keywords: ["sürüm yönetimi","teknik due diligence","yatırım hazırlığı","değerleme iskontosu","kurucu bağımlılığı","konfigürasyon yönetimi","temsil ve tekeffül"] topics: ["Teknik due diligence ve mühendislik incelemesi","Sürüm ve konfigürasyon yönetimi disiplini","Kurumsal süreklilik ve kurucu bağımlılığı","Değerleme iskontosu ve kapanış koşulları"] alternate_language_url: https://www.beirek.com/en/blog/version-control-due-diligence-valuation --- # Sürüm Yönetimi: Bir Mühendislik Alışkanlığının Değerleme Karşılığı > **Kısaca:** Sürüm yönetimi, bir yatırım incelemesinde araç seçimi olarak değil, kurumun ürettiği her çıktının kim tarafından, hangi gerekçeyle ve hangi onayla değiştiğini geriye doğru ispatlayabilme kapasitesi olarak değerlendirilir. Bu kapasitenin belgesiz kalması, teknik ekibe duyulan güveni değil, şirketin kurucudan bağımsız tekrarlanabilirliğini zayıflatır ve değerlemeye iskonto, escrow ya da earn-out yapısı üzerinden yansır. *Sürüm yönetimi teknik bir konfor meselesi olarak kurulduğunda, incelemeye giren tarafın gördüğü şey bir araç değil, kurumun kendi üretimini geriye doğru izleyip izleyemediğidir. Bu izlenebilirliğin yokluğu, teknik borç kaleminde değil, kapanış koşullarında ve temsil-tekeffül kapsamında görünür.* --- Bir teknik due diligence oturumunda, inceleme ekibi genellikle hangi araçların kullanıldığını sormakla başlar ve karşı taraf bu soruyu rahatlıkla yanıtlar; depo adı verilir, dallanma stratejisi anlatılır, çizim arşivinin sunucudaki konumu gösterilir. Asıl kırılma, sorunun bir sonraki katmanına geçildiğinde yaşanır: sekiz ay önce müşteriye teslim edilmiş bir yapılandırmanın tam olarak hangi bileşen sürümlerinden oluştuğu, o teslimattan bu yana kaç değişiklik geçirdiği ve bu değişikliklerin hangisinin onaylı, hangisinin sahada acil müdahale olarak yapıldığı sorulduğunda, odadaki cevap çoğu zaman bir sistemden değil bir kişiden gelir. O kişi bunu bilir, çünkü değişikliği kendisi yapmıştır; sistem bilmez, çünkü sistem yalnızca sonucun son hâlini taşımaktadır. Bu örüntü, teknoloji ve mühendislik yoğun şirketlerde şaşırtıcı biçimde tekrarlar ve şirketin olgunluk düzeyiyle doğrusal olarak azalmaz. Otuz kişilik bir mühendislik ekibinde sürüm disiplini genellikle yazılım deposunda titizlikle uygulanırken, aynı ekibin ürettiği hesap tabloları, teknik şartname taslakları, saha revizyon çizimleri ve müşteriye özel konfigürasyon dosyaları paylaşımlı bir sürücüde dosya adına eklenen tarih ve baş harf kısaltmalarıyla yönetilmeye devam eder. Kurum, kendi kritik çıktısının bir bölümünü izlenebilir, diğer bölümünü izlenemez tutmayı bilinçli bir tercih olarak değil, aracın kapsamıyla disiplinin kapsamını aynı şey sanmakla sonuçlandırır. Altta çalışan mekanizma, kısayolun kendisinde değil, kısayolun koşul değiştikten sonra devam etmesindedir. Beş kişilik bir kurucu ekipte, kimin neyi ne zaman değiştirdiği bilgisi ortak hafızada tutulabildiği sürece, formel bir sürüm kaydı tutmanın marjinal faydası düşük, marjinal maliyeti ise görünür biçimde yüksektir; her değişikliğin gerekçesini yazmak, o değişikliği yapmaktan daha uzun sürer. Ekip büyüdüğünde, ürün çeşitlendiğinde ve müşteri başına farklılaşan yapılandırmalar çoğaldığında ise ortak hafıza taşıma kapasitesini kaybeder, fakat kayıt tutmama alışkanlığı yerinde kalır. Kurum artık bilmediği bir şeyi bildiğini varsayarak çalışmaktadır, ve bu varsayımın yanlışlığı ancak bir geri alma, bir denetim ya da bir inceleme anında yüzeye çıkar. İkinci mekanizma katmanı, sürüm yönetiminin sahipliğiyle ilgilidir. Bu alan tipik olarak bir role değil, bir kişiye — genellikle ekibin en kıdemli mühendisine — fiilen bağlanır; o kişi neyin ana hatta alınacağına, hangi değişikliğin acil sayılacağına ve hangi sürümün müşteriye gideceğine karar verir, fakat bu karar yetkisi hiçbir belgede tanımlı değildir. Yetkinin belgesizliği gündelik operasyonda bir sürtünme üretmez, aksine hızlandırır; kimse onay beklemez, kimse süreç tartışmaz. Buna karşılık aynı belgesizlik, o kişinin izinli olduğu, ayrıldığı ya da paralel iki projeye aynı anda bölündüğü anda, kararın kimde olduğu sorusunu cevapsız bırakır ve bu boşluk çoğu zaman en riskli değişikliğin en az gözetimle geçtiği pencereyi açar. Bu yapının kurumsal bedeli, teknik borç kaleminde değil, incelemenin bambaşka başlıklarında ortaya çıkar. Kaynak koda ve tasarım arşivine ilişkin temsil ve tekeffül maddeleri, satıcının teslim ettiği teknik varlığın bütünlüğünü ve üçüncü taraf bileşenlerden arındırılmışlığını beyan etmesini gerektirir; bu beyanı destekleyecek bir sürüm ve bağımlılık kaydı yoksa, beyanın kapsamı ya daraltılır ya da beyanın arkasına bir escrow konur. Aynı şekilde, açık kaynak lisans uyumu incelemesinde sorulan soru hangi kütüphanenin kullanıldığı değil, hangi sürümünün hangi tarihten itibaren hangi ürüne girdiğidir; bu zincir gösterilemediğinde inceleme ekibi en geniş lisans yükümlülüğünü varsayarak ilerler, çünkü aksini gösteren bir kayıt yoktur. Değerlemeye yansıma kanalı burada niceliksel olmaktan çok yapısaldır. Alıcı taraf, sürüm izlenebilirliği zayıf bir hedefte, kapanış sonrası entegrasyon süresini ve ürün geliştirme hızının ilk yıl içinde düşeceği varsayımını modeline koyar; devralınan ekibin ilk altı ayının önemli bir bölümü yeni ürün üretmeye değil, mevcut ürünün ne olduğunu haritalamaya gider. Bu varsayım fiyata bazen doğrudan bir iskonto olarak, çoğu zaman ise earn-out eşiklerinin geriye çekilmesi, kapanış öncesi koşul listesine teknik envanter tamamlama yükümlülüğü eklenmesi ya da escrow oranının bir mertebe yukarı kalibre edilmesi olarak geçer. Satıcı bu kalemleri ayrı ayrı müzakere ederken, hepsinin aynı boşluktan beslendiğini genellikle geç fark eder. Ölçüm boyutu, bu alanda en sık boş bırakılan ve en kolay doldurulan katmandır. Sürüm yönetiminin sağlığını gösteren göstergeler egzotik değildir: onaysız ya da geriye dönük olarak kayda alınmış değişikliklerin toplam değişiklik içindeki payı, üretime çıkan sürümlerin geri alınma sıklığı, bir hatanın hangi sürümde girdiğinin tespit edilmesi için geçen ortalama süre, ve teslim edilmiş bir yapılandırmanın kayıtlardan yeniden kurulabilme oranı. Bu göstergelerin hiçbiri şirketin mevcut sisteminde olmayan bir veriyi gerektirmez; yalnız hiç kimse onları düzenli bir ritimle bakılan bir tabloya taşımamıştır. Ölçülmeyen alan, inceleme ekibi tarafından iyi ya da kötü olarak değil, belirsiz olarak sınıflanır, ve belirsizlik fiyatlamada her zaman olumsuz tarafa yazılır. Süreklilik boyutunda aranan şey, disiplinin varlığı değil, disiplinin kişiden bağımsız olarak yeniden üretilebilmesidir. Bunun pratik sınaması basittir: şirkete altı ay önce katılmış bir mühendis, kimseye sormadan, yalnızca mevcut belge ve kayıtlara bakarak, belirli bir müşteriye teslim edilmiş belirli bir yapılandırmayı yeniden kurabiliyor mu? Cevap olumluysa sürüm yönetimi kurumsal bir kapasitedir; olumsuzsa, ne kadar titiz uygulanıyor olursa olsun, kişisel bir alışkanlıktır ve alışkanlıklar bilançoda varlık olarak taşınmaz. İnceleme ekibinin kurucu bağımlılığı başlığı altında değerlendirdiği şey, kurucunun ne kadar çalıştığı değil, kurumun kurucunun hafızasına ne ölçüde ipotekli olduğudur. Yapısal müdahalenin ilk bileşeni kapsam tanımıdır: sürüm yönetimi neyi kapsayacak sorusu, araç seçiminden önce cevaplanır. Kod deposu bu kapsamın yalnızca bir parçasıdır; teknik şartnameler, mühendislik hesapları, saha revizyonları, müşteri bazlı konfigürasyonlar, test setleri ve dış bileşen bağımlılık listeleri aynı izlenebilirlik rejimine alınmadığı sürece, kapsam dışında kalan her kalem daha sonra en pahalı boşluk olarak geri döner. İkinci bileşen yetki mimarisidir: değişikliği kim önerir, kim onaylar, kim üretime alır ve acil müdahale durumunda bu zincir hangi kuralla kısaltılır — bu dört rolün aynı kişide toplanması operasyonel hız kazandırırken, incelemede tek kişilik kontrol noktası olarak okunur. Üçüncü bileşen kayıt anıdır: kaydın onay sonrasında değil, değişiklik önerildiği anda tutulması, gerekçenin sonradan rekonstrüksiyonunu ortadan kaldırır. BEIREK'in bu alandaki müdahalesi, şirkete yeni bir araç kurmakla değil, mevcut üretimin izlenebilirlik haritasını çıkarmakla başlar: hangi çıktı türü hangi rejimde yönetiliyor, hangi çıktı hiçbir rejimde değil, ve kapsam dışı kalan kalemlerin hangileri sözleşmesel bir beyana konu olacak. Bu haritanın üzerine, değişiklik önerisinden üretime alınmaya kadar uzanan zinciri dört ayrı role bölen bir yetki tablosu ve acil müdahale için ayrı bir kısa yol tanımı yerleştirilir; kısa yolun varlığı disiplini zayıflatmaz, aksine kısa yolun tanımsız olduğu durumlarda ana zincirin fiilen terk edilmesini önler. Ölçüm tarafında, onaysız değişiklik payı, geri alma sıklığı ve yeniden kurulabilirlik oranı aylık bir gözden geçirme ritmine bağlanır; bu ritmin amacı performans denetimi değil, sürüm kaydının kendisinin sürekli kullanılan bir belge hâline gelmesidir, zira yalnız denetimde açılan kayıt, denetimde de eksik çıkar. Bu müdahalenin bir yatırım süreci öncesinde yapılmasıyla süreç içinde yapılması arasındaki fark, işin niteliğinde değil, kimin gözü önünde yapıldığındadır. Kapanış öncesi koşul listesine giren bir teknik envanter tamamlama yükümlülüğü, aynı işi karşı tarafın takvimine ve karşı tarafın kabul kriterine göre yapmak anlamına gelir; aynı iş bir yıl önce yapıldığında ise şirketin kendi ritmine göre yapılmış, tamamlanmış ve doğrulanmış bir kapasite olarak veri odasına girer. Bu iki durumun değerlemeye yansıması aynı olmaz, çünkü inceleme ekibinin gördüğü şey birincisinde bir taahhüt, ikincisinde bir kayıttır. Nihayetinde sürüm yönetimi, bir şirketin teknik kalitesini değil, teknik kalitesini ispat edebilme kapasitesini ölçer, ve yatırım masasında bu ikisi arasındaki fark fiyatın kendisidir. Bir mühendislik ekibinin ürettiği çözümün ne kadar iyi olduğu, o çözümün nasıl oluştuğunun geriye doğru izlenebildiği ölçüde şirkete ait sayılır; izlenemediği ölçüde ise, ne kadar iyi olursa olsun, onu üretmiş kişilere ait kalır. Değerlemenin sorduğu tek soru budur: bu performans şirketin mi, yoksa şirkette çalışan birkaç kişinin mi? ## Ana Noktalar - İnceleme masasında sorulan soru hangi aracın kullanıldığı değil, altı ay önceki bir çıktının bugün birebir yeniden üretilip üretilemeyeceğidir. - Sürüm yönetimi yalnız yazılım deposunu değil, mühendislik çizimini, hesap tablosunu, teknik şartnameyi ve konfigürasyon dosyasını kapsadığı ölçüde kurumsal bir kapasitedir. - Sahipsiz bırakılan sürüm disiplini, ekipteki en kıdemli kişinin hafızasına bağımlılık üretir ve bu bağımlılık doğrudan kurucu riski olarak fiyatlanır. - Ölçülmeyen sürüm süreçlerinde geri alma sıklığı, acil düzeltme oranı ve onaysız değişiklik payı görünmez kalır; yatırımcı görünmeyeni maliyetli varsayar. - Değerleme farkı çoğu zaman teknik kalitede değil, teknik kalitenin belge zinciriyle gösterilebilmesinde oluşur. ## Sorular ### Yatırımcı teknik incelemede sürüm yönetimine neden bakar? Yatırımcının aradığı şey araç seçimi değil, geriye dönük ispat kapasitesidir: teslim edilmiş bir çıktının hangi bileşenlerden oluştuğu, hangi değişiklikleri geçirdiği ve bu değişikliklerin kim tarafından onaylandığı kayıtlardan gösterilebiliyor mu. Bu zincir gösterilemediğinde, teknik varlığa ilişkin sözleşmesel beyanların kapsamı daralır ve inceleme ekibi en olumsuz varsayımla ilerler. ### Sürüm yönetimi sadece yazılım şirketleri için mi geçerli? Hayır. Mühendislik hesapları, teknik şartnameler, saha revizyon çizimleri, müşteri bazlı konfigürasyon dosyaları ve test setleri de aynı izlenebilirlik rejimine girmediğinde boşluk üretir. Uygulamada en sık görülen durum, kod deposunun titizlikle yönetilirken aynı ekibin ürettiği diğer kritik çıktıların dosya adına eklenen tarih ve baş harflerle takip edilmesidir; incelemede sorun çıkaran genellikle bu ikinci grup olur. ### Sürüm yönetimindeki eksiklik değerlemeyi nasıl etkiler? Etki çoğu zaman doğrudan bir fiyat indirimi olarak değil, işlem yapısı üzerinden görünür: kapanış öncesi koşul listesine teknik envanter tamamlama yükümlülüğü eklenir, escrow oranı yukarı kalibre edilir, earn-out eşikleri geriye çekilir ya da temsil ve tekeffül kapsamı daraltılır. Alıcı ayrıca devralınan ekibin ilk aylarını mevcut durumu haritalamaya harcayacağını varsayarak entegrasyon takvimini uzatır. ### Sürüm yönetiminin kişiye bağımlı olup olmadığı nasıl anlaşılır? Pratik sınama şudur: şirkete yakın zamanda katılmış bir mühendis, kimseye sormadan yalnızca mevcut kayıt ve belgelere bakarak belirli bir teslimatı yeniden kurabiliyor mu. Kurabiliyorsa disiplin kurumsal bir kapasitedir; kuramıyorsa, ne kadar titiz uygulanıyor olursa olsun kişisel bir alışkanlıktır ve inceleme masasında kurucu bağımlılığı başlığı altında değerlendirilir. --- Kaynak: https://www.beirek.com/tr/blog/version-control-due-diligence-valuation Yayımlayan: BEIREK LLC — https://www.beirek.com