Saturday, January 12, 2019

שייחנק הלקוח



English version

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

עד כאן לגבי למה אני חושב שזה לא נכון להשאיר ללקוח את המילה האחרונה באשר לאיכות המוצר שהוא מקבל, אבל אילו זה היה כל הסיפור, לא הייתי טורח לכתוב כאן. אחרי הכל, אנשים טועים באינטרנט כל הזמן. הבעיה היא שהגישה הזו עלולה להוביל מאוד בקלות להעתקת יעדים (אם מישהו מכיר תרגום טוב לgoal displacement, אשמח לשמוע על כך). הבנה פשטנית של העיקרון הזה דוחפת אותנו להתבונן על איכות נתפסת של המוצר ודורשת לא מעט להטוטנות פרשנית כדי להצדיק כל דבר שאיננו פיצ'ר חדש. למשל, אם נסתכל על שינויי תשתיות שמאפשרים לנו לגדול בהתאם לשוק - כרגע, המוצר שלנו מחזיק יופי ומסוגל להכפיל את גודלו בארכיטקטורה הנוכחית, אז אין טעם לשנות, נכון? תיאורטית, אפשר לזרוק עוד חומרה על הבעיה וזה יחזיק אותנו במשך חמש שנים נוספות. התרגיל הפרשני שנדרש הולך בערך ככה: "אם לא ניישר את זה עכשיו נצטרך לתקן את זה תחת לחץ, כשהלקוחות שלנו כבר מרגישים הרעה בשירות, והתיקון יהיה מורכב יותר כי בחמש השנים האלה נוסיף עוד יכולות שיתבססו על התשתיות הישנות, חוץ מזה פתרון בעיות יעסיק אותנו ולא נוכל לספק ללקוח תכולה בקצב דומה לזה של היום". טיעון רב שלבין כזה הוא לוגיקה מורכבת, ובעוד שאין לי ספק שכולנו חכמים ומסוגלים ללוגיקה כזו, ככל שנתרגל את האינסטינקטים שלנו לחשוב על ריצוי הלקוח קודם כל, נדמיין פחות תרחישים כאלה ויהיה לנו קשה יותר להצדיק פעולות צופות עתיד למול תחושות הבטן המבוססות שלנו. אני מאמין שרוב הצוותים היום לא בדיוק צריכים *עוד* משהו שידחף לכיוון פיצ'רים גלויים ללקוח על חשבון שיפוצים נדרשים. 
נכון - אם ממש מנסים, אפשר למצוא קשר בין כל פעולה חיובית במוצר לבין השפעה על הערך שמקבל הלקוח, אבל ההשפעה הזו יכולה להיות עקיפה ולהיות רק אחד הגורמים שמשפיעים על חוויית המשתמש.
תרגיל מחשבתי נוסף כדי להסביר על מה אני מתכוון - דמיינו שתי חברות שמייצרות מוצר דומה, מבוסס ענן. המוצרים עצמם נבדלים זה מזה רק בכמה פיצ'רים מינוריים שפונים לטעם האישי של כל משתמש. חברה א' מחזיקה עשרה מהנדסים מיומנים כדי להפעיל את המוצר והם מנהלים אותו בקפידה. חברה ב', מצד שני, בחרה לשכור עובדים בשכר נמוך משמעותית ובאותו מחיר היא שוכרת 100 אנשים להפעיל את המוצר. גם ההוצאות התפעוליות דומות - חברה א' משלמת על שירותי אחסון יקרים ואמינים מאוד, עם חומרה חזקה וארכיטקטורה שמסוגלת להתמודד עם כל מה שהאינטרנט זורק עליה, ואילו חברה ב' משתמשת בשירות זול יותר ושוכרת הרבה יותר חומרה זולה כדי להתמודד עם אותו עומס בהצלחה. בחברה ב' יש צוות ייעודי שמתמודד עם משברים ודואג להדביק במסקינגטייפ את כל החורים והתקלות כך שהלקוח לא רואה כלום. 
האם אפשר לומר שאיכות שני המוצרים שווה?לכאורה, אלו שתי אסטרטגיות שמובילות לאותו מקום. רק שחברה ב' מתעמרת באנשי Operations שלה ועושה להם חיים קשים. 
תגובה שקיבלתי לזה מיואל הייתה שאנשי Ops הם אחד מסוגי הלקוחות שלנו. 
על זה אני יכול לומר - לא, הם לא. 
עד עכשיו הטיעונים שלנו הניחו שיש זהות בין החברה שמספקת את המוצר לצוות שמפתח אותו. זה עובד רק כל עוד מתייחסים לכל מי שבתוך החברה כאל חלק מהמנגנון הזה. אם אנחנו מתחילים להסתכל על צוות פנימי כעל "לקוח" אנחנו משנים את הרזולוציה של הדיון שלנו ועוברים לדבר על צוות הפיתוח ולא על החברה כולה. 
זה מוביל אותי למשהו שחשוב לי מאוד להבהיר: לצוות פיתוח אין לקוחות. אין. אפילו לא אחד. יש לנו מעסיק ויש לנו עמיתים. השימוש בשפה של "לקוח" הוא דרך נהדרת להדגיש את העובדה שאנחנו מספקים שירות מסוג מסוים, אבל בכל הקשר אחר המינוח הזה יוצר עמימות ובלבול. "לקוח" זו מילה טעונה בהקשרים והתנהגויות, ואי אפשר להתייחס לעובדים פנימיים באותו אופן בו מתייחסים ללקוחות, אם כולם "לקוחות" המונח הזה מאבד משמעות. כשכירים אנחנו מקבלים משכורת כדי לקדם את האינטרסים של המעסיק שלנו. לא פחות ולא יותר.  לא יקצצו לי בשכר כי במשך יומיים בחודש המעסיק שלי בחר לנסות חבר צוות אחר והחוזה שחתום בין המעסיק לביני מגדיר התחייבויות שונות מאוד מאשר אלו שבין ספק שירות והלקוח שלו. ואם אני כשכיר פועל כדי לקדם את האינטרסים של המעסיק שלי, בואו נדבר עליהם לרגע - לחלק הארי של החברות יש מטרה אחת פשוטה וקלה למדידה - כסף. לחברה אכפת מהלקוח אך ורק בתור שק מזומנים מהלך - אם נשמור אותו מרוצה, אולי יותר מהכסף הזה יגיע אלינו. אז נכון, קשה מאוד ליצור מוצר רווחי שלא עונה על צורכי הלקוח, אבל המקרים הנדירים בהם הרווח (ארוך הטווח) של החברה עומד בסתירה עם טובת הלקוח, אני צריך לזכור מי משלם את המשכורת שלי ולבחור בצד של החברה. 

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

4 comments:

  1. עזוב את המינוח לקוח וקרא להם במונח השגור "אוחזי הסטייק" :-) הם ה
    Stake Holders
    הינם מכלול האנשים שהמוצר שלנו אמור להיות יעיל להם

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

    ReplyDelete
  3. Thanks!
    I must agree with you. So many times have I seen releases that were customer tailored instead of progressing the product to the desired GA level. It made us fall behind and keep on chasing our own tails.

    ReplyDelete
    Replies
    1. Thank you for the comment.
      I want to make a point clear though - I don't think there's anything wrong with releasing a customer-tailored version. It is ok to bend your product to a crooked pretzel *if* the business people took a conscious decision to do so. In many cases, it is perfectly reasonable to get some business value by releasing a lower-quality product that meets the customer needs and provides us with more time\funds to refactor that later, or even accept not fixing it ever. Product quality, like customer satisfaction, is almost never the goal - the goal is to have a successful business.

      Delete