📖قبل از طراحی نرم‌افزار، تیم‌هایتان را درست طراحی کنید

مدتی پیش مطالعه کتاب Team Topologies نوشته‌ی Matthew Skelton و Manuel Pais را شروع کردم. قبل از خواندن کتاب تصور می‌کردم قرار است با مجموعه‌ای از توصیه‌های مدیریتی درباره تقسیم نیروها، چارت سازمانی و نحوه تشکیل تیم‌های نرم‌افزاری مواجه شوم؛ اما هرچه بیشتر جلو رفتم، متوجه شدم موضوع کتاب بسیار عمیق‌تر است.

این کتاب فقط درباره این نیست که «چه تیم‌هایی داشته باشیم؟»؛ بلکه سؤال مهم‌تری مطرح می‌کند:

چطور باید انسان‌ها، تیم‌ها، معماری نرم‌افزار و جریان ارزش را طوری کنار هم قرار دهیم که کارها سریع‌تر، امن‌تر و با اصطکاک کمتر پیش بروند؟

بسیاری از مشکلاتی که در ظاهر فنی به نظر می‌رسند، در واقع از فناوری شروع نمی‌شوند. گاهی یک سیستم به این دلیل پیچیده، کند و وابسته شده که تیم‌های سازنده آن نیز به همان شکل پیچیده، جدا افتاده و وابسته سازمان‌دهی شده‌اند.

به زبان ساده، ممکن است تصور کنیم مشکل ما پایگاه داده، معماری، زیرساخت، فرایند استقرار یا ابزارهای DevOps است؛ اما ریشه اصلی مشکل در مرزهای اشتباه تیم‌ها، مسئولیت‌های نامشخص، پاسکاری‌های زیاد و ارتباطات کنترل‌نشده باشد. 😵‍💫

🏢 چارت سازمانی، واقعیت سازمان را نشان نمی‌دهد

یکی از نخستین موضوعاتی که کتاب Team Topologies به چالش می‌کشد، اعتماد بیش از حد به چارت‌های سازمانی است. چارت سازمانی معمولا تصویری مرتب، منطقی و رسمی از سازمان نشان می‌دهد؛ مدیران در بخش‌های بالاتر قرار دارند، واحدها به‌ صورت منظم زیرمجموعه آن‌ها هستند و خطوط مشخص می‌کنند هر فرد باید به چه کسی گزارش دهد، اما شیوه واقعی انجام کار در سازمان معمولا با این تصویر تفاوت زیادی دارد.

در عمل، افراد برای حل مسائل از مسیرهای غیررسمی استفاده می‌کنند؛ برای مثال، ممکن است یک توسعه‌دهنده برای رفع یک مشکل مستقیما با فردی از تیم زیرساخت، امنیت یا محصول ارتباط برقرار کند، حتی اگر در چارت سازمانی هیچ خط مستقیمی میان آن‌ها وجود نداشته باشد. کتاب توضیح می‌دهد که در هر سازمان، سه ساختار به‌ صورت همزمان وجود دارد: ساختار رسمی که در چارت سازمانی دیده می‌شود، ساختار غیررسمی که از روابط، اعتماد و میزان نفوذ افراد شکل می‌گیرد و ساختار خلق ارزش که نشان می‌دهد کار در واقعیت چگونه از یک ایده آغاز می‌شود و در نهایت به دست مشتری می‌رسد. نکته مهم این است که بهبود عملکرد یک واحد، الزاما باعث افزایش سرعت کل سازمان نمی‌شود؛ ممکن است یک تیم وظیفه خود را در چند ساعت انجام دهد، اما برای دریافت تایید نهایی مجبور باشد تا جلسه هفتگی مدیران منتظر بماند! 😅

در چنین شرایطی، سریع بودن آن تیم تاثیر چندانی بر سرعت واقعی تحویل نخواهد داشت. بنابراین، به‌جای تمرکز جداگانه بر کارایی هر واحد، باید کل جریان حرکت کار را از زمان شکل‌گیری ایده تا رسیدن ارزش نهایی به مشتری بررسی کرد و گلوگاه‌هایی را از بین برد که باعث انتظار، پاسکاری و کند شدن فرایند می‌شوند.

🪞 قانون کانوی؛ نرم‌افزار آینه سازمان است

یکی از تأثیرگذارترین مفاهیم کتاب، قانون کانوی بود.

این قانون به زبان ساده می‌گوید: معماری سیستمی که یک سازمان تولید می‌کند، بازتابی از ساختار ارتباطی همان سازمان است.

