מה בעצם למדנו על הנדסה בקנה מידה אנושי
מה בעצם למדנו על הנדסה בקנה מידה אנושי
הסדרה הזו לא ניסתה ללמד טכניקות. היא ניסתה לשנות זווית ראייה.
לא לשאול איך כותבים קוד טוב יותר - אלא למה קוד סביר מתנהג רע בתוך ארגון אמיתי.
זה מה שהתבהר, פוסט אחרי פוסט.
פוסט 1 - ארגונים כותבים קוד, גם בלי לגעת בו
מה לקחנו: מבנה ארגוני אינו “רקע” למערכת - הוא חלק מהלוגיקה שלה. Latency, coupling וכשלים אינם רק תוצאה של החלטות טכניות, אלא של מי מחליט, מי מאשר, ומי לא מדבר עם מי.
מרגע שרואים את זה - קשה יותר להגיד “זו רק בעיה טכנית”.
פוסט 2 - תמריצים חזקים יותר מארכיטקטורה
מה לקחנו: אנשים לא בונים את המערכת הטובה ביותר - הם בונים את המערכת שמתגמלת אותם עליה.
KPI “טוב” יכול לייצר מערכת גרועה, וצוותים יכולים לבצע עבודה מושלמת על מטרה שגויה.
זה לא כשל מוסרי - זה כשל תכנוני.
פוסט 3 - Ownership כחרב פיפיות
מה לקחנו: Ownership מגן על מערכת - אבל גם מייצר אזורי עיוורון.
“לא שלי” הוא לעיתים המקום המסוכן ביותר במערכת. יותר בעלות לא מבטיחה יותר אחריות, ולפעמים היא רק מקשיחה גבולות.
פוסט 4 - תהליכים שנולדו לסקייל, אבל הורגים תגובתיות
מה לקחנו: Approval אחד נוסף אולי “בטוח”, אבל שרשרת אישורים היא לעיתים זו שיוצרת את הבעיה.
תגובה מהירה והכרחית לא נמנעת בגלל קוד - אלא בגלל תהליך.
פוסט 5 - למה “יישור קו” הוא מושג מסוכן
מה לקחנו: יישור מלא הוא אשליה, ולפעמים הוא בדיוק מה שהורג מערכת חיה.
חיכוך, אי-הסכמה וקונפליקט אינם תקלות - אלא מנגנוני בקרה.
ארגון בלי חיכוך הוא ארגון עיוור.
פוסט 6 - הנהגה שמאפשרת טעויות, לא מונעת אותן
מה לקחנו: כשל אינו האויב. פחד הוא האויב.
ארגונים שמכוונים ל”אפס תקלות” מקבלים פחות למידה, יותר הסתרה, וקוד זהיר מדי - עד שהוא נשבר.
בגרות אינה מניעה של טעויות, אלא קיצור זמן ההתאוששות מהן.
פוסט 7 - למה ארגונים מתקשים ללמוד
מה לקחנו: ידע כמעט תמיד קיים. הבעיה היא שהוא לא זז.
Postmortems לא נכשלים בגלל פורמט - אלא כי אין מנגנון שמתרגם תובנה מקומית לשינוי מערכתי.
פוסט 8 - מתי לארגון אין יותר capacity לשיפור
מה לקחנו: יש נקודה שבה עוד אנשים, עוד תהליכים, עוד יוזמות - רק מחמירים את המצב.
Capacity אינו כוח אדם. הוא מרווח קוגניטיבי וארגוני.
בגרות היא לדעת מתי לעצור, לפשט, ולהפסיק “לשפר”.
פוסט 9 - מתי צריך לשבור מבנה ארגוני
מה לקחנו: לפעמים המבנה עצמו הוא הבעיה.
לא כל דבר ניתן לפתור באיטרציה. יש רגעים שבהם שינוי כואב עדיף על אופטימיזציה עדינה של משהו שבור.
השורה התחתונה של כל הסדרה
הנדסה אינה מתרחשת בקוד בלבד. היא מתרחשת בין אנשים.
בין:
- תמריצים למבנה
- תהליכים למציאות
- פחד ללמידה
- ואחריות לבעלות
ומי שמתעלם מהשכבה הזו - יתכנן מערכות שבסופו של דבר ישברו בדיוק במקום האנושי ביותר.
מחשבה אחרונה
מהנדסים בוגרים אינם רק כותבי קוד. הם קוראי מערכות.
הם שואלים:
- למה זה באמת קורה כאן
- איזה מבנה מייצר את ההתנהגות הזו
- ואיפה שינוי קטן מחוץ לקוד ישפיע יותר מאלף שורות חדשות
זו הנדסה בקנה מידה אנושי.
📚 פוסטים נוספים בסדרה: הנדסה בקנה מידה אנושי
- חלק 1 הארגון הוא חלק מהמערכת (גם אם לא כתבת עליו שורה)
- חלק 2 תמריצים חזקים יותר מארכיטקטורה
- חלק 3 Ownership כחרב פיפיות
- חלק 4 תהליכים שנולדו לסקייל, אבל הורגים תגובתיות
- חלק 5 למה "יישור קו" הוא מושג מסוכן
- חלק 6 הנהגה שמאפשרת טעויות, לא מונעת אותן
- חלק 7 למה ארגונים מתקשים ללמוד
- חלק 8 מתי לארגון אין יותר capacity לשיפור
- חלק 9 מתי צריך לשבור מבנה ארגוני
- חלק 10 הנדסה היא מערכת חברתית