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

مقدمه

توی مقاله قبلی راجع به مدل سیلویی (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های حمایتی باعث میشه آدم‌ها همچنان رشد تخصصی خودشون رو ادامه بدن.

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

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

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

اصطلاحات