Post by Dekel Asaf

חלק מסדרת "תובנות שלקחתי מטק ג'ים מחזור חמישי" 💡 שינוי מבנה ארגוני הוא ה-Refactoring היקר ביותר שתעשו בארגון הפיתוח. אנחנו רגילים לנהל חוב טכנולוגי, אבל מתעלמים מחוב מבני (Structural Debt). התוצאה: צווארי בקבוק, אחריות מפוזרת, תלויות מיותרות, וצוותים שממשיכים להתקיים בגלל החלטות עבר, הרבה אחרי שהצורך העסקי השתנה. הנה כמה תובנות ישירות על עיצוב ארגוני מנקודת מבט של System Design: * חוב מבני מתיש את האנשים שלכם: אם אתם פותרים בעיות במבנה הארגוני על ידי הוספת עוד פגישות סנכרון ותיאום - האנשים הטובים שלכם יישחקו. מצד שני, אם תנסו לפתור בעיה פרסונלית ספציפית באמצעות Reorg, אתם לא פותרים את הבעיה, אלא רק מזיזים אותה למקום אחר. * חוק קונוויי (Conway's Law) מכתיב את הדליברי: ארכיטקטורת המוצר שלכם היא תמונת מראה של מבנה התקשורת בארגון. אם הכרזתם על צוות כ"אחראי מקצה לקצה", אבל בפועל הידע, כלי המדידה וההרשאות יושבים מחוץ לצוות - הוא לא באמת עצמאי, והדליברי יתעכב. * AI משנה את מאזן המומחיות: כלי AI מאפשרים לצוותים אורגניים לבצע משימות שבעבר דרשו התערבות של צוותי מומחים (כמו DevOps, ניתוח קוד או אוטומציות). כתוצאה מכך, תפקידם של צוותי רוחב חייב להשתנות מביצוע פעולות עבור אחרים, לאספקת תשתיות ו-Guardrails, כדי לא להפוך לצוואר בקבוק. טעויות נפוצות שכדאי להפסיק לעשות: * לעשות Reorg כדי לפתור בעיית מנהלים או קשיי תקשורת. * לפצל צוותים לפי שכבות טכנולוגיות שלא תואמות את הצרכים המוצריים. * לשנות מבנה כל שבועיים ולקרוא לזה "אג'יליות". * לאמץ מודלים (כמו Team Topologies) כתבנית עיוורת, בלי להבין את ההקשר והמחיר הארגוני. השורה התחתונה: לפני שאתם מזיזים קוביות בתרשים הארגוני, הגדירו במדויק: איזה KPI עסקי המבנה החדש יתקן? אילו תלויות הוא יסיר? ואיפה יישב הידע הקריטי? שינוי מבנה אמיתי מתחיל מפתרון של בעיה עסקית או תפעולית ברורה, לא מהדחף לסדר מחדש את הטבלה.