דלגו לתוכן
ÆVRI, Aeilus Value Research Institute

מאמרי מתודולוגיה · צד שרת, DevOps

מדידת זרמי ערך באספקת תוכנה באמצעות סכמת מערכת ערך

תרגום מכונה. שפת המקור: אנגלית. לקריאת המקור

סיכום קצר של הערך

מהירות (velocity), תפוקה (throughput) ומדדי אספקה בסגנון DORA מתארים כיצד עבודה נעה בצינור, אך לא איזה ערך היא מספקת ואיזה אנטי-ערך היא יוצרת. מאמר זה מציע למובילי מוצר והנדסה שיטה למידול מערכת הערך של מוצר תוכנה באמצעות סכמת מערכת ערך (VSS) ו-VSS Editor, ולהשוואת ערך מתוכנן, ערך ממומש וערך רטרוספקטיבי לכל גרסה. הוא עוסק בהתנגדות זרימה, דליפה, צמתים משותפים כגון הרשאה ושערי API, תפקידים, קצב ומגבלות הגישה.

ממצאים עיקריים והערך שלהם

  • מדדי צנרת (pipeline) מודדים במקרה הטוב ערך מתוכנן. הם נאספים לפני הצריכה ובצד השולח, בעוד שערך מתממש רק בשימוש (A6) והתכנית והעובדות מתפצלות (A4, T3). ערך: מנהיגים יכולים לשמור על מדדי אספקה לבריאות הצנרת מבלי לבלבל אותם עם ערך שסופק.
  • מעגל הערך של המוצר חורג מהצנרת. השערה, בקלוג, פיתוח, תפעול, ייצור, משתמשים וזרם החזרה אל החברה יוצרים מעגל אחד; מדדי האספקה מכסים רק שניים משלביו. ערך: הסכמה מראה היכן ערך מתוכנן, אובד, מתממש וחוזר.
  • השוואה בין ערך מתוכנן לערך שהתממש בכל גרסה חושפת התנגדות ודליפה. הפסדים ביישום, בשחרור, באימוץ ובעיכוב, כולל עלות העיכוב, נרשמים כאנטי-ערך בזרמים ספציפיים. ערך: צוותים יכולים לאתר את הממיר שבו אבד ערך במקום להתווכח על ממוצעים.
  • יש להעריך צמתים משותפים על פני כל הזרמים שהם משרתים. לאימות הרשאות או לשער API אין ערך משלהם, אך הם מוסיפים ערך או אנטי-ערך לכל זרם. ערך: מונע קיצוץ עלויות בצמתים שהידרדרותם מוסיפה התנגדות לכל זרם.
  • הנמענים מאמתים את הערך שהתממש; צד שני בודק אותו. ערך שהוערך עצמית הופך למונה נוסף (T17). ערך: חלוקה ברורה של מי מעריך, מי מאמת ובאיזו תדירות הופכת ערך שסופק לשמיש כמשוב וכבסיס לעדיפות הבקלוג.

כיצד המחקר בוצע

תכנון מתודולוגיה שנגזר מהאקסיומות והמשפטים של תורת ניהול הערך ומתודולוגיית Æilus v2.0, ומיושם על מערכת הערך של אספקת תוכנה. סימון VSS נלקח מ-VSS Editor כפי שפורסם ב-aeilus.tech. השיטה מודגמת באמצעות סכמת מוצר סינתטית ללא מספרים; הדוגמה היא היפותטית ואינה מתארת ארגון אמיתי כלשהו.

מגבלות. לא נאספו נתונים אמפיריים והשיטה לא נבדקה הלכה למעשה. הערכות ב-Æ הן פרשנויות, סוגי ערך ניתנים להשוואה רק באופן חלקי, והסכמה אינה יכולה לייחס ערך שמומש לגרסה בודדת. אימות ידרוש כמה צוותים שיפעילו את השיטה זמן מספיק כדי לתעד ערך רטרוספקטיבי, מרשם אלמנטים ומדיניות צבירה קבועים, אימות עצמאי על ידי הנמענים, ואיסוף מקביל של מדדי אספקה מקובלים.

חומרים / נתונים