برای مثال، اگر چهار تیم کاملا جدا روی یک سیستم کار کنند، به احتمال زیاد خروجی آن‌ها نیز به چهار بخش جدا تبدیل می‌شود. اگر همه تیم‌ها برای تغییر داده‌ها به یک تیم متمرکز پایگاه داده وابسته باشند، سیستم نیز احتمالا حول یک پایگاه داده بزرگ، مشترک و وابسته شکل می‌گیرد.

این موضوع نشان داد که معماری نرم‌افزار فقط حاصل تصمیم معماران و برنامه‌نویسان نیست. مدیرانی که تیم‌ها را تقسیم می‌کنند، بودجه را تخصیص می‌دهند یا افراد را از یک تیم به تیم دیگر منتقل می‌کنند، حتی بدون نوشتن یک خط کد، روی معماری نهایی سیستم اثر می‌گذارند. به همین دلیل، طراحی سازمان و طراحی معماری نرم‌افزار را نمی‌توان از یکدیگر جدا کرد.

کتاب برای استفاده آگاهانه از این قانون، مفهوم مانور معکوس کانوی را معرفی می‌کند. در این رویکرد، ابتدا مشخص می‌کنیم دوست داریم سیستم چه معماری‌ای داشته باشد و سپس تیم‌ها و مسیرهای ارتباطی را طوری طراحی می‌کنیم که آن معماری را تقویت کنند. مثلا اگر می‌خواهیم چند سرویس مستقل داشته باشیم، اما همه تیم‌ها برای کوچک‌ترین تغییر به یک تیم مرکزی DBA وابسته باشند، ساختار سازمان با معماری موردنظر ما تضاد دارد. راه‌حل می‌تواند این باشد که مهارت‌های مربوط به پایگاه داده را وارد خود تیم‌های سازنده کنیم تا هر تیم بتواند سرویس و داده‌های خودش را مستقل مدیریت کند.

👥 تیم فقط چند نفر کنار هم نیست

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

این روش در ظاهر انعطاف‌پذیر است، اما هزینه پنهان بزرگی دارد. اعضای تیم برای اعتماد کردن، شناخت توانایی‌های یکدیگر، پیدا کردن زبان مشترک و رسیدن به هماهنگی واقعی به زمان نیاز دارند. با هر جابه‌جایی، بخش زیادی از این سرمایه انسانی از بین می‌رود. 😕

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

کتاب همچنین با اشاره به محدودیت‌های روابط انسانی و عدد دانبار توضیح می‌دهد که تیم‌های کوچک، حدود هفت تا نه نفر، شانس بیشتری برای شکل دادن اعتماد عمیق، ارتباط موثر و تصمیم‌گیری سریع دارند. بزرگ‌تر شدن بی‌دلیل تیم معمولا باعث افزایش جلسات، کانال‌های ارتباطی و سردرگمی می‌شود.

🧠 بار شناختی؛ مشکلی که معمولاً دیده نمی‌شود

یکی از بخش‌های موردعلاقه من در کتاب، بحث بار شناختی تیم بود.

ما معمولا برای برنامه‌ریزی، فقط تعداد افراد و ساعت کاری آن‌ها را محاسبه می‌کنیم؛ انگار ذهن اعضای تیم از قبل هیچ مسئولیت، نگرانی یا پیچیدگی دیگری ندارد. اما هر تیم ظرفیت محدودی برای درک فناوری‌ها، سرویس‌ها، قوانین کسب‌وکار، ابزارها و فرایندها دارد.

وقتی یک تیم هم‌زمان باید چندین زبان برنامه‌نویسی، زیرساخت، پایگاه داده، سیستم قدیمی، ابزار استقرار، فرایند امنیتی و سرویس مختلف را مدیریت کند، به‌تدریج تمرکزش را از دست می‌دهد. اعضا دائماً بین موضوعات مختلف جابه‌جا می‌شوند و در نهایت به جای تسلط واقعی، فقط تلاش می‌کنند کارها را somehow جلو ببرند! 😅

کتاب بار شناختی را به سه نوع تقسیم می‌کند:

🔸 بار ذاتی: پیچیدگی طبیعی کاری که باید یاد بگیریم؛ مثلاً دانش یک زبان برنامه‌نویسی یا فناوری مشخص.

🔸 بار اضافی: پیچیدگی‌ای که ارزش مستقیمی ایجاد نمی‌کند؛ مثل حفظ کردن ده‌ها دستور عجیب برای راه‌اندازی یک محیط تست.

