חיוני שיהיה לנו חזון משותף לגבי המוצר שאנו רוצים לבנות. התוצאה של החזון היא סקיצה שלו. החזון מניע ומכוון את האנשים ומהווה את הסיבה לקיומו של המוצר. חזון טוב צריך לענות על השאלות:
- מיהם הלקוחות הפוטנציאלים? מי קהל היעד? מי ישתמש במוצר? מיהם משתמשי הקצה?
- על איזה צורך יענה המוצר? איזה ערך מוסף יש למוצר?
- אילו תכונות של המוצר הן קריטיות בכדי שיעמדו בדרישות שנבחרו? איך בערך יראה המוצר ומה הוא יעשה? באילו איזורים המוצר יצטיין?
- מה מיקומו של המוצר אל מול מוצרים מתחרים ומוצרים אחרים של החברה? מהן נקודות החוזקה של המוצר בהיבט המכירתי? מה יהיה מחירו?
- איך החברה תרוויח ממכירת המוצר? מהו המודל העסקי?
- האם ייצור המוצר הוא פיסבילי?
אם המוצר אמור להיות נקודת מפנה של המודל של החברה - זה אמור להשתקף בחזון.
על כל מי שמשתתף בפיתוח להיות מעורב בחזון - קבוצת הסקראם, מנהלים, לקוחות, משתמשים וכד'. אחרת יש סכנה שלכל אחד יהיה חזון משלו ולא חזון משותף.
על החזון להיות מספיק מוחשי בכדי שיוכל להנחות את צוות הפיתוח, אך גם שישאיר מקום ליצירתיות. יש להשאיר מקום גם לפיצ'רים שיתווספו עם התהליך הודות ליצירתיות של המשתתפים.
החזון צריך להיות קצר ומתומצת. עליו להכיל מידע רק על התכונות שיגרמו להצלחת המוצר. החזון אינו רשימת פיצ'רים. על החזון לעמוד במבחן המעלית: האם אפשר להסביר את החזון בזמן של נסיעה במעלית? אם לא - כנראה שהחזון ארוך מידי.
לגבי השיווק, קשה לדעת את העתיד בצורה מלאה, לא משנה כמה נחשוב על כך וכמה סקרי שוק נערוך. חשוב גם שנהיה גמישים ונוכל לשנות את המוצר בדרך.
כיוון שכך, הסיכוי הטוב שלנו הוא לחזון שיווקי מינימלי, שיש לו מינימום פונקציונליות העונה לצרכי הלקוח.
למשל ה-iPhone הראשון היה חסר מרכיבים בסיסיים שהיו אצל המתחרים. למרות זאת הוא ענה על צרכים חשובים בצורנ ייחודית. הוא לא פנה לכל קהל היעד אלא לחלקו. רק הגרסאות הבאות הכילו את הפיצ'רים הנוספים. לעומת זאת אפל השיקו ב-1993 מוצר בשם "ניוטון" שבין היתר היה אמור לזהות כתב יד. המוצר פותח בחמש שנים ונכשל, בעיקר כיוון שלא עשה את המצופה ממנו בזיהוי כתבי יד.
בגרסה ראשונה מינימלית ה-TTM קצר יותר, ההוצאות פחותות. הגרסה הראשונה לא אמורה לשרת את החזון של החברה, למשל לשלוט על שוק הטלפונים הניידים. מספיק שהיא תהווה פתרון טוב בתחומים מצומצמים ומכאן דריסת רגל לדור הבא. אגב, גם גוגל כרום נוצר בדרך זו.
על המוצר להיות פשוט - מינימום פונקציונליות וקלות שימוש. זה לא אומר שעל המוצר להיות פשטני. למשל: הכפתור היחידי של ה-iPod. הוא פשוט אך מספק את הפונקציונליות הבסיסית.
על הפשטות לבוא לידי ביטוי גם במנשק המשתמש.
צרכי הלקוח ותכונות המוצר מהווים את לב החזון. בחירת צרכי הלקוח עליהם נענה עונה על השאלה לאיזה נתח שוק נתכוון. תכונות המוצר הן התשובה לצרכי הלקוח. התכונות יכולות להיות פונקציונליות - כמו קבלת שיחות במכשיר סלולרי - או תכונות לא פונקציונליות כמו ביצועים, סטייל, דיזיין, יוזביליות וכד'. תכונות לא פונקציונליות עשויות להוות מבדיל חשוב שיכולות להשפיע על חווית המשתמש ותחזוקת המכשיר.
ע"י עיון בצרכי הלקוח וקישור לתכונות מינימליות של המוצר אנו מתחברים אל הפתרון הטכני כשהלקוח במרכז.
כשבידינו תכונות המוצר כדאי לתת להן סדר עדיפויות. בראש תכונות שעונות על כמה צרכים ביחד. סדר העדיפויות מועיל בעיקר כשיש תכונות סותרות. אפשר לחלק לשלש עדיפויות:
- שניתן להקריב תכונות אחרות למען תכונה זו.
- נסה לשמר.
- שניתן להקריב למען תכונות אחרות.
הולדת החזון:
בין היתר יש שתי גישות: גישת פרוייקט המחמד וגישת ה-Scrum.
גישת פרוייקט המחמד היא זו שקיימת בגוגל: יש לעובדים 20% זמן "פנוי" להמציא רעיונות, ואם הם מתקבלים הצוות הממציא עובד עליהם. בגוגל זה הוכיח את עצמו.
גישת ה-Scrum טובה כשיש צורך במאמץ רב ליצור חזון. תחילה בבקלוג יהיו בקשות לפרוטוטייפ וראיונות עם לקוחות, אח"כ תכונות בהיי לבל המתארות את עתיד המוצר ע"פ החזון. כל ספרינט יקרב את חזון המוצר לחזון המוגמר.
למעט שימוש נקודתי במומחים נישתיים שונים (כמו מומחי UI), קבוצת החזון היא גם קבוצת הפיתוח. המומחה צריך להיות אחד מבעלי העניין.
טכניקות לבניית החזון
פרוטוטייפ ומוק-אפים (Mock-ups)
לפעמים לא הלקוח ולא אנחנו מבינים בדיוק מה אנו צריכים: מה המוצר יעשה וכיצד היא יראה. במקרה זה תהליך הפקת החזון הוא תהליך של גילוי. מוק-אפ עוזר להבין איך בערך אמור להיראות המוצר, מה עליו לעשות ובאיזו טכנולוגיה וארכיטקטורה להשתמש ואם הרעיון פיסבילי.
פרוטוטייפ פשוט וסקטצ'ים מספיקים לפעמים לבדיקת רעיון.
פרוטוטייפ שבא לבדוק משהו ספציפי נקרא לפעמים spike.
פרסונה וסנריו
פרסונה זו דמות שאמורה לייצג את הלקוח ועליה ניתן לבדוק אם הסנריו אכן תואמים לה וללייף סטייל שלה. ניתן לערוך שני סנריו: אחד בלי המוצר ואחד עם. בנוסף אפשר להבין אילו תכונות הכרחיות יותר ואילו פחות.
אריזת החזון והביקורת העיתונאית
אריזת החזון זה לדמיין את המוצר ארוז ולראות מה כתוב עליו והאם הוא אכן מה שחשבו שיהיה.
הביקורת העיתונאית היא מה היינו רוצים שייכתב על המוצר במדיה התקשורתית.
מודל קאנו
עוזר בבחירת הפונקציונליות הראוייה לסיפוק הלקוח.
ישנם שלשה סוגי פונקציונליות כאן: בסיסית, ביצועית ועינוגית (delighters).
למשל בטלפון נייד פונקציונליות בסיסית היא סגירת ופתיחת הטלפון, קבלת שיחות, SMSים. בלעדיהם אין טעם במוצר, והכפלתם לא תתרום כלום.
פונקציונליות ביצועית מעלה את שביעות הרצון של הלקוח: משקל קטן יותר ומהירות העלייה של מערכת ההפעלה. כמה שיותר - יותר טוב. למרות זאת, תכונות אלו אינן יוצרות את ההבדלה של המוצר שלנו בשוק.
העינוגית לעומת זאת, מעוררת התרגשות. דזיין מדהים, פרסונליזציה. אלו נותנות לנו יתרון מול השוק.
האתגר הוא ליצור עירוב כזה של שלשת רבדי הפונקציונליות שבו ההטבות הרצויות מגיעות למירב.
לפי המודל, במשך הזמן העינוגים יהפכו לתכונות של ביצועים, ובצועים לבסיסיים. לכן תמיד יש לעדכן את המוצר בביצועים ועינוגים.
ה-Road map
כל הנאמר למעלה קשור למוצר חדש. במוצר קיים החזור הוא בעצם ה-Road map. זהו מכשיר המראה את התפתחות המוצר לאורך הגרסאות. מומלץ להשאיר את ה-Road map פשוט ומפוקס בעיקר. עליו לכלול תאריכי יעד, קהל היעד וצרכיו, ואת 3-5 הפיצ'רים המובילים. הפרטים יוכנסו אח"כ בבקלוג. יש לזכור שה-Road map לא מחליף סקר שוק רציני. זה רק כולל את המקום אותו המוצר אמור לתפוס כפי שאנו רואים את המצב כעת.
מסמך ה-Road map הינו מסמך חי שיש לעדכן.
את מסמך ה-Road map יש לכתוב רק אחרי הצלחת הגרסה הראשונה שיוצאת לשוק. כמו תמיד יש לערב בו את צוות הסקראם. הוא אמור לראות חצי שנה עד שנה קדימה.
מינימום של מוצרים
כשהמוצר מתפתח הוא מגיע ליותר ויותר קהלי יעד עם צרכים שונים, מה שמקשה על עדכונים מינימליים. בכדי לפתור זאת עלינו להשתמש בגרסאות מוצר שונות. כל משתנה מייצג קבוצה מוגדרת של לקוחות. למשל שתי גרסאות של הוויזיו: למקצוענים ולמשתמשים אחרים.
כמובן שיותר מדי גרסאות דורשות תחזוקה רבה ובלבול לצרכנים. בכל מקרה הפלטפורמה של כל הגרסאות צריכה להיות זהה.
טעויות נפוצות:
חוסר בחזון. התוצאה היא פשוט אוסף של פיצ'רים.
ניתוח מוגזם של צרכי הלקוח, או התחשבות אך ורק בצרכיו בלי חזון ברור שלנו - לא סביר שיצור הצלחה.
אנחנו יודעים מה טוב ללקוחותינו: הצד השני של המטבע. סומכים על האינטואיציה של המנהלים.
הרבה זה טוב: מוצרים עתירי פיצ'רים. הם צרכני זמן וכסף ובעלי סיכוי טוב להיכשל.
----
האמור למעלה הינו פחות-או-יותר סיכום של הפרק השני בספר Agile Product Management with Scrum.
הספר הזה מנסה להיות כמו מה שנאמר על המוצר: פשוט, ברור ולא מסובך. כמובן שבחיים הדברים לא כאלה פשוטים, ולכן יש לראות בו ספר מבוא למוצר בסביבת ה-Scrum המתאים ככניסה לבעלי מוצר או סיפוק ידע כללי לשאר חברי הצוות.
נקודתית, לגבי שתי (או יותר) גרסאות למוצר, ישנה גישה לטעמי מוצלחת לא פחות ולעיתים יותר, והיא זו של מייקרוסופט. קחו למשל את "אופיס". מאוד קל לכתוב מסמך בוורד, לשמור ולהדפיס. אבל אפשר לליצור טפסים, עיצובים וכד'. זה עוד יותר מוחשי באקסל. "אופיס" זה סט מוצרים קלים להפעלה אבל יכולים להגיע למצבים מורכבים הרבה יותר גם למשתמשים המקצועיים.
לגבי מודל קאנו ותכונות חשובות ופחות חשובות. מצדו של הלקוח, הוא אינו מעוניין בתכונות של המוצר, אלא בתועלות. התועלות עשויות להיות עינוגיות, אבל גם סמל סטטוס הוא תועלת, או רצון שיהיה לך את מה שיש לכולם וכד'.
- מיהם הלקוחות הפוטנציאלים? מי קהל היעד? מי ישתמש במוצר? מיהם משתמשי הקצה?
- על איזה צורך יענה המוצר? איזה ערך מוסף יש למוצר?
- אילו תכונות של המוצר הן קריטיות בכדי שיעמדו בדרישות שנבחרו? איך בערך יראה המוצר ומה הוא יעשה? באילו איזורים המוצר יצטיין?
- מה מיקומו של המוצר אל מול מוצרים מתחרים ומוצרים אחרים של החברה? מהן נקודות החוזקה של המוצר בהיבט המכירתי? מה יהיה מחירו?
- איך החברה תרוויח ממכירת המוצר? מהו המודל העסקי?
- האם ייצור המוצר הוא פיסבילי?
אם המוצר אמור להיות נקודת מפנה של המודל של החברה - זה אמור להשתקף בחזון.
על כל מי שמשתתף בפיתוח להיות מעורב בחזון - קבוצת הסקראם, מנהלים, לקוחות, משתמשים וכד'. אחרת יש סכנה שלכל אחד יהיה חזון משלו ולא חזון משותף.
על החזון להיות מספיק מוחשי בכדי שיוכל להנחות את צוות הפיתוח, אך גם שישאיר מקום ליצירתיות. יש להשאיר מקום גם לפיצ'רים שיתווספו עם התהליך הודות ליצירתיות של המשתתפים.
החזון צריך להיות קצר ומתומצת. עליו להכיל מידע רק על התכונות שיגרמו להצלחת המוצר. החזון אינו רשימת פיצ'רים. על החזון לעמוד במבחן המעלית: האם אפשר להסביר את החזון בזמן של נסיעה במעלית? אם לא - כנראה שהחזון ארוך מידי.
לגבי השיווק, קשה לדעת את העתיד בצורה מלאה, לא משנה כמה נחשוב על כך וכמה סקרי שוק נערוך. חשוב גם שנהיה גמישים ונוכל לשנות את המוצר בדרך.
כיוון שכך, הסיכוי הטוב שלנו הוא לחזון שיווקי מינימלי, שיש לו מינימום פונקציונליות העונה לצרכי הלקוח.
למשל ה-iPhone הראשון היה חסר מרכיבים בסיסיים שהיו אצל המתחרים. למרות זאת הוא ענה על צרכים חשובים בצורנ ייחודית. הוא לא פנה לכל קהל היעד אלא לחלקו. רק הגרסאות הבאות הכילו את הפיצ'רים הנוספים. לעומת זאת אפל השיקו ב-1993 מוצר בשם "ניוטון" שבין היתר היה אמור לזהות כתב יד. המוצר פותח בחמש שנים ונכשל, בעיקר כיוון שלא עשה את המצופה ממנו בזיהוי כתבי יד.
בגרסה ראשונה מינימלית ה-TTM קצר יותר, ההוצאות פחותות. הגרסה הראשונה לא אמורה לשרת את החזון של החברה, למשל לשלוט על שוק הטלפונים הניידים. מספיק שהיא תהווה פתרון טוב בתחומים מצומצמים ומכאן דריסת רגל לדור הבא. אגב, גם גוגל כרום נוצר בדרך זו.
על המוצר להיות פשוט - מינימום פונקציונליות וקלות שימוש. זה לא אומר שעל המוצר להיות פשטני. למשל: הכפתור היחידי של ה-iPod. הוא פשוט אך מספק את הפונקציונליות הבסיסית.
על הפשטות לבוא לידי ביטוי גם במנשק המשתמש.
צרכי הלקוח ותכונות המוצר מהווים את לב החזון. בחירת צרכי הלקוח עליהם נענה עונה על השאלה לאיזה נתח שוק נתכוון. תכונות המוצר הן התשובה לצרכי הלקוח. התכונות יכולות להיות פונקציונליות - כמו קבלת שיחות במכשיר סלולרי - או תכונות לא פונקציונליות כמו ביצועים, סטייל, דיזיין, יוזביליות וכד'. תכונות לא פונקציונליות עשויות להוות מבדיל חשוב שיכולות להשפיע על חווית המשתמש ותחזוקת המכשיר.
ע"י עיון בצרכי הלקוח וקישור לתכונות מינימליות של המוצר אנו מתחברים אל הפתרון הטכני כשהלקוח במרכז.
כשבידינו תכונות המוצר כדאי לתת להן סדר עדיפויות. בראש תכונות שעונות על כמה צרכים ביחד. סדר העדיפויות מועיל בעיקר כשיש תכונות סותרות. אפשר לחלק לשלש עדיפויות:
- שניתן להקריב תכונות אחרות למען תכונה זו.
- נסה לשמר.
- שניתן להקריב למען תכונות אחרות.
הולדת החזון:
בין היתר יש שתי גישות: גישת פרוייקט המחמד וגישת ה-Scrum.
גישת פרוייקט המחמד היא זו שקיימת בגוגל: יש לעובדים 20% זמן "פנוי" להמציא רעיונות, ואם הם מתקבלים הצוות הממציא עובד עליהם. בגוגל זה הוכיח את עצמו.
גישת ה-Scrum טובה כשיש צורך במאמץ רב ליצור חזון. תחילה בבקלוג יהיו בקשות לפרוטוטייפ וראיונות עם לקוחות, אח"כ תכונות בהיי לבל המתארות את עתיד המוצר ע"פ החזון. כל ספרינט יקרב את חזון המוצר לחזון המוגמר.
למעט שימוש נקודתי במומחים נישתיים שונים (כמו מומחי UI), קבוצת החזון היא גם קבוצת הפיתוח. המומחה צריך להיות אחד מבעלי העניין.
טכניקות לבניית החזון
פרוטוטייפ ומוק-אפים (Mock-ups)
לפעמים לא הלקוח ולא אנחנו מבינים בדיוק מה אנו צריכים: מה המוצר יעשה וכיצד היא יראה. במקרה זה תהליך הפקת החזון הוא תהליך של גילוי. מוק-אפ עוזר להבין איך בערך אמור להיראות המוצר, מה עליו לעשות ובאיזו טכנולוגיה וארכיטקטורה להשתמש ואם הרעיון פיסבילי.
פרוטוטייפ פשוט וסקטצ'ים מספיקים לפעמים לבדיקת רעיון.
פרוטוטייפ שבא לבדוק משהו ספציפי נקרא לפעמים spike.
פרסונה וסנריו
פרסונה זו דמות שאמורה לייצג את הלקוח ועליה ניתן לבדוק אם הסנריו אכן תואמים לה וללייף סטייל שלה. ניתן לערוך שני סנריו: אחד בלי המוצר ואחד עם. בנוסף אפשר להבין אילו תכונות הכרחיות יותר ואילו פחות.
אריזת החזון והביקורת העיתונאית
אריזת החזון זה לדמיין את המוצר ארוז ולראות מה כתוב עליו והאם הוא אכן מה שחשבו שיהיה.
הביקורת העיתונאית היא מה היינו רוצים שייכתב על המוצר במדיה התקשורתית.
מודל קאנו
עוזר בבחירת הפונקציונליות הראוייה לסיפוק הלקוח.
ישנם שלשה סוגי פונקציונליות כאן: בסיסית, ביצועית ועינוגית (delighters).
למשל בטלפון נייד פונקציונליות בסיסית היא סגירת ופתיחת הטלפון, קבלת שיחות, SMSים. בלעדיהם אין טעם במוצר, והכפלתם לא תתרום כלום.
פונקציונליות ביצועית מעלה את שביעות הרצון של הלקוח: משקל קטן יותר ומהירות העלייה של מערכת ההפעלה. כמה שיותר - יותר טוב. למרות זאת, תכונות אלו אינן יוצרות את ההבדלה של המוצר שלנו בשוק.
העינוגית לעומת זאת, מעוררת התרגשות. דזיין מדהים, פרסונליזציה. אלו נותנות לנו יתרון מול השוק.
האתגר הוא ליצור עירוב כזה של שלשת רבדי הפונקציונליות שבו ההטבות הרצויות מגיעות למירב.
לפי המודל, במשך הזמן העינוגים יהפכו לתכונות של ביצועים, ובצועים לבסיסיים. לכן תמיד יש לעדכן את המוצר בביצועים ועינוגים.
ה-Road map
כל הנאמר למעלה קשור למוצר חדש. במוצר קיים החזור הוא בעצם ה-Road map. זהו מכשיר המראה את התפתחות המוצר לאורך הגרסאות. מומלץ להשאיר את ה-Road map פשוט ומפוקס בעיקר. עליו לכלול תאריכי יעד, קהל היעד וצרכיו, ואת 3-5 הפיצ'רים המובילים. הפרטים יוכנסו אח"כ בבקלוג. יש לזכור שה-Road map לא מחליף סקר שוק רציני. זה רק כולל את המקום אותו המוצר אמור לתפוס כפי שאנו רואים את המצב כעת.
מסמך ה-Road map הינו מסמך חי שיש לעדכן.
את מסמך ה-Road map יש לכתוב רק אחרי הצלחת הגרסה הראשונה שיוצאת לשוק. כמו תמיד יש לערב בו את צוות הסקראם. הוא אמור לראות חצי שנה עד שנה קדימה.
מינימום של מוצרים
כשהמוצר מתפתח הוא מגיע ליותר ויותר קהלי יעד עם צרכים שונים, מה שמקשה על עדכונים מינימליים. בכדי לפתור זאת עלינו להשתמש בגרסאות מוצר שונות. כל משתנה מייצג קבוצה מוגדרת של לקוחות. למשל שתי גרסאות של הוויזיו: למקצוענים ולמשתמשים אחרים.
כמובן שיותר מדי גרסאות דורשות תחזוקה רבה ובלבול לצרכנים. בכל מקרה הפלטפורמה של כל הגרסאות צריכה להיות זהה.
טעויות נפוצות:
חוסר בחזון. התוצאה היא פשוט אוסף של פיצ'רים.
ניתוח מוגזם של צרכי הלקוח, או התחשבות אך ורק בצרכיו בלי חזון ברור שלנו - לא סביר שיצור הצלחה.
אנחנו יודעים מה טוב ללקוחותינו: הצד השני של המטבע. סומכים על האינטואיציה של המנהלים.
הרבה זה טוב: מוצרים עתירי פיצ'רים. הם צרכני זמן וכסף ובעלי סיכוי טוב להיכשל.
----
האמור למעלה הינו פחות-או-יותר סיכום של הפרק השני בספר Agile Product Management with Scrum.
הספר הזה מנסה להיות כמו מה שנאמר על המוצר: פשוט, ברור ולא מסובך. כמובן שבחיים הדברים לא כאלה פשוטים, ולכן יש לראות בו ספר מבוא למוצר בסביבת ה-Scrum המתאים ככניסה לבעלי מוצר או סיפוק ידע כללי לשאר חברי הצוות.
נקודתית, לגבי שתי (או יותר) גרסאות למוצר, ישנה גישה לטעמי מוצלחת לא פחות ולעיתים יותר, והיא זו של מייקרוסופט. קחו למשל את "אופיס". מאוד קל לכתוב מסמך בוורד, לשמור ולהדפיס. אבל אפשר לליצור טפסים, עיצובים וכד'. זה עוד יותר מוחשי באקסל. "אופיס" זה סט מוצרים קלים להפעלה אבל יכולים להגיע למצבים מורכבים הרבה יותר גם למשתמשים המקצועיים.
לגבי מודל קאנו ותכונות חשובות ופחות חשובות. מצדו של הלקוח, הוא אינו מעוניין בתכונות של המוצר, אלא בתועלות. התועלות עשויות להיות עינוגיות, אבל גם סמל סטטוס הוא תועלת, או רצון שיהיה לך את מה שיש לכולם וכד'.
אין תגובות:
הוסף רשומת תגובה