Yazılım teslimatında değer akışlarının Değer Sistemi Şeması ile ölçülmesi

Tam metin

1 Giriş

Yazılım ekipleri yakından ölçülür: hız (velocity), verim (throughput), teslim süresi, dağıtım sıklığı ve değişiklik başarısızlık oranı otomatik olarak toplanır. Ancak bu sayılar bir soruyu yanıtsız bırakır: ekip hangi değeri, kime ve kayıplar açısından hangi bedelle sundu?

Bu makale, söz konusu soruyu yanıtlamak için bir yöntem önerir. Yöntem, Æilus metodolojisinin modelleme notasyonu olan Değer Sistemi Şeması'nı (Value System Schema, VSS) kullanır ve aeilus.tech adresinde yayımlanan VSS Editor üzerinde uygulanır. Makale, "Business için Æilus" serisinin beşinci makalesidir. Serinin ilk makalesi olan "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026) içinde tanımlanan söz dağarcığını kullanır ve bu tanımları yinelemez. Değerin ölçülebilir bir para birimi (Æ) olarak biçimsel ele alınışı "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026) çalışmasında verilmiştir.

Makale, bir teslimat organizasyonunun kendi değer sisteminin şemasını nasıl oluşturabileceğini, sürümlere planlanan ve gerçekleşen değeri nasıl bağlayabileceğini, akış direncini ve sızıntıyı nasıl bulabileceğini, ortak teknik düğümleri nasıl değerlendirebileceğini ve döngüyü net rollerle ve belirli bir ritimle nasıl yürütebileceğini anlatır. VMT'nin A1, A2, A4, A5, A6, A7, A11 ve A13 aksiyomlarına ile T3, T4, T5, T6, T8, T9, T15, T16 ve T17 teoremlerine dayanır. Ölçülmüş veri içermez. 9. Bölümdeki çalışılmış örnek sentetiktir.

2 Teslimat metrikleri neyi ölçer, neyi ölçmez

Teslimat metrikleri işin hareketini tanımlar. Hız, tamamlanan tahmini eforu sayar; verim, bitirilen kalemleri sayar. Forsgren, Humble ve Kim'in (Accelerate, 2018) yaygınlaştırdığı dört temel metrik, yani dağıtım sıklığı, değişiklikler için teslim süresi, hizmeti geri getirme süresi ve değişiklik başarısızlık oranı, teslimat hattının hızını ve kararlılığını tanımlar. Bu araştırma söz konusu yetkinlikleri organizasyonel performansa bağlar ve bu makale buna itiraz etmez. İddiası daha dardır: bu metrikler hattı tanımlar, hattan geçen değeri değil.

Bundan üç boşluk doğar.

• Efor değer değildir. Yüksek hızlı bir sprint, kimsenin kullanmadığı özellikler sunabilir. Product Value System sunumunun diliyle, "özellikler değer değildir" ve "metrikler değer değildir": özellik, değer hakkında bir varsayımdır; metrik ise bu varsayımın bir yorumudur.
• Hız yön değildir. Kısa bir teslim süresi, yanlış bir hipotezi daha hızlı teslim eder.
• Kararlılık, karşı değerin yokluğu değildir. Düşük bir değişiklik başarısızlık oranı; gecikme, kafa karışıklığı, kullanıcı tarafındaki yeniden iş ya da tam tasarlandığı gibi çalışan bir değişikliğin yol açtığı güven kaybı hakkında hiçbir şey söylemez.

Değer Yönetimi Teorisi (Value Management Theory, VMT) açısından bu boşluk yapısaldır. Değer yalnızca tanımlanmış bir değer sistemi içinde vardır ve o sistemin aktörleri tarafından yorumlanır (A1, A2). Değer tüketim anında gerçekleşir (A6) ve planlanan ile gerçekleşen değer genellikle farklıdır (A4, T3). Hat metrikleri tüketimden önce, göndericinin tarafında toplanır; dolayısıyla en fazla planlanan değerin teslimini tanımlar. Bu metrikler hedef haline geldiğinde Goodhart'ın (1975) tanımladığı etki ortaya çıkar: ekipler sayacı optimize eder. VMT aynı riski sistem terimleriyle ifade eder: yerel optimizasyon, küresel iyileşmeyi garanti etmez (T5).

