ממרכז עלות לממיר ערך: המרת אנטי-ערך בתמיכה טכנית

טקסט מלא

1 מבוא

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

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

המקור העיקרי הוא המאמר ב-Æilus "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). הוא מתאר את התמיכה כשרשרת של מתמרי ערך המקבלים אנטי-ערך מהלקוח וממירים אותו לערך, עם מקדמים הגדלים בכל קו, ומציע שני מקדמים למדידה בכל שלב. מאמר זה מנסח מחדש את המודל, הופך את המקדמים לאופרטיביים, קובע את ערכו של מי הם מודדים, ומציע פרוטוקול מדידה. הוא אינו כולל נתוני שדה; כל המספרים בדוגמה המעובדת הם להמחשה בלבד.

המאמר נשען על האקסיומות של VMT: A1 (הקשריות), A2 (פרשנויות מרובות), A4 (אסימטריה בין תוכנית למציאות), A5 (עצמאות האנטי-ערך), A6 (מימוש בעת הצריכה), A7 (התמרה), A12 (היעדר שימור הערך) ו-A13 (מדידות חלקית משותפת), ועל המשפטים T2 (היפוך זרם), T4 (הצטברות התנגדות), T5 (אופטימיזציה מקומית), T9 (זרמים נסתרים), T14 (ערך שלא פורש אובד), T15 (תלות בגבול) ו-T16 (קנה מידה באמצעות פרשנות ללא מימוש).

2 מדוע התמיכה נתפסת כמרכז עלות, ומה הדבר מסתיר

2.1 ראיית העלות היא בחירת גבול

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

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

2.2 מה ראיית העלות מסתירה

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

3 התמיכה כנקודת הכניסה של זרם האנטי-ערך

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

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

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

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

4 שרשרת ההמרה

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

4.1 קו ראשון

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

4.2 קו שני

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

4.3 קו שלישי

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

4.4 Product Owner

המקור ממקם את צוות ה-Product Owner כמתמר הבא וכמסנתז ערך. הוא מתעדף את הזרם מכל הקווים, מיישר אותו עם האסטרטגיה, מעריך היכן ערך הלקוח הגבוה ביותר באנטי-ערך הנמוך ביותר בעלות, בזמן ובסיכון, ומוסיף ערך פוטנציאלי מצורכי השוק. התוצר הוא תוכנית אספקה שמגדילה ערך קיים ויוצרת ערך חדש. המקור קושר זאת ל-PDCA: Plan מנתוני התמיכה, Do בידי צוותי האספקה, Check על תקריות ומדדי ערך, Act על האסטרטגיה והמוצר. המוצר המעודכן מספק שוב ערך, התמיכה קולטת את הזרם הבא, והמעגל נסגר.

5 המקדמים המוצעים במקור

5.1 מקדמים נומינליים לכל קו

סיכום המקור של המעגל הסגור קובע שאנטי-ערך שנקלט בקו הראשון יכול להיות מומר לערך במקדם של x1 עד x1.5; בקו השני, x10; בקו השלישי, x100. הצעות לקוחות עוברות לקו השני והשלישי בנפח המתואר כבלתי מוגבל, והערך ש-Product Owner מחזיר ללקוח מתואר כבלתי מוגבל כמעט בפוטנציה. התבנית: ככל שהבעיה גדולה יותר, כך היא מגיעה לקו גבוה יותר, וככל שהקו גבוה יותר, כך המקדם גבוה יותר. המקור מציע אותם כסדרי גודל, לא כמדידות. מאמר זה מתייחס אליהם כהשערות.

5.2 VAM ו-ACM

המקור מסיק ששני פרמטרים חייבים להימדד בכל שלב:

• Value Amplification Multiplier (VAM), מקדם העברת הערך: "כמה ערך התקבל והועבר ללקוח".
• Anti-Value Conversion Multiplier (ACM), מקדם ההמרה של אנטי-ערך לערך: כמה אנטי-ערך התקבל וכמה ממנו הומר לערך עבור הלקוח.

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

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s הוא ערך הנכנס לשלב (הצעות או ערך פוטנציאלי שהומר חלקית); V_delivered,s הוא ערך ממומש ללקוח שניתן לייחס לתוצר של השלב; AV_received,s הוא אנטי-ערך הנכנס לשלב; V_converted,s הוא ערך ממומש ללקוח שנוצר ממנו. כל המשתנים נמדדים ב-Æ.

שתי קריאות נובעות מניסוח המקור. הראשונה: המונים הם ערך עבור הלקוח, ולכן תוכניות, כרטיסים ופריטי backlog נספרים רק לאחר שהלקוח מימש אותם (A6). והשנייה: לשני המקדמים מכנים שונים, האחד עוקב אחר הגברה של ערך, והאחר אחר המרה של אנטי-ערך. מקדם ברמת השרשרת הוא ACM_chain = sum of V_converted,s / AV_received,1, כאשר המכנה הוא אנטי-ערך הקליטה, וכל יחידת ערך ממומש מיוחסת לשלב אחד בלבד.

6 של מי הערך נמדד

לפי A1 ו-A2, מקדם ללא מערכת ערך מוגדרת הוא חסר משמעות. השרשרת נוגעת בארבע מערכות ערך:

