הצגתם תכנית אבל אתם נתקלים בהתנגדויות קשות, מה עושים?

22 ביוני 2012

הגעתם מוכנים לפגישה ובום…
מישהו הפעיל מטען צד שלא ציפיתם לו.
עכשיו אתם צריכים לאסוף את השברים ולהתאושש.
זה בדיוק הנושא שעליו כתב יובל גולדשטיין, מנהל מוצר ב-Microsoft וחבר ותיק.
זו הפעם הראשונה שבה אני מארח כותב בבלוג הפתוח למנהל הפיתוח, אז בבקשה תתנהגו יפה ואל תפריעו…
 
***
 
יום חמישי אחה"צ. צוות הפיתוח כולו ישוב בחדר הישיבות הקטן אחרי שבוע אינטנסיבי של ליטוש התכנית לגירסה החדש של המוצר. על הקו נמצא איתנו המשקיע האמריקאי. מטרת השיחה: הצגת התכנית וקבלת אישור להתחלת הפיתוח.
רק שנייה… יש עוד מישהו על הקו… היועץ החדש של המשקיע שלנו…
אחרי היכרות טלפונית קצרה בינינו לבין היועץ, אני מתחיל במצגת ומראה את השקף שמסביר את הצורך בנקודת הזמן הנוכחית. השקף השלישי מראה סקיצה של אחד המסכים המרכזיים במערכת כפי שייראה בגרסה הבאה. אחרי שתי מילים, היועץ החדש של המשקיע יורה "נראה שאתם באמת לא מבינים את הצורך האמיתי של הלקוח אם בחרתם ללכת בקו הזה, המסך הזה פשוט נורא".
אני מנסה בנימוס להבין את שורש המחלוקת ולהציג את הרעיון שלנו בצורה מפורטת ובטון רגוע, אבל היועץ דורש להפסיק את המצגת תיכף ומיד.
בשלב זה בשיחה, השתיקה של המשקיע רועמת ואנחנו מבינים שבקרב הזה אין לנו סיכוי.
 
אז מה בדיוק קרה שם?
התכנית שהכנתם לפרויקט הקרוב אינה מתקבלת כפי שחשבתם, וגם אחרי מספר ניסיונות שכנוע היא עולה על שרטון. למרבה המזל, ניתן למנוע מצבים כאלה, לנהל אותם וגם לתקן את הרושם הראשוני.
 
אז איפה טעינו? מכיוון שהרגשנו מספיק נינוחים עם המשקיע לא טרחנו לשאול מי יצטרף אליו בצד השני של הקו. זו היתה טעות. טעות קשה יותר היא שלא הבנו כבר קודם שהמשקיע שלנו לא חש בנוח איתנו (וזה יכול לנבוע מכל סיבה שהיא, כולל עסקה לא מוצלחת שלא קשורה אלינו).
 
 
איך עושים את זה נכון? אם הפגישה חשובה לכם, דעו מי יגיע אליה ומה הוא חושב, לאן הוא מכוון ומה הוא רוצה להשיג (האמת, שאם הפגישה לא חשובה לכם, ותרו על הפגישה והשקיעו במשהו יעיל יותר).
קיימו דיון לפני הפגישה המשותפת באחד על אחד והביאו את ההצעה שלכם למקום שבו יש לה סיכוי מעולה להתקבל. בנוסף, אם הפגישה באמת חשובה, רצוי שתנהלו אותה פנים מול פנים ולא בטלפון. כן, גם אם זה אומר שתיסעו לחו"ל לפגישה. כך קל יותר להקשיב לצד השני וללבן מחלוקות ביעילות.
 
אז איך מתמודדים עם התנגדות שכזו?
אחרי כמה דקות של הוצאת קיטור רקחנו פתרון. היה לנו ברור שהיועץ החדש מחפש דרך טובה לבסס את מעמדו בפני המשקיע וכי עלינו להתמודד עם  ההתנגדות שלו כדי לקבל את ברכת המשקיע לתכנית שלנו.
החלטנו לתת ליועץ את מה שהוא רוצה: יכולת להיות מעורב בצורה אמיתית בגיבוש התכנית ולהשפיע על הדברים מבפנים. בשיחת המשך ביקשנו את עזרת היועץ בתיקון התכנית וסיכמנו שיגיע למשרדים בארץ לכמה ימים של עבודה מרוכזת, שבסופם נציג למשקיע תכנית חלופית.
 
 
ככה מתמודדים עם משבר
 
"שיטת סרג'יו לכיבוש מהיר בשלושה תשלומים"
הגדרנו לעצמנו שלשה שלבים עיקריים בגיבוש התכנית החדשה:
  1. יצירת אווירת עבודה טובה ועניינית.
  2. ביסוס הסכמה על עקרונות מנחים כלליים למוצר.
  3. חזרה למקורות: עבודת תכנון משותפת של תרחיש משתמש מרכזי במערכת, כדי שלוודא שבאמת יש תמימות דעים לגבי תכולת הגרסה הבאה.
