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

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

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

חוזים אג’ילים – זה כדאי !

אחד מארבעת הערכים של ה-Agile manifesto הוא:
Customer collaboration over contract negotiation

מה זה אומר ?
איך מוציאים לפועל ערך כה מעורפל ?
|מה המשמעות של שיתוף פעולה עם לקוחות?
אז מה עושים ?

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

clip_image002שותפות אמיתית בין לקוח לספק מייצרת מצב שבו לשני הצדדים יש מה להפסיד או להרוויח מכישלון או הצלחה של הפרויקט, למשל אם בתחילתו של הפרויקט אנחנו מתחייבים ללקוח שלנו לספק לו את רשימת הדרישות שהוא דרש, באיכות גבוהה ובזמן המוקצב, הרי בעקבות אי הוודאות השגורה במשימות פיתוח תוכנה אנו לוקחים סיכון עבורו,ואם לא מספיק שאנו לוקחים את הסיכון שלו אנחנו גם בד”כ לא ממש מספרים לו שאנחנו לוקחים סיכון, הוא “משוכנע” שאנחנו נעמוד בהתחייבויות שלנו כי ככה כתוב בחוזה, שהרי אנחנו מחויבים משפטית לעמוד בחוזה, בחוזה חוזה מסוג זה נקרא חוזה קבוע מחיר – Fixed price contract.

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

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

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

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

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

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

אסייג ואומר שוב, אני לא עורך דין, ולא מומחה בחוזים, אבל אני באמת חושב שזה אפשרי.

כמאמר ג.יפית : זה כדאי!