یا مثلاً چگونه مدیر محصولِ بهتری برای تیم باشیم؟

همیشه فکر می‌کردم به عنوان مدیر محصول اصلی‌ترین وظیفه‌ برای تیمم و شرکت، ایجاد یک مسیر درست قابلِ توسعه‌ست. فکر می‌کنم این‌که عملکرد تیم و در مقیاس بزرگ‌تر شرکت بهتر بشه بر می‌گرده به انجام یه سری کارهای ساده و دقیق. کارهایی که به راحتی می‌شه به مرحله انجام برسه و نتیجه‌اش خیلی عجیب و زیاد به بهبود مسیر کمک می‌کنه. در این‌جا سعی کردم اون یه سری نکات ساده ولی مهم مربوط به تیم اسکرامی رو بگم: ۱. در نوشتن یوزر استوری‌ها از As a System استفاده نکنیم! یوزراستوری قرار است در یک جمله برای افراد تیم شرح بدهد که این فیچر برای چه کسی زده‌ شده، آن فرد با این فیچر چه‌کاری بتواند انجام دهد و این‌کار چه ارزشی برایش ایجاد می‌کند. یکی از عادت‌های غلط، تبدیل "چه کسی به چه چیزی" است. اسکرام سعی می‌کند اهمیت افراد ذی‌نفع در تمام مراحل دیده شود و رفتن به سمت خواسته‌های آنها پر رنگ‌تر باقی بماند. در دمو نیز با دعوت از افراد ذی‌نفع بخش انتهایی این پازل را درست می‌کند. حال اگر در ابتدا و در گفتن سناریویی که علت شروع این فیچر است کاربر دیده نشود و تنها از دید سیستم باشد نه تنها بخش پراهمیت کاربران دیده نشده، بلکه تیم به درستی با دلایل و ایجاد این فیچر آشنا نمی‌شوند. در صورت که یوزر استوری کامل و روشنی داشته‌باشیم، در طول اسپرینت افراد تیم را می‌بینیم که نظرات و فیدبک‌های مفیدی می‌دهند که برای محصول در حال توسعه بسیار ارزشمند است.۲. در دیلی‌ها با افراد تیم بحث نکنیم! اسکرام‌مستر برگزارکننده بدون بحث دیلی‌هاست. صبحِ بچه‌های تیمتان را تلخ نکنید. در دیلی‌ها که هر روز سر ساعت مخصوصی برگزار می‌شود، بچه ها درباره تسک‌ها و مشکلات روز قبل و همان روز بقیه افراد تیم را آپدیت می‌کنند. برگزارکننده این جلسه اسکرام‌مستر است و مدیر محصول نیز سوالات خود را مطرح می‌کند. اما اگر روزی دیدید شما به جای اسکرام‌مستر جلسه را برگزار کردید و از بچه ها تک به تک توضیح خواستید، جایی از این راه را به بی‌راهه رفته‌اید.۳. در صورت شکستن محصول و استفاده از روش اسکوادی، جدا از تیم خود ننشینیم! در بعضی از شرکت‌ها مدیر محصول‌ها و تیم محصول جدا از تیم فنی می‌نشینند. این اتفاق باعث جدایی میان افرادی که ایده و ساخت اولیه محصول را دارند و افرادی که آن را توسعه می‌دهند می‌شود. در صورتی که مدیر محصول در کنار تیم فنی خود بنشیند حتی دیگه نیازی به جلسات فشرده، الزاما در اتاق جلسه و به شکل بک‌لاگ ریفایمنت نیست.۴. از دمو نترسیم! بسیاری از مدیر محصول‌ها به دلیل احتمال وجود باگ در دمو، آن را انجام نمی دهند یا به دموی اسپرینت بعدی موکول می‌کنند. این کار باعث می‌شود که بچه های تیم نتیجه کار خود را با تاخیر ببینند، مشغول موضوع جدیدی شوند که هنوز موضوع قبلی مورد استفاده قرار نگرفته و حتی ذی‌نفعان داخلی شرکت هم آن را ندیده‌اند. ممکن است به علت فشار بیزینسی، محصول زودتر از دمو اسپرینت بعد مورد استفاده کاربران قرار بگیرد و عملا در دمو هفته بعد محصولی که به مرحله پروداکشن رفته دمو شود و تمام لذت دید اولیه محصول و دمو از بین برود.۵. واسطه میان بچه‌های تیممان نشویم!باگ از تست یوزر استوری برگشته‌است. تِستر با خود تیم فنی مشکل را مطرح کند؟ قطعاً. بگذارید افراد تیم با یکدیگر صحبت کنند و مشکلاتشان را مطرح کنند. در بعضی از شرکت‌ها مدیر محصول‌ مسئول هماهنگی و انتقال حرف‌های بچه‌های فنی و تست به صورت کامل به همدیگر می‌شود. تا وقتی این اتفاق بیافتد افراد تیم همیشه به حضور شما وابسته هستند، هیچ‌وقت به صورت یک تیم خود را نمی‌بینند و از مرحله قبل و بعد کارشان در تیم و احتمال وابستگی افراد به کار مطلع نمی‌شوند. در پایان هم زمان و انرژی شما بیشتر به عنوان مدیر پروژه صرف شده‌ست نه مدیر محصول. ۶. تیم و خودمان را مجبور به نوشتن مستندات با فرمت یکسان و متن‌های طولانی نکنیم! در بسیاری از موارد Acceptance Criteria نوشته‌ نمی‌شود چون مدیر محصول وقت نداشته عکسی که از تخته گرفته و شامل Criteria بوده را پاک‌نویس و در یوزر استوری داکیومنت کند. مدیر محصول سناریوی اپیک یادش می‌رود چون دست‌نوشته‌های کاغذیش را گم کرده و وقت تایپ‌ کردن همه آنها را برای خودش نداشته. اگر برای تسک‌ها و ساب‌تسک‌ها نیاز به توضیحی است، حتما لازم نیست با روشی ثبت شود که نیاز به زمان و انرژی مضاعف داشته‌ باشد. مدیر محصول می‌تواند یک عکس از تخته را با توضیحات هر چند کم به یوزر استوری اضافه کند و استوری را برای تیمش روشن کند. ۷. نظر تیمِ فنی را از طراحی محصول حذف نکنیم! اصلی‌ترین این نظرات می‌تواند خیلی ساده در اتاق اسکواد که هم افراد فنی هستند و هم مدیر محصول مطرح شود. در Product backlog refinement یا Grooming که در وسط هفته‌ی قبل از شروع اسپرینت جدید انجام می‌شود، آغاز این تبادل نظرات می‌تواند باشد اما آن را محدود نکنید. اجازه بدهید این نظردهی در پروسه پیاده‌سازی و حتی تا بعد از پیاده‌سازی محصول باشد. ابراز این کار می‌تواند یک کاغذ روی دیوار یا روی برد تیم فنی باشد که نظراتشان را درباره بهبود فیچری که خودشان پیاده‌سازی کرده‌اند بگویند. درباره اهمیت فیچر و تاثیرش بر روی کاربر با آنها حرف بزنید.۸. یوزراستوری‌ها باید شامل (DOD (Definition of Done باشند. اهمیت DOD وقتی معلوم می‌شود که در صورت نبود، پیاده‌سازی یوزر استوری تمام شده‌ست ولی استوری هنوز بسته نشده‌است. یا بسته شده‌ست ولی محصولی قابل نمایش با معیارهای خواسته‌شده بیزینس نیست.۹. اگر تیم از تخمین زمانی برای یوزراستوری‌ها استفاده می‌کند، مدل تخمینشان را ناگهانی به عدد فیبوناچی تبدیل نکنیم! بسیاری از شرکت‌ها برای شروع اسکرام از زمان (ساعت یا روز) برای تخمین استفاده می‌کنند. بعد از یک دست شدن تیم که برای هر شرکت زمانش متفاوت است، نیازی به زمان گرفتن از بچه‌های تیم نیست. حدوداً به اندازه بیشتر از دو هفته بر اساس دید خودتون، یوزر استوری برای پلنینگ آماده کنید و اجازه بدهید افراد تیم یوزر استوری‌ها رو انتخاب کنند. یوزر استوری‌ها انتخاب شده و مدت زمانی که باید انجام شوند (دوهفته) هم برای کل تیم معلوم است. این اتفاق باعث می‌شود افراد تیم از مدل زمان دادن، به سرعت مجبور نشوند تا با مدل سختی به تسک‌ها مقدار بدهند و بین دو مرحله زمانی برای تیم آماده کرده‌اید تا برای تبدیل زمان به تعیین سختی زمانی را داشته‌باشند.