את השעות הראשונות לביקור היועץ בילינו בהקשבה מנומסת לכל רעיון וקו מחשבה שלו, וגם רשמנו לפנינו את נקודות המחלוקת אותן העלה לגבי מה המוצר שלנו צריך לתת בגרסה הבאה. כדי ליצור רושם טוב ואווירה נעימה הצגנו בפניו את חברי הצוות, שסיפרו קצת על עצמם ועל הניסיון הקודם שלהם. הצגנו את העבודה שעשינו בגרסאות קודמות, את תהליכי העבודה שלנו ואת הדברים המיוחדים שאנחנו עושים בצורה קצת שונה. רק אחרי שהקרח נשבר והאווירה נעשתה נעימה, התחלנו את הדיון האמיתי.
במקום לתקוף את הבעיה המיידית: מה עלינו לפתח לגרסת המוצר הבאה, קיימנו שיחה שמטרתה לבסס הסכמה על כמה עקרונות מנחים שמהווים תכנית על למוצר.
 
אז למה כדאי לקחת צעד אחורה לפני שצוללים לתכנון הפונקציונלי?
עקרונות מנחים למוצר הם עמודי תווך לכל תכנית או גירסה עתידית. על עקרונות אלו לתת תשובה ממוקדת לשאלה: למה הלקוח יאהב את המוצר שלנו ויעדיף אותו על פני מוצרים אחרים?

לדוגמה: יכול להיות שהלקוח בסגמנט השוק שבחרתם מייחס חשיבות רבה לרכישה מהירה והטמעה קלה של המוצר. במקרה כזה, העקרון המנחה שלכם יהיה האפשרות לרכוש ולהטמיע את המוצר בשבוע עבודה אחד בלבד (יש כאלו שיאמרו שגם שני קליקים זה יותר מדי), ובהתאם לכך תוכלו לרכז את מאמצי הפיתוח באשפים שמסייעים למשתמשים חדשים להכיר את המערכת, הסברי וידאו לכל פונקציה כחלק מובנה ממשק המשתמש, עיבוי צוות התמיכה ושיפור כלי הבקאופיס שהוא עובד איתם, כדי שיוכל לסייע למשתמש לסיים את ההטמעה במהירות.
לקוח אחר, עשוי להתמקד במהירות של טעינת דף העבודה המרכזי ביישום, מכיוון שהוא מתמודד עם עבודה באווירה תזזיתית. וכאן ניתן לקחת את הקו של "המוצר שלנו יעשה הכל כדי שתוכל לצלוח את תהליך העריכה במהירות שיא". לקוח מסוג שלישי ייחס חשיבות ליכולת הקסטומיזציה של המסכים לצורת העבודה הייחודית שלו. לקוח מהסוג הרביעי יכול לעבוד רק במק, ואילו החמישי פשוט חייב לייבא את הנתונים שלו מתוכנה קיימת אל המוצר שלכם לפני שיוכל להתחיל לעבוד.
 
עקרונות מנחים: הבסיס למיקוד
בחירת עקרונות מנחים יוצרת בהירות ומאפשרת דיונים ממוקדים לבחירת התכולות ועיצוב של המוצר. ברגע שתזהו מה חשוב ללקוחות שלכם, תוכלו ביתר קלות להעדיף דרך פיתרון אחת על אחרת, או להכריע בין תכונה אחת לאחרת. חשוב לתקשר את העקרונות לכל חברי הצוות, כדי שיוכלו לקבל בעצמם החלטות מושכלות.
 
מעקרונות מנחים לת'אכלס
אחרי שיש בסיס מוצק, אפשר לדבר על הפרטים. מכיוון שלא ניתן להשלים תכנון מפורט של המוצר בכמה ימים הסכמנו שעלינו להציג מספר מצומצם של יכולות ליבה של הגרסה הבאה של המוצר למשקיע ואת גיבוש הפרטים הסופי נבצע כחלק מהפרויקט עצמו. אחרי שדיברנו על עקרונות כלליים, היה לנו חשוב לוודא שאנחנו מציגים תכנית מוצר שמתארת בצורה אמיתית את הכוונה המשותפת לנו וליועץ.
 
לפעמים זה טוב לספר סיפורים
ישנן דרכים רבות לתאר יכולות מוצר, ובחרנו בשיטה שמאפשרת התקדמות מהירה בזמן קצר: לספר סיפורים. בשיטה זו, מתארים את מה שהיישום עושה בצורת סיפורים קצרים המתמקדים בפעולות של הלקוח (כן, כן בדיוק כמו ב – SCRUM). במקום לשקוד על סקיצות חדשות, החלטנו לכתוב שלושה עמודי טקסט לא טכני, שיתארו שבוע בחיי המשתמשים במערכת שלנו. מרתון כתיבת הסיפור המשותפת הפך לפעילות מהנה. ישבנו בחדר אחד עם מסך גדול , היועץ, מנהל המוצר ומנהל הפיתוח, ובמשך יומיים ארוכים ניסחנו בפשטות את עתיד המוצר שלנו.
בפתיחה הצגנו פתחנו בהסבר כללי קצר שכלל:
  1. תיאור כל המשתמשים במערכת ומהן נקודות הקושי עבור כל אחד מהם.
  2. מיהם המשתמשים שאחראים על רכש המוצר ומה חשוב להם.
  3. מי המשתמש הראשי ביום-יום ומה חשוב לו.
  4. איך מתנהל היום הראשון לשימוש בגרסה החדשה של המערכת..
