Posts tagged ‘סיפורי לקוח’

זה גדול מידי.

imageאתם עובדים בסקראם. ספרינטים של שבועיים. הצוותים בנויים נכון (Feature teams). יש לכם בקלוג. בבקלוג של דרישה של לקוח, ואפילו בפורמט של סיפור לקוח (User story). כבוד!

אבל מה? אין ממש אפשרות לפתח את כל הדרישה בשבועיים. איזה אפשרויות כן עומדות לפניכם?
1. להאריך את הספרינט – נו, לא רעיון משהו, כבר נכתב ונאמר מספיק על החסרונות שבשינוי אורך הספרינט, וחוץ מזה מה אם הוא אמור לקחת 3 חודשים?
2. לחלק את סיפור הלקוח בשיטת הסלאמי (ראו פוסט קודם)
3. לחלק את סיפור הלקוח ל….
סיפורי לקוח קטנים יותר. הופה, הנה רעיון :)


תזכורת: סיפור לקוח הוא מהזוית של הלקוח ומשמעותו – משהו שאפשר ממש להדגים ללקוח)


לפני שאני אתן קצת דוגמאות, אני רוצה להסביר את היתרונות של חלוקה כזו:
– אפשר לקבל פידבק מוקדם הרבה יותר: למשל לא צריך לחכות עד שייסתיים הפיתוח בכדי להבין שהעיצוב לא מתאים.
– אפשר להבין טוב יותר את מידת הנכונות של הערכת המאמצים:. למשל אם חלק שחשבנו שדורש בערך רבע מהמאמץ להשלמת הדרישה לוקח ספרינט שלם, אפשר לנחש שכל הפיצ’ר ייקח 4 ספרינטים.
– אפשר לעצור באמצע:. קורה לא פעם שהלקוח לא באמת צריך את כל הפונקציונאליות עד הפרט האחרון, כשמפתחים את הפיצ’ר בשיטת הסלאמי למעשה עובדים בשיטת “הכל או כלום”, לעומת זאת כששוברים את סיפור הלקוח לחלקים קטנים יותר מבחינה פונקציונאלית אז ניתן בכל רגע להגיד “אוקיי, זה מספיק לנו, בואו נעבור לפי’צר הבא”.

ישנם עוד לא מעט יתרונות אבל נעצור כאן ונעבור לשתי דוגמאות כדי להמחיש.


דוגמא 1 – תוכנה לניהול רשת: בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של המשתמשים במערכת לפי חתכים שונים כדי להודיע הודעות דחופות שקשורות לרשת
ניתן לשבור אותו כך: (אני מוותר על ה”כדי”)

1. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של כל המשתמשים במערכת
2. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת אשר שייכים למחלקה מסוימת.
3. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת בעלי תפקיד מסוים
…..

שברנו את הסיפור ע”י שימוש בשתי טכניקות: הראשונה היא ע”י פישוט פונקציונאלי, בחלק (1) השמטנו לגמרי את כל הפונקציונאליות של הפילטר. בחלקים (2) ו-(3) הוספנו עוד “שדות” ובכך למעשה שברנו לאורך מודל הנתונים.


דוגמא 2 – עיבוד תמלילים: בתור משתמש אני רוצה להיות מסוגל לשמור את הקובץ שלי במיקום ובשם ע”פ בחירתי.

1. בתור משתמש אני רוצה לקבל הודעה כששם הקובץ שבחרתי לא חוקי
2. בתור משתמש אני רוצה לקבל הודעה כשאין מספיק מקום אחסון בדיסק.
3. בתור משתמש אני רוצה לקבל הודעה כשאין לי הרשאות שמירה.
4. בתור משתמש אני רוצה לשמור את הקובץ למקום מוגדר מראש
5. בתור משתמש אני רוצה לבחור את המיקום של הקובץ
6. בתור משתמש אני רוצה לבחור את שמו של הקובץ

שברנו את הסיפור שוב ע”י שימוש בשתי טכניקות: הראשונה היא למצבי שגיאה (1-3) זה בעיקר שימוישי לסיפורים מורכבים מאוד. הטכניקה השניה היא ע”י התחלה מפיצ’ר עם מגבלות קשות (מה שנקרא Hard coded) והסרתן של המגבלות אחת אחרי השניה.

אז ככה, בערך, בפשטות, שוברים או מחלקים סיפורי לקוח.

אם יש לכם דוגמאות שאתם מתקשים איתם מהארגון שלכם, אשמח שתרשמו אותם בתגובות ואני אשבור אותן בבלוג בפוסט אחר.

סיפורי לקוח – User stories

פתאום שמתי לב שאין לי ולו פוסט אחד על סיפורי לקוח.
נכון שהזכרתי את הנושא פה ושם אבל אף פעם לא התייחסתי לנושא בזכות עצמו וחבל.