בהתבסס על החומרים של המחבר עצמו: מתודולוגיית Æilus גרסה v2.0, מאמרי aeilus.tech על VSS Editor ועל הערכת ערך התהליכים, דף VSS Editor ודף Æilus Artifacts and Reports, המצגת על מערכת הערך של המוצר (Product Value System), ופוסטים של המחבר בערוצו הרוסי מהשנים 2022 ו-2025 על זרמי ערך, הובלת צוות, שלבי תהליך משותפים ו-VSS Editor. לצורך המינוח נעשה שימוש במדריך העזר של תורת ניהול הערך (אקסיומות A1-A13, משפטים T1-T17). לא נעשה שימוש במערכי נתונים.

חלק 5 מתוך 8 בסדרת ÆVRI "Æilus לעסקים".

טקסט מלא

1 מבוא

צוותי תוכנה נמדדים באופן הדוק: מהירות (velocity), תפוקה, זמן אספקה, תדירות פריסה ושיעור כשלי שינויים נאספים באופן אוטומטי. ובכל זאת מספרים אלה משאירים שאלה אחת פתוחה: איזה ערך סיפק הצוות, למי, ובאיזה מחיר של הפסדים?

מאמר זה מציע שיטה למתן מענה לשאלה זו באמצעות סכמת מערכת ערך (VSS), סימון המידול של מתודולוגיית Æilus, כפי שהיא ממומשת ב-VSS Editor שפורסם ב-aeilus.tech. זהו המאמר החמישי בסדרה "Æilus for Business". הוא משתמש באוצר המילים שהוגדר במאמר הראשון בסדרה, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), ואינו חוזר על הגדרות אלה. הטיפול הפורמלי בערך כמטבע מדיד (Æ) מובא ב-"Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

המאמר מתאר כיצד ארגון אספקה יכול לבנות סכמה של מערכת הערך שלו, לצרף ערך מתוכנן וערך ממומש לגרסאות (releases), לאתר התנגדות זרימה ודליפה, להעריך צמתים טכניים משותפים, ולהריץ את המחזור עם תפקידים וקצב ברורים. הוא נשען על אקסיומות VMT‏ A1, A2, A4, A5, A6, A7, A11 ו-A13 ועל משפטים T3, T4, T5, T6, T8, T9, T15, T16 ו-T17. הוא אינו מכיל נתונים שנמדדו. הדוגמה המפורטת בסעיף 9 היא סינתטית.

2 מה מדדי אספקה מודדים ומה לא

מדדי אספקה מתארים את תנועת העבודה. המהירות (velocity) סופרת מאמץ משוער שהושלם; התפוקה סופרת פריטים שהסתיימו. ארבעת המדדים המרכזיים שהפכו לפופולריים על ידי Forsgren, Humble ו-Kim (Accelerate, 2018), כלומר תדירות פריסה, זמן אספקה לשינויים, זמן שחזור שירות ושיעור כשלי שינויים, מתארים את המהירות והיציבות של צינור האספקה. מחקר זה קושר יכולות אלה לביצועים ארגוניים, ומאמר זה אינו חולק עליו. טענתו צרה יותר: מדדים אלה מתארים את הצינור, ולא את הערך שעובר דרכו.

שלושה פערים נובעים מכך.

  • מאמץ אינו ערך. ספרינט בעל מהירות גבוהה יכול לספק תכונות שאיש אינו משתמש בהן. בלשון מצגת Product Value System, "features are not value" ו-"metrics are not value": תכונה היא הנחה לגבי ערך, ומדד הוא פרשנות שלו.
  • מהירות אינה כיוון. זמן אספקה קצר מספק השערה שגויה מהר יותר.
  • יציבות אינה היעדר אנטי-ערך. שיעור נמוך של כשלי שינויים אינו אומר דבר על עיכוב, בלבול, עבודה חוזרת בצד המשתמש או אובדן אמון שנגרמו משינוי שפעל בדיוק כפי שתוכנן.

מנקודת המבט של תורת ניהול הערך (VMT), הפער הוא מבני. ערך קיים רק בתוך מערכת ערך מוגדרת ומפורש על ידי השחקנים שבה (A1, A2). הוא ממומש ברגע הצריכה (A6), וערך מתוכנן וערך ממומש נבדלים בדרך כלל (A4, T3). מדדי צינור נאספים לפני הצריכה, בצד השולח, ולכן הם מתארים לכל היותר את אספקת הערך המתוכנן. כאשר מדדים כאלה הופכים ליעדים, מופיעה התופעה שתיאר Goodhart (1975): צוותים מבצעים אופטימיזציה של המונה. VMT מנסחת את אותו סיכון במונחי מערכת: אופטימיזציה מקומית אינה מבטיחה שיפור כולל (T5).