🔸 بار مرتبط و ارزش‌آفرین: فشاری که صرف حل مسئله اصلی کسب‌وکار، طراحی و خلق راه‌حل بهتر می‌شود.

سازمان خوب باید تلاش کند بار اضافی را با اتوماسیون، ابزارهای ساده و پلتفرم‌های مناسب کاهش دهد تا ذهن تیم برای حل مسائل واقعی آزاد بماند. اضافه کردن مسئولیت‌های بیشتر به یک تیم بدون حذف پیچیدگی‌های قبلی، به معنای توانمندسازی نیست؛ گاهی فقط روشی محترمانه برای خسته کردن اعضای تیم است!

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

🧩 چهار توپولوژی بنیادین تیمی

یکی از عملی‌ترین بخش‌های کتاب، معرفی چهار نوع اصلی تیم است. نکته مهم این است که هدف، ساختن عنوان‌های شغلی جدید نیست؛ بلکه روشن کردن مأموریت، مرز مسئولیت و شیوه ارتباط تیم‌هاست.

🟡 ۱. تیم هم‌راستا با جریان

Stream-aligned Team

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

تیم هم‌راستا با جریان تلاش می‌کند این پاسکاری‌ها را حذف کند و مالکیت صفر تا صد را در یک تیم پایدار نگه دارد. نمونه شناخته‌شده این تفکر، قانون تیم‌های دوپیتزایی آمازون است؛ تیم‌هایی کوچک که مسئول ساخت و اجرای سرویس خودشان هستند. اصل معروف آن نیز این است:

You build it, you run it.

یعنی اگر چیزی را می‌سازی، باید مسئول رفتار آن در محیط واقعی هم باشی.

🟣 ۲. تیم توانمندساز

Enabling Team

گاهی تیم‌های جریان باید فناوری یا روش جدیدی یاد بگیرند؛ مثلا تست خودکار، امنیت نرم‌ افزار، استقرار پیوسته، معماری ابری یا مشاهده‌پذیری. اگر بخواهند همه این موضوعات را به‌ تنهایی و از صفر یاد بگیرند، سرعتشان کاهش پیدا می‌کند.

اینجا تیم توانمندساز وارد می‌شود. وظیفه این تیم انجام دائمی کار به جای دیگران نیست؛ بلکه کمک می‌کند تیم‌های دیگر سریع‌تر یاد بگیرند، موانع خود را بشناسند و در نهایت مستقل شوند.

به نظرم جالب‌ترین ویژگی تیم توانمندساز این است که باید برای بی‌نیاز شدن دیگران از خودش تلاش کند. اگر یک تیم سال‌ها برای انجام یک کار ساده به تیم توانمندساز وابسته بماند، توانمندسازی واقعی اتفاق نیفتاده است.

این تیم نباید از بالا دستور بدهد که چه فناوری‌ای استفاده شود. باید وارد مسئله واقعی تیم شود، درد آن را بفهمد، همراهش کار کند و دانش را منتقل کند. 🌱

🟠 ۳. تیم زیرسیستم پیچیده

Complicated-Subsystem Team

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

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

یعنی معیار اصلی، «قابل استفاده بودن توسط چند تیم» نیست؛ بلکه عمق تخصص و کاهش بار شناختی است.

🔵 ۴. تیم یا گروه پلتفرم

Platform Team / Platform Grouping

هدف پلتفرم این است که زندگی تیم‌های توسعه را آسان‌تر کند. تیم پلتفرم قابلیت‌هایی مانند استقرار، مانیتورینگ، ثبت لاگ، محیط تست، زیرساخت یا سرویس‌های مشترک را به شکل سلف‌سرویس ارائه می‌دهد تا تیم‌های جریان مجبور نباشند برای هر کار، منتظر پاسخ یک تیم دیگر بمانند. پلتفرم باید مانند یک محصول واقعی مدیریت شود و تیم‌های توسعه، مشتریان داخلی آن هستند. بنابراین فقط اینکه پلتفرم از نظر فنی کار کند کافی نیست؛ باید استفاده از آن آسان، مستند، قابل‌اعتماد و متناسب با نیاز کاربران باشد.

یکی از مفاهیم جالب کتاب Thinnest Viable Platform یا «کمینه‌ترین پلتفرم زیست‌پذیر» است. یعنی پلتفرم نباید از روز اول تبدیل به یک هیولای عظیم و پیچیده شود! 🐉

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

🚫 چند ضدالگوی مهم که توجهم را جلب کرد

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

تغییر نام، به‌تنهایی ساختار را اصلاح نمی‌کند. 🙂

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

