7,737
עריכות
שינויים
אין תקציר עריכה
{{באנר|תמונה=From_minimum_viable_product_to_more_complex_product.png}}
'''MVP''' הם ראשי תיבות ל–'''M'''inimum '''V'''iable '''P'''roduct, '''מוצר מינימלי בר-קיימא/חיוני.''' זהו מושג המגלם את מינימום הרכיבים הנדרשים במוצר כדי לאפשר לו לפתור את הכאב צורך ממשי של המשתמשמשתמשים (כאב). המושג עלה כחלק ממתודלוגיית ה-Lean Startup ו-[[פיתוח תוכנה אג׳ילי]].
== למה זה טוב? ==ה-MVP שחרר משחרר את החברות, ובייחוד את חברות ההזנק, מתהליכי עבודה ארוכים ומסורבלים שלרוב גם פספסו את מטרתם. במקום להביא לשוק מוצר מוגמר, מושלם ככל הניתן ולגלות מאוחר מדי שהוא לא עונה על הצורך של המשתמשים, ה-MVP מבקש את ההפך: תביאו מוצר ראשוני מוקדם ככל הניתן למשתמשים ומשם תתחילו ללמוד, להשתפר ולהתפתח.
המושג חיוני בגלל [[ניגודיות משלימה|הניגודיות המשלימה]] שמצויה בו – "מינימלי וחיוני" היא השאיפה הבסיסית של ארגונים ועסקים: מקסימום [[אפקטיביות]] במינימום משאבים. יש לשים לב כי אלו מרכיבים יחסיים המחייבים פירוש הקשריבהקשר. לא פעם נגלה שמה שחשבנו שהוא חיוני ממש לא עושה את העבודה. לעתים נגלה את ההפך – ששגינו בהערכת יתר את ציפיות המשתמשים. באותו אופן גם השאלה מה נחשב מינימאלי תלויית הקשר: המשאבים שחברת הזנק יכולה להעמיד לא דומים לאלו של גוף ממשלתי או של תאגיד בינ״ל.
<html><blockquote class="twitter-tweet"><p lang="en" dir="ltr">Making sense of <a href="https://twitter.com/hashtag/MVP?src=hash&ref_src=twsrc%5Etfw">#MVP</a> and why <a href="https://twitter.com/henrikkniberg?ref_src=twsrc%5Etfw">@henrikkniberg</a> prefers Earliest Testable/Usable/Lovable <a href="https://t.co/SRCEPPfbFk">https://t.co/SRCEPPfbFk</a> <a href="https://twitter.com/hashtag/agile?src=hash&ref_src=twsrc%5Etfw">#agile</a> <a href="https://t.co/wF4Oip6sfO">pic.twitter.com/wF4Oip6sfO</a></p>— Agile Alliance (@AgileAlliance) <a href="https://twitter.com/AgileAlliance/status/697804099719467008?ref_src=twsrc%5Etfw">February 11, 2016</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></html>
== הגדרה של MVP ==
== הגדרת MVP עבור מערכות מידע פנימיות בארגון ==
מושג ה-MVP מרכזי מאוד כיום בעולמות העסקיים, אבל הוא רלוונטי מאוד גם לפיתוחים פנים-ארגוניים. מספר רב של מחקרים<ref>Susan Moore, [https://www.gartner.com/smarterwithgartner/it-projects-need-less-complexity-not-more-governance/ IT Projects Need Less Complexity, Not More Governance], Gartner, July 17, 2015 </ref> ודוחו״ת<ref>[https://www.gov.il/BlobFolder/policy/considerations_for_outsourcing/he/The%20committee%20to%20examine%20large%20development%20projects%20in%20the%20government.pdf הועדה לבדיקת פרוייקטים גדולים של פיתוח תוכנה בממשלה: מסמך מסכם], מרץ 2010.</ref>, וכן מקרים שקרו בישראל<ref>[https://www.globes.co.il/news/article.aspx?did=1001263219 כי״ל תובעת 300 מיליון דולר מ-IBM בגין הכישלון בפרויקט מערכות המידע], גלובס 03.12.2018</ref><ref>שחר אילן, [https://www.calcalist.co.il/local/articles/0,7340,L-3724436,00.html מחדל המחשוב בביטוח הלאומי: כך ירדו 600 מיליון שקל לטימיון], כלכליסט, 06.11.17
</ref> ובעולם<ref>רן בר-זיק, [https://www.haaretz.co.il/captain/net/.premium-1.7169807 הטעות המביכה של הרץ צריכה לשמש נורת אזהרה לכולם], הארץ, 28.04.19. </ref>, אנו יודעים לומר כיום שאחת הסיבות בגינה פרוייקטי מחשוב נכשלים בארגונים היא בגין הכישלון לזהות את הצורך האמיתי של העובדים בארגון, פעמים רבות בגלל המרחק בין השטח למטה. עקב כך, מאופיינות ומפותחות מערכות שאינן רלוונטיות למשתמשים בה הם לא משתמשים כלל, או משתמשים באופן כפוי בלבד.
דרך אחת טובה להבין מה צריך לכלול ה-MVP היא באמצעות ישיבת הנהלה בה המשתתפים מעלים רעיונות; ראיונות עומק עם עובדי מפתח; סקר איתור צרכים בקרב עובדי הארגון; ועוד כלים נוספים שיכולים לסייע לנו למקד ולחדד את הבעיה. כן, אנחנו מבינים שהרצון הכי ברור ומיידי של הארגון הוא לדמיין מוצר, לתאר אותו בכמה מילים, לשמוע כמה זה יעלה וכמה זמן זה ייקח, לקבל אותו מוכן, ולעשות קסמים בארגון. אך צריך לזכור עיקרון משמעותי בפיתוח מערכות מידע – עד שלא תנסו את המערכת שלכם, לא תדעו אם היא עובדת. גם אם קניתם מוצר מדף קיים כבר; גם אם המוצר הוא של חברה בעלת שם עולמי, שמבטיחה לכם שהיא שקצרה הצלחה בעשרות ארגונים דומים לשלכם; גם אם אתם בטוחים שפיצחתם את הצורך של העובדים שלכם; כל אלו עשויים לסייע לתחושת הביטחון שלכם ואף להגביר את סיכויי ההצלחה, אבל העיקרון בעינו נותר.
כדי להבין את גבולות ה-MVP צריך ראשית כל להבין מהי הבעיה אותה אנו מנסים לפתור. חשוב לשים לב שתיאור הבעיה אינו כוללני מדי. למשל, ״עובדים לא משתפים בידע״ היא בעיה אמיתית וחמורה עבור ההנהלה; לא בטוח כמה היא חמורה לעובדים עצמם ביום-יום שלהם – ובטוח שאין זו בעיה המאפשרת פיתוח MVP טוב ויעיל. מוטב לכן לחדד את הבעיה ולנסות למצוא את הכאב (עוד מונח מעולם הסטארטאפים) שיגרום לעובדים שלכם בסופו של תהליך לשתף בידע האחד עם השני. במקרה של הדוגמה שניתנה, אפשר לנסות להבין מדוע הם לא משתפים ידע ביום-יום, ואולי לנסות להבין באילו בעיות מקדימות הם נתקלים לפני כן.
בעקבות ניסיון העבודה שלנו מול ארגונים אנחנו יותר ויותר משוכנעים שפרקטיקות עבודה רבות השאובות מעולם הסטארט-אפים טובות ויפות גם לארגונים גדולים ומבוססים, בייחוד בתחום מערכות המידע של הארגון.
== לקריאה נוספת ==
* [[פיתוח תכונה אג׳ילי]]
{{בלוג|hacking-strategy-3}}{{הערות}}
[[קטגוריה:אסטרטגיה טכנולוגית]]
[[קטגוריה:מוצר]]
[[קטגוריה:מושגים]]