מתי צריך לשבור מבנה ארגוני

יש שלב שבו ברור שמשהו לא עובד, אבל שום שיפור מקומי לא באמת משפר.

לא עוד תהליך. לא עוד ישיבת תיאום. לא עוד “נחדד אחריות”.

בשלב הזה, הבעיה אינה איך עובדים - אלא איך הארגון מחולק.

הסימן הראשון: כל תקלה נראית אותו דבר

שוב תקלה בפרודקשן. שוב אותו דפוס:

• הפיתוח אומר: “זה לא אצלנו, זה תלוי בתשתית”
• התשתית אומרת: “הקוד מניח הנחות לא נכונות”
• המוצר אומר: “זה בכלל אילוץ עסקי”

שלוש שיחות, שלושה כיוונים, אפס בעלות אמיתית.

אם זה קורה פעם - זו תקלה. אם זה קורה כל פעם - זה מבנה.

הסימן השני: שיפורים “נתקעים בין כיסאות”

יש בעיה שכולם מסכימים שהיא חשובה: ביצועים, יציבות, אמינות.

אבל:

• היא חוצה שני צוותים
• היא לא נמצאת ב-backlog של אף אחד
• אין לה owner ברור
• וכל ניסיון לקדם אותה נדחה ל”אחר כך”

לא כי אנשים לא רוצים. אלא כי אין מקום ארגוני שבו היא אמורה לחיות.

הסימן השלישי: יותר תיאום, פחות תנועה

ככל שהארגון גדל:

• נוספות ישיבות
• נוספות שכבות אישור
• נוספות נקודות מגע

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

כשיותר אנרגיה מושקעת בלתאם מאשר לבנות - המערכת הארגונית עצמה הפכה לצוואר בקבוק.

הדוגמה המעשית

ארגון עם מערכת ליבה אחת, ושלושה צוותים סביבה:

• צוות פיתוח פיצ’רים
• צוות אמינות
• צוות תשתיות

כל אחד “עושה את העבודה שלו” בצורה מצוינת.

אבל:

• שיפור ביצועים דורש שינוי בקוד, בקונפיגורציה וב-deployment
• אף צוות לא יכול לבצע את זה לבד
• וכל שינוי דורש תיאום רוחבי ארוך

התגובה הארגונית: עוד פורום. עוד מסמך. עוד SLA.

אבל הבעיה האמיתית: המערכת דורשת בעלות end-to-end - והמבנה לא מאפשר את זה.

מתי זה כבר לא בעיית ניהול

אם ניסיתם:

• לחדד אחריות
• להגדיר interfaces
• להוסיף תהליכים
• ולשפר תקשורת

והבעיות חוזרות באותו מקום -

זה לא כשל ניהולי. זה mismatch בין המבנה לבין המערכת.

למה ארגון מחדש לרוב לא פותר

כי ארגון מחדש קלאסי:

• מזיז אנשים בין קופסאות
• אבל משאיר את אותה זרימת החלטות
• את אותם תמריצים
• ואת אותם גבולות אחריות בפועל

ואז, אחרי כמה חודשים: הבעיות חוזרות - רק עם שמות צוותים חדשים.

איך שוברים בלי לשבור הכול

שבירה נכונה מתחילה משאלה אחת: איפה הערך באמת נוצר - ואיפה הוא נתקע?

ואז:

• מגדירים יחידות סביב זרימת ערך, לא סביב מקצוע
• נותנים בעלות מלאה, לא חלקית
• ומצמצמים נקודות תיאום הכרחיות

המטרה אינה סדר מושלם. המטרה היא לאפשר למישהו אחד להגיד: “זה שלי - ואני יכול להזיז את זה”.

השורה התחתונה

לא שוברים מבנה כי הוא “לא יפה”. ולא כי הוא לא מודרני.

שוברים מבנה כש:

• בעיות מערכתיות אינן פתירות בתוכו
• אחריות מתפזרת מהר יותר מיכולת פעולה
• והארגון עצמו הפך לחסימה המרכזית.

מבט לפוסט הסיום

גם אחרי שינוי מבני, וגם אחרי פישוט,

נשארת אמת אחת:

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

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