3 Değer Sistemi Şeması notasyonu

3.1 Notasyonun öğeleri

Æilus metodolojisinde Değer Sistemi Şeması ilk temel artefakttır: değer sisteminin, aktörlerinin, akışlarının, dönüştürücülerinin ve temel değişimlerinin biçimsel bir tanımıdır; sistem sınırlarını belirlemek ve görünmeyen dış bağımlılıkları önlemek için kullanılır. VSS, dönüştürücü düzeyinde ya da sistem düzeyinde çizilebilir.

Aralık 2025'te aeilus.tech üzerinde yayımlanan VSS Editor, bu tür şemalar için tarayıcı tabanlı görsel bir editördür. Notasyonu az sayıda öğeden oluşur.

• Dönüştürücüler (converters). Dönüştürücü, bir şemada dönüştürücü (transformer) rolü için Æilus'ta kullanılan addır: ekip, hizmet ya da alt sistem gibi, değer öğelerini alan, dönüştüren ve yenilerini üreten işlevsel bir bloktur. Dönüştürücüler, değerin yaratıldığı, güçlendirildiği ya da yok edildiği yerlerdir.
• Akışlar. Akış, dönüştürücüler arasında ya da bir dönüştürücü ile dış dünya arasında yönlü bir bağlantıdır. Æ cinsinden belirli bir miktarda değer ya da karşı değer taşır. Akış, dışarıdan içeri (sisteme giren değer), içeriden dışarı (sistemi terk eden değer) ya da içsel (dönüştürücüler arasındaki değer) olabilir.
• Girdiler ve çıktılar. Dış girişler ve çıkışlar, değerin nereden girip nereden çıktığını işaretler. Birlikte sistem sınırını tanımlarlar.
• Değer öğeleri. Öğe türleri, bir akıştan tam olarak neyin geçtiğini tanımlar: müşteri değeri, gelir, maliyetler, riskler, teknik borç ve benzerleri. Kaydedilmiş bir şemada her öğenin bir türü (değer ya da karşı değer), bir işareti, bir miktarı ve bir birimi (Æ) vardır.
• Karşı değer. Karşı değer, kayıpları ve olumsuz etkileri temsil eder: gecikmeler, yeniden iş, kusurlar, bürokrasi, risk, tükenmişlik, boşa harcanan efor. Şemada, değerin yokluğu değil, negatif işaretli açık bir öğedir (A5).

3.2 Makine tarafından okunabilir model olarak şema

Editör, şemayı düğümler (dönüştürücüler), akışlar ve öğelerden oluşan yapılandırılmış JSON olarak kaydeder. Bu nedenle şema ürünle birlikte sürümlenebilir ve daha sonra her akış için planlanan ve gerçekleşen miktarları karşılaştıran analitikler tarafından okunabilir. Bu tür analitikler gelecek çalışma olarak duyurulmuştur ve burada varsayılmaz.

3.3 Şemanın ne olmadığı

VSS Editor açıkça bir KPI panosu, bir BI aracı, bir simülasyon motoru ya da mali muhasebenin yerine geçen bir araç değildir. Berraklığı hesaplamanın önüne koyar. Önerilen modelleme sırası şöyledir: sınırı tanımlayın, yalnızca ana dönüştürücüleri ekleyin, bunları adlandırılmış akışlarla bağlayın (sayılardan önce adlar, kesinlikten önce yön), ardından çoğu zaman en fazla içgörüyü üreten adım olan karşı değeri işaretleyin.

4 Kimin değeri: sistem ve sınırı

Bir değer ölçümü, kimin değerinin ölçüldüğünü belirtmedikçe anlamsızdır (A1, T1). Seçilen sınır da gerçeklikte hiçbir değişiklik olmadan sonuçları değiştirir (T15). Bu nedenle bu makale, herhangi bir ölçümden önce değer sistemini sabitler.

