בפוסט אפשור מול ריסון: קרב האור באופל של ארכיטקטורת התוכנה? התפתח דיון:
- מי נכון שיקבל את ההחלטות הטכנולוגיות בארגון?
- איך זהות מקבל ההחלטות משפיעה על היחס בין ריסון לאפשור?
- ב Code Review - מה מעמדו של ה Reviewer? האם הוא יכול לחייב את כותב הפיצ׳ר לשנות דברים או שהוא רק ממליץ? האם נכון לאפשר לו לחסום הכנסה של קוד ל master?
הנה צץ לו נושא אמיתי, שהטריד כמה מקוראי הבלוג - והחלטתי להרים את הכפפה.
תייגתי את הפוסט כ [דיון] כי בניגוד לרוב הפוסטים, אין לי מתודולוגיה סדורה שאני מתבסס עליה. זה גם אינו נושא שהפכתי וחשבתי עליו רבות (אם אני כותב פוסט על כזה נושא, לרוב התחבטתי בו כבר שנים). אני כותב את הפוסט כי הנושא נראה לי מעניין, חשוב, ורלוונטי - ובעיקר בעקבות בקשות קוראים. אז בואו ניקח אותו בפרספקטיבה הנכונה.
טראומות
"לצערי נתקלתי בהמון מקרים שכל החלטה קטנה הופכת לדיון ובעיניי זה הרסני." - תגובה לפוסט.
"נושא כאוב נוסף שניתן להתייחס אליו זה code review - מה מעמדו של ה reviewer?..." - עוד תגובה לפוסט
הדיון "מי מקבל החלטות טכנולוגיות בארגון?" הוא דיון שמגיע כנראה מתוך כאב, אפילו טראומות. לכל אחד מאיתנו (מלבד הצעירים ביותר) יש סדרה של אירועים כואבים בהם הרגשנו שהחלטה כזו או אחרת פגעה בנו / בארגון, הייתה טעות גדולה או אולי חסרת הגיון ומטופשת לגמרי - אבל לא יכולנו להשפיע עליה.
אשתף בשתי "טראומות" שלי:
שעבדתי ב SAP עבדנו על מוצר וובי (Web) כלשהו, יום אחד הגיע ארכיטקט בכיר מאוד בארגון ודרש שנשכתב את כל המוצר משפת ג'אווה ל PL/QSL - על גבי בסיס הנתונים החדש ש SAP בנתה, HANA. הוא טען שהביצועים ישתפרו בצורה דרמטית, וזה יועיל למוצר - וגם כדרך אגב SAP תוכל להתנסות יותר בפיתוח משמעותי על גבי HANA, כמו שנאמר: Eat your own dog food.
הדבר הזה קרה אחרי שכבר עשינו מעבר מ MySQL ל HANA כבסיס-נתונים - ולמרות ההבטחות ספגנו פגיעות בביצועים (HANA היה מאופטם לשאילתות אנליטיות גדולות, ואת השאילתות הקטנות והממוקדות שלנו הוא ביצע בצורה פחות טובה מ MySQL).
ההתנגדות למהלך בקרב מובילי המוצר הייתה מקיר-לקיר, אבל הארכיטקט הבכיר מאוד (ומי שהוא ייצג) הכריעו - והדבר נעשה. אחרי שישה חודשים של שכתוב קוד ג'אווה ל PL/SQL (שפה גמישה הרבה פחות) שרשרת הכישלונות הייתה כל-כך ברורה וכואבת - שההחלטה התהפכה. לקח לנו עוד כחודשיים להפוך את ההחלטה (לסרוק שינויים ב PL/SQL - ולהכניס אותם חזרה לג'אווה), אבדנו 8 חודשי עבודה (של כ 50 מפתחים), והתשנו מאוד את הצוות ואת האמונה שלו בדרך. המוצר נכשל - אבל גם כנראה היה נכשל בלי קשר להחלטה הזו (לא היה לו מספיק ערך עסקי).
המקרה השני התרחש דווקא בחברת סאטראט-אפ בה רצינו, לראשונה, לבנות אפליקציית Desktop למשתמשים חצי-טכניים. ה VP R&D של הארגון דחף באגרסיביות כלי בשם Eclipse-RCP, פלטפורמת ה UI בה משתמשת Eclipse (ומיועדת לכתיבת IDEs או כלים דומים) - על סמך היכרות על הפלטפורמה מפרויקט שניהל בארגון קודם.
בחנו את הטכנולוגיות מול אלטרנטיבות יותר מקובלות (בזמנו): ממשק וובי, Java Swing, ו FORMS.NET.
Eclipse RCP דורגה מקום אחרון בסקירה, תחת הרשמים שהיא מורכבת, ומספקת כלים מוגבלים ל UI למשתמש הפשוט - אבל מנהל הפיתוח לא ויתר: הוא הזמין שני מובילים טכניים מהחברה הקודמת שלו, לשתף אותנו בניסיון שלהם ב Eclipse RCP. למרבה ההפתעה: הוא אפילו לא תיאם איתם עמדות - הם הביעו חוויה שלילית מהשימוש ב Eclipse RCP וסיפקו לנו עוד דוגמאות וטיעונים מדוע הפלטפורמה לא תהיה בחירה מוצלחת עבורנו. הם המליצו בחום להימנע.
מה אתם חושבים שהיה הצעד הבא? בחרנו ב Eclipse RCP, כמובן. אחרי חודשיים של עבודה ופידבק שלילי מהשטח - החלפנו את הפלטפורמה לטובת ממשק וובי.
המקרה השני יותר מוזר / חזק בעיני: בעוד במקרה הראשון נראה שההחלטה שירתה צורך עסקי אמיתי של החברה (HANA היא מוצר דגל של SAP, שהכניס לחברה מאות מיליונים) - גם במחיר "הקרבה" של קבוצת פיתוח / מוצר זניח אחר, במקרה השני לא היה אינטרס אחר או "גדול יותר" לחברה. ההחלטה להשתמש ב Eclipse RCP הייתה פשוט לא טובה, ולא שירתה שום צורך אמיתי נראה לעין. היא התנהלה בצורה רעה - שגרמה למעורבים (ביניהם אני) לאבד אמון בהנהלה. נכון שהנזק (האבסולוטי) היה קטן יותר: כמה אנשים שאיבדו מידה של אמון במנהל, ואולי עבודה של 2-3 מפתחים לאורך כחודשיים - התבררה כבזבוז.
מה אפשר ללמוד מהמקרים הללו?
(אני מתייחס רק לשני המקרים שתיארתי - שאני מכיר אותם היטב)
- לעתים ה"אנשים הפשוטים בשטח" מבינים טוב יותר, ויכולים לקבל החלטות טובות יותר ממנהלים בכירים.
- בכל זאת, קולם של האנשים הבכירים רם יותר - והשפעתם גדולה יותר.
- במאמר מוסגר אוסיף שזו אחת המוטיבציות של אנשים להתקדם בארגון: להתקדם בעיקר בכדי להיות מסוגלים להשפיע יותר.
- כשהטיעונים להחלטה לא נראים הגיוניים / מציאותיים - מתרחש תהליך של איבוד אמון, תהליך המלווה בתסכול וכאב, בקרב אלו שלא יכולים להשפיע עליו.
- בחדרי הישיבות ובדיונים ניתן לומר הכל - אבל מציאות-ברורה היא חזקה יותר.
- למשל: למרות כוחו הרב של מנהל הפיתוח לקבוע שימוש ב Eclipse RCP בניגוד לכל הדעות האחרות, עבודה קצרה (יחסית) בשטח - הפכה לחלוטין את ההחלטה.
- כלומר: המנהל יכול היה להכריע שננסה את השימוש ב Eclipse RCP, אבל לא באמת היה לו מספיק כח להכריח את השימוש בו לאורך זמן / ניסיון לא טוב.
אני אוסיף כמה תובנות נוספות, מכלל הניסיון שלי:
- אנשים שונים מבינים את המציאות באופנים שונים, לעתים במידה שכמעט ואינה ניתנת לגישור.
- לפעמים, התכתשויות על החלטות טכנולוגיות - נעשות באמונה שלמה, של שני הצדדים, שזה הדבר נכון לארגון. זה המקרה הטוב יותר.
- יש מקרים, לא נדירים, בהם השיקול שמנחה אנשים הוא לא באמת טובת הארגון, אלא טובתם שלהם: חשק, עניין, תחושת ביטחון ("זו הטכנולוגיה שאני מכיר", "נוח לי יותר לעבוד עם הקבוצה הזו", או "זה יקנה לי שקט מול מישהו קולני בארגון"). הרבה פעמים אלו צרכים אישיים ולא "רשעות טהורה" - אבל הגישה הזו לרוב תוביל לתוצאה (וגם אווירה) - טובה פחות. זה המקרה הפחות טוב.
- אני אתוודה, שאני לא פעם "דחפתי" החלטות טכנולוגיות על בסיס היכרות אישית שלי. רציתי שנעבוד עם כלים שאני בקיא בהם, ויהיה לי יותר מה לתרום, ויותר יכולת השפעה. רק במעט הפעמים - זה היה השיקול הנכון לארגון (כלומר: זה שאני אכיר / ארגיש בנוח עם הטכנולוגיה), ואני מנסה מאוד להימנע ולחזור על הטעות הזו.
- החלטות טכנולוגיות, על אף המאמץ להפוך אותן "למדע מדויק" - לעולם לא יהיו לגמרי כאלו. תמיד יש בהן אלמנטים של טעם אישי וניסיונות עבר סובייקטיביים, הן יוכרעו במידה על סמך יחסי-הכוחות בארגון, ובלתי-נמנע שחלק מהאנשים לא יהיו מרוצים.
- אני לא מאמין בניסיון לרצות את כולם - ואני מאמין שהן צריכות להתקבל ולהעשות, גם כשיש חוסר שביעות-רצון. כמובן שככל שחוסר שביעות הרצון גדול יותר, ומאנשים רלוונטיים יותר - נכונות ההחלטה נחלשת.
- חשוב, לתת משקל משמעותי למי שעומד "לחיות" עם ההחלטה, ולשלם בפועל על טעויות בהחלטה. למשל: אם בניתוח הטכני אופציה א' מקבלת ציון 90 ואופציה ב' ציון 70, אבל הצוות שאמור לממש את הקוד ולחיות איתו מאמין יותר באופציה ב' - סיכוי טוב שנכון יותר לאמץ את אופציה ב', משני טיעונים מאוד ענייניים:
- א. סיכוי טוב שמישהו בשטח מבין משהו שאתם לא, אפילו אם הוא לא יודע להסביר את זה בצורה טובה. (אם היה מתקשר מעולה, אולי היו מקדמים אותו והוא כבר לא היה בשטח?).
- ב. מוטיבציה היא הדלק של תעשיית התוכנה. מי שכואב את הבחירה באופציה א', יוכל בלי משים, לממש אותה בדירוג 60, בעוד את אופציה ב' שהוא מאוד מאמין בה, להביא למימוש לדירוג 80.
זו נשמעת כמו סחטנות או כוחנות, אבל זו המציאות האנושית ככל שאני מצליח להבין אותה: כך הדברים מתגלגלים בשטח ולא חכם "לטבוע בצדקנות". אנשים טובים יעשו עבודה פחות טובה שהם לא מרגישים חלק ממנה, ועבודה יותר טובה כאשר הם כן מרגישים חלק ממנה. לכן זה צריך להיות פאקטור גדול בשיקול. - המציאות חזקה יותר מכל טיעון - ולכן לעתים עדיף להתכתש בשטח מאשר באולם הדיונים. כאשר זה אפשרי, יש טעם בפשוט לנסות בשטח, ולשמור אופציות לשינוי כיוון.
- לא פעם נופתע, שבעצם אופציה שפחות האמנו בה עובדת "טוב מספיק".
- לא פעם, המציאות בשטח תשנה את דעת המתנגדים - ברוח טובה, ונוכל לפנות לדרך טובה יותר, כקבוצה מגובשת.
- הכרעה בשטח היא בשום אופן לא הסתמכות על הגורל או "הרמת ידיים". כדי להצליח בה טוב חשוב:
- לחתור בשטח למגע מוקדם וחד-משמעי, ככל האפשר, עם נקודות המחלקות.
- תיאום ציפיות לשינוי כיוון, במידה ומדדי הצלחה מסוימים לא יוכרעו.
- אפשור האופציות הטכנולוגיות (ארכיטקטורה), והפרויקטליות (לוחות זמנים) לשינוי הכיוון. אם יצאנו לניסיון בלי יכולת אמיתית לבצע שינוי כיוון אמיתי מאוחר יותר - יצאנו פשוט טיפשים. סליחה.
- ניתן אולי להסיק מכאן שעדיף "להפוך את הפירמידה" ולתת למפתחים את מירב שיקול הדעת וההחלטות בנושאים טכנולוגיים - וכך גם להשיג את מירב המוטיבציה וההיכרות עם השטח. זו שאיפה יפה, אבל אני חושב שהיא לא מתרחשת מהסיבות הבאות:
- לעתים מפתחים בשטח מבינים טוב יותר - אבל גם לפעמים לא.
- מפתחים נוטים לגלות אהבה רבה לטכנולוגיות חדשות ומדוברות - באופן שמטה יותר מדי החלטות לכיוונים פחות טובים.
- גם מפתחים לא חפים מאלמנט של קידום האינטרס האישי: "שימוש ב <באזז> ישפר את מעמדי מול חברי / קו"ח / בטחון עצמי".
- למפתחים לרוב יש הבנה פחות טובה של הביזנס, אלמנט קריטי בנכונות של ההחלטה.
- מפתחים לא פעם מפגינים חשיבה קצרת טווח / נאיבית - לגבי החלטות.
- בקיצור: הבכירים לרוב קונים את מעמדם (וקולם העדיף) בזכות האמון בהם, שהם מסוגלים לקחת החלטות טובות יותר. כמובן שיש כשלים במינויים, ולא פעם הבכיר הוא אדם שמקבל החלטות טכנולוגיות רעות באופן סדרתי.
- ניסיון וידע הם דבר להתבסס עליו בקבלת החלטות טכנולוגיות - אבל כיצד?
- אני רואה משקל משמעותי למישהו שכבר היה בסיטואציה דומה. זהו ניסיון קונקרטי.
- "שנות-ניסיון" הוא לטעמי מדד מטעה: זה חבל, אבל יש אנשים עם 10 ו 20 שנות ניסיון שהידע שלהם פחות יסודי ו/או הם מקבלים החלטות טכנולוגיות פחות טוב מאנשים אחרים עם 5 או אפילו פחות שנות ניסיון. הם עברו הרבה מערכות וחברות - אבל ספגו מזה רק מעט. מאוד הייתי רוצה לאפיין מהי קבלת החלטות טובה וכיצד רוכשים את המיומנות הזו. ניסיתי בכמה הזדמנויות - אבל זה נושא גדול.
- ברור שהמעמדות (מונח מציק באוזן) בארגון משנים גם הם. לארכיטקט או ראש צוות יהיה משקל גדול יותר - על אף שייתכן שהם לא "יספקו את הסחורה".
- ראשי צוותים, למשל, הם ה Backbone של הארגון. זה תפקיד קשה, שוחק, ולעתים - כפוי טובה. הארגון "חייב" משהו לאנשים הללו בתמורה, ולעתים זה מתבטא בסלחנות להחלטות פחות טובות שלהם. דינאמיקת ה"קח ותן" הזו נוגעת בכל מי שנותן ערך נוסף לארגון והארגון "חייב" לו. זו דינמיקה חיונית, כנראה - שיש לה צדדים פחות יפים, אך היא חשובה.
אפשור מול ריסון בהיבט של קבלת החלטות
מכאן בעצם התחלנו. אני לא בטוח שיש לי משהו משמעותי / מפתיע לומר כאן, אבל אומר את מה שיש לי - ליתר ביטחון.
אפשור מול ריסון הוא דיון סופר-חשוב ורלוונטי בהנדסת תוכנה - כל עוד מתייחסים אליו ככזה. דיון אמיתי, עם נכונות לפנות לכל צד - במידה ונגיע להבנה שזה הדבר הנכון לעשות.
אבל... לעתים אנחנו נוטים "לתפוס מחנה" בצורה גורפת, ולא ע"פ המקרה הנתון. לפעמים זה עניין של אופי (אהבת סיכונים מול שנאת סיכונים), ולפעמים עניין של פוזיציה אישית:
"אני ארכיטקט. מה הערך שלי כאן? מה אני תורם לארגון? - אהה! בזה שאני מגן על המערכת ומרסן כיוונים מסוכנים."
"אני מפתח. מה הערך שלי כאן? במה אני יכול להתבלט? - אהה! בזה שאראה לכולם כמה מהר אני מצליח לשחרר פיצ'ר".
ארכיטקט ומפתח הן הדוגמאות הקאנוניות, אבל מפתחים שונים ומנהלים בדרגות שונות - נוטים לפוזיציות שונות, בניסיון לתת ערך ולהיות משמעותיים.
אני מודע (גם מהמקומות שעבדתי בהם כארכיטקט, וגם כמפתח) מהתסכול שנוצר בקרב מפתחים בשל פעולות ריסון. אני תסכלתי אנשים לא פעם.
אני מניח שההתמודדות הנכונה ביותר היא שקיפות בהחלטות, תקשורת, ופתיחות לדיון שעשוי להיגמר בשינוי הדרך. לאנשים מאוד חשוב לדעת שיש להם אפשרות להשפיע על הדברים.
אספר גם שיש תסכול רב מפעולות אפשור. אנשים שחושבים יותר על המערכת (מתכנתים, ראשי צוותים, ואחרים) מתוסכלים לא פעם מ"קיצורי-דרך", ושינויים משמעותיים ולא צפויים שהוכנסה למערכת כחלק מאפשור. גם כאן באים אלי בטענות לא פעם: איפה אני?, ואיך אני נותן יד / מעלים עין מכאלו דברים?
חקר-מקרה: נקסט אינשורנס
"אני מוצא את עצמי די מזדהה עם התגובה הזאת. ממש הייתי שמח לקרוא מאמר/כתבה על איך צריך לקבל החלטות בצוותי פיתוח. אילו דברים הם ברמת ההחלטה של המפתח הבודד, אילו דברים צריכים לעלות לדיון מול הצוות, אילו דברים ניתן לסגור באישור בין המפתח לראש הצוות וכו׳..." - תגובה לפוסט.
ביקשו שאספר מה קורה בנקסט אינושרנס, מקום לדוגמה. כמה הסתייגויות על מה שאני עומד לספר:
- כמובן שהחברה היא לא מקשה אחד, ומה שאספר מדויק יותר באזורים מסוימים של החברה - ומדויק פחות באזורים אחרים.
- אני מספק נקודת מבט לא אובייקטיבית, כי כארכיטקט-ראשי של החברה, יש לי צד ועניין בדברים.
- אני "שולף" כאן. כל הפוסט הזה נכתב ברצף של כמה שעות, ופרטים שלא חזרתי ועיינתי בהם - יהיו פחות מדויקים ומבושלים, מנושאים שניתחתי בקפידה.
- כל מה שנכתב פה הוא על דעתי האישית בלבד, לא התייעצתי ובדקתי בכדי לנסות ולתאר את "דעת החברה".
החלטות טכנולוגיות
ברור שיש היררכיה בקבלת ההחלטות. החלטות מסוימות נסגרות ברמת הצוות, חלק מול ראש קבוצה או ארכיטקט, חלק בפורום רחב יותר של אנשי-מפתח* ממקומות שונים בארגון, ואחדות ברמת ההנהלה של ארגון הפיתוח.
* אנשי-המפתח במקרה הזה הם בעלי מעמד/סמכות אחרים (ראשי צוותים אחרים) ו/או בעלי מומחיות (מי שכתב רכיב רלוונטי, אולי איש Operations או Data Engineer שיש לו פרספקטיבה נוספת).
הפילוסופיה של הארגון היא:
- קבלת החלטות היא העצמה ופיתוח של העובד - ויש רצון לתת למפתחים לקבל החלטות בעצמם, ככל שזה יעבוד טוב.
- האחריות מוטלת בסופו של דבר על ראשי הצוותים, ראשי הקבוצות, ואף הארכיטקטים - ואחריות באה עם יכולת השפעה.
אלו שני עקרונות סותרים, אבל משרטטים גבול מטושטש כלשהו של קבלת ההחלטות: החלטה מקומית - ברמת המפתח. ככל שההשפעה של ההחלטה גדולה יותר - תתקבל בדרגים גבוהים יותר. הדרגים הגבוהים יכולים וצריכים להשפיע ואפילו במקרים חמורים - להפוך החלטות לא טובות (בהנחה שהם זיהו נכון את המצב, ורוב הפעמים הפיכת ההחלטה תעשה טוב - ולא נזק).
החופש של המפתח לקבל החלטות תלויה מאוד בראש הצוות שלו, והאמון שיש למפתח עם ראש הצוות. ראשי צוותים מסוימים יותר נוטים לסמוך על מפתחים ולתת להם את החופש בקבלת החלטות מאשר אחרים. ראשי צוותים נוטים לסמוך ולתת לחברי צוות אחדים יותר חופש על פני אחרים - זה מאוד אינדוודואלי ומקומי. באופן לא לגמרי טריוויאלי, לא תמיד המפתחים מרגישים תרומה אישית יותר אצל ראשי צוותים שנותנים יותר חופש. יש הטוענים שדווקא ראשי הצוותים שמעורבים בפרטים - הם סביבת עבודה עדיפה וטובה יותר (שוב: הסתכלות אישית).
צוותים אחראים על מיקרו-שירותים - ולכן ניתן להם חופש בעיצוב המיקרו-שירות. לחופש הזה יש גבולות, ולרוב אני (או הארכיטקטים שאיתי) הם אלו שמגבילים אותו:
- חשוב לנו ניהול Stack מינימלי של טכנולוגיות - בכדי לפשט את המערכת ולשמר את היכולת של מפתח מצוות X להבין ולשנות קוד של צוות Y. אנחנו נקשה/נאתגר בכל פעם שיהיה רצון להרחיב ולשנות את ה Stack הטכונולוגי, ונגדיר סדרת מבחנים - שיש לעבור בכדי להוסיף טכנולוגיה ל Stacks (יש לנו כמה Stacks שכאלו: Backend, Frontend, ו Data).
- כנ"ל לגבי מבנים וסגנונות עבודה. יש לנו קווים מנחים / Patterns למבנה של מיקרו-שירות (שכבות, אינטרקציה, דרך לכתוב בדיקות, איך מתבצעת תקשורת בין שירותים, דפוסים לעבודה עם בסיס הנתונים) - ואני והצוות שלי נאתגר את מי שירצה לחרוג או לשנות אותם. צריך להראות ערך / צורך ברור ומעל ספק סביר - בכדי לעשות שינוי. העיקרון המנחה הוא שמערכת אחידה יותר - תהיה מובנה וצפויה יותר לשאר הארגון.
- יש לנו תהליך של "ניסוי" בו כל אחד, בתיאום ראש הצוות, יכול לנסות טכנולוגיה חדשה / סגנון חדש באזור מוגדר. לאחר כמה חודשים של ניסיון אמור להיות שלב Go/no Go. אם קבוצת ה Reveiw השתכנה שזה שיפור ברור - מאמצים כחלק מהסטנדרט (או לעתים: סטנדרט רק למקרים ספיציפיים ומגודרים היטב.). אם צוות ה Reviewer לא השתכנע שזה מספיק טוב - הניסוי יימחק והקוד יומר לסנטדרט.
- תהליך יפה, שלא כ"כ מתנהל בפועל. יש שני מקרים ברורים בהם נכנסו כך טכנולוגיות חדשות לרוחב החברה - וגם מספר דחיות, אבל עדיין ממתינים כ 10 ניסיויים באוויר, בלי שאנחנו עושים להם תהליך רביו. כשל אישי שלי.
- לא מזמן הקמנו קבוצת עבודה להגדרת Guidelines לעבודה: אני מוביל את הקבוצה בעזרת נציג מכל מחלקת פיתוח. אנו מציעים ביחד טיוטה לסטנדרטים (שהוסכם שכארגון אנו רוצים בהם): כיצד להגדיר API, כיצד לעשות Code Review, כיצד להשתמש ב Exceptions. הטיוטה עוברת Community Review - סשנים בהם כל מפתח יכול להצטרף ולהציע שינויים, אבל הוא צריך לבוא עם "שיעורי בית" מוכנים: טיעונים ודוגמאות משכנעים. על השינויים מסכימים ברמת ה Community. לפעמים זה קל, לפעמים בהצבעה - ואחרת אני מכריע (מקרים נדירים שזה נדרש. נדרש כדי לא למרוח החלטות). מאותו שלב אנחנו מפרסמים את ה Guideline ועובדים לפיו.
- עד כמה ה Guideline תואם למציאות בפועל? לפעמים יותר, ולפעמים פחות. כשיש ויכוח בין שני צדדים - הוא כן מסמך מכריע בהחלטה. כלומר: צוות שיחליט לעבוד אחרת יכול לעשות זאת "מתחת לראדאר" עד אשר יהיה ויכוח פומבי בנושא. גם אז - ננסה להבין אם הבעיה היא חוסר-הגמישות של הצוות, או בעיה ב Guideline שנקבע.
ספציפית Code Review הוא חוזה חשוב במארג היחסים והדינמיקה של החלטות טכניות בארגון. אסכם שוב את הרקע: אנו עובדים במיקרו-שירותים בהם לכל שירות אחראי צוות מוגדר. אנחנו מאפשרים ומעודדים אנשים לשנות קוד בשירותים אחרים - אבל רק בהסכמה של הצוות שאחראי על השירות. אלו עיקרי העקרונות שלפיהם אנחנו עובדים:
- חייב להיות לפחות Reviewer אחד שמאשר את הקוד. אם מדובר בקוד של צוות אחר - חייב להיות אישור של מישהו מהצוות.
- Reviewer שלא מרגיש שיש לו משהו משמעותי לתרום ב Review יסיר את עצמו, ויוסיף Reviewer אחר במידת הצורך.
- ברוב המקרים, ה Reviewer רק מספק הצעות לכותב הקוד. הצעות יכולות להתקבל או להדחות. אנו מעודדים אנשים להיות רגישים אחד לשני, וגם לפרגן על קוד טוב - בכדי לבנות את האמון.
- Code Review בהגדרה הוא לא כלי להכתיב סגנון מועדף לאנשים אחרים. ה Reviwer נותן עצות, ורצוי שיצליח לתת אותן ממקום חברי ותומך (ולא ממקום נוזף ומתנגד).
- במידה וה Reviwer מזהה בעיה משמעותית: באג, תכנון (Design) בעייתי, או חריגה משמעותית מה Guidelines הוא מסמן את ה PR כ "Changes Required". מהשלב הזה ה PR לא יוכל להתמזג (merge) ללא הסכמה של אותו Reviewer. כלומר: אנו נותנים ל Reviewer דגל אדום להרים, שיש מאחורי סמכות - אבל הציפיה היא להשתמש בו בזהירות ובאחריות.
- מי שישתמש בזכות הזו במידה רבה מדי - יזכה להכוונה מחדש מהמנהל שלו.
- יש לנו גם שורה של עצות מה לבדוק בקוד Review, ועל מה להעיר. זה בעיקר Checklist לבודק.
סיכום
ההחלטות בארגון מתקבלות מתוך שיקולים טכניים (לא מדויקים, למרות שהיינו רוצים שיהיו כאלו) בשילוב של שיקולים ודינאמיקה ארגונית. ההכרה ב Tradeoffs המעורבים, ובכוחות הפועלים - עוזרת להבין טוב יותר את הדינאמיקה, ולקחת החלטות טובות יותר.
מה הדבר המשמעותי ביותר שאפשר לעשות בכדי לקחת החלטות טכנולוגיות טובות יותר?
כלל חשוב, לדעתי, הוא לקדש את הנוסחה: Org > Group > I.
לנסות כל הזמן לקחת החלטות שטובות לארגון, ולנסות ו"לנער" החוצה שיקולים מקומיים. זה עניין של תרבות ארגונית. בכל פעם שמישהו ייקח החלטה מקומית בוטה יותר, ויצליח בכך - כך נתרחק מהיעד.
מבחינתי, זהו שיקול מרכזי בבחירת ארגון. אני מנסה להימנע מלבחור מקומות-עבודה בהם אנשי המפתח הם צבעונים (הרבה פעמים יש בזה משהו כריזמטי), קולניים, ו"קצת משוגעים". אני נוטה לחשוב שאלו האנשים שיעשו יותר שיקולים אישיים / אמוציונליים - וירחיקו את הארגון מתרבות שמרוכזת בהסתכלות על טובת-הכלל.
אני מנסה גם לבחור ארגונים בהם סט האמונות הטכנולוגי של אנשי המפתח - דומה לשלי. עבדתי במקומות שהיה פער גדול, זו הייתה חוויה מלמדת - אבל עם פוטנציאל לתסכולים גדולים. בסופו של דבר אני מאמין שבארגון חשוב קונצנזוס על ערכי הליבה - וטוב להיות שותף לקונצנזוס.
שיהיה בהצלחה!
