טים ליסטר - מחבר שותף של ספרים

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

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

לטים יש 40 שנות ניסיון בפיתוח תוכנה; בשנת 1975 (אף אחד מאלה שכתבו את ההבראפוסט הזה לא נולד השנה), טים כבר היה סגן נשיא בכיר של Yourdon Inc. כעת הוא מבלה את זמנו בייעוץ, הוראה וכתיבה, עם ביקורים מדי פעם ב עם דוחות כנסים ברחבי העולם.

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

מיכאל אתה יכול להגיד כמה מילים על מה שאתה עושה עכשיו?

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

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

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

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

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

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

19 שנים של זריזות

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

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

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

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

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

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

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

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

כלי אנשים: 30 שנה מאוחר יותר

אולג: האם Peopleware הייתה מהפכה כמו גם המניפסט?

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

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

מיכאל האם משהו השתנה ב-30 השנים האחרונות מאז פרסום הספר?

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

כולנו חיים ב-DevOps

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

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

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

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

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

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

דפוסים ואנטי דפוסים

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

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

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

מיכאל ואכן, כל כמה זמן שמענו על כדור הכסף הבא?

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

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

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

"מהנדס devops" המיתולוגי

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

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

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

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

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

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

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

"מומחים לכל דבר"

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

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

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

סיכונים ואי ודאות

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

אולג: לזוז מהר ולשבור דברים!

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

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

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

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

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

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

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

חשיבה הנדסית למבוגרים

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

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

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

טים: בְּדִיוּק. אני חושב שהטכנאים הטובים ביותר, אם מסתכלים עליהם מקרוב, הם סוג של המנהלים שלהם. איך אני יכול לנסח את זה...

אולג: החיים שלך הם הפרויקט שלך, אותו אתה מנהל.

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

איך להיכנס לניהול סיכונים

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

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

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

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

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

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

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

מחיר התקשורת

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

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

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

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

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

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

מיכאל לך תכתוב קצת קוד!

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

אולג: מישה, אתה חושב על משהו.

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

חיים ללא משכורות

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

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

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

העצה הטובה ביותר

מיכאל אם נחזור ל"עצה הטובה ביותר", האם יש משהו שאתה אומר ללקוחות שלך שוב ושוב? יש רעיון לגבי 80/20, וכנראה כמה עצות חוזרות על עצמן לעתים קרובות יותר.

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

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

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

תרגל ניהול סיכונים!

מיכאל לדעתך, כמה ארגונים עוסקים בניהול סיכונים?

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

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

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

כן, אני שומע לעתים קרובות, "נפתור בעיות כשהן מתעוררות." בטוח שנעשה? האם באמת נחליט?

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

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

טים: בואו ללחוץ על כפתור האיפוס! לא, זה לא עובד ככה.

הערה מרכזית ב-DevOops 2019

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

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

מיכאל גם אני עובדת בייעוץ כבר שנים ומבינה היטב על מה אתה מדבר.

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

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

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

טים ליסטר יגיע עם נאום מרכזי "דמויות, קהילה ותרבות: גורמים חשובים לשגשוג"לכנס DevOops 2019, שיתקיים ב-29-30 באוקטובר 2019 בסנט פטרסבורג. ניתן לרכוש כרטיסים באתר הרשמי. אנחנו מחכים לכם ב-DevOops!

מקור: www.habr.com