5. דוגמאות
..a combined function of price, duration, and number of stops—basically the total
agony you'll experience in your butt and your savings (Adam Goldstien)
12. בערך: הגדרה Feature
או פונקציונליות של המוצר, שנועדה לעזור למשתמש, אך לא ניתן Feature
להבטיח באופן דטרמיניסטי שבכל המקרים הפונקציה אכן עוזרת למשתמש
17. בערך שאינו מעצבן? Feature איך בונים
) • צודק ברוב גדול של המקרים )רוב גדול, מוגדר כגדול מ 70%
טועה: feature • לא נגרם נזק מהותי במקרים בהם ה
• למשתמש
• שיווקי ותדמיתי למוצר
המשתמש מבין לבדו את ה"בערך" של המוצר :Implied disclaimer •
19. feature שלב ראשון: הגדרה של
מחייב feature • בדוק לכל בקשת פיתוח עתידית )מכל מקור(: האם ה
בערך feature דיוק מושלם? – אם לא, מצאת מועמד ל
• מה המשתמש צריך באופן כללי )בדרך כלל(?
האם הוא ברור למשתמש הסביר? ?implied disclaimer • מהו ה
• מה יקרה במקרים בהם קיים חוסר דיוק?
20. שלב שני: הגדרה מדויקת של האיך
• אסוף נתונים )או הגדר באלו נתוני תוכנה יש להשתמש( ורשום את ה
בתחום common knowledge
• התחל בסטטיסטיקה פשוטה:
• ממוצע
• חציון
• שכיח
• מינימום מקסימום
• טבלת ערכים
• למתקדמים: עונתיות או התפלגות בסיסית
• הגדר )היטב( את נוסחת החישוב ומה קורה בכל מצב
)done או ה ( QA • הגדר היטב את מדדי ה
שם פנימי ולא יומרני המשקף את הנוסחא )ולא את ה feature • תן ל
ללקוח( perceived value
21. שלב שלישי: שגר
• העבר לפיתוח איפיון מדויק, כולל נוסחת החישוב
• הסבר לפיתוח שזה "בערך"
• השאר עם יד על הדופק והקפד שזה לא יהפוך ל"תחנת חלל"
22. שלב רביעי: היזון חוזר
• בדוק שימוש והתיחסות הלקוחות לפיטשר ושימוש
• אם אוהבים את הפיטשר: שפר אותו. זה הזמן לסטטיסטיקה למתקדמים
וכו big-data הקמת מרכזי , BI לרכישת מערכות
בטל אותו בגרסה הבאה וזהו : feature • אם לא אוהבים את ה
• אי אפשר לעודד שימוש על ידי שיפור רמת הבערך
agile • השקעה נוספת מאבדת את מהות הרעיון – בערך, מהיר ו
בערך חדש feature • הכי פשוט: תמציא