MVP – מוצר מינימאלי שלם וחיוני

/, מאגר הידע, מתודולוגיית אג'ייל/MVP – מוצר מינימאלי שלם וחיוני

MVP – Minimal Viable Product או בתצורתו העברית ממ״ש (מוצר מינימלי שלם או חיוני) מגלם בתוכו את מינימום הרכיבים הנדרשים במוצר כדי לאפשר לו לפתור בעיה ארגונית. השאלה הראשונה שעולה על הדעת היא כמובן – ״מה ייחשב למינימום?״. בעוד כי אין תשובות מדף לשאלה זו, בגדול כלל האצבע הוא שממ״ש טוב הוא כזה שעומד בפני עצמו. הוא לא יהיה יפה או אסתטי במיוחד, אולי הוא לא יהיה היעיל ביותר, אך הוא יפתור לעובדים בארגון בעיה שהם מתמודדים איתה ולפיכך יהיה בעל שימוש להם.

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

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

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

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

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

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

לקריאה נוספת על MVP בארגונים: