MVP ( מוצר מינימלי בר-קיימא)
MVP הם ראשי תיבות ל–Minimum Viable Product, מוצר מינימלי בר-קיימא/חיוני. זהו מושג המגלם את מינימום הרכיבים הנדרשים במוצר כדי לאפשר לו לפתור צורך ממשי של משתמשים (כאב). המושג עלה כחלק ממתודלוגיית ה-Lean Startup ו-פיתוח תוכנה אג׳ילי.
למה זה טוב?
ה-MVP משחרר את החברות, ובייחוד את חברות ההזנק, מתהליכי עבודה ארוכים ומסורבלים שלרוב גם פספסו את מטרתם. במקום להביא לשוק מוצר מוגמר, מושלם ככל הניתן ולגלות מאוחר מדי שהוא לא עונה על הצורך של המשתמשים, ה-MVP מבקש את ההפך: תביאו מוצר ראשוני מוקדם ככל הניתן למשתמשים ומשם תתחילו ללמוד, להשתפר ולהתפתח.
המושג חיוני בגלל הניגודיות המשלימה שמצויה בו – "מינימלי וחיוני" היא השאיפה הבסיסית של ארגונים ועסקים: מקסימום אפקטיביות במינימום משאבים. יש לשים לב כי אלו מרכיבים יחסיים המחייבים פירוש בהקשר. לא פעם נגלה שמה שחשבנו שהוא חיוני ממש לא עושה את העבודה. לעתים נגלה את ההפך – ששגינו בהערכת יתר את ציפיות המשתמשים. באותו אופן גם השאלה מה נחשב מינימאלי תלויית הקשר: המשאבים שחברת הזנק יכולה להעמיד לא דומים לאלו של גוף ממשלתי או של תאגיד בינ״ל.
Making sense of #MVP and why @henrikkniberg prefers Earliest Testable/Usable/Lovable https://t.co/SRCEPPfbFk #agile pic.twitter.com/wF4Oip6sfO
— Agile Alliance (@AgileAlliance) February 11, 2016
הגדרה של MVP
אין תשובת מדף לשאלה ״מה ייחשב למינימום?״ וכן לשאלה מה נחשב ״בר-קיימא״. המענה על השאלה הזו הוא חלק משמעותי מאוד מפיתוח ה-MVP ולרוב יכלול גישוש מקדים מול השוק והלקוחות הפוטנציאליים במסגרת סקר שוק כזה או אחר.
מבחינת התכולות, כלל האצבע הוא ש-MVP טוב הוא כזה שעומד בפני עצמו. הוא לא יהיה יפה או אסתטי במיוחד, אולי הוא לא יהיה היעיל ביותר, אך הוא יפתור למשתמשים בעיה שהם מתמודדים איתה ולפיכך יהיה בעל שימוש עבורם. שימוש שיאפשר לנו גם להתקדם לשלב הבא: הוא יספק מידע על הצורך של המשתמשים ועל בסיס מידע זה נוכל להמשיך בדיוק והתאמה של המוצר למשתמשים.
כלומר, בהגדרה של MVP יש להציב תשובה לשאלות הבאות:
- חיוניות למשתמשים:
- מה הצורך הממשי של הלקוחות שהמוצר פותר (האם שאלנו אותם)?
- כיצד הם מתמודדים כיום עם הצורך הזה?
- מדוע שיעברו למוצר חדש?
- בתהליכים פנים ארגוניים - כיצד נבין את ה-ROI של ה-MVP?
- מינימליות:
- האם באמת הגדרנו את המוצר הרזה ביותר?
- היכן אנו יכולים לחסוך כרגע בפיתוח כדי להגיע מהר יותר למשתמשים?
- חיוניות להמשך הפיתוח - כדאי לנסח את ההשערות שלנו לגבי המוצר וכיצד הן ניתנות לבחינה באמצעות המוצר:
- כיצד נבין מהשימוש במוצר את נטיות המשתמשים?
- האם ה-MVP יפיק לנו את המידע שאנו צריכים?
- האם תהיה לנו דרך לשאול את המשתמשים באופן ישיר?
הגדרת MVP עבור מערכות מידע פנימיות בארגון
מושג ה-MVP מרכזי מאוד כיום בעולמות העסקיים, אבל הוא רלוונטי מאוד גם לפיתוחים פנים-ארגוניים. מספר רב של מחקרים[1] ודוחו״ת[2], וכן מקרים שקרו בישראל[3][4] ובעולם[5], אנו יודעים לומר כיום שאחת הסיבות בגינה פרוייקטי מחשוב נכשלים בארגונים היא בגין הכישלון לזהות את הצורך האמיתי של העובדים בארגון, פעמים רבות בגלל המרחק בין השטח למטה. עקב כך, מאופיינות ומפותחות מערכות שאינן רלוונטיות למשתמשים בה הם לא משתמשים כלל, או משתמשים באופן כפוי בלבד.
דרך אחת טובה להבין מה צריך לכלול ה-MVP היא באמצעות ישיבת הנהלה בה המשתתפים מעלים רעיונות; ראיונות עומק עם עובדי מפתח; סקר איתור צרכים בקרב עובדי הארגון; ועוד כלים נוספים שיכולים לסייע לנו למקד ולחדד את הבעיה. כן, אנחנו מבינים שהרצון הכי ברור ומיידי של הארגון הוא לדמיין מוצר, לתאר אותו בכמה מילים, לשמוע כמה זה יעלה וכמה זמן זה ייקח, לקבל אותו מוכן, ולעשות קסמים בארגון. אך צריך לזכור עיקרון משמעותי בפיתוח מערכות מידע – עד שלא תנסו את המערכת שלכם, לא תדעו אם היא עובדת. גם אם קניתם מוצר מדף קיים כבר; גם אם המוצר הוא של חברה בעלת שם עולמי, שמבטיחה לכם שהיא שקצרה הצלחה בעשרות ארגונים דומים לשלכם; גם אם אתם בטוחים שפיצחתם את הצורך של העובדים שלכם; כל אלו עשויים לסייע לתחושת הביטחון שלכם ואף להגביר את סיכויי ההצלחה, אבל העיקרון בעינו נותר.
כדי להבין את גבולות ה-MVP צריך ראשית כל להבין מהי הבעיה אותה אנו מנסים לפתור. חשוב לשים לב שתיאור הבעיה אינו כוללני מדי. למשל, ״עובדים לא משתפים בידע״ היא בעיה אמיתית וחמורה עבור ההנהלה; לא בטוח כמה היא חמורה לעובדים עצמם ביום-יום שלהם – ובטוח שאין זו בעיה המאפשרת פיתוח MVP טוב ויעיל. מוטב לכן לחדד את הבעיה ולנסות למצוא את הכאב (עוד מונח מעולם הסטארטאפים) שיגרום לעובדים שלכם בסופו של תהליך לשתף בידע האחד עם השני. במקרה של הדוגמה שניתנה, אפשר לנסות להבין מדוע הם לא משתפים ידע ביום-יום, ואולי לנסות להבין באילו בעיות מקדימות הם נתקלים לפני כן.
בעקבות ניסיון העבודה שלנו מול ארגונים אנחנו יותר ויותר משוכנעים שפרקטיקות עבודה רבות השאובות מעולם הסטארט-אפים טובות ויפות גם לארגונים גדולים ומבוססים, בייחוד בתחום מערכות המידע של הארגון.
לאחר שיש לנו את הצורך מחודד דיו, אנחנו יכולים להתחיל לפרק אותו ליומן צרכים (Backlog – בקלוג) כבר להתחיל להעריך עלויות והיקפים.
לקריאה נוספת
פוסטים בנושא MVP בבלוג דואלוג
יש שותפים רבים לכתיבה במאגר הידע. מאמר זה נכתב ברובו על ידי יותם הכהן. ניתן לצטט אותו באופן הבא:
- יותם הכהן, MVP ( מוצר מינימלי בר-קיימא), מאגר הידע של דואלוג, 2020.
הטקסטים במאגר הידע מוגשים תחת רישיון CC-BY 4.0 וניתן לעשות בהם שימוש חופשי כל עוד ניתן קרדיט וקישור למקור.
הערות שוליים
- ↑ Susan Moore, IT Projects Need Less Complexity, Not More Governance, Gartner, July 17, 2015
- ↑ הועדה לבדיקת פרוייקטים גדולים של פיתוח תוכנה בממשלה: מסמך מסכם, מרץ 2010.
- ↑ כי״ל תובעת 300 מיליון דולר מ-IBM בגין הכישלון בפרויקט מערכות המידע, גלובס 03.12.2018
- ↑ שחר אילן, מחדל המחשוב בביטוח הלאומי: כך ירדו 600 מיליון שקל לטימיון, כלכליסט, 06.11.17
- ↑ רן בר-זיק, הטעות המביכה של הרץ צריכה לשמש נורת אזהרה לכולם, הארץ, 28.04.19.