3 סימון סכמת מערכת הערך

3.1 רכיבי הסימון

במתודולוגיית Æilus, סכמת מערכת הערך (Value System Schema) היא ארטיפקט הליבה הראשון: תיאור פורמלי של מערכת הערך, השחקנים, זרמי הערך, המתמרים והחלפות המפתח שלה, המשמש לקביעת גבולות המערכת ולמניעת תלויות חיצוניות בלתי נראות. ניתן לשרטט VSS ברמת המתמר או ברמת המערכת.

VSS Editor, שפורסם ב-aeilus.tech בדצמבר 2025, הוא עורך חזותי מבוסס דפדפן לסכמות כאלה. הסימון שלו כולל מספר קטן של רכיבים.

  • ממירים. ממיר (converter) הוא השם ב-Æilus לתפקיד מתמר בסכמה: בלוק פונקציונלי, כגון צוות, שירות או תת-מערכת, שמקבל רכיבי ערך, הופך אותם ומפיק חדשים. הממירים הם המקום שבו ערך נוצר, מוגבר או נהרס.
  • זרמים. זרם הוא קשר מכוון בין ממירים, או בין ממיר לעולם החיצון. הוא נושא כמות של ערך או אנטי-ערך ב-Æ. זרם הוא חיצוני נכנס (ערך הנכנס למערכת), חיצוני יוצא (ערך העוזב את המערכת) או פנימי (ערך בין ממירים).
  • כניסות ויציאות. זרמים חיצוניים נכנסים ויוצאים מסמנים היכן ערך נכנס ועוזב. יחד הם מגדירים את גבול המערכת.
  • רכיבי ערך. סוגי הרכיבים מתארים מה בדיוק נע דרך זרם: ערך ללקוח, הכנסה, עלויות, סיכונים, חוב טכני ודומיהם. בסכמה שמורה לכל רכיב יש סוג (ערך או אנטי-ערך), סימן, כמות ויחידה (Æ).
  • אנטי-ערך. אנטי-ערך מייצג הפסדים והשפעות שליליות: עיכובים, עבודה חוזרת, פגמים, בירוקרטיה, סיכון, שחיקה, מאמץ מבוזבז. בסכמה הוא רכיב מפורש בעל סימן שלילי, ולא היעדר ערך (A5).

3.2 הסכמה כמודל קריא למכונה

העורך שומר סכמה כ-JSON מובנה עם צמתים (ממירים), זרמים ורכיבים. לפיכך ניתן לנהל גרסאות של הסכמה יחד עם המוצר, ובהמשך לקרוא אותה באמצעות אנליטיקה שמשווה בין כמויות מתוכננות לכמויות ממומשות לכל זרם. אנליטיקה כזו הוכרזה כעבודה עתידית ואינה מונחת כאן כמובנת מאליה.

3.3 מה הסכמה אינה

VSS Editor אינו, במפורש, לוח מחוונים של KPI, כלי BI, מנוע סימולציה או תחליף להנהלת חשבונות פיננסית. הוא מציב בהירות לפני חישוב. סדר המידול המומלץ הוא כדלקמן: להגדיר את הגבול, להוסיף רק ממירים עיקריים, לחבר ביניהם בזרמים בעלי שם (שמות לפני מספרים, כיוון לפני דיוק), ולאחר מכן לסמן אנטי-ערך, שלב שמניב לעיתים קרובות את התובנות הרבות ביותר.

4 הערך של מי: המערכת וגבולה

מדידת ערך חסרת משמעות כל עוד אינה מציינת הערך של מי נמדד (A1, T1). הגבול שנבחר משנה גם את המסקנות מבלי שהמציאות תשתנה (T15). לכן מאמר זה קובע את מערכת הערך לפני כל מדידה.

