שביעות רצון לקוח בפרויקט: איך מנהלים לקוחות ומגדילים ערך עסקי?
למנהל הפרויקט יש מספר זרועות או בעלי עניין איתם הוא בא במגע שוטף: מנהלים בארגון שהם לרוב מקבלי ההחלטות ובעלי התקציב, ספקים, צוותי פיתוח, בדיקות, אבטחת מידע ועוד. עם זאת, הגורם המרכזי שמשפיע על הצלחת הפרויקט הוא הלקוח, שכן שביעות רצון לקוח בפרויקט היא מדד ההצלחה המשמעותי ביותר ולא רק עמידה בלוחות זמנים או בתקציב.
הלקוח הוא החלק הארי בכל פרויקט: הפרויקט נבנה עבורו. הוא מגדיר את הדרישות, מלווה את הפרויקט מתחילתו, וגם לאחר סיומו משתמש בתוצרים בפועל. לכן, ניהול נכון של הדרישות והאינטראקציה מול הלקוח משפיעים ישירות על שביעות רצון לקוח בפרויקט לאורך כל מחזור החיים שלו.
לדוגמה, בפרויקט של הקמת מערכת CRM חדשה (מערכת לניהול קשרי לקוחות), העובדים המשתמשים במערכת הם הלקוחות של הפרויקט. הצלחת הפרויקט אינה נמדדת רק בהשלמת התכולה, אלא בעיקר במידה שבה התוצר נותן מענה לצרכים האמיתיים שלהם ומוביל ל־שביעות רצון לקוח בפרויקט בפועל.
כל לקוח תמיד ירצה את האיכות הכי טובה שניתן, בעלות נמוכה ובזמן הקצר ביותר האפשרי (ערך עסקי Business Value). לכן מנהל הפרויקט צריך לנהל באופן אישי את האינטראקציה עם הלקוח לכל אורך הפרויקט, כך שתהיה יציבה, שקופה והוגנת עם הלקוחות שלו. תקשורת עם הלקוח היא לא רק סיסמה, היא "לחם חוקו" של מנהל הפרויקט. איכות הפרויקט נמדדת אם כן ב Business Value (שנעשה בעזרת תיעדוף ברור ומקובל על ידי הלקוח) שיקבל הלקוח ולא רק בהיבטים הטכניים של לו"ז ותכולה.
סיבה נוספת מדגישה את הצורך ב"ניהול" הלקוח: חוויה לא טובה של לקוח מהפרויקט שלכם תעשה נזק לאורך זמן. אנשים נוטים יותר לספר לאחרים כאשר קיבלו שרות או מוצר גרוע (ולפרסם ברשתות חברתיות למשל) ופחות ישתפו אם קיבלו מוצר או שירות מעולה. לכן, חוויה לא טובה של לקוחות מתוצרי הפרויקט עלולה לעשות נזק, ולעיתים קשה לתקנו.
סוגי הלקוחות
ניתן לחלק את הלקוחות לשני סוגים: לקוחות חיצוניים לארגון ולקוחות פנים ארגוניים. לרוב הארגונים הגדולים כיום יש פלטפורמות ומערכות פנים ארגוניות בהם משתמשים העובדים והמנהלים בארגון ופלטפורמות חיצוניות לארגון כמו אתרים, אפליקציות ואחרים.
על מנת להבין מיהם הלקוחות של הפרויקט נהלו רשימה של "בעלי העניין" בפרויקט. חלקו אותן במטריצה החל מבעלי עניין גבוה בפרויקט ובעלי "עוצמה" גבוהה לפרויקט ועד לבעלי עניין נמוך בפרויקט ובעלי "עוצמה"
נמוכה. שיטה זו תעזור למנהל הפרויקט להבין מיהם בעלי העניין אותם הוא חייב לנהל בצורה הדוקה יותר. שימו לב: הלקוחות בעלי העניין הגבוה ביותר בפרויקט ובעלי העוצמה הגבוהה יכולים אפילו לעצור אותו. ולכן בדיוק חשובה התקשורת הרציפה עימם.
אופן ההתנהלות מול הלקוחות לאורך שלבי הפרויקט תלויה גם בסוג הלקוח: האם הוא פנים ארגוני או חיצוני לארגון (בין אם משתמשים אקראיים, מנויים וכו') או גם וגם.
ישנן מספר שיטות מתודולוגיות לניהול הפרויקט. הבחירה ביניהן תלויה בסוג הפרויקט ובסוג הארגון המטפל בפרויקט. אסקור בקצרה שתיים מהן: שיטת "מפל המים" (Waterfall) היא השיטה "המסורתית" יותר ומסדרת אותו בשלבי פרויקט סדורים המגיעים אחד אחר השני בעבודה "לפי הספר". היא מותאמת לפרויקטים בעלי נפח עבודה גדול וממשקי עבודה מרובים. כל שלב יבוצע ע"י צוות אחר בהתאם להתקדמות הפרויקט (צוות הייזום, הפיתוח, הבדיקות וכו').
השיטה השנייה היא שיטת Agile המחלקת את הפרויקט ל"סבבים" – כל "סבב" הוא פרוסה נוספת מהעוגה כך שהתוצר הסופי יגיע רק לאחר שכל הסבבים יסתיימו.
ניתן לבחור בשיטה היברידית המשלבת שתי שיטות אלו ולוקחת את היתרונות בכל שיטה.
בפרויקטים שלי המכילים מספר צוותי עבודה, כאשר קיימת הגדרת דרישות ברורה מצד הלקוח אבחר בד"כ במתודולוגיה של שיטת "מפל המים" (Waterfall), או בשילוב שלה עם שיטת ה : נשתמש בתחילת הפרויקט בשיטת Waterfall כך שתיתן אבני בניין טובים ויציבים להמשך, ולאחר מכן את השיטה האג'ילית של סבבים קצרים שתביא תוצרים בזמן קצר. זאת כדי לאזן בין ודאות לבין גמישות מול צרכי הלקוח לאורך חיי הפרויקט*.
*הרחבה למתודולוגיית פרויקט ניתן למצוא לדוגמה במאמר זה.
שביעות רצון לקוח בפרויקט לאורך חיי הפרויקט
התנעה: שלב הייזום – הגדרת הצרכים והערך ללקוח
מזל טוב! פרויקט נולד. זה השלב הכי חשוב בפרויקט. אם נבנה אותו מתחילה בצורה נכונה ובחוכמה, נחסוך לעצמנו בעיות במעלה הדרך.
תחילה חשוב לקבוע את מטרות הפרויקט. ללא קביעה של מטרות מוגדרות לא נדע להגדיר את מידת ההצלחה שלו Definition Of Done. חשוב להבין מהם הצרכים של הלקוח וכן מה מגדיר את סיום הפרויקט, על מנת שלא להתפזר (עצם ההגדרה של פרויקט היא שיש לו נקודת סיום).
לאחר שסוכמה התכולה, נדרש לחלק את הפרויקט ל"חבילות עבודה" ולחלק אחריות למשימות השונות.
לעיתים הלקוח הפנים ארגוני מתנגד לפרויקט, בין אם באופן פעיל או סביל ("למה מוסיפים לי עוד עבודה…?"). מה שיגרור בהכרח עיכובים בפרויקט. היו קשובים לקולות אלו מההתחלה ונסו לבנות תקשורת חיובית ופתוחה, להסביר את התועלות בתוצרי הפרויקט ולבנות איתו מערכת יחסים טובה. מנהל הפרויקט יסביר ללקוחות שאולי תתווסף עוד עבודה בשלב הראשון ולאחריו תהיה אוטומיזציה של התהליך כך שיהיה יעיל ומהיר.
לקוחות חיצוניים גם הם יכולים להוות אתגר בעיקר בגלל המתחרים שלכם בשוק ומה שהם מציעים. חשוב לשלב אסטרטגיה שיווקית נבונה.
בשלב הייזום נרצה לבצע סקרי עומק ומחקרים למדגם משתמשים ולבדוק מגמות וציפיות. צוות הפרויקט צריך לבצע ראיונות עם משתמשים רלוונטיים, לבצע הפקת דוחות וכן תצפיות על אופן השימוש.
אף פעם אל תניחו הנחות לגבי מה המשתמש צריך או רוצה. תשאלו אותו. נסו להבין מה "הכאבים" שלו במצב הנוכחי כדי להתאים את הפרויקט אליו במידה אופטימלית. נסו מוקדם ככל האפשר להראות ללקוח דמו של תוצרי הפרויקט כדי לוודא שהפרויקט עומד בציפיות שלו.
מנהל הפרויקט ייפגש עם האנשים הרלוונטיים בארגון (משתתפי הפרויקט). יהיו אלו למשל אנשי ה UX (מאפייני חווית משתמש) ולאחר מכן אנשי ה UI (מעצבי חווית משתמש), אנשי הפיתוח, המנהלים, מנהל המוצר אם קיים, אנשי השיווק, מחלקה משפטית במידת הצורך ועוד.
נתבו את הפרויקט כבר משלב היזום לעבר הערך העסקי שהוגדר כגון: שיפור הכנסות, קיצור זמני תפעול, צמצום טעויות משתמש.
ממש השבוע סיימנו פרויקט גדול ללקוחות פנימיים בחברה, שארך כשנה. את הפרויקט בעצם קיבלתי בירושה ממנהלת פרויקטים שעברה לתפקיד אחר בחברה. מטרת הפרויקט היתה למכן תהליך חדש שעד אותו זמן בוצע באופן ידני ומסורבל כדי למנוע טעויות ידניות, הכנסת תהליך בקרה אינטגרלי ובניית תהליך אחיד ומהיר שיחסוך משך תפעול ויהיה נוח לתפעול.
מאחר והפרויקט היה בעצם די בראשיתו, החלטתי שאני בעצם מתחילה מחדש. למדתי את הנושא עם צוותי השירות, ראיתי כי התהליך מצריך תפעול של מסכים רבים, אך מיצבתי אותו ב Flow (תהליך זרימה) הגיוני ומסודר. ביחד עם מערכות המידע עלה רעיון להכניס מסך ניהול שישמור על ביצוע תהליך מסודר עם בקרה אינטגרלית. כלומר המשתמש עובד בעצם עם מסך אחד המאגד כ 10 תהליכים שונים יחד. בוצע POC ראשוני ("בדיקת התכנות" Proof of concept – בודקים שהפרויקט ישים ביישום "רזה) למערכת והוא הוצג בישיבה רבת משתתפים של הנהלה, צוותי הבדיקות וכמובן נציגי הלקוחות האמורים לתפעל את התהליך. בתום פגישה זו אושר הפתרון המוצע וניתן האור הירוק ליציאה לדרך. גם בשלב הבדיקות, שילבתי את נציגי השירות הרלוונטיים. מעצם העבודה בפרויקט עם הלקוחות "יד ביד" לכל אורך התהליך, התקבלה התוצאה של שביעות רצון מצד כל משתתפי הפרויקט וההנהלה.
ליבת הפרויקט: פיתוח בראיית משתמש
פיתוח הוא לא "עוד שלב". הוא השלב העיקרי שמלבדו לא יוקם פרויקט במערכות מידע. הוא השלב העיקרי ומשכך הוא, חובה לתת לו מקום של כבוד בקביעת גאנט הפרויקט (לוח הזמנים), תוך הסתכלות על האילוצים, על התקציב והסיכונים.
פיתוח לוקח זמן. לעיתים הרבה זמן. ומאחר שכך, חשוב שמנהל הפרויקט יקיים פגישות סטטוס שוטפות עם מנהלי הפיתוח ויפתור בעיות כל עוד הן קטנות. במידה והפרויקט נבנה בשיטה אג'ילית של סבבים קטנים יש לפקח על כל שלב והתוצרים שלו, כך שכולם יעמדו במסגרת הפרויקט שהוגדר.
חשוב שהפיתוח יתקיים בהיבט של ראיית המשתמשים והחוויה שלהם מהתוצר של הפיתוח. בעת ה- DESIGN REVIEW (סקירת הפתרון) חשוב לוודא שמסמכי האפיון תואמים את המתבקש וכן שהדמיית המסכים תמחיש ללקוח הסופי מה הוא עתיד לקבל.
תפקידו של מנהל הפרויקט להבטיח שכל פיצ'ר חדש או שיפור שיפותח יגע ככל הניתן ב"כאבים" של הלקוח וייצר יעילות תפעולית. למשל בפרויקט שביצענו שיפרנו את התצוגה באתר החברה של מחשבון התשואות למכשירים פיננסיים הנמכרים בחברה, מתוך הבנה שהמחשבון הקיים נופל מזה של המתחרים בשוק. התוצאה היתה הגדלת ההכנסות במכשירים הפיננסיים המובילים, בין אם ע"י הגדלת החיסכון של לקוחות קיימים ובין אם בכניסת לקוחות חדשים.
שלב הבדיקות
חשוב לשתף את הלקוח בבדיקות כבר בתחילתם, כאשר הפיתוח יציב דיו. זאת כדי לוודא עמידה בציפיות של הלקוח. זה השלב שבו הלקוח "מרגיש" את הפרויקט שהיה עד כה וירטואלי. בקשו מהלקוחות שלכם בארגון "לשחק" עם המערכת בדרך בה היו משתמשים בה. בפרויקט עם לקוחות חיצוניים, שחררו גרסה ראשונית למדגם משתמשים ואספו נתונים על אופן השימוש ושביעות הרצון מהשימוש.
הלקוח שלכם עסוק בעבודתו השוטפת ולכן קבעו מולו לוח זמנים ריאלי עבורו לבדיקות בלו"ז הפרויקט. זכרו כי הלקוח הוא אומנם מומחה תוכן אך לא בהכרח מכיר את התהליכים הטכניים של הבדיקות. לוו אותו בבדיקות והיו זמינים לשאלות.
בעצם שילוב הלקוח בבדיקות אתם הופכים אותו מ"מבקר" לשותף בפרויקט ולכן יש לו מניע לעזור ולהיות שותף בהצלחת הפרויקט.
לפני שנים אחדות סיימנו פרויקט גדול של מיכון אוטומטי של חישוב אוטומטי של ריבית. עד אז, למרות שהיו נהלים מסודרים, התפעול היה ידני ברובו והתבסס על כך שהמשתמש מחשב את סכום הריבית בצורה נכונה מתוך סימולטור באקסל ומציב את הסכום בשדה המתאים בביצוע התהליך. מיכון התהליך היה מסובך בגלל שנדרשה שיטת חישוב שונה לכל סוג פעולה. היה נדרש למצוא "כללי אצבע" לחישוב, וכן לבנות תהליך אחיד מאחר וכל צוות עבד לפי נהלים מעט שונים. עוד נדרש מהפרויקט לבצע בקרה לתהליך וכן שהתהליך יהיה קל ומהיר למשתמשים, מאחר והיו התנגדויות בתחילה על עומס נוסף של עבודה.
בתחילה קיימתי סט ישיבות שוטפות עם ההנהלה וכן עם יועצים מקצועיים לצורך הבנת שיטות החישוב הדרושות. חילקנו את הפרויקט לחבילות עבודה. וביצענו חשיבה וסיעור מוחות עם מערכות המידע, שבסופה הוחלט על שלושה תוצרים לפרויקט: תחילה נבנה מסך אחד למשתמשים שהוא ברור (ללא מילים "מסובכות") ונוח לתפעול, וברובו אוטומטי, וכן נבנה מסך המציג את היסטוריית הפעולות בתיק הלקוח ולבסוף נבנה דוח ייעודי להנהלה הסוקר את הביצועים ברמה שוטפת. הלקוחות וההנהלה היו שבעי רצון וכן עמדנו בזמנים ובתקציב שהוגדר.
טיפים: עשה ואל תעשה בהתנהלות מול הלקוח
- אל תניחו הנחות. בצעו ראיונות עם משתמשים (או עם משתמשים פוטנציאליים), צפו בעבודה השוטפת שלהם והבינו מה הצרכים שלהם כדי "לתפור" להם תוצר נכון עבורם. שאלו אותם איזה ערך עסקי יצפו לקבל מהפרויקט.
- בצעו תיאום ציפיות עם הלקוח מיד בתחילת הפרויקט מה נכלל בתכולה שיקבל, אילו מהסעיפים נתקשה לספק וכו'. היו כנים ושקופים לגבי לוח הזמנים על מנת לא לטעת תקוות שווא ולהביא לתסכול. הקשיבו אך אל תבטיחו את מה שלא ניתן לביצוע. הראו ללקוח מה יקבל, עדיף בצורה ויזואלית.
- היצמדו למטרת הפרויקט שהוגדרה מראש לכל אורך הדרך ואל תסטו ממנה למעט חריגים הכרחיים, אחרת תתפזרו בדרך. עם זאת, היו פתוחים לשינויים. לא תמיד הלקוח מבין מהתרשימים שהעברתם לו בתחילה מה הוא מקבל. היו פתוחים לשנות אך הסבירו ללקוח מה המשמעות של הבקשה: למשל סטיה מלוח הזמנים שהוגדר לסיום.
- דברו עם הלקוח בשפה שהוא מבין. לא כל לקוח מבין את השפה העסקית והטכנולוגית בה אתם רגילים להשתמש. השתמשו ככל האפשר בוויזואליזציה של המסכים, במקום במסמכי אפיון כתובים.
- וכן, זה עובד גם להיפך. על מנת שהפרויקט יהיה מוצלח חשוב להבין את הלקוח. הלקוחות חיים ביומיום "את העסק". מנהל הפרויקט בד"כ בא מעולם אחר ולכן חשוב שיהיה קשוב להם ויבין את "שפת השטח" שלהם. הבנה לא נכונה תגרום לטעות בפענוח ועלולה להוביל למציאת פתרון לא נכונה. תקשורת היא לב הסיפור.
- בחרו מתוך הלקוחות את אלו שמוכנים לאמץ את השינוי ובחרו בהם כשגרירים להטמעה בארגון.
- נסו להפוך את התקלות שנמצאו להזדמנות, כדי לא ליצור תסכול אצל הלקוח. שקפו ללקוח שמזל שאותרו בשלב מוקדם לפני העלייה לסביבת היצור (Production Environment).
שביעות רצון של משתמשים ולקוחות אינה נוצרת בסיום העבודה, אלא נבנית לאורך כל שלבי הפרויקט. ניהול נכון של תקשורת, דרישות ושיתוף הלקוח מגדיל את סיכויי ההצלחה ומחזק את הערך העסקי.
נכתב ע"י ליאת יגר מנהלת פרויקטים בכירה | מאפיינת UX ומנהלת מוצר | MA במדיניות ציבורית
