לעיתים קרובות אנשים משתמשים במונחים POC ו-MVP ללא הבחנה. וזה חבל כי אלו בדיוק המקומות שאם לא נדייק בהם אנחנו עלולים לגמרי לפספס את המהות של מה שנדרש מאיתנו לעשות.
כהרגלנו בקודש בואו נתחיל בהבנה של המונחים עצמם: POC זה ראשי תיבות של Proof Of Concept, או בעברית יפה “הוכחת היתכנות”. כלומר ישנה שאלה אמיתית האם הפרויקט ישים מבחינה פרקטית. בעוד ש-MVP זה Minimum Viable Product כלומר המוצר המינימלי האפשרי. ב-“מינימלי האפשרי” הכוונה היא שמדובר במוצר הכי פשוט שניתן לייצר שעדיין נותן ערך למשתמש שלנו. אני שמתי לב שלפעמים מבלבלים את ההגדרה הזו עם MMP שזה minimum marketable product, קרי המוצר הבסיסי ביותר שאנחנו עדיין יכולים לשווק. אלו דברים שונים.
בסדר, הבנו את המונחים אבל בואו נעבור על דוגמה כדי להמחיש את הנקודות הבעייתיות. נניח לדוגמה בהשראת הקומיקס של XKCD שיש לנו כמוצר אפליקצייה של רשות הטבע שצריכה לקבל תמונה שצולמה בפלאפון ולהגיד האם התמונה צולמה בגן לאומי ובהנחה שכן לומר האם התמונה היא של ציפור או לא.
על מנת לבצע בדיקת היתכנות (POC) אנחנו יכולים לכלול את שני הפיצ’רים הללו. אבל מבחינה טכנולוגית אנחנו יודעים שלבדוק האם התמונה צולמה בתוך גן לאומי זה אפשרי, סה”כ צריך לקחת את המיקום של התמונה, לבצע חיפוש מול שירותי המיקום של גוגל ולראות האם הנקודה היא בתוך גן לאומי. שימו לב שאני לא אומר שזה בהכרח קל. יכול להיות שפיצ’ר יקח המון זמן עבודה בכדי ליישם אבל אין לנו שאלה לגבי האם הוא אפשרי לביצוע.
לעומת זאת אנחנו לא יודעים עד כמה זה אפשרי או מה אחוזי ההצלחה בעיבוד תמונה ולהחזיר תשובה האם היא מכילה ציפור. לכן לפני אישור פרויקט כזה יכול להיות שנרצה לעשות בדיקת היתכנות. יכול מאוד להיות שתהיה דרישה לבצע POC רק של רכיב התוכנה שמזהה ציפורים כי זה החלק הבעייתי ויכול להיות שכ-POC נרצה לראות את התהליך מקצה לקצה. כנראה שרק בצורה מפושטת כדי שלא לפתח את כל המוצר כי זו לא המטרה של POC.
חשוב מאוד להגדיר מראש מה יהיו גבולות הגזרה של POC. לפעמים, כמו בדוגמה שלנו, יכול להיות בסדר גמור שלתוצר של ה-POC לא יהיה בכלל ממשק משתמש או עיצוב כלשהו, רק בחינה של הישימות הטכנולוגית. לפעמים התוצאה הרצויה מ-POC תהיה בדיקה של סדרי גודל. למשל, לקחת מאגר ספציפי של תמונות ציפורים ולהגדיר את ה-POC כהצלחה אם המוצר שלנו הצליח לזהות נכונה לפחות 85% מהתמונות. אגב, על מנת להימנע מבעיות אני ממליץ תמיד להגדיר מראש את תנאי ההצלחה של כל POC באופן שיהיה מוסכם על כל הצדדים לפני שמתחילים לעבוד.
איך יראה MVP של אותה האפליקציה? ובכן, בדרך כלל בשביל להגדיר היטב MVP יש להגדיר מהי רשימת הפיצ’רים המינימלית שנדרשת על מנת שהמוצר יתן ערך. כל שאר הפיצרים הולכים ל-bakclog ונוכל להוסיף אותם בעתיד אם נראה שה-MVP הוא משהו שיש בו עניין. ב-MVP יהיה ממשק או כל דבר אחר שיאפשר למשתמש להשתמש במוצר. אולי הוא לא יהיה מעוצב יפה, אולי ההוראות יהיו מסמך פשוט במקום מדריכים מסודרים. אבל יהיה את כל מה שנדרש בשביל להשתמש במוצר.
לרוב MVP בא עם שימושיות מוגבלת ולפעמים גם לא נראה כל כך טוב. אבל יצירת MVP מאפשר לנו להוציא משהו שכן נותן ערך למשתמשים שלנו ובזמן שהמשתמשים בודקים אותו אז אנחנו יכולים לקבל מידע על אופני השימוש של המשתמשים ופידבק לגבי מה עוד המשתמשים שלנו היו רוצים שיהיה במוצר. זה מאפשר לנו התקדמות יותר ממוקדת מטרה. כמו כן, בזמן שהמוצר ברמת ה-MVP אצל המשתמשים אז אנחנו יכולים להתקדם ולפתח את הגרסה הבא שלו. זה אחד מהיתרונות של עבודה עם MVP בסיסי שיוצא למשתמשים כמה שיותר מהר. היתרון השני הוא שאם ה-MVP הוא לחלוטין לא מה שהמשתמשים צריכים אז אנחנו יכולים לגלות את זה בשלב ממש ראשוני של התהליך ולא לבזבז עוד משאבים על מוצר שלא נדרש.
לסיכום: כאשר אנחנו לא בטוחים האם רעיון כלשהו ניתן ליישום אז אנחנו עורכים POC בכדי לבדוק האם הוא אפשרי. כאשר אנחנו רוצים לייצר מוצר בסיסי ביותר כדי להתחיל לבדוק האם הוא הכיוון הנכון לפתור את הבעיות של המשתמשים שלנו, אנחנו ניצור MVP.
(ואל תדאגו לגבי ההבחנה האם יש ציפור בתוך תמונה, כבר עובדים על זה)
