קצת פחות שיחה

מתי היה ה בפעם האחרונה שקבעת פגישה והזמנת שמונה אנשים במקום שלושת האנשים שבאמת היו צריכים להיות שם פשוט כי לא רצית שמישהו ירגיש בחוץ?

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

כריסטין רוטנברג ובן מזווויטה

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

אלו הם תסמינים של מחלה שכיחה: יותר מדי תקשורת .

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

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

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

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

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

איזה מזל הוא 13 בספטמבר

העלות של תקשורת יתר בארגונים הושק על ידי פרד ברוקס בספרו משנת 1975, חודש האדם המיתולוגי . ברוקס סייע בהפעלת פרויקט OS / 360 ב- IBM, בבניית מערכת הפעלה ענקית למיינפריים של החברה. באותם ימים, מחשבים היו מכונות גדולות, מקוררות במים, ולפעמים עם זיכרון ראשי מסיבי של 256,000 בתים. OS / 360 היה ככל הנראה פרויקט התוכנה הגדול ביותר שאי פעם ניסה עד אז. וזה היה באופן מונומנטלי מאוחר.

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

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

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

ככל שהקבוצה גדולה יותר, כך היא הולכת ומחמירה. כשיש לך צוות של אדם אחד, אין לך דרישות תקשורת. אף אחד.

מזל ל-25 באוגוסט

הוסף אדם שני, ועכשיו יש לך קשר יחיד: אדם ומרי צריכים לדבר אחד עם השני מדי פעם.

עכשיו הוסף אדם שלישי, נניח, סריניבאס, ופתאום עברנו מחיבור אחד לשלוש, מכיוון שסריניבאס צריך לדבר עם אדם ומריה.

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

עבור נוטים מתמטית, הנוסחה היא שאם יש לך n אנשים בצוות שלך, יש (נ^שתיים-n) / 2 חיבורים. תרשים זה ממחיש כיצד זו הופכת לבעיה:

כפי שאתה יכול לראות, עלויות התקשורת מתחילות לעלות די מהר, עד שבצוותים גדולים כל מה שמישהו יכול לעשות הוא לתאם עם כולם - ואף אחד לא עושה שום עבודה. בשנת 2006 כתב מוישי לטווין, מתכנת לשעבר במיקרוסופט, פוסט בבלוג המתאר את השנה בה השקיע בתיאום רשימת הפריטים שתוצג בתפריט אחד ב- Windows Vista - התפריט בו אתה משתמש בכיבוי המחשב. (לִרְאוֹת Crapfest של Windows Shutdown .) לטווין הבין שלכולם 43 אנשים קולו בעיצוב תפריט אחד זה. ארבעים ושלוש! לפי הנוסחה של ברוקס, פירוש הדבר לנהל 903 חיבורים. לטווין אומר שהוא השקיע כל כך הרבה זמן במשימות תיאום, שבמשך 12 חודשים הוא הפיק פחות מ -200 שורות קוד.

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

שרון דן אדל שווי נקי

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

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

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

ג'ואל ספולסקי הוא המייסד והמנכ'ל של Fog Creek Software ומארח הבלוג הפופולרי Joel on Software. לארכיון הטורים שלו, עבור אל www.inc.com/author/joel-spolsky .