מערכת הערך המומדלת כאן היא מערכת הערך של המוצר של מוצר תוכנה יחיד בתוך ארגון מוצר. בהתאם למצגת Product Value System, השחקנים בה הם פונקציית המוצר, צוות הפיתוח, התפעול, המוצר בייצור, המשתמשים, והחברה כמקבלת הערך החוזר מהמשתמשים. הכספים הם זרם חיצוני מאפשר נכנס (משכורות).

נמדדות שתי פרשנויות ממומשות: ערך למשתמשים, המפורש על ידי המשתמשים או על ידי התנהגותם הניתנת לצפייה, וערך לחברה, המפורש על ידי החברה כמקבלת זרם ההחזר (הכנסה, שימור, הפחתת עלות או סיכון). ערך מתוכנן הוא פרשנות השולח לפני הפצת הגרסה. הערך של אותה גרסה עבור שותף או רגולטור נמצא מחוץ לגבול, אלא אם הוא מורחב במפורש.

5 מהשערת מוצר לערך ממומש: לולאת הערך

מצגת Product Value System מעצבת את עבודת המוצר כלולאה שבה השערות ערך נוצרות, מיושמות, מאומתות ומתמידות. במונחי סכמה, בלולאה יש את הממירים והזרמים הבאים.

  1. השקעה לפונקציית המוצר. פונקציית המוצר ממירה משאבים ואותות משתמשים להשערות הנושאות ערך מתוכנן.
  2. פונקציית המוצר לפיתוח. השערות הופכות לפריטי בקלוג עם ערך מתוכנן. המצגת קובעת שתי ציפיות: הערך המתוכנן של השערה לא אמור לרדת בזמן בנייתה, והערך שסופק לא אמור להיות שונה בהרבה מהערך המתוכנן.
  3. פיתוח לתפעול. הפיתוח צורך מאמץ ומפיק שינויים עובדים, יחד עם אנטי-ערך (חוב טכני, פגמים, עיכוב).
  4. תפעול לייצור. שינויים הופכים לתוכנה רצה; שגיאות פריסה וזמן השבתה מופיעים כאנטי-ערך.
  5. ייצור למשתמשים. ערך מתממש רק בשימוש (A6), ולכן זו הנקודה הראשונה שבה ניתן לצפות בערך ממומש.
  6. משתמשים לחברה. המשתמשים מחזירים הכנסה, שימור ואמון. פוסט הערוץ של המחבר מינואר 2022 מכנה זאת זרם סגור: הערך שסופק ללקוח מאוזן בערך שזורם חזרה, לעיתים קרובות אך לא רק כסף.

הלולאה הופכת את אקסיומת ההמרה לקונקרטית (A7): כל ממיר מממש את מה שהוא מקבל ומפיק ערך מתוכנן חדש עבור הבא. היא גם מראה מדוע מדדי הצינור מכסים רק את שלבים 3 ו-4. שלבים 1, 2, 5 ו-6, שבהם ערך מתוכנן, מתממש וחוזר, נמצאים מחוץ לצינור.

הסיפון מפרט גם סוגי רכיבים הניתנים לצפייה עבור מוצרים פנימיים וחיצוניים. רכיבי ערך כוללים חיסכון בזמן, פחות שגיאות תפעוליות, תזרים מזומנים, הפחתת סיכון, עומס קוגניטיבי נמוך יותר, יכולת חיזוי, יכולות חדשות ואמון. מקבילי אנטי-ערך כוללים זמן אבוד, עבודה חוזרת, עלות תפעול גדלה, חוב טכני, חוסר יכולת חיזוי, פתרונות עקיפה ידניים, אובדן אמון והידרדרות בשירות הלקוחות. טיפולוגיה זו היא נקודת המוצא של מרשם רכיבי הערך (Value Element Registry) למסירה.

6 ערך מתוכנן וערך ממומש לכל מהדורה, התנגדות ודליפה

6.1 המהדורה כיחידת ההשוואה

יחידת ההשוואה היא המהדורה, או פריט ה-backlog כשהמהדורות קטנות. עבור כל אחת מהן השיטה מתעדת ב-Æ:

  • ערך מתוכנן: אומדן השולח, המתועד לפני תחילת הפיתוח ומתעדכן רק באמצעות החלטה מפורשת ומתועדת ביומן;
  • ערך ממומש ואנטי-ערך ממומש: פרשנות המקבל לאחר שהמהדורה הייתה בשימוש במשך תקופת תצפית מוסכמת;
  • ערך רטרוספקטיבי: הערכה מחדש מאוחרת, לאחר שהשפעות מסדר שני (עומס תמיכה, נטישה, חוב טכני) נעשו גלויות.