وظیفه درست چنین تیم‌هایی باید ساخت قابلیت‌های سلف‌سرویس، آموزش و انتقال دانش باشد، نه انجام همیشگی مراحل تحویل به جای تیم‌های محصول. کتاب درباره کپی کورکورانه مدل اسپاتیفای نیز هشدار می‌دهد. مفاهیمی مانند Squad، Tribe، Chapter و Guild جالب‌اند؛ اما مدل اسپاتیفای یک تصویر ثابت و نسخه جهانی برای همه سازمان‌ها نبود. این ساختار نتیجه فرهنگ، شرایط و مسیر تکامل همان شرکت بود.

این بخش برایم یادآور شد که کپی کردن ظاهر یک مدل، بدون درک مسئله‌ای که آن مدل برای حلش ساخته شده، معمولاً فقط واژه‌های جدیدی به مشکلات قدیمی اضافه می‌کند.

✂️ مرزهای نرم‌افزار باید در اندازه یک تیم باشند

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

• کدام تیم مالک این بخش خواهد بود؟

• آیا آن تیم می‌تواند کل این محدوده را درک کند؟

• برای تغییر آن، به چند تیم دیگر وابسته خواهد شد؟

• آیا این مرز با دامنه کسب‌وکار هماهنگ است؟

• آیا تیم می‌تواند آن را مستقل منتشر و پشتیبانی کند؟

کتاب از مفاهیمی مانند Bounded Context در طراحی دامنه‌محور و Fracture Planes یا صفحات شکست استفاده می‌کند تا مرزهای طبیعی سیستم پیدا شوند.

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

مرز خوب مرزی است که به تیم اجازه دهد بخش خودش را با کمترین وابستگی به دیگران تغییر دهد.

🤝 آیا همه تیم‌ها باید همیشه با هم همکاری کنند؟

یکی از باورهای رایج این است که هرچه ارتباط و همکاری بیشتر باشد، نتیجه بهتر خواهد شد. کتاب این تصور را به‌طور جدی به چالش می‌کشد. ارتباط زیاد هزینه دارد؛ جلسه، هماهنگی، پیام، توضیح، انتظار و جابه‌جایی ذهنی ایجاد می‌کند. اگر همه برای انجام کارشان مجبور باشند دائما با همه صحبت کنند، احتمالا مرزها یا رابط‌های سیستم درست طراحی نشده‌اند.

کتاب سه حالت اصلی برای تعامل میان تیم‌ها معرفی می‌کند:

🤝 Collaboration — همکاری نزدیک

این حالت برای کشف مسئله‌های جدید، آزمایش فناوری تازه و پیدا کردن مرزهای مناسب مفید است. دو تیم برای مدتی با تعامل زیاد کنار هم کار می‌کنند.

مزیت آن، یادگیری و نوآوری سریع است؛ اما هزینه‌اش افزایش بار شناختی و کمرنگ شدن مرز مسئولیت‌هاست. بنابراین همکاری نزدیک بهتر است هدفمند و معمولا موقت باشد.

اگر دو تیم برای همیشه مجبور باشند روی هر موضوعی با هم همکاری کنند، احتمالا تقسیم مسئولیت یا معماری سیستم نیاز به بازنگری دارد.

🔌 X-as-a-Service — ارائه به‌صورت سرویس

در این حالت، یک تیم قابلیت مشخصی مانند API، ابزار یا پلتفرم را ارائه می‌دهد و تیم دیگر با کمترین هماهنگی از آن استفاده می‌کند.

این روش مسئولیت‌ها را روشن و تحویل را قابل‌پیش‌بینی می‌کند؛ اما فقط زمانی موفق است که سرویس باکیفیت، قابل‌اعتماد و آسان باشد.

اگر مصرف‌کننده برای هر بار استفاده مجبور باشد ساعت‌ها با تیم ارائه‌دهنده جلسه بگذارد، آن رابطه در عمل سرویس‌محور نیست.

🌱 Facilitating — تسهیل‌گری

در این حالت، یک تیم به تیم دیگر کمک می‌کند تا مانعی را برطرف کند، مهارت تازه‌ای یاد بگیرد یا روش بهتری برای انجام کار پیدا کند.

برای موفقیت این مدل، هم «کمک کردن» و هم «کمک گرفتن» مهارت می‌خواهد. تیم دریافت‌کننده نیز باید ذهن باز داشته باشد و کمک را تهدیدی برای استقلال یا تخصص خودش تلقی نکند. نوع تعامل میان دو تیم نباید برای همیشه ثابت بماند. ممکن است دو تیم ابتدا برای کشف نیازها همکاری نزدیک داشته باشند، سپس بعد از تثبیت API یا سرویس، رابطه‌شان به X-as-a-Service تبدیل شود.

