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

مقدمه

توی مقاله قبلی راجع به مدل سیلویی (Silo Model) و مشکلاتش حرف زدیم. دیدیم که وقتی تیم‌ها فقط بر اساس تخصص جدا می‌شن (مثلا تیم‌های فرانت‌اند، بک‌اند و دیزاین)، خروجی پر از هندآف‌های (Handoff) بی‌پایان، باگ‌های ارتباطی و تأخیر میشه. حالا وقتشه بریم سراغ عمل: اگه ما یه تیم کوچیک (۷ نفره) باشیم، چطور می‌تونیم از این مدل سنتی بیایم سمت مدل بهتری مثل مدل کراس فانکشنال (Cross-functional) و سرعت و کیفیت کارمون رو بهتر کنیم؟

چالش‌های تغییر

عموما وقتی می‌خوای یه تیم رو از مدل سیلویی (Silo Model) ببری سمت کراس فانکشنال (Cross-functional)، اولین چیزی که سر راهت سبز میشه «مقاومت آدم‌ها»ست. اعضای تیم می‌ترسن که نقش تخصصی‌شون گم بشه؛ به عنوان مثال، ممکنه یه فرانت‌اند دولوپر (Frontend Developer) فکر کنه حالا باید به کمک تیم‌های دیگه هم بره یا مسئولیت‌های اضافه‌ای بهش محول میشه.

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

شاید بشه گفت، یکی دیگه از بزرگ‌ترین مشکلات، «ابهام در نقش‌ها و مسئولیت‌ها (Roles & Responsibilities)»ست. فرض کن قراره یه ریسرچ (Research) روی تجربه کاربر انجام بشه. اینجاست که سوال‌ها شروع میشه: «آیا دیزاینر (Designer) باید کار رو بگیره چون به تجربه کاربر نزدیکه؟»، «یا بک‌اند دولوپر (Backend Developer) باید وارد بشه چون دیتا رو بهتر می‌شناسه؟»، «یا مدیر محصول (Product Manager) مسئول اصلیه؟». وقتی هیچ‌کس دقیق نمی‌دونه مرز کارش کجاست، آدم‌ها «حس ناامنی» می‌کنن و تغییر براشون ترسناک میشه.

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

راهکارهای عملی برای تیم کوچک (۷ نفره)

۱. یک Squad واحد بسازیم (Squad)

به جای اینکه تیم رو تیکه‌تیکه کنیم ( ۳ نفر فرانت‌اند دولوپر (Frontend Developer) + ۲ نفر بک‌اند دولوپر (Backend Developer) + ۲ نفر دیزاینر (Designer) )، بهتره همه رو بیاریم زیر یک سقف و تبدیل کنیم به یک Squad. این Squad مسئول «فیچرها (Feature)»ست، نه کارهای تخصصی جدا جدا. یعنی ما دیگه نمی‌گیم «فلانی فقط فرانت کار می‌کنه»، بلکه می‌گیم «این تیم مسئول Checkout و هرکس هر کمکی لازمه می‌کنه تا Checkout به کامل‌ترین شکل ممکن به دست کاربر برسه». این نگاه ساده باعث میشه همه حس کنن روی یک محصول مشترک کار می‌کنن، نه اینکه توی جزیره خودشون گیر کردن.

۲. کار رو بر اساس فیچر تقسیم کنیم (Feature-based Work)

در مدل‌های قدیمی کارها رو بر اساس تخصص تقسیم می‌کردیم: Front توی یه ردیف، Back توی یه ردیف، ِDesign هم توی یه ردیف دیگه. نتیجش چی بود؟ هندآف‌های (Handoff) بی‌پایان. حالا توی مدل کراس فانکشنال (Cross-functional)، کار رو می‌بریم سمت فیچر (Feature). مثلاً برای فیچر Checkout، یه فرانت‌اند دولوپر، یه بک‌اند دولوپر و یه دیزاینر کنار هم می‌شینن و از صفر تا صد کار رو پیش می‌برن. برای Dashboard هم همینطور. اینجوری هر فیچر End-to-End ساخته میشه و دیگه وسط راه معطل «اون تیم» نمی‌مونی. خروجی سریع‌تر، با کیفیت‌تر و بدون دوباره‌کاری.

۳. جلسات کوتاه روزانه (Daily Standup)

هیچ‌کس حوصله جلسه‌های بی‌پایان نداره. پس ما فقط ۱۵ دقیقه در روز وقت می‌ذاریم. توی این Daily Standup هر نفر سریع میگه «دیروز چی کار کردم؟ امروز چی کار می‌کنم؟ چه مشکلی دارم؟». همین. نه گزارش اضافی، نه پاورپوینت. این جلسه باعث میشه همه بدونن تیم کجای کاره، کی به کمک نیاز داره و کارها گیر نمی‌کنه.

۴. نقش ریسرچ (Research) رو شفاف کنیم