Burada modellenen değer sistemi, bir ürün organizasyonu içindeki tek bir yazılım ürününün ürün değer sistemidir. Product Value System sunumuna göre aktörleri ürün işlevi, geliştirme ekibi, operasyonlar, üretimdeki ürün, kullanıcılar ve kullanıcılar tarafından geri döndürülen değerin alıcısı olarak şirkettir. Finans, dış bir destekleyici girdidir (maaşlar).

Gerçekleşen iki yorum ölçülür: kullanıcılar ya da gözlemlenebilir davranışları tarafından yorumlanan kullanıcılar için değer ve geri dönüş akışının alıcısı olarak şirket tarafından yorumlanan (gelir, elde tutma, azaltılmış maliyet ya da risk) şirket için değer. Planlanan değer, göndericinin sürümden önceki yorumudur. Aynı sürümün bir iş ortağı ya da düzenleyici için değeri, açıkça genişletilmedikçe sınırın dışındadır.

5 Ürün hipotezinden gerçekleşen değere: değer döngüsü

Product Value System sunumu, ürün işini değer hipotezlerinin oluşturulduğu, uygulandığı, doğrulandığı ve sürdürüldüğü bir döngü olarak çerçeveler. Şema terimleriyle döngünün dönüştürücüleri ve akışları şöyledir.

1. Yatırımdan ürün işlevine. Ürün işlevi, kaynakları ve kullanıcı sinyallerini planlanan değer taşıyan hipotezlere dönüştürür.
2. Ürün işlevinden geliştirmeye. Hipotezler, planlanan değeri olan backlog kalemlerine dönüşür. Sunum iki beklenti belirtir: bir hipotezin planlanan değeri geliştirilirken azalmamalıdır ve teslim edilen değer planlanan değerden çok farklı olmamalıdır.
3. Geliştirmeden operasyonlara. Geliştirme efor tüketir ve karşı değerle (teknik borç, kusurlar, gecikme) birlikte çalışan değişiklikler üretir.
4. Operasyonlardan üretime. Değişiklikler çalışan yazılıma dönüşür; sürüm hataları ve kesinti süresi karşı değer olarak ortaya çıkar.
5. Üretimden kullanıcılara. Değer yalnızca kullanımda gerçekleşir (A6); dolayısıyla bu, gerçekleşen değerin gözlemlenebildiği ilk noktadır.
6. Kullanıcılardan şirkete. Kullanıcılar geliri, elde tutmayı ve güveni geri döndürür. Yazarın Ocak 2022 tarihli kanal gönderisi bunu kapalı bir akış olarak adlandırır: müşteriye teslim edilen değer, çoğunlukla ama yalnızca para olmayan, geri akan değerle dengelenir.

Döngü, dönüşüm aksiyomunu somutlaştırır (A7): her dönüştürücü aldığını gerçekleştirir ve bir sonrakine yeni planlanan değer üretir. Ayrıca hat metriklerinin neden yalnızca 3. ve 4. adımları kapsadığını gösterir. Değerin planlandığı, gerçekleştiği ve geri döndüğü 1., 2., 5. ve 6. adımlar hattın dışında kalır.

Sunum ayrıca iç ve dış ürünler için gözlemlenebilir unsur türlerini de listeler. Değer unsurları arasında kazanılan zaman, daha az operasyonel hata, nakit akışı, risk azaltımı, daha düşük bilişsel yük, öngörülebilirlik, yeni yetenekler ve güven yer alır. Karşı değer karşılıkları arasında kaybedilen zaman, yeniden iş, artan işletme maliyeti, teknik borç, öngörülemezlik, manuel geçici çözümler, güven kaybı ve bozulan müşteri hizmeti bulunur. Bu tipoloji, teslimat için bir Değer Unsurları Sicili'nin başlangıç noktasıdır.

