🥇ספר "איך לנהל אינטלקטואלים. אני, חנונים וגיקים"

מוקדש למנהלי פרויקטים (ולמי שחולמים להיות בוסים).

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

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

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

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

קטע. מנטליות הנדסית

מחשבות על: האם להמשיך בכתיבת קוד?

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

הישאר גמיש!

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

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

תפסיק לכתוב קוד!

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

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

עצה טובה, נכון? סוּלָם. הַנהָלָה. אַחֲרָיוּת. מילות באז נפוצות כאלה. חבל שהעצה שגויה.

לֹא נָכוֹן?

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

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

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

מה עשו מפתחים ב-20 השנים האחרונות? במהלך הזמן הזה כתבנו מלא קוד. ים של קוד! כתבנו כל כך הרבה קוד שהחלטנו שזה רעיון טוב לפשט הכל וללכת לקוד פתוח.

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

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

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

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

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

תפסיק לכתוב קוד, אבל...

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

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

יש לך התנגדויות. מבין. בואו נקשיב.

“רנדס, אני בדרך לכיסא הבמאי! אם אמשיך לכתוב קוד, אף אחד לא יאמין שאני יכול לגדול".

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

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

"אוף, רנדס! אבל מישהו צריך להיות הבורר! מישהו צריך לראות את התמונה הגדולה. אם אכתוב קוד, אאבד פרספקטיבה."

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

הטיפים שלי לשמירה על מנטליות הנדסית:

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

שוב התנגדות?

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

בסדר.

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

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

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

אל תפסיק להתפתח

עמית שלי בבורלנד תקף אותי פעם מילולית על שכינה אותה "קודנית".

"רנדס, הקודן הוא מכונה חסרת שכל! קוֹף! הקודן לא עושה שום דבר חשוב מלבד לכתוב שורות משעממות של קוד חסר תועלת. אני לא קודן, אני מפתח תוכנה!"

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

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

להיות גמיש. זכרו מה זה אומר להיות מהנדס ואל תפסיקו לפתח תוכנה.

על המחבר

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

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

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

» פרטים נוספים על הספר ניתן למצוא בכתובת אתר האינטרנט של ההוצאה לאור
» תוכן העניינים
» קטע

עבור Khabrozhiteley 20% הנחה באמצעות קופון - מנהל אנשים

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

נ.ב: 7% ממחיר הספר יועברו לתרגום ספרי מחשב חדשים, רשימת ספרים שנמסרה לבית הדפוס כאן.

מקור: www.habr.com

הספר "איך לנהל אינטלקטואלים. אני, חנונים וגיקים"