معمار تیم

تیم خوب

اتفاقی ساخته نمی‌شود

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

۰
گزینهٔ پیشنهادی
۰
نوع قانون قطعی
۰
شاخص امتیازدهی
۰
وضعیت پروژه
شروع

با یک جمله شروع می‌شود،

نه با یک فرم بلند

به زبان خودت بنویس می‌خواهی به چه چیزی برسی. بعد ساختار تیم‌ها را مشخص می‌کنی و آدم‌ها را از فهرست پرسنل اضافه می‌کنی — همان‌هایی که قبلاً وارد کرده‌ای.

هدف تو

۲۰ نفر از کارکنان را برای یک هکاتون داخلی دوهفته‌ای به ۴ تیم متوازن تقسیم کن. می‌خواهم سطح‌های ارشدیت و واحدها با هم ترکیب شوند و هر تیم یک راهبر قوی داشته باشد.

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

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

شکل نتیجه را تو تعیین می‌کنی

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

تعداد تیم‌ها

چند تیم می‌خواهی داشته باشی

حداقل و حداکثر اندازه

کف و سقف تعداد نفرات هر تیم

اندازه‌های برابر

همهٔ تیم‌ها هم‌اندازه بمانند یا نه

عضو شناور

کسانی که می‌توانند بین تیم‌ها جابه‌جا شوند

بدون تیم ماندن

اگر نتیجهٔ کلی بهتر شود، کسی خارج از تیم‌ها بماند

نقش‌های الزامی

نقش‌هایی که هر تیم حتماً باید داشته باشد

قوانین

چیزهایی که هوش مصنوعی

حق ندارد نادیده بگیرد

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

باید در تیم‌های جدا باشند

«این دو نفر پروژهٔ قبلی را با هم به مشکل خوردند.»

باید در یک تیم باشند

«این دو ماه است روی همین موضوع کار می‌کنند، جدا کردنشان بی‌معنی است.»

باید راهبر باشد

«این پروژه را قرار است او هدایت کند؛ تصمیمش گرفته شده.»

نباید راهبر باشد

«هنوز آمادهٔ راهبری نیست؛ می‌خواهم این دوره را یاد بگیرد.»

کنار گذاشته شود

«مرخصی است یا درگیر پروژهٔ دیگری است.»

قانون سفارشی

«هر تیم حداقل یک نفر از واحد پشتیبانی داشته باشد.»

قانون قطعی: غیرقابل مذاکره

هیچ پیشنهادی که این‌ها را نقض کند ساخته نمی‌شود. یکی از هشت شاخص امتیازدهی هم دقیقاً همین است: میزان رعایت محدودیت‌ها، تا بتوانی مطمئن شوی.

ترجیح نرم: تا جای ممکن

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

پیشنهادها

یک جواب درست نداریم،

سه جواب متفاوت داریم

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

تیم‌ها تا حد ممکن هم‌وزن می‌شوند: نه یک تیم ستاره‌ای و نه یک تیم ضعیف. مناسب وقتی که همهٔ تیم‌ها قرار است خروجی قابل مقایسه بدهند — مثل هکاتون یا چند پروژهٔ موازی با اهمیت یکسان.

توازن92
هم‌خوانی همکاری88
توان اجرا79
ظرفیت یادگیری81
پوشش رهبری85
توزیع ریسک90
پوشش نقش‌ها87
رعایت محدودیت‌ها100

«رعایت محدودیت‌ها» در هر سه گزینه ۱۰۰ است و این تصادفی نیست: قوانین قطعی تو شرط ساخت پیشنهادند، نه یکی از معیارهای بهینه‌سازی.

داخل هر تیم

فقط فهرست اسم

تحویلت نمی‌دهد

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

تیم ۲ · «مسیر پرداخت»

۵ نفر
  • نیما اسدیمهندس بک‌اند · ارشدراهبر
  • شیرین قاسمیمدیر محصول · میان‌ردهجانشین
  • پویا رستمیمهندس فرانت‌اند · میان‌رده
  • هستی مرادیطراح محصول · تازه‌کار
  • کاوه سلطانیتضمین کیفیت · میان‌رده

90

توازن

86

همکاری

82

اجرا

88

یادگیری

91

رهبری

77

ریسک

چرا این ترکیب

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

احتمالاً این‌طور کار می‌کنند

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

نقاط قوت

  • تنها تیمی که هر سه لایهٔ بک‌اند، فرانت‌اند و کیفیت را کامل پوشش می‌دهد.
  • راهبر و جانشین قبلاً دو پروژه را با هم تمام کرده‌اند.

ریسک‌ها

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

دستور جلسهٔ اول

سه چیزی که این تیم بهتر است قبل از شروع کار حلشان کند — بر اساس همان ریسک‌های بالا.

  1. 1توافق کنید تصمیم‌های فنی کجا و چطور مکتوب می‌شوند.
  2. 2مشخص کنید هستی برای بازبینی طراحی به چه کسی مراجعه کند.
  3. 3تعیین کنید در نبود نیما، شیرین تا کجا اجازهٔ تصمیم دارد.

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

بازخورد

اگر پیشنهاد را نپسندیدی،

بگو چرا

لازم نیست از اول شروع کنی. ایراد را می‌نویسی و نسخهٔ بعدی با همان قوانین قبلی به‌علاوهٔ بازخورد تو ساخته می‌شود. همهٔ نسخه‌ها می‌مانند تا بتوانی مقایسه کنی.

پیشنهاد اول معمولاً آخری نیست

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

بازخورد تو

تیم ۳ خیلی تازه‌کار شده. یک نفر میان‌رده از تیم ۱ به آن منتقل کن ولی نیما را جابه‌جا نکن.

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

از پیش‌نویس تا تأیید

پروژهٔ تیم‌سازی وضعیت مشخصی دارد، پس همیشه معلوم است منتظر چه چیزی هستی — دادهٔ آدم‌ها، تصمیم خودت، یا هیچ‌کدام.

01

پیش‌نویس

هدف و ساختار را می‌نویسی

02

جمع‌آوری داده

مشارکت‌کنندگان ارزیابی کوتاه را انجام می‌دهند

03

آمادهٔ پیشنهاد

دادهٔ کافی رسیده و می‌شود ساخت

04

پیشنهادها آماده

سه گزینه ساخته شده و منتظر توست

05

تأیید شده

یک گزینه از یک نسخه انتخاب شده

06

بایگانی

پروژه بسته شده ولی تاریخچه‌اش می‌ماند

سوالات متداول

چیزهایی که

معمولاً پرسیده می‌شود

یک تیم واقعی را با هم بچینیم

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

درخواست دمو