6 Sürüm başına planlanan ve gerçekleşen değer, direnç ve sızıntı

6.1 Karşılaştırma birimi olarak sürüm

Karşılaştırma birimi sürümdür; sürümler küçük olduğunda ise backlog öğesidir. Yöntem, her biri için Æ içinde şunları kaydeder:

• planlanan değer: gönderenin tahmini; geliştirme başlamadan önce kaydedilir ve yalnızca açık, kayıt altına alınmış bir karar yoluyla güncellenir;
• gerçekleşen değer ve gerçekleşen karşı değer: sürümün üzerinde anlaşılan bir gözlem süresi boyunca kullanılmasının ardından alıcının yorumu;
• retrospektif değer: ikinci dereceden etkiler (destek yükü, müşteri kaybı, teknik borç) görünür hale geldikten sonra yapılan sonraki bir yeniden değerlendirme.

Sunum, aşamalı bir uygulama önerir: önce her backlog öğesinde planlanan değer, ardından yayımlanan her öğede gerçekleşen değer ve karşı değer, sonra retrospektif değer. Planlanan değer olmadan ölçülecek bir fark yoktur; gerçekleşen değer olmadan plan bir hipotez olarak kalır.

6.2 Teslimatta akış direnci

Akış direnci, planlanan ve gerçekleşen değer arasındaki fark ile bir akışta ortaya çıkan karşı değerin toplamıdır. VMT, sıfırdan farklı bir farkı normal kabul eder (T3), ancak direncin tarihsel olarak biriktiğini (T4) ve gelecekteki değeri gerçekleştirme yeteneğini azalttığını (T6) savunur. Teslimatta değer; uygulamada (kapsamın kısılması, hipotezin yanlış anlaşılması), yayında (hatalar, geri almalar), benimsemede (kullanıcıların değişikliği bulamaması veya kullanamaması) ve gecikme nedeniyle kaybedilir. Gecikme maliyeti kavramını (Reinertsen, 2009) izleyerek gecikme, ayrı bir metrik olarak değil, geç kalan akış üzerindeki karşı değer olarak modellenir.

Her akış kendi planlanan ve gözlenen niceliklerini taşıyorsa, şema kaybın hangi dönüştürücüde gerçekleştiğini gösterir. Æilus artefakt kümesindeki Akış Direnci Kaydı ve Planlanan ve Gerçekleşen Değer Farkı Raporu'nun amacı budur.

6.3 Sızıntı

Sızıntı, sistemden çıkan gerçekleşen değerin sistemin içine giren değeri sürekli olarak aşmasıdır (A11). Bir ürün değer sisteminde iki biçim yaygındır. Birincisinde kullanıcılar fayda sağlar, ancak geri dönüş akışı etkinleştirici girdi akışını karşılamaz. İkincisinde ekip, hipotezler oluşturulurken yatırımı tüketir, ancak bu hipotezler hiçbir zaman gerçekleştirilmez. Her iki durumda da çıktı hacmi sağlıklı görünebilir; girdi ve çıktı akışları aynı sınırda yer aldığından şema ikisini de gösterir.

7 Ortak düğümler: tüm akışlar boyunca değerlendirme

Bir yazılım sistemindeki bazı dönüştürücüler, bir kullanıcının adlandıracağı herhangi bir değer üretmez, ancak her değer akışı bunlardan geçer. Yazarın Eylül 2025 tarihli kanal gönderisi ve ilgili aeilus.tech makalesi örnek olarak yetkilendirmeyi kullanır: tek başına hiçbir değer üretmez, ancak o olmadan her senaryo durur. API ağ geçidi veya CI hattı da aynı türdendir.

Böyle bir düğüm tek başına değerlendirildiğinde maliyet gösterir, çıktı göstermez ve maliyet kesintisini davet eder. Şemada ise aynı anda birçok akışta yer alır ve verimliliği ancak desteklediği tüm akışların toplam değeri üzerinden netleşir. Bu nedenle yöntem, ortak bir düğüme şunları atar:

