توپولوژی تیم‌های نرم‌افزاری

مسعود بهرامی 16 اردیبهشت 1405

۱ دیدگاه

8 بازدید

اشتراک گذاری

مهندسی ساختار انسانی برای مقیاس‌پذیری نرم‌افزار

در سال‌های اخیر، مشاهده شده که سازمان‌های تکنولوژی با یک پارادوکس مواجه شدند. آن‌ها با اضافه کردن صدها مهندس، به جای افزایش سرعت، با افزایش بی‌سابقه در هماهنگی (Coordination) و پیچیدگی روبرو شدند. مشکل اصلی، کد نبود؛ مشکل، پیچیدگی شناختی (Cognitive Load)بود.

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

کتاب Team Topologies (اثر مانول پیس و متئو اسکات (Manuel Pais  و  Matthew Skelton) با این ایده مطرح شد که: ما باید تیم‌ها را طوری طراحی کنیم که بار ذهنی آن‌ها بهینه شود و مرزهای ارتباطی آن‌ها با سایر تیم‌ها مشخص و کم‌هزینه باشد. هدف، رسیدن به جریان مداوم ارزش (Continuous Flow of Value)  از طریق مدیریت وابستگی‌هاست.

الگوی اصلی تیم (The Four Team Types)

در مدل توپولوژی تیم، ما چهار نوع اصلی تیم داریم که هر کدام وظیفه و بار ذهنی متفاوتی را بر عهده دارند.

1. تیم‌های جریان خدمات (Stream-aligned Teams)

این‌ها قلب تپنده سازمان هستند. این تیم‌ها بر روی یک جریان مداوم از کار (از ایده تا مشتری) تمرکز دارند. آن‌ها یک “بازه ارزش” (Value Stream) مشخص را مدیریت می‌کنند.

• ویژگی: خودگردان، Cross-functional  (دارای تمام مهارت‌های لازم) و تمرکز بر محصول.

1. بار ذهنی: آن‌ها باید منطق بیزنس را عمیقاً بدانند، اما نباید درگیر جزئیات زیرساختی پیچیده شوند.

2. تیم‌های پلتفرم (Platform Teams)

وظیفه این تیم‌ها این است که بار ذهنی تیم‌های جریان خدمات را کاهش دهند. آن‌ها یک پلتفرم داخلی (Internal Developer Platform)  می‌سازند که تیم‌های دیگر بتوانند به راحتی از آن استفاده کنند.

• ویژگی: ارائه خدمات به صورت خودکار (Self-service).
• مثال: تیمی که زیرساخت ابری، سیستم‌های استقرار (Deployment) و ابزارهای مانیتورینگ را آماده می‌کند تا تیم‌های دیگر بدون درگیر شدن با پیچیدگی‌های زیرساخت، کد بزنند.

3. تیم‌های قابلیت (Enabling Teams)

این تیم‌ها تیم‌های متخصص هستند که برای رفع شکاف‌های دانش (Knowledge Gaps) در سازمان استفاده می‌شوند. آن‌ها کارِ انجام دادن را بر عهده نمی‌گیرند، بلکه آموزش و مشاوره می‌دهند.

• ویژگی: تمرکز بر رفع گلوگاه‌های دانش (مثلاً تیم متخصص امنیت یا تیم متخصص معماری ابری).
• مثال: اگر تیم‌های جریان خدمات در استفاده از تکنولوژی جدیدی مشکل دارند، تیم قابلیت می‌آید، آن‌ها را آموزش می‌دهد و سپس می‌رود.

4. تیم‌های تسهیل‌گر (Complicated Subsystem Teams) – اختیاری

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

• ویژگی: تمرکز بر محاسبات و الگوریتم‌های بسیار تخصصی که فراتر از توان یک تیم معمولی است.

سه الگوی تعامل (The Three Interaction Modes)

داشتن تیم‌های درست کافی نیست؛ نحوه صحبت کردن آن‌ها با هم تعیین‌کننده سرعت است.

همکاری (Collaboration): دو تیم برای مدتی طولانی روی یک هدف مشترک کار می‌کنند (مثلاً ساخت یک ویژگی جدید که نیاز به تغییرات در پلتفرم و جریان خدمات دارد). این حالت پرهزینه است و نباید دائمی باشد.

 هم‌افزایی/تسهیل (X-as-a-Service): یک تیم (معمولاً پلتفرم) خدمات خود را به صورت خودکار و بدون نیاز به تماس مستقیم در اختیار تیم دیگر قرار می‌دهد. این بهترین و مقیاس‌پذیرترین حالت است.

فاز یا انتقال (Facilitating): استفاده از تیم‌های قابلیت برای انتقال دانش به تیم‌های دیگر.

مطالعه موردی (Case Study) – سرویس B2C گردشگری (TravelJoy)

فرض کنید یک پلتفرم بزرگ گردشگری داریم که شامل رزرو پرواز، هتل، و مدیریت تور است.

ساختار تیم‌ها در TravelJoy

1. Stream-aligned Teams

• تیم Flight Booking: مسئول تمام فرآیند از جستجوی پرواز تا خرید بلیط.
• تیم Hotel Stay: مسئول رزرو، مدیریت اتاق‌ها و قوانین هتل.
• تیم User Experience: مسئول سبد خرید و پروفایل مشتری.

2. Platform Team

• تیم Cloud Infra: ارائه پلتفرم کانتینر (Kubernetes)، سیستم پرداخت یکپارچه و زیرساخت دیتابیس. هدف آن‌ها این است که تیم Flight Booking نیازی نداشته باشد بداند دیتابیس چگونه نصب می‌شود.

3. Enabling Team

• تیم Security & Compliance: آموزش تیم‌های گردشگری برای رعایت قوانین GDPR و امنیت داده‌های مشتریان.

4. Complicated Subsystem Team

تیم Dynamic Pricing: یک تیم متخصص که الگوریتم‌های پیچیده یادگیری ماشین برای تعیین قیمت لحظه‌ای (بر اساس تقاضا و آب و هوا) را توسعه می‌دهد.

چالش‌های اجرایی

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

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

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

خطر تبدیل شدن تیم پلتفرم به گلوگاه: اگر تیم پلتفرم نتواند خدمات خود را به صورت Self-service ارائه دهد، تبدیل به یک تیم تاییدکنند (Approval Team) می‌شود که سرعت را از بین می‌برد.

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