اگر یک شرکت نرمافزاری چند مشتری و چند پروژه هم‌زمان دارد، پاسخ درست معمولاً ساختن یک تیم جداگانه برای هر مشتری نیست. راهکار مؤثرتر این است که درخواستهای مشتریان ابتدا به یک سیستم واحد تصمیم‌گیری وارد شوند، تیمهای توسعه حول حوزه‌های پایدار محصول شکل بگیرند و ظرفیت هر تیم میان توسعه محصول، درخواستهای مشتری، مشکلات عملیاتی و بدهی فنی تقسیم شود. افزایش تعداد تیمها زمانی منطقی است که دادههای واقعی نشان دهند گلوگاه اصلی واقعاً کمبود ظرفیت توسعه است، نه اولویتبندی ضعیف، تغییر مداوم برنامه یا وابستگی میان تیمها.
چرا زیاد شدن مشتریان نباید مستقیماً به زیاد شدن تیمهای توسعه منجر شود؟
فرض کنید یک شرکت نرمافزاری ۸ مشتری سازمانی دارد و هر مشتری در طول ماه ۳ درخواست جدید ارائه می‌کند. در ظاهر با ۲۴ درخواست مواجه هستیم، اما این ۲۴ مورد الزاماً ۲۴ پروژه مستقل نیستند. ممکن است چند مشتری در اصل یک قابلیت مشابه مانند سطح دسترسی جدید، گزارش مدیریتی، API یا تغییر در گردش کار را با بیان‌های متفاوت درخواست کرده باشند.
مشکل از جایی آغاز می‌شود که شرکت هر درخواست را به‌عنوان یک «پروژه مشتری» ببیند. در چنین شرایطی تیم توسعه مرتب میان مشتریان جابه‌جا می‌شود، یک قابلیت مشابه چند بار پیاده‌سازی می‌شود و معماری محصول به مجموعه‌ای از استثناهای مخصوص مشتریان تبدیل می‌شود. نتیجه ممکن است رضایت کوتاه‌مدت یک مشتری باشد، اما در بلندمدت هزینه نگهداری محصول به‌شدت افزایش پیدا می‌کند.
بنابراین اولین تصمیم مدیریتی باید تفکیک درخواستها حداقل در ۴ گروه باشد:
- قابلیت عمومی محصول: نیازی که برای تعداد قابل توجهی از مشتریان یا بازار هدف ارزش دارد.
- قابلیت قابل تنظیم: نیازی که بهتر است از طریق تنظیمات، فیلدهای سفارشی، گردش کار یا پیکربندی حل شود.
- توسعه اختصاصی مشتری: قابلیتی که عملاً فقط برای یک قرارداد یا یک مشتری خاص ارزش دارد.
- نگهداری و زیرساخت: باگ، امنیت، بهبود عملکرد، بازطراحی معماری و بدهی فنی.
| نوع درخواست | سؤال اصلی | روش برخورد پیشنهادی |
|---|---|---|
| قابلیت عمومی | آیا مشتریان دیگری هم از آن استفاده میکنند؟ | ورود به نقشه راه محصول |
| قابلیت قابل تنظیم | آیا میتوان مسئله را بدون توسعه اختصاصی حل کرد؟ | تبدیل به قابلیت Configuration |
| توسعه اختصاصی | آیا درآمد قرارداد هزینه ساخت و نگهداری را توجیه می‌کند؟ | پروژه مستقل با هزینه و SLA مشخص |
| نگهداری فنی | عدم انجام آن چه ریسکی برای محصول ایجاد می‌کند؟ | ظرفیت ثابت در برنامه توسعه |
۱. همه درخواستهای مشتریان باید از یک دروازه اولویتبندی عبور کنند
یکی از خطرناک‌ترین مدل‌ها این است که فروش، پشتیبانی، مدیر پروژه و مدیرعامل هرکدام مستقیماً برای تیم توسعه کار تعریف کنند. اگر ۵ کانال مختلف بتوانند اولویت تیم را تغییر دهند، حتی بهترین برنامه‌ریزی اسپرینت نیز عملاً بی‌اثر خواهد شد. تیم توسعه باید یک صف رسمی و شفاف از درخواستها داشته باشد و تغییر اولویت نیز تنها از همان مسیر انجام شود.
برای هر درخواست میتوان حداقل ۵ معیار در نظر گرفت: تعداد مشتریان منتفع، اهمیت تجاری، همراستایی با استراتژی محصول، هزینه یا پیچیدگی توسعه و فوریت. چارچوب‌هایی مانند RICE، Cost of Delay یا ماتریس ارزش در برابر تلاش نیز می‌توانند برای منظم کردن این تصمیم‌ها استفاده شوند، اما مهم‌تر از فرمول انتخاب‌شده، یکسان بودن قواعد تصمیم‌گیری است.
برای مثال اگر مشتری بزرگی قابلیتی با ارزش قراردادی بالا درخواست کند ولی آن قابلیت معماری محصول را پیچیده کند و فقط همان مشتری از آن استفاده کند، نباید صرفاً به دلیل اندازه مشتری فوراً وارد توسعه شود. ممکن است راه بهتر، ارائه API، تنظیمات قابل سفارشی‌سازی یا حتی تعریف یک پروژه توسعه اختصاصی با قیمت جداگانه باشد.
- درخواست ثبت شود.
- مسئله واقعی پشت درخواست مشخص شود.
- مشتریان یا کاربران دیگری که همین مسئله را دارند شناسایی شوند.
- ارزش تجاری و هزینه توسعه تخمین زده شود.
- درخواست در Backlog واحد محصول اولویتبندی شود.
نکته مهم این است که «مشتری این قابلیت را خواسته» هنوز دلیل کافی برای توسعه نیست. مدیر محصول باید بفهمد مشتری چه مسئله‌ای دارد؛ زیرا گاهی راه‌حل پیشنهادی مشتری تنها یکی از چند راه ممکن برای حل آن مسئله است.
۲. تیمها را حول حوزه محصول متمرکز کنید، نه حول نام مشتریان
اگر ۱۰ مشتری دارید، ساختن ۱۰ تیم توسعه معمولاً باعث ایجاد ۱۰ نسخه ذهنی متفاوت از محصول می‌شود. هر تیم به مرور تصمیم‌های معماری، الگوهای توسعه و اولویت‌های متفاوتی پیدا می‌کند و اشتراک دانش میان تیمها کاهش می‌یابد. ساختار پایدارتر این است که مالکیت تیمها بر اساس حوزه‌های نسبتاً مستقل محصول تعیین شود.
برای مثال یک شرکت SaaS ممکن است ۳ تیم اصلی داشته باشد: تیم «هسته محصول و مدیریت کاربران»، تیم «فرآیندها و مدیریت کار» و تیم «مشتریان، گزارش‌ها و یکپارچه‌سازی‌ها». درخواست مشتری A، B یا C بسته به حوزه مربوطه وارد یکی از این جریان‌ها می‌شود، نه اینکه هر مشتری تیم اختصاصی خودش را داشته باشد.
راهنمای Scrum نیز بر تیمهای کوچک و متمرکز تأکید دارد و Scrum Team را معمولاً ۱۰ نفر یا کمتر در نظر می‌گیرد. بنابراین وقتی حجم کار بیشتر می‌شود، ساخت یک تیم بسیار بزرگ معمولاً انتخاب مناسبی نیست؛ میتوان چند تیم کوچک و پایدار داشت که هدف محصول و Backlog هماهنگی دارند.
یک ساختار نمونه برای سازمانی با ۲۰ تا ۳۰ نیروی فنی می‌تواند چنین باشد:
- ۲ یا ۳ تیم جریان محصول: مسئول توسعه انتها‌به‌انتهای حوزه‌های کسب‌وکاری.
- ۱ تیم یا گروه پلتفرم: مسئول زیرساخت مشترک، CI/CD، احراز هویت، Observability و سرویس‌های مشترک.
- نقش‌های تخصصی موقت: برای امنیت، معماری، داده یا موضوعات پیچیده‌ای که همه تیمها دائماً به آن نیاز ندارند.
این منطق با مدل Team Topologies نیز هم‌راستا است؛ جایی که تیمهای Stream-Aligned حول یک جریان ارزش مشخص متمرکز می‌شوند و تیم Platform یا Enabling پیچیدگی‌های مشترک را از دوش آنها برمی‌دارد.
۳. ظرفیت تیم را از قبل میان چند نوع کار تقسیم کنید
اگر ۱۰۰ درصد ظرفیت تیم به Roadmap اختصاص داده شود، اولین باگ بحرانی یا درخواست مهم مشتری کل برنامه را به هم می‌زند. از طرف دیگر، اگر تیم هر روز براساس جدیدترین درخواست مشتری کار کند، محصول عملاً Roadmap نخواهد داشت. راه‌حل، رزرو کردن ظرفیت برای چند کلاس مختلف کار است.
یک نقطه شروع مناسب ـ نه یک قانون ثابت ـ می‌تواند تقسیم ظرفیت به شکل ۶۰/۲۵/۱۵ باشد:
- ۶۰٪: توسعه استراتژیک و Roadmap اصلی محصول.
- ۲۵٪: درخواستهای مشتریان و فرصت‌های تجاری اولویت‌دار.
- ۱۵٪: باگ، بدهی فنی، امنیت، نگهداری و بهبود زیرساخت.
برای محصولی که در مرحله تثبیت قرار دارد، نسبت ۵۰/۳۰/۲۰ ممکن است مناسبتر باشد و برای محصول بالغ با زیرساخت پایدار شاید بتوان سهم Roadmap را به ۷۰ درصد رساند. مهم این است که این نسبت براساس دادههای واقعی هر ۲ یا ۳ ماه بازبینی شود، نه اینکه هر هفته با فشار آخرین مشتری تغییر کند.
همچنین باید ظرفیت واقعی تیم اندازه‌گیری شود. اگر یک تیم در ۶ اسپرینت گذشته بهطور متوسط ۴۰ واحد کار تحویل داده است، برنامه‌ریزی روی ۷۰ واحد صرفاً به دلیل افزایش درخواستها ظرفیت واقعی ایجاد نمی‌کند. پیش‌بینی بهتر باید بر Throughput گذشته، مدت انجام کار و ظرفیت در دسترس اعضا استوار باشد.
۴. مدل زمان‌بندی باید دو سطح داشته باشد: برنامه میان‌مدت و اجرای کوتاه‌مدت
مشکل بسیاری از شرکت‌های نرمافزاری این نیست که Scrum یا Kanban استفاده نمی‌کنند؛ مشکل این است که افق‌های مختلف برنامه‌ریزی را با هم مخلوط میکنند. قرارداد مشتری ممکن است ۳ ماهه باشد، Roadmap محصول ۶ ماهه باشد، اما توسعه باید در بازه‌های کوتاه ۱ یا ۲ هفته‌ای قابل بازبینی باقی بماند.
یک مدل ساده دو سطحی می‌تواند این ساختار را داشته باشد:
- برنامه‌ریزی ظرفیت هر ۶ تا ۱۲ هفته: تعیین حوزه‌های مهم، اهداف محصول و سهم تقریبی انواع کار.
- برنامه‌ریزی اجرایی ۱ یا ۲ هفته‌ای: انتخاب کارهایی که واقعاً با ظرفیت فعلی تیم قابل انجام هستند.
درخواستهای جدید مشتری در طول دوره مستقیماً نباید کارهای در حال انجام را متوقف کنند. آنها وارد صف بررسی می‌شوند و در نزدیک‌ترین نقطه برنامه‌ریزی دوباره ارزیابی می‌شوند. فقط موارد واقعاً بحرانی مانند اختلال Production، مشکل امنیتی جدی یا تعهد قراردادی فوری باید اجازه ورود به Fast Lane را داشته باشند.
برای جلوگیری از اینکه همه چیز «فوری» نامیده شود، بهتر است حداکثر ۳ کلاس خدمت تعریف شود: عادی، زمان‌دار و بحرانی. اگر بیش از چند مورد هم‌زمان در کلاس بحرانی قرار می‌گیرند، تعریف بحران اشتباه است و مدیریت باید دوباره قواعد اولویت را بررسی کند.
۵. چه زمانی افزایش تعداد تیمهای توسعه واقعاً منطقی است؟
استخدام بیشتر زمانی منطقی است که حداقل طی ۲ یا ۳ چرخه برنامه‌ریزی مشخص شود حجم تقاضای ارزشمند بهطور پایدار بیشتر از ظرفیت تحویل است. اگر این وضعیت تنها یک ماه به دلیل پروژه‌ای خاص اتفاق افتاده باشد، ساخت یک تیم دائمی احتمالاً هزینه بلندمدت غیرضروری ایجاد می‌کند.
پیش از استخدام باید ۵ سؤال پاسخ داده شود:
- آیا کارهای کم‌ارزش از Backlog حذف شده‌اند؟
- آیا تیمها زمان زیادی منتظر تصمیم یا تیم دیگری می‌مانند؟
- آیا یک قابلیت مشابه برای مشتریان مختلف چند بار پیاده‌سازی می‌شود؟
- آیا مشکل اصلی واقعاً ظرفیت توسعه است یا تحلیل، تست، انتشار و تصمیم‌گیری؟
- آیا حوزه‌ای مستقل و پایدار وجود دارد که تیم جدید بتواند مالک آن شود؟
اگر پاسخ نشان دهد تقاضای واقعی مثلاً برای ۳ فصل متوالی حدود ۲۰ تا ۳۰ درصد بیشتر از Throughput قابل اتکای تیم است و حذف کارهای کم‌ارزش نیز مسئله را حل نمی‌کند، افزایش ظرفیت قابل بررسی است. اما تیم جدید باید مالک یک جریان ارزش یا حوزه مشخص شود، نه اینکه صرفاً «نیروی کمکی برای همه پروژهها» باشد.
تیم مشترکی که امروز روی پرداخت، فردا روی گزارش، هفته بعد روی اپلیکیشن مشتری A و سپس روی زیرساخت کار می‌کند، ظاهراً انعطاف‌پذیر است ولی هزینه Context Switching بسیار بالایی دارد. افزایش تعداد چنین تیم‌هایی معمولاً مشکل را تکثیر می‌کند.
۶. چگونه درخواستهای اختصاصی مشتری را بدون تخریب محصول مدیریت کنیم؟
یکی از مهم‌ترین تصمیم‌ها این است که هر نیاز مشتری الزاماً به Feature جدید تبدیل نشود. اگر ۵ مشتری فرایندهای متفاوت دارند، گاهی ساخت یک موتور تنظیمات یا قابلیت قابل پیکربندی ارزشمندتر از اضافه کردن ۵ حالت اختصاصی در کد است.
برای هر درخواست اختصاصی میتوان از یک آزمون ۴ مرحله‌ای استفاده کرد:
- آیا این مسئله برای بخش قابل توجهی از بازار وجود دارد؟
- آیا میتوان آن را به یک قابلیت عمومی‌تر تبدیل کرد؟
- آیا میتوان از طریق تنظیمات یا API آن را حل کرد؟
- اگر کاملاً اختصاصی است، آیا مشتری هزینه توسعه و نگهداری آن را می‌پردازد؟
این تفکیک از تبدیل شدن محصول SaaS به یک نرم‌افزار سفارشی برای ده‌ها مشتری جلوگیری می‌کند. توسعه اختصاصی ذاتاً بد نیست؛ مشکل زمانی ایجاد می‌شود که هزینه واقعی نگهداری آن در نسخه‌های آینده، تست Regression، پشتیبانی و تغییر معماری در قرارداد محاسبه نشده باشد.
در برخی شرکت‌ها ایجاد یک لایه Extension، API یا Configuration می‌تواند پس از ۳ یا ۴ درخواست مشابه بسیار اقتصادی‌تر از ادامه Fork کردن رفتار محصول باشد. به این ترتیب مشتری انعطاف لازم را دریافت می‌کند، ولی Core Product همچنان قابل مدیریت باقی می‌ماند.
۷. یک نمونه عملی از مدیریت ۲۰ درخواست از چند مشتری
فرض کنید ۶ مشتری طی یک ماه مجموعاً ۲۰ درخواست جدید مطرح کرده‌اند. مدیر ضعیف ممکن است ۲۰ Task بسازد و آنها را مستقیماً میان برنامه‌نویسان تقسیم کند. مدیر محصول ابتدا درخواستها را تجمیع می‌کند و ممکن است متوجه شود این ۲۰ درخواست در واقع به ۷ مسئله اصلی مربوط هستند.
| نتیجه بررسی | تعداد | تصمیم |
|---|---|---|
| قابلیت مشترک محصول | ۳ مورد | ورود به Roadmap |
| قابل حل با تنظیمات | ۱ مورد | توسعه Configuration عمومی |
| درخواست کاملاً اختصاصی | ۱ مورد | برآورد و قرارداد جداگانه |
| باگ | ۱ مورد | ورود به صف نگهداری |
| نیاز آموزشی، نه توسعه‌ای | ۱ مورد | حل توسط پشتیبانی |
به این ترتیب تیم به‌جای واکنش به ۲۰ پیام پراکنده، تنها با ۷ مسئله واقعی روبه‌رو می‌شود و حتی همه آن ۷ مورد نیز الزاماً وارد توسعه نمی‌شوند. همین مرحله Discovery می‌تواند بدون اضافه کردن حتی یک برنامه‌نویس، فشار ظاهری روی تیم را به‌شدت کاهش دهد.
برای اجرای چنین مدلی در یک ابزار مدیریت کار، بهتر است «مشتری»، «پروژه»، «حوزه محصول» و «نوع درخواست» از یکدیگر قابل تفکیک باشند. برای مثال در تیکبورد میتوان پروژهها را به مشتریان متصل کرد، کارها را روی بردهای مختلف قرار داد، برای آنها اولویت، وزن و زمان تقریبی تعریف کرد و سپس با گزارش‌ها و ثبت زمان، میزان ظرفیت مصرف‌شده برای هر مشتری یا پروژه را بررسی کرد.
اگر بخش زیادی از ظرفیت یک تیم طی ۲ ماه صرف یک مشتری شده باشد، مدیریت اکنون داده کافی برای تصمیم‌گیری دارد: آیا آن مشتری باید قرارداد متفاوتی داشته باشد؟ آیا نیازهایش باید به قابلیت عمومی محصول تبدیل شوند؟ یا واقعاً جریان کاری مستقلی شکل گرفته که ایجاد یک تیم جدید را توجیه می‌کند؟ برای مطالعه بیشتر درباره روش‌های مدیریت کار تیمی می‌توانید به مقالات مدیریت پروژه و مدیریت تیم مراجعه کنید.
جمع‌بندی
شرکت نرمافزاری چندمشتری پیش از آنکه تعداد توسعه‌دهندگان را افزایش دهد باید جریان ورود تقاضا را مدیریت کند. درخواست مشتری، Feature محصول، توسعه اختصاصی، باگ و بدهی فنی یک نوع کار نیستند و نباید در یک صف بدون قاعده با یکدیگر رقابت کنند.
مدل مناسب در بیشتر موارد بر ۵ اصل استوار است: یک Backlog مشترک، اولویتبندی واحد، تیمهای پایدار حول حوزه‌های محصول، تخصیص مشخص ظرفیت و برنامه‌ریزی در بازه‌های کوتاه همراه با بازبینی میان‌مدت. افزایش تعداد تیمها زمانی معنا دارد که پس از اجرای این اصول هنوز تقاضای ارزشمند به‌صورت پایدار از ظرفیت واقعی بیشتر باشد.
هدف نهایی این نیست که همه درخواستهای مشتریان سریع‌تر وارد برنامهنویسی شوند؛ هدف این است که مسائل درست، در زمان درست، توسط تیم درست حل شوند. استفاده از یک سیستم یکپارچه مدیریت پروژه و وظایف مانند تیکبورد نیز می‌تواند شفافیت لازم درباره پروژهها، مشتریان، ظرفیت تیم، زمان مصرف‌شده و وضعیت درخواستها را فراهم کند تا تصمیم‌های توسعه براساس داده گرفته شوند، نه براساس آخرین درخواست یا بلندترین صدای سازمان.