• şemadan okunan, içinden geçen akışlar kümesi;
• bu akışların her birine eklediği karşı değer (gecikme, kesintiler, başarısız girişler, entegrasyon kusurları);
• tükettiği değer (ekip çabası, altyapı).

Verimliliği, aynı makaledeki süreç verimliliği tanımını izleyerek, tüm akışları boyunca teslim edilen değerden karşı değerin çıkarılması ve sonucun tüketilen değerle karşılaştırılmasıdır. Ortak bir düğümdeki bozulma hiçbir zaman yerel bir olay değildir; hizmet verdiği her akışa eklenen dirençtir. T8 teoremi bir sürdürülebilirlik argümanı ekler: bir dönüştürme rolü yerine getirilemediğinde kararlılık kaybolur ve rolün yedekliliği kararlılığı artırır.

8 Bir ekip lideri ne kazanır

Yazarın Şubat 2022 tarihli kanal gönderisi, yaklaşımın bir ekibe ve liderine neler sağladığını listeler. Bu makalenin terimleriyle yeniden ifade edilirse:

• Geri bildirim olarak teslim edilen değer. Herhangi bir dönem için ekip, hızın (velocity) dolaylı sinyali yerine, teslim ettiği değeri Æ içinde, alıcılar tarafından onaylanmış olarak görür.
• Süreç metodolojisinden bağımsız bir etkinlik ölçüsü. Uygulama ne olursa olsun ölçü, tüketilen değer başına gerçekleşen değerdir ve uygulamalar bunun üzerindeki etkilerine göre seçilir veya bırakılır (P7).
• İş tarafı için şeffaflık. Teknik iş, desteklediği akışlar üzerinden açıklanabilir hale gelir.
• Değerden türetilen backlog önceliği. Öncelik, en yüksek sesle konuşan paydaş yerine planlanan değerden, bunun güvenilirliğinden ve gecikme maliyetinden türetilebilir.
• Karşı değer olarak gecikme maliyeti ve üretim hataları. İş tarafı, bir değişiklik geç kaldığında veya hatalı olduğunda değerin nasıl düştüğünü gösterebilir; ekip de işinin yararlılığının zamanlamaya ve üretim kalitesine nasıl bağlı olduğunu görür.
• Ortak kaynaklar için argümanlar. Yöneticilerin ve DevOps mühendislerinin paylaşıldığı yerlerde, değere dayalı öncelik, bir ekibin işinin neden bir diğerininki lehine ertelendiğini her iki yönde de açıklar.

Bu kazanımlar yalnızca gerçekleşen değer alıcıları tarafından doğrulanırsa geçerlidir. Ekip kendi değerini kendisi tahmin eder ve onaylarsa, ölçü kendi bildirimine dayanan bir sayaca dönüşür ve T17 geçerli olur: etkili kaynaklardan gelen ve gerçekleşmeyle doğrulanmayan yorumlar karşı değer biriktirir.

9 Sentetik bir ürünün işlenmiş şeması

Bu bölüm sentetik, açıklayıcı bir ürünü anlatır. Bir vaka çalışması değildir, hiçbir gerçek kuruluşu tanımlamaz ve ölçülmüş sayı içermez.

Sentetik ürün, küçük hizmet işletmelerinin müşteri rezervasyonlarını kabul ettiği abonelik tabanlı bir web uygulamasıdır. Değer sistemi, Bölüm 4'te tanımlanan sınırı izler. İki ortak düğüm, bir yetkilendirme hizmeti ve bir API ağ geçidi, kullanıcıya dönük tüm akışlara hizmet eder. Finans, etkinleştirici girdi akışını sağlar. Şirket, geri dönüş akışı olarak abonelik gelirini ve müşteri elde tutmayı alır.

Şema VSS Editor'da dört geçişte oluşturulur: bir dış girdi akışı (yatırım ve maaşlar) ve kullanıcılara giden dış çıktı akışlarıyla sınır; yedi dönüştürücü; taşıdıkları değer unsurlarıyla adlandırılan akışlar; ve karşı değer unsurları. Nicelikler, ilk tahmin oturumuna kadar boş kalır.

