Posts tagged ‘תקשורת’

סיפורי לקוח – 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. על מנת ש<סיבה> – למרות שהחלק הזה אינו חובה, הוא מוסיף הרבה מאוד לתיאור, כאשר הלקוח מציין את הסיבה לדרישה, הוא למעשה מציין את המוטיבציה מאחורי הדרישה, ולעתים קרובות מאוד, התוספת הקטנה הזו מצליחה לעורר ולעודד חדשנות ורעיונות טובים לפיתרון הבעיה. למשל: בתור מנהל אני רוצה לראות דוח יומי של עסקאות בכדי לדעת אם המאזן הוא חיובי או שלילי, סיפור כזה עלול להדליק נורה, אם כל מה שהמנהל רוצה זה לדעת את מצב המאזן, למה לפתח דו”ח שלם בשביל זה.

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

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

לשבור את הקיר

clip_image002[4]

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

אז בואו נתן דוגמאות לכמה קירות כאלה באירגונים חלקם פיזיים וחלקם וירטואלים:

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

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

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

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