نوشته: رضا تشت بلند زمان مورد نیاز برای مطالعه: 15 دقیقه
این نوشته چند ستاره دارد؟
4
اگر به عنوان مالک محصول کار می کنید ،این مقاله میتواند به شما کمک بسیاری کند. این لیست شامل متداول ترین ضد الگوی های مالک محصول است و میتواند نقطه شروع بسیار خوبی باشد.
از این رو، اگر برخی از الگوهای ضد کار را در کارهای روزمره خود تشخیص می دهید، چرا از بقیه تیم Scrum درخواست کمک نمی کنید؟ لیست ضد الگوهای Product Owner نقطه شروع خوبی برای بررسی روش های کاری گذشته است.
نقش صاحب محصول طبق راهنمای اسکرام
“مالک محصول مسئول به حداکثر رساندن ارزش محصول ناشی از کار تیم توسعه است.” راه اصلی دستیابی به این هدف به عنوان PO، مدیریت بک لاگ محصول است. طبق راهنمای اسکرام،
این فعالیت شامل موارد زیر است:
بیان واضح موارد موجود در بک لاگ محصول.
مرتب کردن موارد موجود در بک لاگ محصول برای دستیابی بهتر به اهداف و مأموریت ها.
بهینه سازی عملکرد تیم توسعه و ارزش کاری که انجام می دهد ؛
اطمینان از قابل مشاهده بودن، شفاف بودن و واضح بودن بک لاگ محصول برای همه و نشان می دهد تیم Scrum در آینده بر روی چه مواردی کار خواهد کرد.
اطمینان از اینکه تیم توسعه موارد موجود در بک لاگ محصول را به خوبی درک کرده اند.
از نظر من، بیشتر ضد الگو های مالک محصول ناشی از عدم مدیریت کافی بک لاگ محصول است.
ضد الگوها
انبار ایده ها
مالک محصول از بک لاگ محصول به عنوان مخزن ایده ها و محلی برای لیست کردن نیازها استفاده می کند. (این کار باعث قفل شدن بک لاگ محصول میشود و ممکن است منجر به اضافه بار شناختی شود و همسویی با نقشه کلان محصول و برنامه ریزی نقشه راه را بسیار مشکل کند.)
مالک محصول پاره وقت
مالک محصول روزانه بر روی بک لاگ محصول کار نمی کند. ( بک لاگ محصول لازم است در هر زمان لازم به روز باشد و میزان کار انجام شده توسط تیم را نشان دهد. به روزرسانی آن، یک بار در هفته و یا قبل از جلسه retrospective کافی نیست.)
! بگیر و بچسبون
مالک محصول، همان اسنادی را که از مدیران ارشد شرکت و یا کارفرما دریافت می کند را به بخشهای کوچکتر تقسیم میکند و داستانهای کاربر را ایجاد می کند. (به یاد داشته باشید: ایجاد داستان کاربر یک تمرین تیمی است.)
مالک محصول دیکتاتور
مالک محصول تنها به گفتن “چرا” در مورد داستانهای کاربر بسنده نکرده و بلکه “چگونه” و “چه” را نیز در مورد داستان های کاربر را خودش ایجاد می کند. (تیم به سوال “چگونه” – پیاده سازی فنی – پاسخ می دهد، و هر دو، تیم و PO در مورد “چه” همکاری می کنند: چه محدوده ای برای دستیابی به هدف مورد نظر لازم است.)
اولویت بندی توسط ذینفعان
یک ذی نفع یا کمیته ذینفعان ویژگی های اصلی محصولات را اولویت بندی میکند. (قدرت اسکرام بر پایه موقعیت محکم مالک محصول است. مالک محصول تنها کسی است که تصمیم می گیرد چه مواردی از بک لاگ محصول در دستور کار قرارگیرد. از این رو، مالک محصول در مورد اولویت تصمیم می گیرد. این قدرت را بردارید، اسکرام تبدیل می شود به یک فرایند آبشار بسیار قوی.)
اطمینان کاذب
تیم Scrum یک Backlog محصول ایجاد می کند که پروژه یا محصول را کامل پوشش می دهد زیرا تصور میکنند که ویژگی های آن محدود است. (سوال: چگونه می توانید مطمئن باشید که امروز می دانید در شش ماه دیگر چه چیزی را تحویل دهید؟)
سنگ بزرگ
بک لاگ محصول شامل مواردی است که تیم اسکرام نمی تواند در سه تا چهار اسپرینت آنها را تحویل دهد. (به این ترتیب مالک محصول با انباشت مسائلی که ممکن است هرگز محقق نشود، بک لاگ محصول را به زباله دانی تبدیل میکند)
موارد تاریخ مصرف گذشته
بک لاگ محصول شامل مواردی است که از شش تا هشت هفته یا بیشتر از زمان آخرین بررسی آنها گذشته است (این زمان به طور معمول باید بین ۲ تا ۴ اسپرینت باشد. اگر مالک محصول اقلام تاریخ مصرف گذشته را هنوز در بک لاگ محصول نگهداری می کند ، این خطر وجود دارد که مواردی را که تحویل داده اند قدیمی شده و تیم همچنان درگیر توسعه اقلام از رده خارج شده است)
همه چیز تخمین زده می شو
زمان تمام داستان های کاربر در بلاگ محصول در ابتدا کار خمین زده میشود (این کار خیلی عجولانه است و خطر تخمین نادرست زمان توسط تیم اسکرام را دارد.)
اقلام مبتنی بر کامپوننت
موارد بک لاگ محصول بر اساس کامپوننت و نه بر اساس ویژگی های مهم، برای بخش های سازمانی شما تقسیم بندی می شوند. (این امر ممکن است به دلیل ساختار سازمانی شما باشد. تیم های چند منظوره را تشکیل دهید تا توانایی و عملکرد تیم ها را بهبود ببخشید. در غیر این صورت ،تیم و مالک محصول باید در دوره آموزشی در زمینه نوشتن داستان های کاربر شرکت کنند.)
از دست دادن معیارهای پذیرش
داستان های کاربری در بلاگ محصول بدون معیارهای پذیرش وجود دارد. (داشتن معیارهای پذیرش در ابتدای چرخه توسعه ضروری نیست، اگرچه وجودش کار را بسیار آسان می کند. در هر حال، در پایان، همه داستان های کاربر باید تعریف استاندارد را داشته باشند و معیارهای پذیرش بخشی از این تعریف است.)
نه بیشتر از یک عنوان
بک لاگ محصول شامل داستان های کاربری است که کمی بیشتر از یک عنوان ساده است. (به بالا نگاه کن.)
مشکلات بیش از حد دقیق
مالک محصول در داستان های کاربر زمان زیادی را صرف می کند تا جزئیات آنها بیش از حد مشخص شود. (اگر داستان کاربر کامل به نظر برسد، اعضای تیم ممکن است ضرورتی برای درگیر شدن و اصلاح داستان را نبینند. به این ترتیب یک داستان کاربر “بزرگ” سطح تعامل تیم را کاهش می دهد و ایجاد یک درک مشترک را به خطر می اندازد.)
themes و epicsبدون
بک لاگ محصول با توجه به ساختار themes و epics ساخته نشده است. (این کار یکپارچه سازی هر بخش را با “Big Picture” سازمان را دشوار می کند.)
ضد الگوهای برنامه ریزی اسپرینت
لیست شماره دو
ضد الگوهای مــالک محصول, بـــــرنامه ریزی اسپرینت است
مابرای چه میجنگیم؟ مالک محصول نمی تواند هدف تجاری اسپرینت های بعدی را با چشم انداز کلی محصول همسو کند. (یک هدف جدی به سوال "ما برای چه می جنگیم؟" پاسخ می دهد. تا حدی، همچنین مذاکره ای بین مالک محصول و تیم توسعه است.)
بدون اهداف تجاری، بدون هدف اسپرینت
مالک محصول مواردی را به عنوان ویژگیهای محصول پیشنهاد می کند که شبیه مجموعه ای تصادفی از وظایف است و هیچ انسجامی بین آنها ورود ندارد. در نتیجه، تیم اسکرام هدفی برای پایان اسپرینت ایجاد نمی کند. (اگر این روش معمول برای اتمام برنامه ریزی Sprint شما باشد،احتمالا اسکرام برای شما مفید نمیباشد. بسته به بلوغ محصول شما، Kanban ممکن است راه حل بهتری باشد. در غیر این صورت، تصادفی بودن ويژگی های محصول ممکن است نشان دهد یک مالک محصول ضعیف که به جای ایجاد مناسب بک لاگ محصول، بیش از حد به سهامداران گوش می دهد.)
کار ناتمام
داستانهای کاربر ناتمام و سایر وظایف مربوط به آخرین Sprint بدون هیچ گونه بحثی به Sprint جدید سرازیر می شود. (ممکن است دلایل خوبی برای این امر وجود داشته باشد ، به عنوان مثال ، ارزش یک کار تغییر نکرده است. هر چند نباید اتوماتیک باشد ،هزینهغرقشده را به خاطر بسپارید.)
تغییرات لحظه آخری
مالک محصول سعی می کند برخی از موارد بک لاگ محصول را در آخرین لحظه وارد اسپرینت کند. (اصولاً ، ایجاد چنین تغییراتی برای اطمینان از اینکه تیم توسعه فقط در مورد ارزشمندترین کارها در هر زمان مشخص کار می کند ، از اختیار صاحب محصول است. اگر این موارد به طور مکرر اتفاق می افتد ، نشانگر این است که مالک محصول در زمینه بررسی ویژگی های محصول و ارتباطات تیمی به کمک نیاز دارد. یا مالک محصول برای گفتن “نه” بیشتر به ذینفعان به پشتیبانی نیاز دارد.)
تمرکز بر توسعه
مالک محصول مسئولیت تیم توسعه را به عهده می گیرد تا وظایف بیشتری از آنچه که واقعاً تیم می تواند انجام دهد را بر عهده آنها بگذارد و انجام دهند.(این همچنین راهی برای تبدیل شدن تیم به یک کارخانه ویژگی است و اسکرام مستر باید به این موضوع توجه کند.)
عدم آماده سازی
مالک محصول برای تحویل موارد با ارزش بیشتر برای انتخاب توسط تیم توسعه ، بک لاگ محصول را تهیه نمی کند. (بک لاگ محصول باید نشان دهنده بهترین وضعیت ممکن از کار تیم توسعه از منظر ارزش مشتری در هر لحظه باشد. به عبارت دیگر ، بک لاگ محصول تیم اسکرام شما باید 24/7 قابل مشاهده و به روز باشد)
ضد الگوهای Sprint
- یکی دیگر از مناطق مستعد ضد الگوهای مالک محصول ، خود اسپرینت است:
مالک محصول فراری
مالک محصول در بیشتر زمان های اسپرینت غایب است و برای پاسخگویی به سوالات تیم توسعه در دسترس نیست. (از آنجایی که بک لاگ اسپرینت ممکن است تغییر کند و کارهای جدید برای دستیابی به هدف Sprint ضروری شناخته شود، این نگرش ممکن است تیم توسعه را در معرض خطر قرار دهد و تحقق هدف Sprint را به خطر بیندازد.)
چسبیدن به وظایف
مالک محصول نمی تواند اقلام بک لاگ محصول را پس از تبدیل شدن به بخشی از بک لاگ اسپرینت رها کند. به عنوان مثال ، مالک محصول دامنه یک نیاز را افزایش می دهد یا هنگامی که تیم موضوع را به عنوان بک لاگ اسپرینت پذیرفت ، معیارهای پذیرش را تغییر می دهد. (یک اصل واضح وجود دارد: قبل از اینکه یک آیتم بک لاگ محصول به بخشی از بک لاگ اسپرینت تبدیل شود ، مالک محصول مسئولیت آن را بر عهده دارد اما هنگامی که از یک بک لاگ محصول به بک لاگ اسپرینت منتقل می شود ، تیم توسعه مسئولیت آن را بر عهده می گیرد و تیم توسعه به در مورد نحوه اداره آنها تصمیم خواهد گرفت.)
انعطاف پذیر نیست
مالک محصول در تنظیم معیارهای پذیرش انعطاف پذیر نیست. (اگر در انجام یک کار مشخص شود که معیارهای پذیرش توافق شده دیگر غیرقابل دستیابی است ، تیم اسکرام باید با واقعیت جدید سازگار شود. پیروی کورکورانه از طرح اصلی اصول اصلی اسکرام را نقض می کند.)
به تأخیر انداختن تحویل اقلام آماده شده
مالک محصول پس از اتمام مواردی از بک لاگ اسپرینت آن موارد را قبول نمی کند. در عوض ، او منتظر می ماند تا اسپرینت به پایان برسد و تمامی موارد را با یکدیگر تحویل بگیرد. (مالک محصول باید فوراً اقلام آماده شده را که مطابق با معیارهای پذیرش هستند بررسی کرده و تحویل بگیرد . در غیر این صورت ، مالک محصول یک صف غیر واقعی در Sprint ایجاد می کند ، که باعث می شود بی جهت زمان تحویل افزایش یابد. این رفتار رسیدن به هدف Sprint را نیز در معرض خطر قرار می دهد.)
سوء استفاده از قدرت در لغو اسپرینت
مالک محصول اسپرینت را لغو می کند تا اراده خود را به تیم تحمیل کند. (لغو اسپرینت از اختیارات مالک محصول است. با این حال ، مالک محصول نباید این کار را بدون دلیل جدی انجام دهد. مالک محصول نیز هرگز نباید قبل از مشورت با تیم توسعه ، اسپرینت را لغو کند.ممکن است تیم برای پایان دادن به اسپرینت ایده ای داشته باشد ، سوء استفاده از اختیار لغو اسپرینت نشان دهنده یک مشکل سئله جدی در همکاری تیمی است.)
عدم لغو اسپرینت
مالک محصول اسپرینت را که دیگر نمی تواند به هدف اسپرینت برسد را لغو نمی کند. (به عنوان مثال ، یک روش پرداخت جدید را اضافه می کند ، و سپس مدیریت آن روش پرداخت را در اواسط اسپرینت کنار می گذارد. در این حالت ، مالک محصول باید امکان لغو اسپرینت را در نظر بگیرد.)
ضد الگوهای PO در طول جلسات اسکرام روزانه
در مقایسه با سایر رویدادهای اسکرام ، Daily Scrum به طور قابل توجهی در برابر ضد الگوهای مالک محصول مقاوم است:
جلسه برنامه ریزی
مالک محصول در جلسه روزانه اسکرام شرکت می کند تا درباره نیازهای جدید بحث کند، داستان های کاربر را اصلاح کند و به این شکل یک نوع جلسه برنامه ریزی میکرو (Sprint) داشته باشد.
گفتگو مالک محصول
مالک محصول به طور فعال در Daily Scrum شرکت می کند. (مالک محصول و سهامداران قرار است به صحبت های اعضای تیم توسعه در هنگام بارگذاری جلسه اسکرام روزانه گوش دهند اما آنها را منحرف نکنند.)
ضد الگوهای Sprint Review
سرانجام در انتهای لیست ضد الگوها، Sprint Review قرار دارد. علی رغم اینکه این یک فرصت عالی برای مالک محصول است که می تواند همکاری بین سهامداران و تیم توسعه را بهبود بخشد و بطور جمعی بفهمد محصول را در چه جهتی می برد ، برخی از مالکان محصول این پیام را دریافت نمی کنند.
تنها من
صاحب محصول موفقیتهای “خود” را به ذینفعان ارائه می دهد. (جمله قدیمی را بخاطر بسپارید: “من” در “تیم” وجود ندارد)
دریافت نیازمندی ها
مالک محصول از Sprint Review برای دریافت وظایف یا موارد باقیمانده محصول استفاده می کند.
مالک محصول یک دنده
مالک محصول نظرات سهامداران یا تیم توسعه را نمی پذیرد. (چنین رفتاری هدف اصلی رویداد Sprint Review را نقض می کند.)
نتیجه
مسلماً نقش مالک محصول چالش برانگیزترین نقش اسکرام است و هرچه انتظارات بیشتر باشد ، شکست آنها آسان تر خواهد بود. با این وجود ، مفهوم بهبود مستمر در مورد نقش مالک محصول نیز صدق می کند. لیست ضد الگوهای مالک محصول در بالا ممکن است یک نقطه شروع باشد.
چه ضد الگوهای مالک محصول را مشاهده کرده اید که در لیست وجود ندارد؟ لطفا با ما در نظرات به اشتراک بگذارید.
به مدیریت علاقه مند هستم و عاشق برنامه نویسی، معتقدم ندانسته هام بسیار زیادن و برای کم کردنشون هر روز تلاش میکنم و در تلاشم با کمک دیگر همکارانم بهبودی هر چند کوچک در مدیریت ایجاد کنم.
مطلب مفیدی برای شما بود ؟؟ پس به اشتراک بگذارید برای دوستانتان
سوفرولوژی هم مثل مدیتیشن، یوگا و تمرینهای تنفس اثری جادویی بر آرام شدن و تعادل سیستم عصبی فرد در محیط کار دارد و در کوتاه مدت میتوانید نتیجه خوبی از آن بگیرید.
مقاله بسیار کاربردی ای بود . از شما سپاسگذارم.