حتی پژوهش‌های مطرح‌شده در کتاب نشان می‌دهند که همکاری مقطعی می‌تواند از همکاری دائمی مؤثرتر باشد؛ چون تیم‌ها هم از مزیت تبادل دانش استفاده می‌کنند و هم فرصت تفکر مستقل را از دست نمی‌دهند.

📡 سازمان باید مثل یک موجود زنده حس کند

بخش پایانی کتاب بنظرم از متفاوت‌ترین قسمت‌ها بود؛ چون توضیح می‌دهد ساختار تیمی نباید یک طراحی ثابت و همیشگی باشد.

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

برای مثال:

⚠️ اگر تیمی برای انجام کارهای ساده دائما منتظر تیم دیگری است، وابستگی مشکل دارد.

⚠️ اگر استفاده از یک پلتفرم به جلسات و توضیحات طولانی نیاز دارد، تجربه توسعه‌ دهنده ضعیف است.

⚠️ اگر نرم‌افزار برای یک تیم بیش از حد بزرگ شده، مرزها باید بازطراحی شوند.

⚠️ اگر سرعت انتشار کاهش یافته، ممکن است مشکل از خود برنامه‌نویسی نباشد و وابستگی‌های بین تیمی جریان را مسدود کرده باشند.

⚠️ اگر یک تیم زیر بار مسئولیت‌ها، ابزارها و فناوری‌های متعدد فرسوده شده، بار شناختی آن از ظرفیتش عبور کرده است.

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

💡 این کتاب چه تغییری در نگاهم ایجاد کرد؟

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

بعد از خواندن Team Topologies بیشتر متوجه شدم که معماری نرم‌افزار، فقط معماری کد نیست؛ معماری ارتباطات انسانی هم هست.

یک معماری زیبا روی کاغذ، زمانی ارزش دارد که تیم‌های واقعی بتوانند آن را بفهمند، مالک آن باشند، تغییرش دهند و در محیط واقعی اجرا کنند.

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

این کتاب به من نشان داد که:

✨ تیم باید واحد اصلی تحویل ارزش باشد، نه فرد.

✨ تیم‌های پایدار از گروه‌های موقت مؤثرترند.

✨ ارتباط بیشتر همیشه بهتر نیست؛ ارتباط باید هدفمند باشد.

✨ پلتفرم باید پیچیدگی را پنهان کند، نه اینکه پیچیدگی تازه‌ای بسازد.

✨ تیم توانمندساز باید دانش را پخش کند، نه اینکه آن را انحصاری نگه دارد.

✨ مرزهای نرم‌افزار باید با ظرفیت شناختی تیم هماهنگ باشند.

✨ ساختار تیم‌ها و نوع تعامل آن‌ها باید در طول زمان تکامل پیدا کند.

✨ معیار نهایی موفقیت، تعداد خروجی‌ها یا سرعت کدنویسی نیست؛ بلکه سرعت و کیفیت رسیدن ارزش واقعی به مشتری است.

🌟 حرف آخر

برای من مهم‌ترین پیام کتاب این بود:

برای ساختن نرم‌افزار بهتر، فقط نباید کد و فناوری را طراحی کنیم؛ باید تیم‌ها و تعاملات میان آن‌ها را نیز آگاهانه طراحی کنیم.

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

اگر به معماری نرم‌افزار، کار تیمی، DevOps، مدیریت محصول یا طراحی سازمان علاقه دارید، پیشنهاد می‌کنم کتاب Team Topologies را تهیه یا دانلود کنید و با دقت بخوانید. 📥📚

این کتاب از آن دسته کتاب‌هایی است که فقط چند مفهوم جدید به شما یاد نمی‌دهد؛ بلکه باعث می‌شود بسیاری از مشکلات قدیمی تیم و سازمانتان را با زاویه‌ای کاملاً متفاوت ببینید.

احتمالا هنگام مطالعه بارها با خودتان خواهید گفت:

«پس دلیل این همه جلسه، انتظار، پاسکاری و وابستگی در تیم ما همین بوده!» 😅

و شاید بعد از خواندن آن، نگاهتان به مفهوم تیم، معماری و حتی مدیریت سازمان برای همیشه تغییر کند. 🌱✨

اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است 🌱

نویسنده: امین مستوری نژاد

دانشجوی مهندسی نرم افزار دانشگاه شهید بهشتی

مرداد 1405