הלקוח המכסה, מנסה להסתיר או לכסות על משהו. לפני שנבין על מה הוא מנסה לכסות, אספר לכם שהוא שונה מכל סוגי הלקוחות, שהצגתי בפוסטים קודמים:
הוא אינו יודע הכל, כלומר: הוא יודע שלא רק שאינו יודע הכל, אלא שהוא יודע מעט מאד ואת זה צריך להסתיר.
הוא אינו מתבטל בפני היועץ. הוא אינו מקבל את דעתו של היועץ בחלק מהמקרים. אם דעתו של היועץ, מאפשרת כיסוי או בלשון פחות יפה מאפשרת כסת"ח, הוא כמובן יקבל אותה.
הוא אינו לקוח שבוי בידי ספק זה או אחר. גם כאן הקו המנחה הוא: הסתרה. כל עוד הספק יאפשר הסתרה, הוא ילך איתו. אם יפסיק לאפשר זאת, הוא יפעל נגד הספק. הוא יעשה זאת לפעמים באופן הבוטה ביותר.
בוודאי שאינו המנתח המשותק. יכולת הניתוח שלו ממוקדת בניתוח מצבים בהם ניתן להסתיר, בהשוואה למצבים בהם בלתי ניתן להסתיר. ניתוח הפן המקצועי הוא לא בדיוק הצד החזק שלו.
הוא עשוי להיות לקוח חברתי, אם וכאשר זה יסיע לו להסתיר. הוא יהיה אנטי-חברתי, אם וכאשר זאת תהיה הדרך היחידה לכסות על המגבלות שלו.
הוא לעולם לא יהיה הלקוח הטוב, אבל בהחלט עלול להיות הרע או המכוער.
מה מנסה להסתיר הלקוח המכסה?
הלקוח המכסה מנסה להסתיר מוגבלות שלו, חוסר ידע או חוסר יכולת (או שילוב של שניים מהם או שילוב של שלושתם).
הוא מעוניין, שיתנו לו להמשיך להתנהל, כפי שהתנהל עד כה. הוא מעוניין להמשיך לבצע טעויות (גם כשהוא יודע שהן טעויות) בלי ללמוד שום דבר חדש. לשמר את המצב הקיים לפרק זמן ארוך ככל האפשר, בלי לשפר את ההתנהלות בנושאים בהם הוא מטפל.
הוא מעוניין, שיתנו לו להמשיך להתנהל, כפי שהתנהל עד כה. הוא מעוניין להמשיך לבצע טעויות (גם כשהוא יודע שהן טעויות) בלי ללמוד שום דבר חדש. לשמר את המצב הקיים לפרק זמן ארוך ככל האפשר, בלי לשפר את ההתנהלות בנושאים בהם הוא מטפל.
כפי שכבר ציינתי בפוסט קודם, הלקוח בארגון הוא מושג מורכב. אם מדברים על הקשר של ארגון, זה יכול להיות אדם אחד או מספר אנשים ולאו דווקא קבוצה גדולה של אנשים או תרבות ארגונית. לפעמים המכסה מחזיק בתפקיד מרכזי בארגון והתוצאות הן מרחיקות לכת.
דוגמה ללקוח כזה בתחום המחשוב
לשמחתי הרבה טרם נתקלתי בלקוח כזה בייעוצים שאני מבצע בכלכלת המשפחה (לכל מאיתנו עלול להיות דפוס התנהגות חלקי כזה, אבל כשזה אינו הדפוס המוביל אלא מתייחס רק לנקודה כזו או אחרת בשוליים, אין מדובר בלקוח המכסה).
הדוגמה מתייחסת לארגון, בו יעצתי למישהו מה Business ולא מיחידת טכנולוגיית המידע. הלקוח אליו אני מתייחס אינו הארגון כלו, אלא איש מפתח בהקשר של המערכות של הלקוח העסקי, ששכר את שירותי.
הדוגמה מתייחסת לארגון, בו יעצתי למישהו מה Business ולא מיחידת טכנולוגיית המידע. הלקוח אליו אני מתייחס אינו הארגון כלו, אלא איש מפתח בהקשר של המערכות של הלקוח העסקי, ששכר את שירותי.
לא באתי רק על מנת לקבל כסף עבור עבודתי. כשאני מגיע ללקוח בתחום כלשהו (כלכלת המשפחה, טכנולוגיית המידע או כל תחום אחר), חשוב לי שהלקוח יצליח וישיג תוצאות.
במקרה זה המשמעות הייתה, שאנשי יחידת טכנולוגיית המידע יספקו ללקוח שלי מערכות, שעונות על הצרכים שלו, עובדות באופן תקין ידידותיות ונוחות לשימוש ומספיק גמישות לשינויים בעתיד.
אנלוגיה להנדסת בניין
במקום להיכנס לעומק לתפיסת העולם המקצועית של הלקוח בתחום של הנדסת תוכנה, אשתמש באנלוגיה לתחום הנדסי בוגר ובשל יותר: הנדסת בניין.
מהנדס בניין צריך לתכנן הקמת בניין חדש. למרות חוסר הידע שלי בתחום הנדסת בניין, אני מניח שהתכנון מבוסס על בנייה של היסודות ואחרי כן הקומות התחתונות ולבסוף את הקומות האחרונות.
המהנדס שלנו, מחליט לעבוד אחרת: קודם לבנות את הקומה האחרונה ואחרי כן להחליט, האם בכלל צריך יסודות וקומות מתחתיה.
כל מהנדס בניין סביר וכל ספר או מצגת מקצועית בתחום, יפסלו את הגישה המוזרה של המהנדס שלנו ויסכימו על כך, שהבנייה מתחילה ביסודות.
במקרה זה גם כל אדם סביר, שאינו מהנדס, מבין את האבסורד שבגישת המהנדס, אבל אם אתם גבר, שנחת כרגע מהמאדים או אישה, שהגיעה זה עתה מכוכב נוגה ומעולם לא ראיתם בית, ייתכן מאד, שלא תבינו את האבסורד מבלי שיסבירו לכם.
משתמשים עסקיים (בעיקר בגיל מבוגר), דומים במידה זו או אחרת לאנשים מכוכב אחר, כאשר מדובר בהיבטים טכניים של פיתוח מערכות מידע. ייתכן שהם יחשבו, שיש ויכוח אמיתי בין שתי גישות בתחום הנדסת תוכנה: בנייה מהקומה האחרונה או בנייה מהיסודות.
בחזרה למערכות מידע
הגישה של אותו לקוח מכסה, הייתה להתחיל בפיתוח הקוד, לפני ניתוח כלשהו של צרכי הלקוח.
הלקוח העסקי היה במצב לא קל: מצד אחד הוא תלוי באותו איש IT בפיתוח המערכת ובתחזוקתה לאחר שיסתיים הפיתוח. מצד שני היועץ, שהוא הביא (במקרה זה אני) מסביר לו באופן חד וברור, שמדובר בגישה שגויה ולחלוטין לא מקובלת בתעשיית טכנולוגית המידע. גישה שתגרום לכך, שהוא יקבל (שוב) מערכת, שאינה עונה על הצרכים שלו ובוודאי שלא יהיה קל להתאימה לצרכים העתידיים שלו.
החוסר שלו במומחיות וידע בתחום מערכות המידע, העמיק את הקונפליקט.
הנימוקים שלי
1. הסבר רציונלי מדוע הגישה מוטעית. תוך שימוש באנלוגיות דוגמת זו שהבאתי לעיל.
2. הארגון אימץ את נוהל מפת"ח כסטנדרט עבודה. קל לראות שנוהל מפת"ח מציג גישה זהה לשלי (גילוי נאות: הייתי שותף לכתיבת חלקים קטנים של הנוהל, לא בהקשר הנוכחי).
מהיכרותי עם נוהל מפת"ח, אני יכול להגיד שמצאתי בו כמה דברים נבונים ומקוריים. אין הכוונה להקשר של הוויכוח עם אותו לקוח מכסה. בהקשר הנ"ל, מדובר באלף בית, שכל אחד אחר, שכתב על הנושא, הציג בדיוק את אותה גישה.
ההמלצה שלי: היות שמחלקת ה IT הייתה זקוקה לחתימה פורמלית של הלקוח לאישור כל שלב בעבודה, להימנע מחתימה עד לשינוי הגישה לגישה המקובלת בתעשיית מערכות המידע.
הנימוקים של הלקוח המכסה
1. אולי במקומות אחרים עובדים כפי שהיועץ מציג, אצלנו בארגון עובדים ככה. הנימוק עושה עוול לאנשים בארגון. כמו ברוב הארגונים, גם באותו ארגון יש אנשי מקצוע טובים. אנשים רבים ביחידת ה IT של הארגון עבדו כפי שצריך לעבוד.
2. היועץ מפריע ומעכב: לא נעמוד בלוחות זמנים, ייקחו לנו תקציבים, ייקחו לנו מפתחים.
במאמר מוסגר לקוראים הבאים מתחום מערכות המידע
שלא תטעו אין כאו וויכוח בין גישות שונות בפיתוח מערכות מידע.
אין ספק שפיתוח Water Fall מתאים לגישה שלי. אבל גם בפיתוח Agile מתחילים ביסודות: הצרכים של הלקוח.
קניית מערכות מוכנות, מתחילה אף היא ביסודות: הצרכים של הלקוח. אם נתייחס לאנלוגיה של בניין, היא מבוססת על בניית היסודות והבאת מבנה טרומי מוכן וחיבורו אליהן.
כיצד מייעצים ללקוח מכסה?
הבעיה העיקרית של הלקוח המכסה, אינה השגיאות והטעויות שהוא מבצע. כל אדם עושה שגיאות. כפי שכבר כתבתי בפוסט קודם, שכותרתו: ייעוץ ואימון: דיסיפלינות משלימות או דיסיפלינות סותרות. אני מעודד מתאמנים או תלמידים לבצע דברים, גם אם יבצעו טעויות, משום שמטעויות לומדים. זאת בדיוק הבעיה של הלקוח המכסה: הוא אינו לומד מטעויות.
אל תנסו לדבר איתו על טובת הארגון, המשפחה או המערכת. הוא אינו קשוב למטרות ולצרכים האמיתיים שלהם. הוא ממוקד רק בכיסוי.
בהקשר של ייעוץ לארגון, רצוי להימנע מעבודה עם הלקוח המכסה ולנסות לעבוד מול גורם שונה ממנו במערכת. לא תמיד זה אפשרי.
הדוגמה הקלסית של הימנעות מעבודה עם לקוח מכסה היא Pilot לתפיסה חדשה, טכנולוגיה חדשה או ארכיטקטורה חדשה.
כישלון ב Pilot פירושו בדרך כלל כישלון בהכנסת הטכנולוגיה/הארכיטקטורה/התפיסה לארגון. לקוח מכסה יבטיח את כישלונכם, משום, שהמטרה שלו היא הנצחת המצב הקיים.
אנלוגיה להנדסת בניין
במקום להיכנס לעומק לתפיסת העולם המקצועית של הלקוח בתחום של הנדסת תוכנה, אשתמש באנלוגיה לתחום הנדסי בוגר ובשל יותר: הנדסת בניין.
מהנדס בניין צריך לתכנן הקמת בניין חדש. למרות חוסר הידע שלי בתחום הנדסת בניין, אני מניח שהתכנון מבוסס על בנייה של היסודות ואחרי כן הקומות התחתונות ולבסוף את הקומות האחרונות.
המהנדס שלנו, מחליט לעבוד אחרת: קודם לבנות את הקומה האחרונה ואחרי כן להחליט, האם בכלל צריך יסודות וקומות מתחתיה.
כל מהנדס בניין סביר וכל ספר או מצגת מקצועית בתחום, יפסלו את הגישה המוזרה של המהנדס שלנו ויסכימו על כך, שהבנייה מתחילה ביסודות.
במקרה זה גם כל אדם סביר, שאינו מהנדס, מבין את האבסורד שבגישת המהנדס, אבל אם אתם גבר, שנחת כרגע מהמאדים או אישה, שהגיעה זה עתה מכוכב נוגה ומעולם לא ראיתם בית, ייתכן מאד, שלא תבינו את האבסורד מבלי שיסבירו לכם.
משתמשים עסקיים (בעיקר בגיל מבוגר), דומים במידה זו או אחרת לאנשים מכוכב אחר, כאשר מדובר בהיבטים טכניים של פיתוח מערכות מידע. ייתכן שהם יחשבו, שיש ויכוח אמיתי בין שתי גישות בתחום הנדסת תוכנה: בנייה מהקומה האחרונה או בנייה מהיסודות.
בחזרה למערכות מידע
הגישה של אותו לקוח מכסה, הייתה להתחיל בפיתוח הקוד, לפני ניתוח כלשהו של צרכי הלקוח.
הלקוח העסקי היה במצב לא קל: מצד אחד הוא תלוי באותו איש IT בפיתוח המערכת ובתחזוקתה לאחר שיסתיים הפיתוח. מצד שני היועץ, שהוא הביא (במקרה זה אני) מסביר לו באופן חד וברור, שמדובר בגישה שגויה ולחלוטין לא מקובלת בתעשיית טכנולוגית המידע. גישה שתגרום לכך, שהוא יקבל (שוב) מערכת, שאינה עונה על הצרכים שלו ובוודאי שלא יהיה קל להתאימה לצרכים העתידיים שלו.
החוסר שלו במומחיות וידע בתחום מערכות המידע, העמיק את הקונפליקט.
הנימוקים שלי
1. הסבר רציונלי מדוע הגישה מוטעית. תוך שימוש באנלוגיות דוגמת זו שהבאתי לעיל.
2. הארגון אימץ את נוהל מפת"ח כסטנדרט עבודה. קל לראות שנוהל מפת"ח מציג גישה זהה לשלי (גילוי נאות: הייתי שותף לכתיבת חלקים קטנים של הנוהל, לא בהקשר הנוכחי).
מהיכרותי עם נוהל מפת"ח, אני יכול להגיד שמצאתי בו כמה דברים נבונים ומקוריים. אין הכוונה להקשר של הוויכוח עם אותו לקוח מכסה. בהקשר הנ"ל, מדובר באלף בית, שכל אחד אחר, שכתב על הנושא, הציג בדיוק את אותה גישה.
ההמלצה שלי: היות שמחלקת ה IT הייתה זקוקה לחתימה פורמלית של הלקוח לאישור כל שלב בעבודה, להימנע מחתימה עד לשינוי הגישה לגישה המקובלת בתעשיית מערכות המידע.
הנימוקים של הלקוח המכסה
1. אולי במקומות אחרים עובדים כפי שהיועץ מציג, אצלנו בארגון עובדים ככה. הנימוק עושה עוול לאנשים בארגון. כמו ברוב הארגונים, גם באותו ארגון יש אנשי מקצוע טובים. אנשים רבים ביחידת ה IT של הארגון עבדו כפי שצריך לעבוד.
2. היועץ מפריע ומעכב: לא נעמוד בלוחות זמנים, ייקחו לנו תקציבים, ייקחו לנו מפתחים.
במאמר מוסגר לקוראים הבאים מתחום מערכות המידע
שלא תטעו אין כאו וויכוח בין גישות שונות בפיתוח מערכות מידע.
אין ספק שפיתוח Water Fall מתאים לגישה שלי. אבל גם בפיתוח Agile מתחילים ביסודות: הצרכים של הלקוח.
קניית מערכות מוכנות, מתחילה אף היא ביסודות: הצרכים של הלקוח. אם נתייחס לאנלוגיה של בניין, היא מבוססת על בניית היסודות והבאת מבנה טרומי מוכן וחיבורו אליהן.
כיצד מייעצים ללקוח מכסה?
הבעיה העיקרית של הלקוח המכסה, אינה השגיאות והטעויות שהוא מבצע. כל אדם עושה שגיאות. כפי שכבר כתבתי בפוסט קודם, שכותרתו: ייעוץ ואימון: דיסיפלינות משלימות או דיסיפלינות סותרות. אני מעודד מתאמנים או תלמידים לבצע דברים, גם אם יבצעו טעויות, משום שמטעויות לומדים. זאת בדיוק הבעיה של הלקוח המכסה: הוא אינו לומד מטעויות.
אל תנסו לדבר איתו על טובת הארגון, המשפחה או המערכת. הוא אינו קשוב למטרות ולצרכים האמיתיים שלהם. הוא ממוקד רק בכיסוי.
בהקשר של ייעוץ לארגון, רצוי להימנע מעבודה עם הלקוח המכסה ולנסות לעבוד מול גורם שונה ממנו במערכת. לא תמיד זה אפשרי.
הדוגמה הקלסית של הימנעות מעבודה עם לקוח מכסה היא Pilot לתפיסה חדשה, טכנולוגיה חדשה או ארכיטקטורה חדשה.
כישלון ב Pilot פירושו בדרך כלל כישלון בהכנסת הטכנולוגיה/הארכיטקטורה/התפיסה לארגון. לקוח מכסה יבטיח את כישלונכם, משום, שהמטרה שלו היא הנצחת המצב הקיים.
כאשר מזהים דפוס כזה בייעוץ אישי או משפחתי, אי אפשר להחליף אותו בגורם אחר במערכת. החלופות העיקריות העומדות בפני היועץ הן:
א. לוותר על הייעוץ - זהו הפתרון הקל, אבל לפעמים גם הנכון.
ב. לשנות את הגישה שלו - זהו פתרון קשה. אם אתם גם מאמנים ולא רק יועצים, ייתכן שתצליחו.
אחת האפשרויות היא לחפש תחום אחר, בו נוגע הלקוח המכסה (למשל תחביב האהוב עליו) ולא את תחום הייעוץ (למשל כלכלת המשפחה) ולזהות שם דפוס התנהלות שונה (למשל: רצון ללמוד דברים חדשים ולתקן טעויות). את דפוס מהתחום האחר אפשר לנסות להרחיב גם לתחום הבעייתי.
אין תגובות:
הוסף רשומת תגובה