הסיפון מציע הנהגה בשלבים: תחילה ערך מתוכנן בכל פריט ב-backlog, אחר כך ערך ממומש ואנטי-ערך בכל פריט ששוחרר, ולבסוף ערך רטרוספקטיבי. בלי ערך מתוכנן אין פער למדוד; בלי ערך ממומש התוכנית נותרת השערה.

6.2 התנגדות זרימה במסירה

התנגדות זרימה היא הפער בין ערך מתוכנן לערך ממומש בתוספת האנטי-ערך המופיע בזרם. VMT רואה בפער שאינו אפס דבר רגיל (T3), אך קובעת שההתנגדות מצטברת היסטורית (T4) ומפחיתה את היכולת לממש ערך בעתיד (T6). במסירה ערך אובד ביישום (קיצוץ בהיקף, הבנה שגויה של ההשערה), בשחרור (תקלות, החזרות לאחור), באימוץ (משתמשים אינם מוצאים או אינם מצליחים להשתמש בשינוי) ובעיכוב. בהתאם למושג עלות העיכוב (Reinertsen, 2009), עיכוב מעוצב כאנטי-ערך בזרם המאוחר, ולא כמדד נפרד.

אם כל זרם נושא כמויות מתוכננות ונצפות משלו, הסכמה מראה באיזה ממיר התרחש ההפסד. זו מטרתם של מרשם התנגדות הזרימה (Flow Resistance Register) ושל דוח פער בין ערך מתוכנן לערך ממומש (Planned vs Realized Value Gap Report) בסט הארטיפקטים של Æilus.

6.3 דליפה

דליפה היא עודף מתמשך של ערך ממומש היוצא מהמערכת על פני ערך הנכנס אליה (A11). במערכת ערך של מוצר שכיחות שתי צורות. בראשונה, המשתמשים נהנים אך זרם החזרה אינו מכסה את הזרם הנכנס המאפשר. בשנייה, הצוות צורך השקעה בזמן שהשערות נבנות אך לעולם אינן ממומשות. התפוקה יכולה להיראות תקינה בשני המקרים; הסכמה מציגה את שניהם משום שזרמים נכנסים ויוצאים נמצאים על גבול אחד.

7 צמתים משותפים: הערכה על פני כל הזרמים

ממירים מסוימים במערכת תוכנה אינם מפיקים ערך שמשתמש היה מציין בשמו, ובכל זאת כל זרם ערך עובר דרכם. פוסט הערוץ של המחבר מספטמבר 2025 והמאמר הקשור ב-aeilus.tech משתמשים באימות הרשאות כדוגמה: הוא אינו מייצר ערך כשלעצמו, אך בלעדיו כל תרחיש נעצר. שער API או צינור CI הם מאותו סוג.

כשמעריכים צומת כזה בבידוד, הוא מראה עלות ולא תפוקה, ומזמין קיצוץ בעלויות. בסכמה הוא מופיע על זרמים רבים בו-זמנית, ויעילותו מתבהרת רק דרך הערך המצרפי של כל הזרמים שהוא תומך בהם. לכן השיטה מקצה לצומת משותף:

  • את קבוצת הזרמים העוברים דרכו, כפי שנקראת מהסכמה;
  • את האנטי-ערך שהוא מוסיף לכל אחד מהזרמים הללו (השהיה, השבתות, כניסות שנכשלו, פגמי אינטגרציה);
  • את הערך הנצרך שלו (מאמץ הצוות, תשתית).

יעילותו היא הערך שנמסר פחות האנטי-ערך על פני כל זרמיו, ביחס לערך הנצרך, בהתאם להגדרת יעילות התהליך באותו מאמר. הידרדרות בצומת משותף אינה לעולם אירוע מקומי; היא התנגדות שנוספת לכל זרם שהוא משרת. משפט T8 מוסיף טיעון של קיימות: היציבות אובדת כאשר לא ניתן למלא תפקיד טרנספורמציה, ויתירות של התפקיד מגדילה את היציבות.

8 מה מקבל ראש צוות

