دبستانی بودم و تازه با کتاب‌خوندن انس گرفته بودم که در یکی از نمایشگاه‌های بین‌المللی کتاب، عنوان کتابی از نشر هرمس توجه من رو به خودش جلب کرد: «۱۰۱ راه برای ذله کردن پدر و مادرها!» نوشته «لی‌وارد‌لاو». عنوان کتاب مجذوبم کرد و به خانواده اصرار کردم که برام بخرن. قطعا واکنش منفیشون هم قابل حدس بود چون عملا با دست خودشون داشتن به ضرر خودشون کار می‌کردن. اما بالاخره اون کتاب رو خریدم و از همون عصر شروع کردم به خوندنش. درسته که کتاب ظاهرا داشت روش‌های ذله کردن رو معرفی می‌کرد اما در پس پرده، داشت خواننده رو برای خلاف اون رفتارها تشویق می‌کرد.
در این مقاله سعی کردم به همون سبک و سیاق روش‌های ذله کردن مدیران محصول رو بهتون معرفی کنم. اگر از مدیران رده بالا، صاحب کسب و کار یا ذینفع هستید این مقاله رو بخونید ولی خواهشا به اون عمل نکنید. سعی کنید در پس پرده به خلاف انجام این رفتارها تشویق بشید. اما چطور میشه یک مدیر محصول رو ذله کرد:
اولین راه برای ذله کردن مالک محصول اینه که فریم‌ورک اسکرام رو به طور کلی ناکارآمد جلوه بدید و یا تغییراتی رو درخواست کنید که کاملا برخلاف اصول اولیه اسکرام باشن. به عنوان مثال:
۱- استقلال مالک محصول رو کاملا نادیده بگیرید
۲- مالک محصول رو کنار بگذارید و مستقیما با توسعه‌دهندگان صحبت کنید
۳- مالک محصول رو مجبور کنید تا نقش اسکرام‌مستر رو هم به عهده بگیره.
۴- انجام روش‌های قدیمی مدیریت پروژه رو به مدیر محصول تحمیل کنید.
۵- روش‌های قدیمی مدیریت پروژه مثل waterfall رو با فریم‌ورک اسکرام مخلوط کنید. مثلا مدیرمحصول رو مجبور کنید برای کوچکترین تغییرات از شما تاییدیه بگیره.
۶- با به کارگیری فرایند‌های ارتباطی سنتی در سازمان، ارتباط تیم‌های چابک با بقیه سازمان رو مشکل کنید.
۷- جلسات مهم با ذینفعان رو دقیقا در روزهای جلسه بازبینی اسپرینت برگزار کنید.
۸- اطمینان حاصل کنید که ذینفعان مهم و حیاتی هیچ‌وقت در دسترس مدیر محصول نباشن.
۹- اهداف دشوار رو به مدیر محصول تحمیل کنید
۱۰- اصرار کنید که تمام پروژه‌ها باید با یک بودجه، ظرفیت تیمی و بازه زمانی ثابت تکمیل شوند.
اگر ۱۰ روش مستقیم که در بالا گفتیم جواب نداد، بهتره از در پشتی وارد بشید و کاری کنید که تیم‌های اسکرام بدترین عملکرد ممکن رو داشته باشن. این موارد برای آسیب زدن به مدیر محصول و تیم اسکرام پیشنهاد میشه:
۱۱- اجازه مدیریت درون تیمی رو به تیم‌های اسکرام ندید و مستقیما خودتون رو وارد کنید و روی تک تک تسک‌ها میکرومنیجمنت داشته باشید.
۱۲- به تیم توسعه تسک‌های مختلف از پروژه های مختلف محول کنید تا حسابی شلوغ و ناکارآمد بشن. بعد می‌تونید مدیر محصول رو به خاطر ناکارآمدی تیم و کمبود خلاقیت و پیشرفت سرزنش کنید.
۱۳- اعضای تیم‌های مختلف رو دائما عوض کنید یا در وسط اسپرینت افراد جدید رو به تیم معرفی کنید تا هیچ‌وقت هیچ‌کسی روی یک پروژه مسلط نشه و افراد دائما در حال آنبرد شدن باشن.
۱۴- عمدا اعضای تیم اسکرام رو از افرادی انتخاب کنید که به طور واضح با اسکرام زاویه و تضاد دارن.
۱۵- خارج از حوزه اختیار اعضای تیم، به اونها تسک‌های فورس و ad-hoc محول کنید تا حسابی اذیت بشن.
۱۶- همیشه تیم توسعه رو تحت فشار قرار بدید. مستقیما و بدون پرده به اونها بگین که خیلی کند هستند و اصلا از بیزینس سر در نمیارن!
۱۷- انگیز‌های متضاد با کار تیمی رو بین افراد تشویق کنید تا در تیم اسکرام رقابت داخلی ایجاد بشه.
۱۸- هرروز اولویت‌ها رو عوض کنید و همچنان مدیر محصول رو مسئول مستقیم نرسیدن به اهداف بدونید.
۱۹- مطمئن بشین که دسترسی به ابزارها و منابع لازم برای تیم اسکرام رو به حد کافی محدود کردید.
تا اینجای کار حسابی تیم اسکرام رو مورد عنایت قرار دادین و فرهنگشون رو داغون کردید. حالا وقت اینه که چندتا مانع جذاب هم جلوی مسیرشون بذارید تا حسابی به دردسر بیوفتن.
۲۰- اصلا و ابدا به هیچ کسی و هیچ تیمی فیدبک ندید!
۲۱- با فاصله زمانی زیاد و به ندرت به سوالات مدیر محصول پاسخ بدید و اگه خیلی تابلو نبود اصلا به سوالاتش پاسخ ندید.
۲۲- به هیچ وجه چشم‌انداز بازار و اطلاعاتی که دارید رو با مدیر محصول به اشتراک نگذارید، علی‌الخصوص در جلسات بازبینی اسپرینت سکوت مطلق اختیار کنید. بعد می‌تونید مدیر محصول رو سرزنش کنید که چرا این اطلاعات رو نداشته.
۲۳- به ندرت و بسیار نامنظم در جلسات بازبینی اسپرینت شرکت کنید. اگر هم شرکت کردید حتما دیر به جلسه برسید.
۲۴- به هیچ وجه درخواست جلسات مدیر محصول رو قبول نکنید.
۲۵- دسترسی تیم اسکرام به مشتریان رو به طور کامل محدود کنید. اصلا چه معنایی داره که تیم محصول دغدغه‌های مشتری رو بدونه!
۲۶- مطمئن بشید که بازخوردهای مشتری به طور محرمانه نزد تیم فروش نگهداری شده و به هیچ‌وجه در اختیار هیچ تیمی قرار نمی‌گیره.
۲۷- هیچ‌وقت در خصوص تغییرات سازمانی که ممکنه در عملکرد تیم اسکرام تاثیر بگذاره صحبت نکنید. وقتی تغییرات رخ دادن، خودشون متوجه می‌شن!
یکی دیگه از راه‌های ذله کردن مدیران محصول استفاده از اهرم معیارهای اندازه‌گیری و گزارش‌دهی هست. فقط کافیه تمام اعضای تیم اسکرام رو تبدیل به کارمندانی کنید که صبح تا شب وظیفه دارن به شما گزارش‌های عجیب و غریب و چالش بر‌انگیز بدن. چندتا از بهترین روش‌ها در این خصوص:
۲۸- با درخواست گزارش‌های غیرضروری، مستندسازی و وظایف اداری حسابی سر تیم را شلوغ کنید.
29- معیارهای من‌درآوردی خودتان را با متریک‌های استاندارد تیم اسکرام جایگزین کنید
۳۰- از مدیر محصول شواهد پیشرفت پروژه رو طلب کنید. در عین حال تمام معیارهای اندازه گیری ارائه شده توسط تیم اسکرام رو به درد نخور جلوه بدید.
۳۱- جزئیات اینکه دقیقا چه کاری در چه زمانی تمام می‌شود را دائما طلب کنید. اصرار کنید که برنامه توسعه باید با تاریخ و ساعت دقیق تحویل هر بخش ارائه شود و عینا مطابق با آن انجام شود. نه یک دقیقه جلوتر نه یک‌دقیقه عقب‌تر!
یکی از جذاب‌ترین روش‌های ذله کردن مدیر محصول فریب‌کاریه. بنابراین سعی کنید تا جای ممکن اهداف استراتژیک و مسیر رسیدن به اون رو برای مدیر محصول و تیم اسکرام مبهم کنید.
۳۲- به طور منظم اولویت‌ها و تمرکز سازمان رو تغییر بدین!
۳۳- یک چشم‌انداز نامشخص تبیین کنید و دائما اون رو هم تغییر بدید.
۳۴- چشم‌انداز رو به نیازمندی‌های مبهم تفکیک کنید و از شفاف‌سازی اون برای مدیر محصول اجتناب کنید. هر زمان که مدیر محصول درخواست شفاف‌سازی داشت، با لحن حق به جانب بگین که همه چیز شفافه و چیز مبهمی مشاهده نمی‌کنید.
۳۵- مدیر محصول رو با جریان پایان ناپذیر نیازمندی‌ها و درخواست‌ها غرق کنید و خلاص!
۳۶- نیازمندی‌هایی خارج از توان تیم رو از اونها طلب کنید. اگه برای منابع جدید اعلام نیاز کردن بی‌درنگ درخواستشون رو رد کنید. اما با این حال مدیر محصول رو مسئول عواقب شکست پروژه بدونید!
۳۷- به مدیر محصول یادآوری کنید که رتبه شما از اون بالاتره و تمام تصمیماتش رو رد کنید.
۳۸- چندین پروژه مختلف رو به طور همزمان به مدیر محصول محول کنید، سپس شکایت کنید که مدیر‌محصولتون به اندازه کافی روی جزئیات تمرکز نداره.
۳۹- هر وقت خواستید، هرچیزی که خواستید رو شخصا به بک‌لاگ محصول اضافه کنید.
40- روی بک‌لاگ محصول و بهبود‌های آن میکرومنیجمنت داشته باشید. برای مثال، اصرار کنید که حتما در جلسات بک‌لاگ حاضر باشید، اما تعهدی برای حاضر شدن نداشته باشید.
۴۱- اصرار داشته باشید که برای تک تک آیتم‌های بک‌لاگ جزئیات دقیق به شما ارائه بشه.
مالک محصول شما هنوز تیم رو برای توسعه و انتشارها رهبری می‌کنه و هنوز از پا نیوفتاده؟ وقتشه که محافظه‌کار بشین و چندین مرحله تاییدیه قبل از انتشار و تاییدیه‌های امنیتی رو الزامی کنید. البته همه می‌دونن که این کار رو فقط و فقط به خاطر مشتریان‌تون انجام میدین!! از انجام اینکارها غافل نشید:
۴۲- برنامه‌های توسعه رو رد کنید و این بهانه رو بیارید که الزامات رو رعایت نکردن. می‌تونین به خاطر این قضیه مدیر محصولتون رو هم حسابی سرزنش کنید.
۴۳- تسک‌هایی رو مستقیما برای تیم توسعه تعیین کنید که با اهداف اسپرینت هم‌سو نیستند.
۴۴- برای بهترینِ بهترین‌ها تلاش کنید و تا به آن نرسیدید، اجازه انتشار ندید!
۴۵- دستور بدید که یک فرایند تایید چند مرحله‌ای و مجزا در خارج از تیم، برای هر انتشار الزامی بشه.
۴۶- یک هیئت نظارت مجزا برای تایید کیفیت محصول و مشکلات امنیتی ایجاد کنید.
۴۷- پرتکل‌های امنیتی جدیدی رو به تیم اسکرام تحمیل کنید. می‌تونید برای متقاعد کردنشون این بهونه رو بیارید که اینها الزامات قانونی هستن!
برای منافع خود، به سراغ هم‌رده‌هاتون برید. منظورم افرادی هستن که سالهای سال برای ایجاد نتورک باهاشون تلاش کردید. اگر هنوز مالک محصولتون زنده‌ست و ذله یا دیوانه نشده، شاید وقتش باشه که از کسی کمک بگیرید. لینک‌های شما می‌تونن اینطوری کمک‌تون کنن:
۴۸- به طور مستمر در بین سلسله‌مراتب سازمان در خصوص قابلیت‌های مدیر محصول بذر شک و ناامیدی بپاشید.
۴۹- دائما در خصوص قابلیت‌های اسکرام چالش ایجاد کنید. برای اینکار می‌تونید از شکست‌های اسکرام در بقیه سازمان‌ها مثال‌های متعدد بیارید.
۵۰- برای هر شکستی مدیر محصولتون رو به شدت سرزنش کنید و موفقیت‌های تیم اسکرام رو به خودتون نسبت بدید.
اگه همه چیز شکست بخوره، مطمئن باشید که هیچ‌کس سراغ خوندن اصول اسکرام نمی‌ره! از فرایند‌های بودجه بندی برای پیشبرد اهدافتون استفاده کنید. مثلا می‌تونید
۵۱- بودجه رو نصف کنید، اما حجم کار رو ثابت نگه دارید.
۵۲- بودجه رو ثابت نگه دارید ولی حجم کار رو زیاد کنید.
۵۳- فرایند تخصیص بودجه رو بسیار سخت‌تر و طاقت‌فرسا کنید اما فرایند اضافه کردن نیازمندی‌های مسخره رو تسهیل کنید. مثلا می‌تونید با یه تلفن یه نیازمندی رو به تیم تحمیل کنید، اما برای دریافت بودجه کلی کاغذ‌بازی راه بندازید.
این مقاله در حقیقت ترجمه یک مقاله مشابه با نام how to sabotage a product owner نوشته شده توسط stefan wolpers هست. در ترجمه مقاله‌ی آقای ولپرز با بسیاری از بندهای اون خندیدم و بسیاری از بندهاش برام خاطرات تلخی رو زنده کرد که با گوشت و پوستم تجربه کردم. مدیران ناآگاه و بعضا نالایق باعث رقم خوردن این اتفاقات تلخ برای سازمان می‌شن و در نهایت هم اکثر کاسه کوزه‌ها سر مدیر محصول می‌شکنه. بسیاری از مدیران از این مثال نخ‌نما برای افزایش همدلی استفاده می‌کنن و می‌گن که «همه‌مون توی یه کشتی هستیم» اما عملکردشون چیز دیگری رو نشون میده و این شک رو به تیم میده که احتمالا اونا یه جایی از کشتی یه قایق موتوری لوکس برای خودشون قایم کردن. بارها گفتم و بازهم تاکید می‌کنم که اجایل صرفا یک فریم‌ورک نیست. اجایل یک فرهنگ سازمانیه که باید از بالاترین رده تا پایین‌ترین رده به اون پایبند باشن.
