קריאה של הדרישות של מנהל המוצר צריכה להיות ביקורתית ולאתר טעויות. מניסיוני, רוב האנשים לא עושים את זה כמו שצריך.
קריאת המסמכים צריכה להיות אקטיבית, ולא פאסיבית (פאסיבית במובן של לההשקיע אנרגיה בהבנה בלבד).
בזמן הקריאה יש לחשוב, מול כל דרישה / סעיף, על הדברים הבאים:
0. האם הדרישה כתובה בצורה ברורה? אם אתם מוצאים את עצמכם משלימים נקודות מתוך הנחות שאתם עושים, אולי זה כיף אבל assumption is the mother of all fuckups. אל תתביישו, תשאלו. סביר להניח שחלק גדול מהאנשים גם לא הבינו ואולי התביישו לשאול, או גרוע יותר , הניחו הנחות. אחרת, זה מה שיקרה*.
1. מה הסיבה / המוטיבציה לדרישה? האם הדרישה עונה עליה?
2. אם כבר אז ולידציה: בדיקה שהמוצר אכן תואם את ציפיות הלקוח ושהדרישות היו נכונות מלכתחילה.
3. האם יש user stories ברמה הנאותה?
4. האם יש case studies אם רלוונטי?
5. האם דרישה זו מסתדרת יפה עם המוצר הקיים? עם דרישות נוספות?
כלומר מישהו יכול לחשוב על פיצ'ר מדהים שבאופן עצמאי יעבוד מצויין, אבל זה לא מסתדר עם המוצר כפי שהוא היום. דוגמא? יש לך אתר קניות והדרישה היא להקל על תהליך הרכישה דרך העברה בנקאית. דא עקה שהאפשרות הזו בוטלה באתר לגמרי...
6. האם אכן נוח למשתמש - ה-flows, מיקום הכפתורים? לשון אחר: usability.
7. האם לא חסר משהו שהמשתמש מצפה לו, או יקל עליו. אותה משפחה כמו סעיף 6. כמובן שיש וניתן לצלול כאן לרבדים רבים נוספים (יש עזרה מתאימה, קל למשתמש להבין למה הוא במקום שהוא נמצא בו וכד').
8. אם ברור לכם שהטכנולוגיה לא קיימת ו/או שייקח זמן רב לפתח את זה.
9. האם לא חסר מידע? האם יש קפיצות בדרישה?
10. סתירות פנימיות: פעם כתובה דרך אחת ליצירת דבר מסויים, פעם דרך אחרת וכד'.
11. מילים דו משמעיות, TBD, אחרי האישור של <> ועוד.
12. האם יש מוקאפים?
13. אולי ממש הגדלת ראש, אבל אם יש זמן: איך המתחרים התמודדו עם בעיות דומות? האם הם הצליחו? האם יש משהו שאפשר ללמוד ממנו?
*
קריאת המסמכים צריכה להיות אקטיבית, ולא פאסיבית (פאסיבית במובן של לההשקיע אנרגיה בהבנה בלבד).
בזמן הקריאה יש לחשוב, מול כל דרישה / סעיף, על הדברים הבאים:
0. האם הדרישה כתובה בצורה ברורה? אם אתם מוצאים את עצמכם משלימים נקודות מתוך הנחות שאתם עושים, אולי זה כיף אבל assumption is the mother of all fuckups. אל תתביישו, תשאלו. סביר להניח שחלק גדול מהאנשים גם לא הבינו ואולי התביישו לשאול, או גרוע יותר , הניחו הנחות. אחרת, זה מה שיקרה*.
1. מה הסיבה / המוטיבציה לדרישה? האם הדרישה עונה עליה?
2. אם כבר אז ולידציה: בדיקה שהמוצר אכן תואם את ציפיות הלקוח ושהדרישות היו נכונות מלכתחילה.
3. האם יש user stories ברמה הנאותה?
4. האם יש case studies אם רלוונטי?
5. האם דרישה זו מסתדרת יפה עם המוצר הקיים? עם דרישות נוספות?
כלומר מישהו יכול לחשוב על פיצ'ר מדהים שבאופן עצמאי יעבוד מצויין, אבל זה לא מסתדר עם המוצר כפי שהוא היום. דוגמא? יש לך אתר קניות והדרישה היא להקל על תהליך הרכישה דרך העברה בנקאית. דא עקה שהאפשרות הזו בוטלה באתר לגמרי...
6. האם אכן נוח למשתמש - ה-flows, מיקום הכפתורים? לשון אחר: usability.
7. האם לא חסר משהו שהמשתמש מצפה לו, או יקל עליו. אותה משפחה כמו סעיף 6. כמובן שיש וניתן לצלול כאן לרבדים רבים נוספים (יש עזרה מתאימה, קל למשתמש להבין למה הוא במקום שהוא נמצא בו וכד').
8. אם ברור לכם שהטכנולוגיה לא קיימת ו/או שייקח זמן רב לפתח את זה.
9. האם לא חסר מידע? האם יש קפיצות בדרישה?
10. סתירות פנימיות: פעם כתובה דרך אחת ליצירת דבר מסויים, פעם דרך אחרת וכד'.
11. מילים דו משמעיות, TBD, אחרי האישור של <> ועוד.
12. האם יש מוקאפים?
13. אולי ממש הגדלת ראש, אבל אם יש זמן: איך המתחרים התמודדו עם בעיות דומות? האם הם הצליחו? האם יש משהו שאפשר ללמוד ממנו?
*