פוסט הערוץ של המחבר מפברואר 2022 מפרט מה הגישה מעניקה לצוות ולראשו. בניסוח מחדש במונחי מאמר זה:

  • ערך שנמסר כמשוב. לכל תקופה הצוות רואה את הערך שמסר, ב-Æ, מאושר על ידי הנמענים, במקום האות העקיף של ה-velocity.
  • מדד אפקטיביות שאינו תלוי במתודולוגיית התהליך. יהיו הפרקטיקות אשר יהיו, המדד הוא ערך ממומש לכל יחידת ערך נצרך, ופרקטיקות נבחרות או מופסקות לפי השפעתן עליו (P7).
  • שקיפות לעסק. עבודה טכנית נעשית ניתנת להסבר דרך הזרמים שהיא תומכת בהם.
  • סדר עדיפויות ב-backlog מתוך ערך. ניתן לגזור את סדר העדיפויות מהערך המתוכנן, מרמת הוודאות שלו ומעלות העיכוב שלו, במקום מבעל העניין הקולני ביותר.
  • עלות עיכוב ושגיאות בייצור כאנטי-ערך. העסק יכול להראות כיצד הערך יורד כששינוי מתעכב או פגום, והצוות רואה כיצד התועלת של עבודתו תלויה בתזמון ובאיכות הייצור.
  • טיעונים למשאבים משותפים. כאשר מנהלי מערכות ומהנדסי DevOps משותפים, סדר עדיפויות מבוסס ערך מסביר מדוע עבודתו של צוות אחד נדחתה לטובת עבודת צוות אחר, בשני הכיוונים.

יתרונות אלה מתקיימים רק אם הערך הממומש מאומת על ידי נמעניו. אם הצוות מעריך ומאשר את הערך של עצמו, המדד הופך למונה מדווח עצמית נוסף, וחל T17: פרשנויות ממקורות משפיעים שאינן מאושרות על ידי מימוש צוברות אנטי-ערך.

9 סכמה מעובדת של מוצר סינתטי

סעיף זה מתאר מוצר סינתטי להמחשה. אין זה מקרה בוחן, הוא אינו מתאר ארגון אמיתי, והוא אינו מכיל מספרים שנמדדו.

המוצר הסינתטי הוא יישום אינטרנט מבוסס מנוי שדרכו עסקי שירות קטנים מקבלים הזמנות מלקוחות. מערכת הערך שלו בנויה לפי הגבול שהוגדר בסעיף 4. שני צמתים משותפים, שירות אימות הרשאות ושער API, משרתים את כל הזרמים הפונים למשתמש. הכספים מספקים את הזרם הנכנס המאפשר. החברה מקבלת הכנסות ממנויים ושימור כזרם החזרה.

הסכמה נבנית ב-VSS Editor בארבעה מעברים: הגבול עם זרם חיצוני נכנס אחד (השקעה ומשכורות) והזרמים החיצוניים היוצאים אל המשתמשים; שבעה ממירים; זרמים הנקראים על שם רכיבי הערך שהם נושאים; ורכיבי אנטי-ערך. הכמויות נשארות ריקות עד לפגישת האומדן הראשונה.

ממירזרם נכנס עיקריזרם יוצא עיקרירכיבי ערך (להמחשה)רכיבי אנטי-ערך (להמחשה)מי מעריך / מי מאמת
פונקציית המוצרהשקעה, משוב משתמשיםהשערות עם ערך מתוכנןתרחישי הזמנה חדשים, פחות אי-הגעותהשערות שלא אומתו, עלות הזדמנותבעל המוצר מעריך; VSO סוקר
צוות הפיתוחהשערות, משכורותשינויים עובדיםיכולת שמומשה ביישוםחוב טכני, עבודה חוזרת, עיכובראש הצוות מעריך; בעל המוצר מאמת
תפעולשינויים עובדיםמהדורות פועלותמהדורות צפויותשגיאות שחרור, השבתההתפעול מעריך; ראש הצוות מאמת
שירות אימות הרשאות (משותף)כל בקשות המשתמשיםהפעלות מאומתותגישה, אבטחת חשבוןכניסות שנכשלו, השהיההצוות הבעלים מעריך; מוערך על פני כל הזרמים
שער API (משותף)קריאות לקוחות ושותפיםבקשות מנותבותזמינות כל התרחישיםהשבתות, פגמי אינטגרציההצוות הבעלים מעריך; מוערך על פני כל הזרמים
היישום בייצורמהדורה פועלתהזמנות שבוצעו על ידי משתמשיםחיסכון בזמן, פחות שגיאות ידניותבלבול, תרחישים שאבדו, פתרונות עקיפה ידנייםאנליטיקת המוצר צופה; המשתמשים מאמתים
משתמשים עסקייםהזמנות, יכולותהכנסות ממנויים, שימורהכנסות, אמוןתלונות, נטישההחברה (VSO) מפרשת את זרם החזרה