image סיפור לקוח או User story  הוא שיטה לתאר דרישות של מוצר, הדבר הייחודי בשיטה הזו הוא שהיא מתארת את הדרישה מנקודת מבטו של הלקוח, מה ייחודי אתם שואלים? הייחודי הוא שבניגוד למקובל, מי שחשוף לדרישה הזו הם כולם,
בד”כ מי שחשוף לדרישה של הלקוח (אם בכלל) אלה הם אנשי השיווק או אנשי המוצר, הם יושבים עם הלקוח או עם עצמם ומנסים להבין מה הלקוח צריךרוצה.
אחרי שהם “הבינו” הם מתרגמים את הדרישות לדרישות שהפיתוח יבין, לדוגמא: הלקוח רוצה לקבל דו”ח יומי על משהו.
ברוב הארגונים מה שקורה עכשיו הוא פחות או יותר זה:

1. יושבים אנשי השיווק עם אנשי ה-System ומנסים להבין איך יעבוד הדו”ח היומי, איזה שדות יהיו בו, איזה פעולות צריך המשתמש לבצע
2. את התובנות שלהם, הם הופכים למשהו שהפיתוח “יבינו” שהרי הנחת יסוד היא שהפיתוח לא מבין כלום חוץ מפיתוח.
3. את המשהו שהמפתחים מבינים, המפתחים הופכים לקוד, שבסופו של דבר הופך לפונקציונליות במוצר.
4. כשהפיתוח הסתיים מראים לאנשי המוצר את התוצאות, והם בד”כ טוענים שלא בדיוק לזה הם התכוונו…
5. הפיתוח מבצע מקצה שיפורים.
6. מראים שוב לאנשי המוצר. הפעם זה טוב.
7. כשיוצאת גרסה, אנשי המוצר מציגים ללקוח את המוצר בגרסתו החדשה עם הפונקציונליות שביקש. הוא אומר שזה לא בדיוק מה שהתכוון. חוזרים לסעיף 2 עד שמישהו מתייאש, או שעבר כל כך הרבה זמן שהפיצ’ר כבר לא רלוונטי יותר.

במקום כל התהליך הזה, אפשר לנסות ולשנות גישה למשהו פשוט ויעיל יותר, נתחיל במעבר לסיפורי לקוח – User stories. לסיפור לקוח יש נוסח קבוע שנראה כך:

<As a <user type> I want to <do/get somthing> so that <reason
בתור <סוג לקוח> אני רוצה ש<משהו יקרה> על מנת ש<סיבה>

ישנם שלושה חלקים לסיפור הלקוח:
1. בתור <סוג לקוח> – חשוב מאוד לציין עבור מי אצל הלקוח הדרישה מיועדת, אצל המנהל, הפקיד, משתמש הקצה, מנהל המערכת. ידע מוקדם שכזה מוסיף הרבה פרספקטיבה לגבי הפתרון הרלוונטי.
2. אני רוצב ש<משהו> – זהו תיאור הפתרון המבוקש, זוהי דרך לתאר מה לא קורה היום שהלקוח רוצה שיקרה, למשל “אני רוצה שהלקוח יחשף למבצעים החדשים" בכל קניה”
3. על מנת ש<סיבה> – למרות שהחלק הזה אינו חובה, הוא מוסיף הרבה מאוד לתיאור, כאשר הלקוח מציין את הסיבה לדרישה, הוא למעשה מציין את המוטיבציה מאחורי הדרישה, ולעתים קרובות מאוד, התוספת הקטנה הזו מצליחה לעורר ולעודד חדשנות ורעיונות טובים לפיתרון הבעיה. למשל: בתור מנהל אני רוצה לראות דוח יומי של עסקאות בכדי לדעת אם המאזן הוא חיובי או שלילי, סיפור כזה עלול להדליק נורה, אם כל מה שהמנהל רוצה זה לדעת את מצב המאזן, למה לפתח דו”ח שלם בשביל זה.

המעבר לעבודה עם סיפורי לקוח עלול להיראות טכני אך לא כל הדבר.
השינוי אמנם מתחיל בכך שמשנים את הפורמט שבו מתארים דרישות, אך עיקרו ורובו טמון בכך שמשתמשים בו ככלי שעוזר לכולם לדבר באותה שפה: הלקוח, אנשי המוצר והפיתוח, כולם משתמשים באותו ניסוח לתיאור הדרישות של המוצר. יותר מזה, כולם ביחד יושבים ומנסחים את הדרישה, מדברים עליה ומקבלים דעות מכל מיני זוויות על אותה דרישה.  כשעובדים עם סיפורי לקוח, אז  עקב המיעוט בפרטים (זה דבר טוב) אנו “נאלצים” לתקשר יותר אחד עם השני, לשאול שאלות, להפגין דימיון ויצירתיות ובכך בסופו של יום לשפר את המוצר שאני מפתחים עבור הלקוחות.

בהמשך (אולי בפוסט הבא) אני אצלול טיפה יותר לעומק ואתן טיפים ודגשים לעבודה עם סיפורי לקוח.