יום שלישי, 30 בדצמבר 2008

שנה של ניהול - סיכום 2008

כמו בכל שנה, אני אוהב לכתוב בסופה מה עבר עלי, מה למדתי ומה הייתי רוצה לשנה הבאה. בתחום הניהול היתה לי שנה עמוסה עם מספר רב ביותר של פרוייקטים (בשיא ניהלתי בסביבות 10 פרוייקטים בו זמנית, צוותים שונים, טכנולוגיות שונות, מיקום גיאוגרפי ושיטות פיתוח שונות). התמזל מזלי לעבוד עם אנשים טכניים חזקים מאוד, מנוסים מאוד, וכם עם אנשים חדשים, סטודנטים, בפרוייקטים של מוצרים, אתרים, וכדומה. בנוסף התנסיתי בפיתוח מוצר, ניהול עסקי, מכירות, יעוץ בגיוס, וכדומה. שנה מלאה.

חוץ מהתוכן עצמו, שהיווה בית ספר מצויין, מה למדתי על ניהול בזמן הזה?

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

סה"כ אני מרוצה מהתפקוד, פחות מכמה תוצאות, יותר מאחרות, אבל אלו החיים, you win some, you loose some. אני רק מקווה שיצא לי לכתוב יותר בשנה הבאה, על כל הדברים האלה ואחרים..

יום ראשון, 23 בנובמבר 2008

ניהול תחת לחץ - בוא נשמע את הסטטוס

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

יצא לי לעבוד לאחרונה במספר פרוייקטים שכללו 3 שעות (3-4 פגישות של חצי שעה עד שעה כל אחת, ועוד עדכונים שוטפים) של דיווחים. עם לא היו שעות נוספות, זה כמעט חצי יום עבודה שנעלם למטרת דיווחים על למה העבודה לא מתקדמת מהר מספיק.. ברור כשמסתכלים על זה ככה זה נראה מגוחך, אבל למה באמת זה קורה?

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

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

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

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

כדי לסכם, כמה נקודות שעל הצוות הטגני לעשות:

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

על הצוות המנהל לעשות:

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

יום שלישי, 4 בנובמבר 2008

נראות (visibility) של עובדים

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

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

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

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

איך משיגים נראות?

  • שולחים סטטוס קבוע (לא חד פעמי) על דברים חשובים, עדיף לפני שהמנהל מבקש. חושב מאוד שהסטטוס יהיה קבוע מתחילת הטיפול בבעיה (או מהרגע שהיא הפכה לחשובה) על הסיום, לא קטעים מסויימים. המנהל חייב לסמוך על הדיווח שלכם.
  • האימיילים שלכם צריכים להיות ברורים. המנהל קורא הרבה תכנים והרבה סטטוסים, ולא תמיד מבין תוך שנייה על מה מדובר. אם אתם מוסיפים למנהל עוד עבודה ("לך אחורה ותקרא על מה מדובר") אתם אולי צודקים, אבל אתם רק גורעים מכמות הזמן שהמנהל שלכם יכול לטפל בכם. הסבירו מה המצב, מה הבעיה, ומה הסטטוס הנוכחי - אם שום דבר לא ממש השתנה, לא קורה שום דבר אם אתם עושים copy&paste, בשביל זה המציאו את זה.
  • דברו בישיבות על מה אתם עושים - בין אם זו ישיבה שבועית או scrum יומי. אל תנסו להעביר את הזמן שלכם - הוא שלכם, תשמתשו בו.
  • דברו גם במטבח, בצהריים, מתי שאפשר ונוח - על מה עשיתם, מה ראיתם. אף פעם אי אפשר לדעת מי שומע ואיך זה ישחק לטובתכם.
  • הגיבו מהר - אם המנהל שלכם מבקש משהו - מהירות התגובה חשובה - אתם נראים מקצועיים יותר (לא הייתם צריכים ללכת לחפש אחרי התשובה), שירותיים יותר (כן, גם מתכנתים הם נותני שירות) וזמן התגובה גם מרמז על אופי העבודה שלכם.

איך לא להשיג נראות? אל תשלחו אימייל בלילה רק כדי להראות שהייתם עד מאוחר. צוותים טובים עובדים לפי תפוקה, ולא בהכרח לפי שעות. אני תמיד זוכר את החבר'ה שהיו מגיעים 5 שעות אחרי בבוקר (כן, היו תקופות שהייתי מגיע ב6 בבוקר לעבודה), ויוצאים שעה אחרי - רק כדי לשלוח מייל שאומר שהם לבד בעבודה. אל תשלחו רק מיילים שאנשים מודים לכם על עבודה טובה (למרות שזה חשוב) - בלי לשלוח את כל השירשור לפני זה. אם אתם רוצים שידעו מה אתם עושים תשתפו אנשים בשירשורים החשובים (כנראה שאני כמנהל ממילא רוצה לדעת על שירשור חשוב) ואני כבר אראה את התודות שאתם מקבלים ואת הדרך שבה אתם עובדים.

יום רביעי, 2 בינואר 2008

Most Popular Stories 2007 — HBS Working Knowledge

 

An excellent link that shows the best management related stories from HBS (Harvard Business School) this year. I greatly appreciate these articles and getting the best of 2007 is awesome.

Most Popular Stories 2007 — HBS Working Knowledge