נבחן מהדורה היפותטית אחת: תכונת תזכורות שנועדה להפחית פגישות שהוחמצו. לפני הפיתוח בעל המוצר מתעד ערך מתוכנן לכל אלמנט (זמן שנחסך, פחות הזמנות שהוחמצו, השפעה צפויה על שימור לקוחות). לאחר תקופת תצפית מוסכמת, ניתוח המוצר ומדגם של משתמשים עסקיים מספקים את הערך שהוּמש, והצוות מתעד את האנטי-ערך שהוּמש: מהדורה שהתאחרה, פגם ששלח תזכורות כפולות, עומס נוסף על שער ה-API. ההפרש הוא ההתנגדות של מהדורה זו. הפגם והעומס על השער נמצאים גם בזרמים המשרתים תרחישים אחרים, ולכן הם משויכים גם לצמתים המשותפים. רבעון מאוחר יותר, ערך רטרוספקטיבי מתעד אם השימור השתנה בכלל. ביישום אמיתי, הכמויות יגיעו מהמפגשים המתוארים להלן.

10 איך מפעילים זאת

10.1 מי מעריך ומי מאמת

הכלל של Æilus מהפוסט של 2025 קצר: את ערך הפלט של תהליך חייב להעריך מי שצורך אותו, ואדם אחר צריך לבדוק את ההערכה הזו. כשמיישמים זאת על אספקה, מתקבלת חלוקה ברורה.

  • ערך מתוכנן מוערך על ידי השולח. בהיפותזות זהו בעל המוצר, הפועל כבעל מתמר הערך (VTO) של מתמר המוצר. במתמר הפיתוח זהו ראש הצוות כ-VTO.
  • ערך שהוּמש מפורש על ידי המקבל: המשתמשים, הנצפים באמצעות ניתוח מוצר או ניתוח אתרים, והחברה עבור זרם החזרה. המצגת מציעה, כצעד זמני, שניתוח המוצר ייצג את צד המשתמשים עד שיוקם אימות ישיר.
  • אימות הפירוש מבוצע על ידי צד שני: בעל מערכת הערך (VSO), האחראי על קיימוּת ברמת המערכת, או בעל הזרימה לזרם קריטי.
  • שלמות מתודולוגית נתמכת על ידי מאסטר Æilus (במצגת, אלוף Æilus שתפקידו מוחזק על ידי מנהל פרויקט), המכין את דוחות אספקת הערך, תכנון מול ביצוע והתנגדות הזרימה.

10.2 מקצב

Æilus אינה קובעת לוח זמנים. מקצב מינימלי לצוות אספקה, העולה בקנה אחד עם האירועים המומלצים של המתודולוגיה, הוא כדלקמן.

  • בכל חידוד באקלוג: ערך מתוכנן מוקצה לפריטים חדשים, באמצעות מרשם האלמנטים.
  • בכל מהדורה, לאחר תקופת התצפית: ערך ואנטי-ערך שהוּמשו מתועדים ומאומתים; רטרוספקטיבת ערך קצרה דנה בפער.
  • חודשי או רבעוני: סקירת התנגדות הזרימה על הסכמה, כולל הצמתים המשותפים; ערך רטרוספקטיבי לפריטים שהופצו קודם.
  • רבעוני או בעת שינוי מבני: סקירת מערכת הערך של גבולות, מתמרים ותלויות, עם עדכון וניהול גרסאות של קובץ הסכמה.

10.3 משמעת