Bir hipotetik sürümü ele alalım: kaçırılan randevuları azaltmayı amaçlayan bir hatırlatma özelliği. Geliştirmeden önce ürün sahibi, öğe başına planlanan değeri kaydeder (kazanılan zaman, azalan kaçırılmış rezervasyonlar, elde tutmaya beklenen etki). Üzerinde anlaşılan gözlem döneminden sonra ürün analitiği ve bir iş kullanıcıları örneklemi gerçekleşen değeri sağlar, ekip ise gerçekleşen karşı değeri kaydeder: geç yayınlanan bir sürüm, yinelenen hatırlatmalar gönderen bir hata, API ağ geçidinde ek yük. Aradaki fark bu sürümün direncidir. Hata ve ağ geçidi yükü, diğer senaryolara hizmet eden akışlar üzerinde de yer aldığından, ortak düğümlere de atanır. Bir çeyrek sonra, retrospektif değer elde tutmanın hiç değişip değişmediğini kaydeder. Gerçek bir uygulamada nicelikler, bundan sonra anlatılan oturumlardan gelirdi.

10 Nasıl yürütülür

10.1 Kim tahmin eder, kim doğrular

2025 tarihli yazıdaki Æilus kuralı kısadır: bir sürecin çıktı değeri onu tüketen kişi tarafından değerlendirilmeli ve bu değerlendirmeyi başka biri kontrol etmelidir. Teslimata uygulandığında bu, net bir iş bölümü sağlar.

• Planlanan değer gönderen tarafından tahmin edilir. Hipotezler için bu, ürün dönüştürücüsünün Değer Dönüştürücü Sahibi (Value Transformer Owner, VTO) olarak görev yapan ürün sahibidir. Geliştirme dönüştürücüsü için VTO olarak ekip liderdir.
• Gerçekleşen değer alıcı tarafından yorumlanır: ürün veya web analitiği üzerinden gözlemlenen kullanıcılar ve geri dönüş akışı için şirket. Sunum, doğrudan doğrulama kurulana kadar geçici bir önlem olarak ürün analitiğinin kullanıcı tarafını temsil etmesini önerir.
• Yorumun doğrulanması ikinci bir taraf tarafından yapılır: sistem düzeyindeki sürdürülebilirliğin sahibi olan Değer Sistemi Sahibi (Value System Owner, VSO) veya kritik bir akış için Akış Sahibi (Flow Owner).
• Metodolojik bütünlüğü bir Æilus Master destekler (sunumda, bir proje yöneticisinin üstlendiği Æilus şampiyonu); değer teslimi, plan ile gerçekleşen karşılaştırması ve akış direnci raporlarını hazırlar.

10.2 Ritim

Æilus bir takvim dayatmaz. Metodolojinin önerdiği etkinliklerle uyumlu, bir teslimat ekibi için asgari ritim şöyledir.

• Her backlog iyileştirmesinde: öğe sicili kullanılarak yeni öğelere planlanan değer atanır.
• Her sürümde, gözlem döneminden sonra: gerçekleşen değer ve karşı değer kaydedilir ve doğrulanır; kısa bir değer retrospektifi aradaki farkı tartışır.
• Aylık veya çeyreklik: ortak düğümler dahil şema üzerinde bir Akış Direnci Gözden Geçirmesi; daha önce yayınlanan öğeler için retrospektif değer.
• Çeyreklik veya yapısal değişiklikte: sınırların, dönüştürücülerin ve bağımlılıkların Değer Sistemi Gözden Geçirmesi; şema dosyası güncellenir ve sürümlenir.

10.3 Disiplin