מאמר זה קובע את המדידה כך. המונים של VAM ו-ACM נמדדים במערכת הערך של הלקוח, משום שערך ממומש הוא פרשנות של המקבל. המכנים נמדדים בגבול בין הלקוח לתמיכה: אנטי-ערך כפי שהלקוח חווה ומדווח עליו, כפי שנרשם על ידי הקו הראשון. מערכות התמיכה והמוצר משתמשות במקדמים; מערכת החברה שוקלת אותם אל מול העלות. ה-VSO אחראי על מדיניות האגרגציה להשוואת קריאות אלה, שהן ברות השוואה רק חלקית (A13). אילו התמיכה הייתה מודדת את עצמה ממערכת הערך שלה, היא הייתה מדווחת על מאמץ ועל ערך מתוכנן. ההגדרות במקור מצביעות כלפי חוץ, והפרוטוקול משאיר אותן שם.

7 פרוטוקול מדידה

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

7.1 נתונים לרישום

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

7.2 מי מאמת ערך ממומש

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

7.3 מחזור סקירה

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

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

7.4 מלכודות

Goodhart (1975) הבחין שחוקיות סטטיסטית נוטה להתמוטט משעה שמשתמשים בה לצורך בקרה. במונחי VMT זהו T5: אופטימיזציה מקומית אינה מבטיחה שיפור גלובלי.

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

8 הקשר לתחומי שירות

מתודולוגיית Æilus מגדירה תחום כהקשר פרשנות של ערך הכופה דרישות על פרקטיקות ותוצאות קבילות. תחומים אינם יוצרים ערך; הם מונעים אנטי-ערך שאינו קביל. התמיכה נוגעת בכמה תחומים אופייניים:

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

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

9 דוגמה מעובדת להמחשה

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

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

• קליטה. האנטי-ערך של כל לקוח מוערך ב-10 Æ, ולכן AV_received,1 = 100 Æ.
• קו ראשון. פתרון עקיף מוכר ועדכוני סטטוס משיבים את העבודה לתפקוד; הלקוחות מאשרים 120 Æ של ערך ממומש. ACM_1 = 120 / 100 = 1.2, בתוך הטווח הנומינלי של המקור.
• קו שני. נמצאת סיבת שורש בתצורה; ברירת מחדל מתוקנת ומאמר במאגר הידע מגיעים ללקוחות המדווחים ולאחרים. הערך הממומש שאושר: 400 Æ. ACM_2 = 400 / 100 = 4, מתחת ל-x10 הנומינלי. בפרוטוקול זו תוצאה שיש לבחון, ולא טעות שיש לתקן.
• קו שלישי ומוצר. פרוטוקול הייבוא נמצא שברירי; תכנון מחדש ובדיקה אוטומטית נכנסים למפת הדרכים עם ערך מתוכנן של 5,000 Æ. דבר עדיין לא נמסר, ולכן ACM_3 = 0 עבור קוהורטה זו. ה-5,000 Æ נרשמים ומוחרגים מהחישוב.
• הצעות. שני לקוחות מבקשים ייבואים מתוזמנים. זהו ערך פוטנציאלי במסלול VAM, והוא אינו נכנס ל-ACM.

בסקירה זו ACM_chain = (120 + 400 + 0) / 100 = 5.2. אם התכנון מחדש יימסר בהמשך והלקוחות יאשרו ערך, הקוהורטה של הקו השלישי תעודכן למפרע; אם הוא יגרום לנסיגה, אנטי-ערך זה יירשם על חשבון הקו השלישי. הדוגמה חושפת מה פיילוט צריך לעקוב אחריו: הפער בין התכנון למציאות בשלב העמוק ביותר (A4, A6), השהיית המימוש, וסטייה אפשרית מהמקדמים הנומינליים.

10 מגבלות

אין כאן נתוני שטח, וגם לא במקור. המקדמים x1 עד x1.5, x10 ו-x100 הם סדרי גודל מוצעים, סבירים לפי המנגנון המתואר (תיקון אחד שמוכפל על פני לקוחות רבים, מתמרים חדשים שנוצרים) אך לא נמדדו. הנוסחאות הן קריאתו של מאמר זה להגדרות מילוליות; קריאות אחרות אפשריות. הערכות ה-Æ תלויות בפרשנות, שלפי A2 היא תכונה של הערך, אך השוואה בין צוותים עדיין דורשת סקאלה משותפת מכוילת שמאמר זה אינו מספק. ייחוס בין השלבים מוטל על ה-VSO ללא כלל.

פיילוט שיכול לתמוך במודל או להחליש אותו יצטרך להראות:

• שאנשים שונים מבצעים הערכות Æ עקביות עבור אותן פניות;
• שה-ACM של הקוהורטה במשך כמה מחזורי סקירה עוקב אחר הסדר החזוי לפי קו, יהיו הערכים המוחלטים אשר יהיו;
• שהערך הממומש אושר על ידי לקוחות או על ידי מייצגים מוסכמים, ולא על ידי הקווים התובעים אותו;
• שהשימוש במקדמים לווה בירידה בסך זרם האנטי-ערך הנכנס, ללא המניפולציות המפורטות בסעיף 7.4;
• שהמקדמים מוסיפים מידע מעבר למדדים מקובלים כמו זמן לשחזור שירות (Forsgren, Humble and Kim, 2018).

11 סיכום

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

מקורות

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• 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.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.