כל תוצר דורש בעלים, מחזור עדכון ומטרת החלטה; אחרת הוא יוצר אנטי-ערך דרך עלות תחזוקה וביטחון שווא. בשיטה זו מטרות ההחלטה הן עדיפות באקלוג, הקצאת משאבים משותפים, עיתוי מהדורות והשקעה בצמתים משותפים. גידול בערך מתוכנן מותר רק כאשר יכולת הצוות להמשיש אותו אושרה (P9). הגדלת הערך המתוכנן מהר יותר מהערך שהוּמש היא אופן הכשל המתואר על ידי T16.

11 מגבלות ומה שמחקר אמפירי יצטרך

מאמר זה הוא רעיוני ולא נבדק על נתונים שנמדדו. מכך נובעות כמה מגבלות.

  • איכות ההערכה. ערכים ב-Æ הם פירושים שאמינותם תלויה במעריכים ובכיולם.
  • מדידות חלקית משותפת. זמן שנחסך, הכנסות ואמון ניתנים להשוואה רק באופן חלקי (A13). הבעתם במטבע אחד דורשת מדיניות צבירת הערך, שמאמר זה מניח אך אינו מגדיר.
  • ייחוס. ערך שהוּמש הוא לרוב תוצאה של כמה מהדורות וגורמים חיצוניים; הסכמה מציגה מבנה אך אינה יכולה לבודד את תרומתה של מהדורה אחת.
  • זרמים נסתרים. אם הסכמה אינה יכולה להסביר את היציבות או הירידה הנצפות של המערכת, קיימים זרמים סמויים או שהגבול שגוי (T9). סכמה היא השערה על מבנה וחייבת להיות מתוקנת.
  • עלות השיטה. מפגשים שאינם מניבים החלטות הופכים את השיטה עצמה לאנטי-ערך.

מחקר אמפירי יצטרך, לכל הפחות: כמה צוותי אספקה המיישמים את השיטה לתקופה ארוכה דיה כדי לתעד ערך רטרוספקטיבי; מרשם אלמנטים יציב ומדיניות צבירה שהוסכמו לפני איסוף הנתונים; אימות עצמאי של ערך שהוּמש על ידי הנמענים ולא על ידי הצוותים; איסוף מקביל של מדדי אספקה מקובלים, כדי שאפשר יהיה לבחון את היחס בין מדדים אלה לבין ערך שהוּמש; והשוואה בין החלטות שהתקבלו עם הסכמה ובלעדיה. רק מחקר כזה יוכל להראות אם תעדוף מבוסס ערך משנה את הערך שסופק, ובאילו תנאים.

12 סיכום

מדדי אספקה מתארים כיצד העבודה נעה בצינור, ולא מה היא שינתה עבור נמעניה; לפי VMT הם אינם יכולים לעשות זאת, משום שערך הוא הקשרי, מוּמש רק בשימוש, והערך המתוכנן והערך שהוּמש סוטים זה מזה. סכמת מערכת הערך (Value System Schema), כפי שהיא מיושמת ב-VSS Editor, מאפשרת לצוותי תוכנה לשרטט את לולאת ערך המוצר מהיפותזה ועד ערך שהוּמש וחזרה אל החברה. תיעוד ערך מתוכנן, ערך שהוּמש וערך רטרוספקטיבי לכל מהדורה הופך את הלולאה למדידה: התנגדות ודליפה נעשות גלויות, צמתים משותפים מוערכים על פני כל הזרמים שהם משרתים, וראשי צוותים מקבלים כמשוב את הערך שסופק, עדיפות מבוססת ערך ואת עלות העיכוב והטעויות. השיטה נשארת הוגנת רק אם גבול המערכת מוצהר, הנמענים מאמתים את הערך שהוּמש, וכל תוצר משרת החלטה. האם היא משפרת בפועל את הערך שסופק היא שאלה אמפירית שמאמר זה מגדיר אך אינו עונה עליה.

מקורות

  • 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 (in Russian). 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.

ציטוט העבודה

Bolshakov, V. (2026). Measuring Value Flows in Software Delivery with the Value System Schema. Aeilus Value Research Institute (ÆVRI). https://aeilus.institute/research/measuring-value-flows-in-software-delivery-with-vss/

עד כמה זה היה בעל ערך עבורכם?

0ערך מתוך 1 הערכות

זמן הקריאה נחשב להערכה שלכם. התחברות כדי לבחור תגובה בעצמכם.

הוספת תגובה

התחברות כדי להשאיר תגובה.

כיצד הערך נמדד

כל המחקרים