Her artefaktın bir sahibi, bir güncelleme döngüsü ve bir karar amacı olmalıdır; aksi halde bakım maliyeti ve yanlış güven yoluyla karşı değer yaratır. Bu yöntem için karar amaçları backlog önceliği, ortak kaynakların tahsisi, sürüm zamanlaması ve ortak düğümlere yatırımdır. Planlanan değerin artırılması, yalnızca ekibin onu gerçekleştirme yeteneği doğrulandığında kabul edilebilir (P9). Planlanan değeri gerçekleşen değerden daha hızlı ölçeklendirmek, T16'da tanımlanan arıza kipidir (failure mode).

11 Sınırlamalar ve bir ampirik çalışmanın neye ihtiyaç duyacağı

Bu makale kavramsaldır ve ölçülmüş veriler üzerinde sınanmamıştır. Birkaç sınırlama buradan doğar.

• Tahmin kalitesi. Æ içindeki değerler, güvenilirliği tahmin edenlere ve onların kalibrasyonuna bağlı olan yorumlardır.
• Kısmi ölçülebilirlik. Kazanılan zaman, gelir ve güven yalnızca kısmen ortak ölçülebilirdir (A13). Bunları tek bir para biriminde ifade etmek, bu makalenin varsaydığı ama tanımlamadığı bir Değer Toplulaştırma Politikası gerektirir.
• Atıf. Gerçekleşen değer çoğu zaman birkaç sürümün ve dış etkenlerin sonucudur; şema yapıyı gösterir ama tek bir sürümün katkısını ayıramaz.
• Gizli akışlar. Şema, sistemin gözlenen istikrarını veya gerilemesini açıklayamıyorsa, örtük akışlar vardır ya da sınır yanlıştır (T9). Şema, yapıya ilişkin bir hipotezdir ve gözden geçirilmelidir.
• Yöntemin maliyeti. Karar üretmeyen oturumlar, yöntemin kendisini karşı değere dönüştürür.

Bir ampirik çalışma en azından şunlara ihtiyaç duyar: retrospektif değeri kaydedecek kadar uzun bir süre boyunca yöntemi uygulayan birkaç teslimat ekibi; veri toplamadan önce üzerinde anlaşılmış istikrarlı bir öğe sicili ve toplulaştırma politikası; gerçekleşen değerin ekipler tarafından değil, alıcılar tarafından bağımsız biçimde doğrulanması; bu ölçütler ile gerçekleşen değer arasındaki ilişkinin incelenebilmesi için geleneksel teslimat ölçütlerinin paralel toplanması; ve şemayla ve şemasız alınan kararların karşılaştırılması. Değer temelli önceliklendirmenin teslim edilen değeri değiştirip değiştirmediğini ve hangi koşullarda değiştirdiğini ancak böyle bir çalışma gösterebilir.

12 Sonuç

Teslimat ölçütleri, işin bir boru hattından nasıl geçtiğini anlatır, alıcıları için neyi değiştirdiğini değil; VMT çerçevesinde de bunu yapamazlar, çünkü değer bağlamsaldır, yalnızca kullanımda gerçekleşir ve planlanan ile gerçekleşen değer birbirinden ayrışır. VSS Editor'da uygulanan Değer Sistemi Şeması (Value System Schema), yazılım ekiplerinin ürün değer döngüsünü hipotezden gerçekleşen değere ve oradan şirkete geri dönüşe kadar çizmesine olanak tanır. Sürüm başına planlanan, gerçekleşen ve retrospektif değerin kaydedilmesi döngüyü bir ölçüme dönüştürür: direnç ve sızıntı görünür hale gelir, ortak düğümler hizmet ettikleri her akış boyunca değerlendirilir ve ekip liderleri teslim edilen değeri, değer temelli önceliği ve gecikme ile hataların maliyetini geri bildirim olarak elde eder. Yöntem yalnızca sistem sınırı belirtildiğinde, alıcılar gerçekleşen değeri doğruladığında ve her artefakt bir karara hizmet ettiğinde dürüst kalır. Uygulamada teslim edilen değeri iyileştirip iyileştirmediği, bu makalenin çerçevelediği ama yanıtlamadığı ampirik bir sorudur.

Kaynakça

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (Rusça). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.