את עיקר המסמך ביססנו על מטלות היום יום של המשתמשים וכיצד המערכת מסיעת לכל אחד מהם. לכל מטלה הצמדנו סיפור קצר שמדגים את האינטראקציה של המשתמש עם המערכת , מה היא מבצעת עבורו וכיצד המטלה שלו מושלמת בהצלחה.
בשלב הבא, הבהרנו כיצד מספר סיפורי משתמש משתלבים והדגמנו כיצד מטלות מורכבות, המבוצעות על ידי כמה משתמשים, עוברות ממצב אחד לאחר ומה המידע הנלווה אליהן בכל שלב.
לבסוף שלחנו את המסמך לכמה לקוחות שיש לנו איתם היכרות אישית טובה וקיבלנו מהם תגובות, הצעות לשינוי וגם הרבה חיזוקים. לבסוף ישבנו שוב עם צוות הפיתוח, במטרה לגבש פתרון טכני שתומך ביכולות החדשות הנדרשות למערכת, להבין את עבודת הפיתוח הנוספת ולגבש לוח זמנים כללי.
להצגת התכנית, ביקשנו מהמשקיע שלנו להגיע אל המשרדים בארץ וקיימנו את הצגת התכנית פנים מול פנים. למעשה הצגנו תכנית שהיתה קרובה לתכנית המקורית שלנו, אבל הפעם נהנינו ממספר יתרונות:
  1. במקום להציג רק את הפתרון שלנו לצרכי הלקוח, הצגנו את העקרונות המנחים שעמדו מאחורי ההחלטות שלנו, וגם הראינו מידע שיבסס את ההנחות שלנו לגבי רצונות הלקוח.
  2. במקום להציג סקיצות מסכים שמאפשרות הסחות דעת והתמקדות בפרטים קטנים ולא מרכזיים, הצגנו סיפור כללי שמשאיר מקום לדמיון אבל ממחיש את הפונקציונליות הבסיסית.
  3. העבודה המשותפת על התכנית עם היועץ יצרה קואליציה שבה שני הצדדים רוצים בהצלחת התכנית.
  4. ההצגה פנים מול פנים אפשרה דיון קל וישיר בתוכן המוצג.
 
אז מה הלקח?
הפגישה הסתיימה בהצלחה וכבר למחרת יצאנו לדרך והתחלנו לעבוד על הגירסה החדשה. למדתי שתכנית טובה בלבד אינה מספיקה, ושצריך להשקיע אנרגיות בשכנוע וגיוס תמיכה לפני שתוכלו לצאת לדרך. בסופו
של דבר, העובדה שהצוות התגבר על המהמורה ועשה מאמץ מיוחד לצאת עם תכנית מתוקנת יצרה תחושה טובה של הישג וחיזקה גם את הגיבוש שלנו כצוות.
 
יאללה, לעבודה!

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

4 תגובות

  1. איתן גנור24 ביוני 2012 ב 10:27

    כשעובדים מול חברות גדולות, המושג "לקוח" אינו חד משמעי, ומורכב מכמה בעלי תפקידים משפיעים בעלי אינטרסים שונים. כאן נתקלתם בזה שלמושג "לקוח" נתוסף מרכיב היועץ שבא עם אג'נדה שלו.
    נתקלתי כבר במקרים מורכבים פי כמה, כאשר המושג לקוח היה מורכב מ-:
    * יחידת מכרזים – רוצים לסגור חוזה ומהר, ובכמה שפחות עבודה.
    * כספים – רוצים מוצר זול.
    * הנדסה – רוצים מוצר מתוחכם.
    * מחלקת איכות – רוצה מוצר עם איכות ואמינות אינסופיים.
    * משתמשי קצה – רוצים מוצר נוח לתפעול ותחזוקה.
    * מנהלים שונים – רוצים שהחוזה ישרת פוליטיקת פנים שלהם.
    עכשיו לך תרצה את כולם… זו אומנות השיווק… ואין תחליף למנהל מוצר שהינו בן בית אצל הלקוח, יכול להשפיע על התהוות המכרז לפני פירסומו, ויכול לפרוק מוקשים.

    בהצלחה, איתן גנור
    מנהל איכות ותיק בהייטק

    הגב
  2. Moshe Kaplan24 ביוני 2012 ב 13:29

    שלום איתן,

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

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

    ממשיכים לפתח,
    משה קפלן

    הגב
  3. יובלגו24 ביוני 2012 ב 14:56

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

    יובל.

    הגב
  4. Moshe Kaplan25 ביוני 2012 ב 10:37

    יובל אתה צודק לחלוטין,

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

    ממשיכים לפתח,
    משה קפלן

    הגב