SMALL TEAM، شفافیت
چرا تیم کوچک گاهی بهتر است، و گاهی نیست
یازیاپ تیم بزرگی نیست و قصد نداریم این واقعیت را پشت عبارت‌های مبهم پنهان کنیم. تیم کوچک یعنی فاصله‌ی کمتر تا آدمی که کار را انجام می‌دهد؛ هم‌زمان یعنی ظرفیت محدودتر.
جواب کوتاه
برای پروژه‌ای با دامنه‌ی روشن و نیاز به ارتباط مستقیم، تیم کوچک می‌تواند سریع‌تر و مسئولانه‌تر باشد. برای چند جریان کاری هم‌زمان، پوشش شبانه‌روزی یا تحویل بسیار بزرگ در زمان کوتاه، تیم بزرگ‌تر انتخاب منطقی‌تری است.
۱
مزیت واقعی تیم کوچک چیست؟
آدمی که مسئله را می‌شنود به آدمی که تصمیم فنی می‌گیرد نزدیک است؛ پیام در چند لایه‌ی مدیریت گم نمی‌شود.
- گفت‌وگوی مستقیم با افراد درگیر اجرا
- تصمیم‌گیری کوتاه‌تر و مسئولیت روشن‌تر
- شناخت عمیق‌تر اعضا از کل محصول
- هزینه‌ی سربار اداری کمتر
۲
محدودیت واقعی کجاست؟
تیم کوچک نمی‌تواند تعداد نامحدودی پروژه را هم‌زمان با کیفیت ثابت جلو ببرد.
- ظرفیت شروع پروژه محدود است
- پوشش ۲۴ ساعته فقط با قرارداد و شیفت مشخص ممکن است
- نباید دانش پروژه دست یک نفر بماند
- پروژه‌های بسیار بزرگ باید فازبندی یا با همکاران تخصصی اجرا شوند
اگر دامنه و مهلت پروژه با ظرفیت ما سازگار نباشد، باید پیش از قرارداد ردش کنیم؛ نه اینکه بعداً با تأخیر توضیح بدهیم.
۳
ریسک وابستگی را چطور کم می‌کنیم؟
مالکیت کد و زیرساخت برای کارفرما، مستندات، نسخه‌ی پشتیبان و بازبینی مشترک، ریسک قفل‌شدن به تیم را کم می‌کند.
- مخزن کد و دسترسی اصلی به نام کارفرما
- ثبت تصمیم‌های مهم و راه‌اندازی پروژه
- نسخه‌ی پشتیبان و امکان تحویل به تیم دیگر
- گزارش پیشرفت قابل مشاهده، نه فقط گزارش شفاهی
۴
چه زمانی ما انتخاب مناسبی نیستیم؟
وقتی ده‌ها توسعه‌دهنده‌ی هم‌زمان، دفتر در چند کشور، مرکز تماس شبانه‌روزی یا گواهی سازمانی خاص شرط پروژه است، باید سراغ مجموعه‌ی متناسب‌تری بروید.
کوچک‌بودن نه فضیلت مطلق است و نه ضعف پنهان؛ فقط باید با شکل پروژه جور باشد.