یکی از جاهایی که خیلی سریع ابهام درست میشه، همین موضوع ریسرچه (Research). برای همین از همون اول باید روشن کنیم چه کسی مسئول چه بخشی از ریسرچه:

• User Research → تیم دیزاین (به دلیل نزدیکی به تجربه کاربر)
• Technical Research → تیم‌های فرانت‌اند و بک‌اند (به دلیل شناخت ابزار و تکنولوژی)
• Business Research → مدیر محصول (Product Manager) چون به اهداف بیزینس وصل میشه

وقتی این تقسیم‌بندی روشن باشه، دیگه کسی ناآگاه نمی‌مونه و همه می‌دونن دقیقاً وظیفه‌شون کجاست.

۵. شبکه حمایتی (Chapter) بسازیم

یه زنگ خطر خلی مهم توی کراس فانکشنال (Cross-functional) اینه که آدم‌ها حس کنن دارن تخصصشون رو از دست می‌دن. برای همین لازمه کنار Squad اصلی، یه ساختار حمایتی به اسم Chapter داشته باشیم. مثلاً همه فرانت‌اند دولوپرها هفته‌ای یه بار دور هم جمع بشن و درباره تجربه‌هاشون، ابزار جدید یا مشکلات فنی حرف بزنن. همین برای بک‌اند دولوپرها و دیزاینرها هم باشه. اینطوری هم تخصص حفظ میشه، هم یادگیری جمعی اتفاق میفته، در حالی که کار اصلی همچنان داخل Squad پیش میره.

مثال‌های واقعی از شرکت‌ها

وقتی از کراس فانکشنال (Cross-functional) حرف می‌زنیم، خیلیا فکر می‌کنن این مدل فقط برای شرکت‌های بزرگه. ولی واقعیت اینه که خیلی از معروف‌ترین شرکت‌های دنیا دقیقاً به خاطر همین تغییر تونستن رشد کنن. چندتا مثال روشن:

• Spotify: با معرفی مدل Squad تونست تیم‌ها رو کوچک، مستقل و کراس فانکشنال کنه. یعنی هر Squad شامل فرانت‌اند دولوپر (Frontend Developer)، بک‌اند دولوپر (Backend Developer)، دیزاینر (Designer)، تضمین کیفیت (Quality assurance) و حتی دیتا ساینتیست (Data Scientist) میشه. هر Squad مثل یک استارتاپ کوچیک داخل شرکت عمل می‌کنه.
• Airbnb: تیم‌ها رو حول محصول (Product Teams) سازماندهی کرده. یعنی هر تیم مسئول یک بخش مشخص از تجربه کاربره. در کنارش یک تیم DesignOps ساخته که وظیفه‌ش اینه ابزار و فرآیند مناسب رو برای همه دیزاینرها فراهم کنه تا کارشون سریع‌تر و هماهنگ‌تر بشه.
• Shopify: اوایل تیم‌ها رو به صورت سیلویی (Silo Model) اداره می‌کرد و همین باعث تاخیرهای زیاد شد. بعد از مدتی فهمیدن این مدل جواب نمی‌ده و رفتن سمت Feature Teams؛ یعنی تیم‌هایی که هرکدوم مسئول یک فیچر End-to-End هستن. این تغییر سرعت و کیفیتشون رو خیلی بالا برد.
• Basecamp: فلسفه‌ش اینه که تیم‌های کوچک بهترین خروجی رو میدن. هر تیم مسئول یک فیچر یا پروژه از ابتدا تا انتهاست. کتاب معروفشون به اسم Shape Up دقیقاً همین مدل رو توضیح می‌ده و نشون می‌ده چرا تیم‌های کوچک و کراس فانکشنال موفق‌ترن.

جمع‌بندی

خب، تا اینجا دیدیم که مدل سیلویی (Silo Model) به ظاهر مرتب و ساده‌ست، ولی در عمل پر از تاخیر، هندآف‌های بی‌پایان و سوءتفاهمه. از اون طرف، کراس فانکشنال (Cross-functional) کمک می‌کنه تیم حتی اگه کوچیک باشه، بتونه سریع‌تر، هماهنگ‌تر و با انگیزه‌تر جلو بره.

در مثال تیم ۷ نفره‌ هم گفتیم که بهتره که به جای سه تیم بصورت جزیره‌ای، یک Squad واحد بسازیم. تسک‌ها (Task) باید حول فیچرها تقسیم بشه، نقش‌ها شفاف باشن و همه هر روز بدونن بقیه کجا Squad هستن. از طرف دیگه، داشتن Chapterهای حمایتی باعث میشه آدم‌ها همچنان رشد تخصصی خودشون رو ادامه بدن.

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

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

پس اگه این بحث برات جالب بود، مقاله‌ی بعدی رو از دست نده 😉

اصطلاحات

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

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

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

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 رسمی منبع بسیار مفیدی است.

اصطلاحات