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