מישהו שומע אותי?
אני יודע שרבים מכם ממתינים לפוסט ההמשך לקבוצות הדיון: המקורות באינטרנט שפשוט אי אפשר בלעדיהם. אבל הפעם החלטתי להקדיש את הפוסט לבעיה כאובה: תקשורת, או יותר נכון בעיות בתקשורת.
נתקלתם פעם במהנדסים שבוחרים בטכנולוגיה חדשה ללא התייעצות מינימאלית?
הלכתם לקבוצת דיון, עלה לכם רעיון מדהים שיכול עוד חצי שנה להקפיץ את המוצר קדימה ולא ממש הצלחתם להעביר אותו הלאה?
לאף אחד בחברה אין מושג לאן הדברים מתקדמים ומהו היעד החשוב ביותר לרבעון?
כולם מתעסקים במענה לבעייה שכבר לא רלוונטית, כי במכירות שכחו לעדכן שהליד הלך, והם מתמקדים בליד אחר?
אחד המהנדסים עובד כבר יומיים על בעייה ששני מהנדסים אחרים כבר פתרו שלוש פעמים בעבר?
כולם מבטיחים שהכל בסדר עד שמגיעים לאינטגרציה הסופית וכולם מגלים שהכל ממש לא?
אם נתקלתם באחת מהסוגיות הללו, כנראה שיש לכם בעיית תקשורת בארגון, ואתם ממש לא לבד. כדי לתת תשובות קצת יותר מוסמכות ואקדמיות לבעייה הזאת נעזרתי בספר ניהול פרויקטים, תכנון ביצוע ובקרה מאת שלמה גלוברזון ואבי שטוב בהוצאת דיונון (2005). החלטתי להתמקד בפוסט זה בנושאים פנים ארגוניים, מכיוון שפנייה החוצה מחייבת הקדשת התייחסות מיוחדת.
אז מה הבעיה?
אם נתקלתם בסוגיה כזאת היא ככל הנראה נובעת מאחת הבעיות הבאות:
- בעיית תקשורת אופקית: המתכנתים שלכם לא ממש מדברים אחד עם השני, ואם הם כן, סביר שהם בעיקר עסוקים באיזו מסעדה הם הולכים לאכול בצהרים (ולא שיש משהו רע בזה).
- בעיית תקשורת אנכית: המנכ"ל בהרמת כוסית האחרונה סיפר כמה אנחנו קרובים לכבוש את השוק האסייאתי, אבל שכח לציין שה - POC הכי קריטי ברבעון הקרוב הוא באוסטריה. לחילופין הפיתוח יודע שהגרסה תקועה עמוק בבוץ, אבל בשיווק עדיין מבטיחים ללקוחות שהיא תצא בזמן.
- בעיית תקשורת אלכסונית: אתם מנסים לתקשר עם אנשי המכירות ולעקוף את הבוס... אה... אולי זאת הבעייה, אם אתם רוצים שיחתכו אתכם בחזרה, אתם כנראה בדרך הנכונה.
ממה זה נובע?
- רקע חברתי ותרבותי: חשבתם שלנהל קבוצת פיתוח בהודו זה קשה? חכו עד שתנסו לפענח מאנשי המכירות עד כמה היתה באמת מוצלחת פגישת המכירות האחרונה או שלחילופין תנסו לקבל מראש צוות בפיתוח תאריך מדוייק שהגרסה תצא בלי באגים (תוכלו לקרוא על זה מעט יותר ביומנו של איש הייטק בגלובס)
- חסמים טכנולוגיים: מי שהתנסה בעבודה בארגון מורכב המצוי בכמה אתרים וכמה מדינות (ולפעמים מספיק כמה קומות באותו בניין) יודע עד כמה שיחת פנים אל פנים קצרה יכולה לסגור אי הבנות שבקלות יכולות להתגלגל בדוא"ל חודשים.
- חסמים ארגוניים: הבוס של התפעול מסוכסך עם הרכש? צפו לבעיות קלות בגזרה וכל מיני הפתעות על הדרך.
אז איך פותרים את זה?תקשורת אנכיתלמה? המטרה של תקשורת אנכית היא מצד אחד להוריד מסרים מקודקוד הפרמידה מטה כולל הבהרת מגמות וכיוונים, גיבוש הנחות עקרוניות והגדרת הערכות לגבי הביצועים, העלות והמעטפת הרצויים, ומצד שני לחשוף את ההנהלה לאמת המרה של בשלות המוצר והטכנולוגיה.
איך עושים את זה?
- דיוני סטטוס תקופתיים: כל עוד הם לא ארוכים מדי, הם מאפשרים להציף נושאים, ולהבין לדוגמה שבאינטרגציה אף אחד לא הולך לקלוט את הגרסה, כי הם בדיוק עסוקים בדילוור של גרסה קריטית ללקוח.
- משלוח סטטוס: שונאים דיונים ארוכים? הבוס מסנן אתכם? רוצים להעביר מסר ברור וחד לעובדים שלא יהיו לו פרשנויות? דוא"ל קצר יעשה את העבודה ולא ישאיר סימני שאלה.
- פגישות מסדרון: אין כמו שיחה בפינת קפה על אספרסו טוב או כוס מהבילה של קקאו כדי לגלות את הבעיות האחרונות ולהעביר מסרים לא פורמליים.
תקשורת אופקיתלמה? המטרה של תקשורת אופקית שחרור חסמים ופתיחת צווארי בקבוק, כמו גם הקטנת תלויות ויצירת שיתוף פעולה.
איך עושים את זה?
- יציאה לימי עיון והרבה: טוב כתבתי על זה פוסט, אבל אם האנשים הולכים להרצאות (ולא רק של מיקרוסופט), הם זוכים לנקודת ראייה קצת שונה, הם נפגשים עם אנשים (נטוורקינג) ולומדים קצת מניסיון של אחרים. איך דואגים שהידע לא ישאר רק אצלהם? אצלנו כל אחד שהולך להרצאה, מעביר בעצמו לאחר מכן הרצאה של 15 דקות על הנושא לקבוצה. ההרצאה יכולה להיות תמצית של ההרצאה המקורית, הדעה שלהם על הנושא, מצגת הרבה יותר טובה שהם מצאו באינטרנט או הצגה כיצד ניתן להשתמש בטכנולוגיה במוצר שלכם.
- בקרה על הכנסת טכנולוגיה חדשה: אחד מהאנשים חזר מהרצאה וחושב ש - LINQ זאת טכנולוגיה מדהימה? מישהו קרא בדף של מיקרוסופט ש - DBML זה דבר נהדר והבאזז החדש זה משהו שחייבים להכניס למוצר? כדי להקטין סיכונים, מומלץ לקיים TechTalk: הרצאה של 15 דקות לקבוצה ע"י יוזם הרעיון, זה גם יקטין את החורים השחורים במערכת, וגם יתן אפשרות להערות ביקורתיות ואיפכא מסתברא (האם הטכנולוגיה בשלה? מה מדיניות הרישוי? בדקתם ביצועים? יש סיפורי הצלחה אמיתיים עם זה? הספק באמת מחוייב לטכנולוגיה הזאת?) מצד אחד, ויבטיח שהאדם שהולך לשלב את הטכנולוגיה הזאת באמת יודע מה הוא עושה.
- Code Review: אחת הדרכים המצויינות לפתוח צווארי בקבוק וחוסר הבנה באינטגרציה. כמובן שראש צוות יכול לעשות Core Review לחברי הצוות, אבל מה יותר מועיל מאיש שרת שעושה Code Review לאיש Client ולהיפך על קטעי קוד שהולכים לעבור אינטגרציה ביחד? זה כמו לפתור את בעיות האינטגרציה עוד לפני שהתחלתם אותה :-). כמובן שאם אתם הולכים באסרטגיה כזאת, אתם חייבים לבצע הכשרה באיך עושים Code Review נכון.
- Release Notes: אין כמו עבודה משותפת שכולם מזינים הערות לתוך ה - Release Notes כדי להציף את כל הח... החוצה.
- Wiki: תיעוד של כל המשימות, הנהלים, אוסף הבאגים והלקחים במקום אחד שכולם יכולים לתרום לו. יש כאלו שקוראים לזה Enterprise 2.0.
תקשורת אלכסונית?למה? המטרה של תקשורת אלכסונית היא להעביר מסרים לכפיפים של עמית שלכם. נפוץ מאוד בארגונים מטריציונים, אבל לא רק.
למה לא? אוהבים עקיפות סמכות? רוצים שידרכו לכם על הרגליים? רוצים לייצר שחיקה בדרג הטכני (אין כמו לתת למתכנת שסיים לפני חצי שנה אוניברסיטה לתעדף משימות של שני סמנכ"לים ובסוף לחטוף צעקות)? ותתפלאו גם בארגונים מטריציונים, האנשים בד"כ מצוותים לפרויקט לתקופה מסויימת ולא מדלגים בין 10 פרויקטים בו זמנית.
בכל זאת? הדרך לעשות את זה היא בד"כ דרך פינת הקפה.
צריכים שיעשו לכם עבודה? אוספים תכולות ומעבירים אותם כחבילה משמעותית דרך מנהל הפרויקט/הצוות.
אין עוד דרכים?אחד הבאזזים החזקים בשוק היום הוא הטמעת SCRUM. לא חייבים לעשות את זה, אבל אחד הדברים היפים בשיטה הזאת (שעוד נייחד לה כמה פוסטים) היא שני תהליכים שפותחים את התקשורת בארגון:
- ה - Stand up היומי שבו כל אחד מחברי הקבוצה מספר בכמה מילים מה הוא עשה אתמול, מה הוא הולך לעשות היום ומה החסמים. העברת המסרים הזו חושפת את חברי הקבוצה למתרחש, ומאפשרת זיהוי בעיות מהותיות ולעזור לעמית שנתקע על בעיות שהם כבר פתרו (תקשורת אופקית).בנוסף ניתן להשתמש בה כדי להעביר מסר או שניים (תקשורת אנכית).
- ה - Sprint Review וה - Sprint Analysis - בתחילת/סוף כל סיבוב, תהליך הפקת הלקחים וניתוח התרחישים (ץתקשורת אופקית) יכול וצריך לשמש גם כדי להבהיר מספר מילים על הכיוון (תקשורת אנכית). מומלץ לשתף את מנהל המוצר בתהליך כדי לפתוח גם את הסתימה הזאת.
Social
חשבתם פעם מה היה קורה אם כל פעם שמתכנת ה - iPhone שלכם היה שולח Twit על הוספת Feature? או שלאחר סיום התקנת גרסה היה עדכון בסטטוס? או שהשיווק יגלה שבבדיקת העומסים האחרונה הצלחתם לעמוד ב - 500,000 משתמשים בו זמנית על שרת אחד? לא נראה שהייתם שמחים שזה היה רץ ב - Facebook, אבל מה אם היתה לכם רשת חברתית פנימית רק לחברה? עם
Ning אפשר לעשות את זה ב - $20 לשנה אם יש לכם עד 150 איש בחברה, ו - $200 אם אתם באמת גדולים (http://about.ning.com/plans)
השורה התחתונה
מרגישים תקועים? לא מבינים אתכם? כל מה שצריך זה לפתוח את הצנרת: הרצאות, דגשים וסטטוסים (גם בדוא"ל) יעשו את העבודה. גם זה לא עוזר? אני אשמח לדסקס את זה.
יש לכם שיטות טובות יותר? יש לכם דוגמה טובה מהחיים? רוצים לשתף אותנו? הרגישו חופשי לתרום
ממשיכים לפתח,
משה קפלן
נ"ב קונספט ה - TechTalk מצא חן בעינכם? מניפסט החומוס גרם לכם לזוז בחוסר נחת? אני ממליץ לכם לעיין באתר
TechTalkIL הישראלי, שמחבר בין חברות סטארט אפ להחלפת ידע והרצאות על הנושאים החמים ביותר והכל ללא תשלום.
עדכונים ותגובות של קוראיםהטיפ של רן אדמון שתורם אספקטים מתחום הניהול המולטי דיסיפלינארי (שאינו תוכנה בלבד):
המיפוי הוא חלקי מאחר והוא ממוקד בשוק התוכנה. כאשר מרחיבים אותו לעולם המולטידיספליארי יתווסף נדבך נוסף והוא התקשורת בין דסיפלינות שונות במהותן שצריכות יחד לפתח מוצר שהדרישות אליו הן רב-תחומיות. בחקר נושא זה מגלים לפחות שתי רמות קושי - כאשר הדרישות ניתנות לשיוך לתוצר של דסיפלינה בודדת - בעית התקשורת תהייה רק בהיבט של סינכרון כל הדסיפלינות לאותו פרוייקט. אבל כאשר התוצר הוא emerged propert (כלומר התוצאה הנדרשת ע"י הלקוח נוצרת רק כאשר מספר תוצרים דסיפלינאריים פועלים יחדיו) יתווסף נדבך הקושי של תקשורת התיאום והנעת הדסיפלינות יחד להשגת תכן משותף שמספק את התכונה התוצאתית. מעבר לכך, בתעשיות רבות התוצר אינו חבילת התוכנה או המכשיר או המערכת המסופקים stand alone מפלטפורמת הלקוח ופעמים רבות הלקוח עצמו והפלטפורמה שלו (או זו שהוא מפתח במקביל) הם חלק מהפרוייקט. אירוע כזה מכפיל (אם לא יותר) את מימדי אתגרי התקשורת, הן ברמה הניהולית והן ברמה הטכנית. המקרה המסובך הוא כמובן כאשר אותם emerged properties שציינתי ומוגדרים במפרטים נוצרים רק עקב חיבור נכון בין התכולות של המפתח לבין התכולות של הלקוח שלו.
לכן, עמדתי היא שבב בבד עם ניהול הפרוייקטים, תוך שימוש בשיטות כאלה ואחרות, אסור לשכוח להנהיג את האנשים שבעשיה. כאן מדובר על החדרת התודעה לאנשים שהם accountable (ולא רק אחראים - כי עבור ישראלים המשמעות שונה) וחלק מכך הוא האחריות שלהם לממשק לזולת. האחריות לממשק ולתקשורת אינה רק של המנהלים אלא של כל אדם בארגון, כולל תחקור מידע מעמיתים אם הוא לא מגיע בזמן שצריך אותו וכולל יזימת אירוע התקשורת ועיתויו בהתאם לצרכי התכן. בעצם, סיכום הדברים מעלה הוא שלדעתי שיטות ללא חינוך והנהגה תגרומנה סה"כ להמצאת שיטות נוספות. נכון שבלי שיטה אי אפשר, אבל גם שיטה ללא מימד העומק לא תצלח.