فصل ۱: معضل چارت‌های سازمانی سنتی و توهم کنترل

بخش بزرگی از ناکارآمدی‌ها، تاخیرهای طولانی در تحویل محصول و شکست پروژه‌های فناوری در سازمان‌های امروزی، نه به دلیل ضعف فنی برنامه‌نویسان و نه به خاطر انتخاب زبان برنامه‌نویسی اشتباه، بلکه ریشه در چارت سازمانی سنتی دارد. چارت‌های سازمانی به صورت تاریخی برای کارخانه‌های عصر صنعتی و محیط‌های تیلوریستی طراحی شده‌اند؛ جایی که کارها به قطعات کوچک و قابل پیش‌بینی تقسیم می‌شدند و اطلاعات به صورت عمودی از مدیران به کارگران جریان می‌یافت. متیو اسکلتون و مانوئل پایس در آغاز کتاب تاکید می‌کنند که تلاش برای مدیریت توسعه نرم‌افزارهای مدرن از طریق خطوط گزارش‌دهی سلسله‌مراتبی، یک خطای راهبردی مهلک است؛ زیرا چارت سازمانی صرفاً نشان می‌دهد «چه کسی به چه کسی گزارش می‌دهد و بودجه را امضا می‌کند»، نه اینکه «ارزش چگونه در سازمان خلق و منتقل می‌شود».

در هر سازمان، به طور هم‌زمان حداقل سه ساختار متفاوت وجود دارد که مدیران سنتی معمولاً تنها اولی را می‌بینند: ۱) ساختار رسمی (Formal Structure) که همان چارت سازمانی است و مسئولیت‌های قانونی و انضباطی را مشخص می‌کند؛ ۲) ساختار غیررسمی (Informal Structure) که شبکه نفوذ، دوستی‌ها و ارتباطات واقعی بین افراد است؛ و ۳) ساختار خلق ارزش (Value Creation Structure) که نحوه همکاری واقعی گروه‌ها برای رساندن یک ایده به دست مشتری را نشان می‌دهد. زمانی که یک سازمان تصور می‌کند چارت سازمانی همان نقشه ارتباطی و عملیاتی است، تیم‌ها را وادار می‌کند برای هر تغییر کوچک در کد، از چندین لایه مدیریتی و کمیته‌های تایید عبور کنند.

چارت سازمانی یک توهم مدیریتی است؛ کار واقعی در سازمان‌ها نه در خطوط عمودی گزارش‌دهی، بلکه در شبکه‌های پویا و غیررسمی جریان خلق ارزش انجام می‌شود.

یکی از بزرگ‌ترین سوءتفاهم‌ها در مدیریت مدرن این است که «هرچه ارتباطات در سازمان بیشتر باشد، بهتر است». نویسندگان با قاطعیت این باور را به چالش می‌کشند. در سیستم‌های پیچیده مهندسی، ارتباطات بدون مرز و تعریف‌نشده نه تنها نشانه سلامت سازمان نیست، بلکه علامت یک معماری معیوب و مرزهای مسئولیتی مبهم است. وقتی برای افزودن یک قابلیت ساده به محصول، همه تیم‌ها مجبورند با همه تیم‌های دیگر جلسه بگذارند، سازمان درگیر «ترافیک ارتباطی فلج‌کننده» شده است. هدف توپولوژی‌های تیمی این نیست که ارتباطات را به حداکثر برساند، بلکه می‌خواهد نیاز به ارتباطات پرهزینه و هماهنگی‌های مداوم بین‌تیمی را به حداقل ممکن کاهش دهد و ارتباطات باقی‌مانده را هدفمند، شفاف و کم‌اصطکاک کند.

در دهه‌های گذشته، معماران نرم‌افزار در برج عاج خود می‌نشستند و نمودارهای معماری ایده‌آل را روی کاغذ رسم می‌کردند، بی‌آنکه توجهی به ساختار تیم‌هایی داشته باشند که قرار است آن معماری را بسازند. نتیجه این شکاف، سیستم‌هایی بود که روی کاغذ ماژولار به نظر می‌رسیدند اما در عمل به گلاف‌های درهم‌تنیده کد (Big Ball of Mud) تبدیل می‌شدند. اسکلتون و پایس توضیح می‌دهند که با ظهور معماری‌های میکروسرویس، رایانش ابری و جنبش DevOps، صنعت فناوری دوباره به حقیقتی رسید که ملوین کانوی در سال ۱۹۶۸ بیان کرده بود: ساختار ارتباطی سازمان، مستقیماً شکل و معماری خروجی فنی آن سازمان را دیکته می‌کند.

مشکل دیگر سازمان‌های سنتی این است که با تیم‌های نرم‌افزاری مانند «پردازنده‌های مکانیکی» رفتار می‌کنند که می‌توان بی‌نهایت پروژه، دامنه کسب‌وکار و فناوری را به آن‌ها تحمیل کرد. وقتی یک تیم هم‌زمان مسئول نگهداری از سه سیستم قدیمی، توسعه دو سرویس جدید، پاسخگویی به تیکت‌های پشتیبانی و یادگیری زیرساخت ابری می‌شود، ظرفیت ذهنی یا بار شناختی (Cognitive Load) تیم سرریز می‌کند. تیمی که دچار سرریز شناختی شود، دیگر توانی برای تفکر معماری، کیفیت کد و نوآوری ندارد و به حالت بقا و واکنش‌های تدافعی فرو می‌رود.

رویکرد «توپولوژی‌های تیمی» در پاسخ به این بحران‌ها متولد شده است. این رویکرد یک مدل ایستا و نسخه‌ای واحد برای همه شرکت‌ها نیست، بلکه یک زبان مشترک و چارچوبی تکاملی برای طراحی سازمان‌های فناوری است. این چارچوب بر چهار اصل استوار است: قرار دادن تیم به عنوان واحد اتمی تحویل ارزش، هم‌راستاسازی معماری سیستم با مرزهای تیمی از طریق قانون کانوی، محدود کردن مسئولیت‌های تیم متناسب با ظرفیت شناختی انسان، و تعریف صریح حالت‌های تعاملی میان تیم‌ها.

سازمان‌هایی که طراحی تیم‌های خود را به شانس یا سنت‌های اداری می‌سپارند، در واقع معماری نرم‌افزار و سرعت کسب‌وکار خود را به دست تصادف سپرده‌اند.