از نظر ریاضی، اضافهشدن نیروی انسانی باید ظرفیت سازمان را بالا ببرد.
پنج نفر میتوانند بیشتر از دو نفر کار کنند.
بیست نفر باید بیشتر از پنج نفر خروجی داشته باشند.
اما مدیران بارها خلاف این را تجربه میکنند.
پروژه کوچک با سه نفر سریع جلو میرود. همان پروژه وقتی به فروش، مالی، عملیات، حقوقی، محصول و فناوری متصل میشود، ناگهان جلسهها زیاد میشود، تصمیمها کند میشود و هیچکس مطمئن نیست مالک نهایی کار کیست.
مشکل کمبود آدم نیست.
مشکل هزینه هماهنگی است.
مقاله امروز Inc. این مسئله را با پژوهشی درباره رفتار گروهی مورچهها مقایسه میکند. در آزمایشهای پیچیده، گروههای بزرگتر مورچهها عملکرد بهتری داشتند، چون قواعد مشترک داشتند، اطلاعات در گروه جریان داشت و اعضای تازه بدون مذاکره دائمی بر سر اولویتها وارد سیستم میشدند.
در شرکتها معمولاً برعکس است.
هر واحد KPI خودش را دارد.
فروش میخواهد درآمد امروز را حفظ کند.
محصول میخواهد چیز جدید آزمایش کند.
مالی هزینه را کاهش میدهد.
عملیات ثبات میخواهد.
هرکدام منطقی رفتار میکنند، اما نتیجه جمعی ممکن است غیرمنطقی باشد.
مثال ساده: فروش در برابر نوآوری
فرض کنید تیم محصول میخواهد نسخه جدیدی را روی چند مشتری آزمایش کند.
فروشنده نگران است.
چون Bonus او به درآمد و حفظ مشتری وابسته است.
محصول جدید ممکن است مشکل ایجاد کند و رابطه مشتری را به خطر بیندازد.
بنابراین فروش مقاومت میکند.
از نگاه خودش تصمیم درستی گرفته است.
تیم محصول نیز برای یادگیری به مشتری واقعی نیاز دارد.
او هم درست فکر میکند.
مشکل هیچکدام از افراد نیست.
سیستم امتیازدهی دو رفتار متضاد تولید کرده است.
ابزار فرصت امروز: Cross-Functional Alignment Score
برای هر پروژهای که بیش از دو واحد درگیر آن هستند، پنج معیار را از صفر تا ۲۰ بسنجید.
۱. Shared Outcome — نتیجه مشترک
آیا همه واحدها روی یک نتیجه نهایی توافق دارند؟
مثلاً:
«راهاندازی موفق محصول در ۹۰ روز با حداقل ۲۰ مشتری فعال»
نه اینکه فروش فقط Revenue را ببیند و محصول فقط Launch Date را.
۲. Shared Metric — معیار مشترک
آیا حداقل یک KPI وجود دارد که همه در برابر آن پاسخگو باشند؟
اگر هر واحد فقط شاخص خودش را بهینه کند، پروژه به مجموعهای از اهداف محلی تبدیل میشود.
۳. Shared Truth — منبع اطلاعات مشترک
آیا همه نسخه یکسانی از وضعیت پروژه را میبینند؟
یا هر واحد فایل Excel و گزارش خودش را دارد؟
وقتی حقیقت مشترک نیست، جلسهها صرف بحث درباره داده میشود، نه تصمیم.
۴. Decision Rights — حق تصمیم
چه کسی در چه چیزی تصمیم نهایی دارد؟
بخش زیادی از تأخیر پروژهها از این سؤال میآید:
«چه کسی باید تأیید کند؟»
اگر پاسخ روشن نیست، پروژه تقریباً حتماً کند خواهد شد.
۵. Rule Simplicity — سادگی قواعد
برای انجام کار چند مرحله، فرم، تأیید و استثنا وجود دارد؟
قانون زیاد معمولاً با رشد سازمان اضافه میشود ولی کمتر حذف میشود.
نتیجه سازمانی است که برای جلوگیری از یک اشتباه قدیمی، همه تصمیمهای جدید را کند کرده است.
تفسیر امتیاز
۸۰ تا ۱۰۰: پروژه آماده Scale
۶۰ تا ۷۹: هماهنگی قابل قبول، اما شکننده
۴۰ تا ۵۹: Friction بالا
زیر ۴۰: اضافهکردن نفر احتمالاً مشکل را بدتر میکند
این امتیاز را قبل از استخدام فرد جدید یا اضافهکردن واحد جدید به پروژه محاسبه کنید.
گاهی پاسخ کمبود نیرو نیست.
پاسخ حذف اصطکاک است.
پروتکل یک هدف، یک داشبورد، سه قانون
برای پروژههای بینوظیفهای یک صفحه بسازید.
بالای صفحه فقط یک هدف نوشته شود.
مثلاً:
«تا ۳۰ آذر، محصول جدید را به ۵۰ مشتری واقعی برسانیم و نرخ حفظ بالای ۸۰ درصد داشته باشیم.»
بعد فقط یک داشبورد داشته باشید.
همه واحدها همان اعداد را ببینند.
سپس سه قانون تصمیم تعریف کنید.
مثلاً:
۱. مشکلات ایمنی همیشه Launch را متوقف میکنند.
۲. تغییرات کمتر از X تومان نیاز به تأیید مالی ندارد.
۳. صاحب هر Workstream اختیار تصمیم روزانه دارد.
سه قانون خوب گاهی از ۳۰ صفحه Process مؤثرترند.
هزینه ارتباط با رشد تیم بالا میرود
وقتی تعداد افراد زیاد میشود، تعداد ارتباطات احتمالی سریعتر از تعداد افراد رشد میکند.
به همین دلیل سازمان نمیتواند صرفاً با اضافهکردن جلسه مشکل را حل کند.
جلسه بیشتر خودش هزینه هماهنگی جدید ایجاد میکند.
راهحل بهتر این است که نیاز به هماهنگی دائمی را کم کنیم.
چطور؟
هدف روشن.
اطلاعات مشترک.
اختیار تصمیم.
قاعده محدود.
اگر این چهار مورد وجود داشته باشد، افراد میتوانند بدون جلسه جدید حرکت کنند.
Meeting Dependency Ratio
یک شاخص ساده تعریف کنید:
تعداد تصمیمهایی که بدون جلسه گرفته میشوند ÷ کل تصمیمهای پروژه
اگر تقریباً هیچ تصمیمی بدون جلسه امکانپذیر نیست، سیستم بیش از حد وابسته به Synchronization شده است.
برای پروژه سالم باید بخشی از تصمیمها بتوانند براساس قواعد و اطلاعات مشترک بدون جمعشدن همه افراد جلو بروند.
آزمایش هفتروزه اصطکاک
یک پروژه کند را انتخاب کنید.
هفت روز تمام توقفها را ثبت کنید.
برای هر توقف فقط یکی از این علتها را انتخاب کنید:
اطلاعات نبود.
مالک تصمیم معلوم نبود.
اهداف متضاد بود.
تأیید لازم بود.
منابع نبود.
سپس تعداد هر دسته را بشمارید.
اگر بیشتر توقفها از سه دسته اول هستند، استخدام نیروی جدید احتمالاً مشکل را حل نمیکند.
سیستم همکاری باید اصلاح شود.
Rulebook Diet
Inc. پیشنهاد میکند بهجای Processهای سنگین، تعداد کمی اصل راهنما ایجاد شود.
هر سه ماه یک سؤال بپرسید:
«کدام قانون فقط به این دلیل وجود دارد که زمانی مشکلی رخ داده بود؟»
اگر شرایط تغییر کرده، آن قانون شاید دیگر ارزش هزینهای را که ایجاد میکند نداشته باشد.
سازمانها معمولاً Process را اضافه میکنند.
کمتر پیش میآید آن را حذف کنند.
به همین دلیل هر دوره رشد میتواند مقداری اصطکاک تاریخی روی سازمان باقی بگذارد.
حکم فرصت امروز
بزرگشدن تیم فقط مسئله جذب استعداد نیست.
مسئله طراحی هماهنگی است.
اگر افراد بیشتر وارد سیستمی شوند که اهداف متضاد، اطلاعات پراکنده و اختیار مبهم دارد، ظرفیت بیشتر به آشفتگی بیشتر تبدیل میشود.
اما اگر همه بدانند:
کجا میرویم،
چه عددی مهم است،
اطلاعات واقعی کجاست،
و چه کسی حق تصمیم دارد،
اندازه تیم میتواند مزیت شود.
پس قبل از پرسیدن:
«چند نفر دیگر لازم داریم؟»
یک سؤال بهتر بپرسید:
«چه چیزی باعث شده افراد فعلی نتوانند با سرعت یکدیگر حرکت کنند؟»