הארגון הוא חלק מהמערכת (גם אם לא כתבת עליו שורה)
הארגון הוא חלק מהמערכת (גם אם לא כתבת עליו שורה)
כשמהנדסים מדברים על “המערכת”, הם מתכוונים בדרך כלל לקוד.
לשירותים. ל-APIs. לזרימות נתונים.
אבל בפועל, המערכת האמיתית רחבה יותר.
היא כוללת גם את מי שמפתח, מי שמאשר, מי שמפחד לשנות, ומי שמשלם את המחיר כשמשהו נשבר.
האשליה: אפשר להפריד בין טכני לאנושי
קל להאמין ש יש שכבה טכנית “טהורה”, ומעליה שכבה ארגונית “מלוכלכת”.
שאם רק נכתוב קוד נכון, נוכל לבודד את עצמנו מרעש אנושי.
במציאות זה לא עובד כך.
כל החלטה טכנית היא גם החלטה אנושית:
- מי צריך לאשר שינוי
- מי נושא באחריות לתקלות
- מי מתוגמל על מהירות, ומי על יציבות
- ומי בכלל רשאי לומר “לא”
הבחירות האלו נחרטות במערכת בדיוק כמו כל שורת קוד אחרת.
דוגמה פשוטה: למה פעולה אחת הופכת לשלוש קריאות
יש במערכת פעולה בסיסית: עדכון סטטוס של ישות.
במקור, זה היה שירות אחד, קריאה אחת.
עם הזמן נוספו עוד שני שירותים:
- אחד “רק כדי לאשר”
- אחד “רק כדי לתעד”
למה זה פוצל?
לא כי היה צורך טכני. לא בגלל סקייל. ולא בגלל ביצועים.
אלא כי:
- האישור היה באחריות צוות אחר
- התיעוד היה באחריות צוות שלישי
- ואף אחד לא רצה להיות זה ש”שובר” לאחרים משהו
וכך, פעולה אחת פשוטה הפכה לשרשרת:
שירות → שירות → שירות
עם retries. עם timeouts. ועם אחריות שמתפזרת בין כולם.
כשהשינוי הבא מגיע, כולם מסכימים ש”זה מסובך” - אבל אף אחד לא זוכר למה זה התחיל ככה.
הקוד נראה טכני. הסיבה היא אנושית.
איפה רואים את הארגון בקוד
לא צריך להכיר תיאוריה כדי לזהות את זה.
מספיק להסתכל על:
- שירותים שמתקשרים דרך רשת במקום דרך פונקציה
- שכבות “תיאום” עבות שלא מוסיפות לוגיקה
- קוד שאף אחד לא נוגע בו למרות שהוא קריטי
- בדיקות שלא נכתבות כי “זה מסוכן מדי”
אלה לא תקלות טכניות. אלה סימנים למבנה אנושי.
למה זה מחמיר עם הזמן
במערכות קטנות, פערים אנושיים נספגים.
במערכות גדולות, הם מצטברים.
כל חיכוך קטן הופך ל: עוד retry, עוד workaround, עוד חריג.
לא כי המהנדסים פחות טובים - אלא כי המערכת כבר משקפת מערכת יחסים מורכבת בין אנשים.
נקודת המפנה למהנדסים מנוסים
בשלב מסוים בקריירה, מהנדסים טובים מפסיקים לשאול:
“איך מתקנים את זה בקוד?”
ומתחילים לשאול:
“איזה מבנה אנושי יצר את זה?”
זו לא בריחה מאחריות טכנית. זו הרחבה שלה.
כי במערכות גדולות באמת, אי אפשר לתקן את האחד בלי להבין את השני.
השורה התחתונה
הארגון אינו “רקע” למערכת. הוא חלק ממנה.
מי שמתכנן, מפתח או מתחזק מערכת בלי להבין את ההקשר האנושי שלה - בונה פתרון חלקי בלבד.
והמערכת תזכיר לו את זה, שוב ושוב, בדיוק ברגעים הכי לא נוחים.
מבט קדימה
אם הארגון הוא חלק מהמערכת - עולה שאלה מטרידה:
מה קורה כשמבנה ארגוני לא מאפשר קבלת החלטות בזמן?
בפוסט הבא נעסוק בשאלה: איך מתקבלות החלטות כשהמערכת חיה, אבל אין תמונה מלאה.
📚 פוסטים נוספים בסדרה: הנדסה בקנה מידה אנושי
- חלק 2 תמריצים חזקים יותר מארכיטקטורה
- חלק 3 Ownership כחרב פיפיות
- חלק 4 תהליכים שנולדו לסקייל, אבל הורגים תגובתיות
- חלק 5 למה "יישור קו" הוא מושג מסוכן
- חלק 6 הנהגה שמאפשרת טעויות, לא מונעת אותן
- חלק 7 למה ארגונים מתקשים ללמוד
- חלק 8 מתי לארגון אין יותר capacity לשיפור
- חלק 9 מתי צריך לשבור מבנה ארגוני
- חלק 10 הנדסה היא מערכת חברתית
- חלק 11 מה בעצם למדנו על הנדסה בקנה מידה אנושי