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

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

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

Marty Cagan (نویسنده کتاب Inspired) یه جمله معروف داره:

محصول عالی نتیجه‌ی کار تیم‌های کوچک کراس فانکشناله (Cross-functional Team)، نه نتیجه‌ی هندآف‌های (Handoff) بی‌پایان بین تیم‌های تخصصی.

مدل سیلویی (Silo Teams) چیه؟

به جرئت میشه گفت، مدل سیلویی یکی از رایج‌ترین ساختارهای تیمی توی شرکت‌ها/سازمان‌هاست؛ مخصوصاً جاهایی که می‌خوان همه‌چیز «مرتب» به نظر برسه. توی این مدل، تیم‌ها نه بر اساس محصول یا فیچر، بلکه صرفاً بر اساس تخصص دسته‌بندی می‌شن: برای مثال اگه بخوایم یه شرکت با ابعاد کوچیک رو بررسی کنیم که درک مطلب برامون ساده‌تر بشه شرکتی رو فرض کنید که یه تیم 3 نفره برنامه‌نویس Front-end، یه تیم 2 نفره برنامه نویس Back-end و همینطور یه تیم 2 نفره هم به عنوان طراح UI/UX داشته باشه. توی این شرکت احتمالا ظاهر کار اینجوریه که «هر کسی کار خودش رو بلده»، اما توی عمل اتفاقی که میفته بیشتر شبیه پاس‌کاری بی‌پایانه


توی این شرکت جریان کار معمولاً اینطوریه:

1. مدیر محصول یه ایده میده.
2. تیم دیزاین میره ریسرچ می‌کنه و خروجی (Figma، Prototype) میده.
3. تیم بک سرویس‌ها و API رو می‌سازه.
4. تیم فرانت پیاده‌سازی رابط کاربری رو شروع می‌کنه.
5. آخر سر همه می‌افتن به وصله‌پینه کردن کارها.

به ظاهر مرتب، اما توی عمل این مدل پر از باگ و تاخیره.

کتاب Team Topologies دقیقاً همینو توضیح میده:

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

مشکلات مدل سیلویی مو به مو

بیاید خیلی شفاف بگیم در صورت استفاده از مدل سیلویی احتمالا چه بلایی سرمون میاد:

• هندآف‌های (Handoff) بی‌پایان؛ دیزاین کارشو میده به فرانت، فرانت گیر می‌کنه چون API آماده نیست، بک میگه طراحی منطقی نیست و همه توپ رو میندازن تو زمین هم.
• کندی توسعه؛ هر تیم منتظر تیم قبلی می‌مونه و تحویل فیچرها چند برابر کندتر میشه.
• سوءتفاهم بین تیم‌ها؛ طراح چیزی می‌کشه که فنی نیست، بک چیزی می‌سازه که نیاز فرانت رو جواب نمیده و آخر سر فرانت باید وصله‌کاری کنه.
• انگیزه پایین؛ تیم‌ها توی جزیره خودشون گیر می‌کنن و حس «ما یک محصول می‌سازیم» از بین میره. همه فقط وظیفه تخصصی خودشونو می‌بینن.
• مسئولیت گنگ در ریسرچ؛ وقتی ریسرچ رو فقط مال تیم دیزاین بدونیم، بخش فنی و بیزینسی حذف میشه و خروجی ناقص درمیاد.

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

Nielsen Norman Group در این مورد میگه:

User Research فقط بخشی از تحقیقات محصوله. برای موفقیت، باید با ریسرچ فنی و بیزینسی ترکیب بشه.

مدل کراس فانکشنال (Cross-functional Teams): راه‌حل مدرن

برخلاف مدل سیلویی که همه‌چیز رو جزیره‌ای می‌کنه، توی مدل کراس فانکشنال همه تخصص‌ها دور یک میز جمع می‌شن. مثلا همون تیم ۷ نفره که بالاتر در موردش صحبت کردیم (۳ فرانت + ۲ بک + ۲ دیزاین) به جای سه تیم جدا، تبدیل میشه به یک Squad واحد که از اول تا آخر مسیر محصول رو خودش جلو می‌بره.
توی این مدل، به جای اینکه منتظر «هندآف» بمونیم، کارها به صورت همزمان و هم‌راستا جلو میره: دیزاین کنار فرانت و بک می‌شینه، بک هم از همون روز اول در جریان محدودیت‌های فنی هست، و فرانت می‌دونه چه APIهایی ساخته میشه.

Nielsen Norman Group طبق Scrum Guide:

Scrum Team یک تیم کوچک کراس فانکشناله که تمام مهارت‌های لازم برای تحویل ارزش به مشتری رو داره، بدون اینکه به تیم خارجی وابسته باشه.

نتیجه این ساختار، افزایش سرعت توسعه، شفافیت بالاتر، استفاده بهینه‌تر زمان، آموزش و تبادل اطلاعات بهتر و حس واقعی مالکیت محصول بین همه اعضاست. هر فیچر (مثلاً Checkout یا Dashboard) از اول تا آخر توی یک تیم بسته میشه و نیازی به پاسکاری بین تیم‌های مختلف نیست.

مثال‌های واقعی از تیم‌های موفق

• Spotify: مدل Squad؛ هر Squad شامل فرانت، بک، دیزاین، QA و حتی Data Scientist میشه.
  
• Airbnb: تیم‌های محصولی + یک تیم DesignOps برای کمک به دیزاینرها و ایجاد هماهنگی بهتر.
  
• Shopify: قبلاً فرانت و بک رو جدا کرده بودن؛ بعد از مشکلات جدی هماهنگی، رفتن سمت تیم‌های فیچر محور (Feature Teams).
  
• Basecamp: تیم‌های کوچک که هر کدوم یه فیچر رو End-to-End تحویل میدن. کتاب Shape Up دقیقاً همین مدل رو توضیح می‌ده.
  

راهکار عملی چیه؟

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

• برای فیچر Checkout → یک نفر بک‌اند دولوپر، یک نفر فرانت‌اند دولوپر و یک دیزاینر با هم کار می‌کنن.
• برای فیچر Dashboard → ترکیب دیگه‌ای از اعضا شکل می‌گیره.
• اینطوری هر فیچر End-to-End جلو میره و دیگه کسی منتظر بقیه نمی‌مونه.

برای هماهنگی هم کافیه هر روز یک Daily Standup کوتاه ۱۵ دقیقه‌ای داشته باشیم تا همه بدونن بقیه دارن چی کار می‌کنن.

نقش ریسرچ هم باید شفاف باشه:

• User Research → تیم دیزاین
• Technical Research → فرانت و بک
• Business Research → مدیر محصول یا بیزینس

برای رشد تخصصی هم می‌تونیم یک شبکه حمایتی یا همون Chapter داشته باشیم: همه فرانت‌‌اند دولوپرها هفته‌ای یک بار دور هم جمع بشن و تجربه‌هاشونو به اشتراک بذارن؛ بک‌اند دولوپرها و دیزاینرها هم همینطور. ولی اصل کار همیشه توی Squad واحد انجام میشه. حالا نتیجه این کار چیه؟ تیم کوچیک ما بدون پیچیدگی‌های اضافی سازمان‌های بزرگ، سریع‌تر جلو میره، و هینطور محصول رو واقعاً «با هم» می‌سازه.

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

اصطلاحات