آیا PBIهایی که در پایان اسپرینت Done میشوند، واقعاً ارزش ایجاد میکنند؟ آیا اولویت اول بکلاگ، واقعا جایگاه اول را دارد؟ اگر اولویت اول بکلاگ با اهمیت بالا در زودترین زمان، توسط تیم توسعه انجام شود، برای سازمان ارزش ایجاد میکند؟
در چارچوب اسکرام، برای تیمهای اسکرام مهم است که تا جایی که میتوانند یک Increment ارزشمند ارائه دهند - حداقل یک بار در هر اسپرینت. بدون ارائه Increment، آگاهی یافتن در مورد چیزهای دیگری که نیاز است و همچنین برای کاهش ریسک کار پیچیده، دشوار است. مالک محصول مسئول به حداکثر رساندن ارزش کار انجام شده توسط تیم توسعه است. در حالی که این موضوع در ظاهر بسیار درست به نظر میرسد، در دنیای واقعی چه معنایی دارد؟ در محیط کار خودتان چه معنایی دارد؟ آیا شما میتوانید به این سوال ها جواب دهید؟
مسلما پاسخ به این سوالات دشوار است. راهنمای اسکرام هوشمندانه از تعریف "ارزش" دوری میکند و استدلال میکند که تعریف ارزش به زمینه محصول و ذینفعانی بستگی دارد که کار برای آنها انجام میشود. و در حالی که من شایستگی آن تصمیم را می بینم، چگونه یک تیم اسکرام میتواند با اسکرام موثر باشد، وقتی که تعریفی از ارزش ندارد؟
من به راحتی میتوانم یک تیم اسکرام را تصور کنم که از طریق اسپرینتهای خود به خوبی کار میکند، در هر اسپرینت، Increment های باکیفیت را به ذینفعان خود ارائه میکند، اما در واقع هیچ چیز ارزشمندی را به سازمان ارائه نمیدهند. در واقع، این همان چیزی است که ما اغلب در موارد زامبی اسکرام شدید میبینیم.
اگرچه همه از طریق حرکات درست، در مسیر پیش میروند، اما در پایان هیچ چیز ارزشمندی وجود ندارد. "انجام اسکرام" (Doing scrum) به طور جادویی منجر به ایجاد ارزش نخواهد شد.
هر زمان که چارچوب اسکرام در مورد "ارزش" صحبت میکند، به معاملات بین تیم اسکرام و ذینفعان آن اشاره دارد. ذینفعان افرادی هستند که سهم واقعی در محصول دارند. ما قصد داریم در مورد "ارزش تجاری" صحبت کنم، حتی اگر راهنمای اسکرام آن را "ارزش" مینامد. این عنوان، تأکید میکند که کاری که یک تیم انجام میدهد باید به نحوی برای سازمان یا کسب و کار به طور کلی منفعت و سود داشته باشد. اما توجه داشته باشید که این موضوع چقدر مبهم است. خوشبختانه، وقتی صحبت از "ارزش تجاری" میشود، تعاریف قابل استفاده زیادی در ادبیات و اینترنت وجود دارد. تعریف زیر، تعریفی است که ویکی پدیا ارائه کرده است:
ارزش تجاری یک اصطلاح غیررسمی است که شامل تمام اشکال ارزشی است که سلامت و رفاه شرکت را در بلند مدت تعیین میکند.
اگرچه این تعریف به این نکته بارز اشاره میکند که وقتی چیزی بر طول عمر یک سازمان تأثیر مثبت میگذارد، ارزش تجاری دارد، اما هنوز کاملاً مبهم و گسترده است. وقتی وارد جزئیات ظریف راهاندازی یک product backlog و تعیین ارزش تجاری هر epic ، story یا آیتم موجود در بکلاگ میشویم، کمکی به ما نخواهد کرد. به زبان ساده؛ ما باید راهی برای تعیین اینکه آیا اقلام در لیست بکلاگ «مورد درست» یا « مورد اشتباه» است؛ داشته باشیم. همچنین هنگام اولویتبندی باید بتوانیم بگوییم که آیا این «زمان مناسب» است یا «زمان اشتباه».
اسکرام برای توسعه نرم افزار طراحی شده است، اگرچه میتوان آن را به راحتی در انواع دیگر کارها اعمال کرد. ما میتوانیم چندین نوع ارزش را که میتوان برای کسبوکار/ سازمان ایجاد کرد را، با کاری که یک تیم در یک اسپرینت انجام میدهد، مشخص کنیم. یک لیست از انواع ارزشها در ادامه خواهیم گفت.
ارزش تجاری بارزترین ارزش است و شامل عملکرد یا کاری است که مستقیماً به سود تبدیل میشود، مانند:
سوال کلیدی این است که "این کار چقدر درآمد یا سود دارد؟"
ارزش بازار تعداد مشتریان بالقوه را افزایش میدهد، مانند:
سوال کلیدی این است که "به چند مشتری جدید میتوانیم خدمت کنیم؟"
ارزش کارایی باعث افزایش کارایی سازمانی و در نتیجه کاهش هزینههای عملیاتی میشود، مانند:
سوال کلیدی که باید بپرسیم این است که "این کار چقدر زمان یا پول ما را نجات میدهد؟"
ارزش مشتری این احتمال را افزایش میدهد که مشتریان فعلی شما، همچنان از محصول شما استفاده کنند ("بهتر بچسبند")، مانند:
سوال کلیدی در اینجا این است که "این امر تا چه اندازه احتمال خروج مشتری را کاهش میدهد؟"
ارزش آینده با سرمایهگذاری در نوآوری و یادگیری در زمان حاضر، شانس دستیابی آسانتر به یکی از ارزشهای فوق را در آینده (نزدیک) افزایش میدهد، مانند:
سوال کلیدی که در اینجا باید پرسید این است که "این کار چقدر در زمان یا پول ما در آینده صرفه جویی میکند؟"
سوال کلیدی هر بخش به شما کمک میکند که در حین انتخاب دسته ارزش برای هر آیتم بکلاگ، با پاسخ دادن به آن سوال، مطمئن شوید که آیا این آیتم بعد از تکمیل، واقعا این ارزش را ایجاد خواهد کرد؟
یک مالک محصول باید بتواند برای هر مورد از ارزشها در بکلاگ محصول یک آیتم قرار دهد. و باید بتواند آنها را به ارزش (تجاری) برای سازمان تبدیل کند.
به زبان ساده؛ تمام کارهایی که یک تیم انجام میدهد باید به یکی از ارزشهای تجاری ذکر شده در بالا، تفسیر شود تا ثابت شود که "موارد مناسب در زمان مناسب" است. اگر اینطور نیست، یا اگر آیتم بکلاگ به اندازه کافی قوی نباشد، مالک محصول نباید تیم را مجبور کند برای آن وقت بگذارند.
در همین راستا برای ارزیابی و اندازه گیری ارزش خلق شده محصول، پارامترهایی مشخص در مفهومی به نام مدیریت ارزش کسب شده تعریف شده است که در ادامه بیشتر توضیح خواهیم داد.
مدیریت ارزش کسب شده (Earned Value Management) تکنیکی برای اندازهگیری عملکرد و پیشرفت یک پروژه بر اساس محدوده، زمانبندی و هزینه آن است. با این حال، به کارگیری EVM در محصولات قابل تحویل چابک میتواند چالش برانگیز باشد، زیرا پروژههای چابک پویاتر، تکراریتر و مشتریمدارتر از پروژههای سنتی هستند.
ارزش برنامهریزی شده (PV)، ارزش کاری است که قرار است تا تاریخ معینی در پروژه تکمیل شود. به عبارت دیگر این پارامتر نشان میدهد که چگونه انتظار دارید بودجه پروژه خود را در طول مدت پروژه کسب کنید.
PV = number of story or value points planned to be completed (each iteration) × average cost per story or value point
ارزش کسب شده (EV)، ارزش کاری است که تاکنون در پروژه انجام شده است.
EV = number of story or value points completed (each iteration) × average cost per story or value point
ارزش کسب شده، منعکس کننده پیشرفت و عملکرد واقعی پروژه و همچنین رضایت مشتری و ارزش ارائه شده است.
بودجه پایانی یا تکمیلی (BAC) کل هزینه برنامهریزی شده پروژه است.
BAC = number of story or value points in the planning package × average cost per story or value point
میانگین هزینه هرstory points را میتوان از دیتاهای هیستوریک، بنچ مارک یا نظر کارشناسان استخراج کرد. از طرف دیگر، برای محاسبه BAC میتوانید از تعداد کل امتیازهای ارزش (value points) در پکیج برنامهریزی که منظور همان بکلاگ اسپرینت میباشد، و هزینه متوسط هر value points استفاده کنید.
هزینه واقعی (AC) نشان دهنده آن چیزی است که برای تکمیل کار در طول پروژه خرج میکنید.
در محصول و پروژه خود میتوانید به این معیارها از نظر بودجه و برنامه، فکر کنید.
Story point و Value point دو روش برای تخمین اندازه و ارزش محصولات قابل تحویل چابک هستند. Story point معیاری نسبی از تلاش، پیچیدگی و عدم قطعیت مربوط به تکمیل یک user story یا یک ویژگی است. Value point معیاری نسبی از ارزش کسب و کار، اولویت و رضایت مشتری هستند که توسط user story یا یک ویژگی ارائه میشود.
با استفاده از روشهای مختلفی، مانند planning poker, affinity estimation, t-shirt sizing میتوان، Story point و Value point را به هر آیتم در بکلاگ اسپرینت خود اختصاص دهید.
در ادامه باید به این بپردازیم که چگونه میتوان ارزش به دست آمده را برای محصولات قابل تحویل چابک با استفاده از برخی سازگاریها و بهترین شیوهها اندازهگیری کرد. به عبارت دیگر چگونه میتوان نمود واقعی و عملی ارکان اساسی چابک یعنی بازرسی و انطباق را در ارزیابی ارزش خلق شده محصول، مشاهده کرد. (استفاده از چرخه Inspect و Adapt). بطور کلی 6 گام برای رسیدن به این موضوع تعریف شده است. توجه داشته باشید که جزئیات در نحوه اجرای این گامها، برای هر محصول میتواند بسته به ماهیت محصول و شرایط تیم متفاوت باشد، ولی دستورالعملهای اجرایی باید بطور کامل درون تیم و سازمان شفاف باشد. (رکن اساسی سوم در چابک، شفافیت (transparency) میباشد.)
1) پکیج برنامهریزی یا همان بکلاگ اسپرینت را تعریف کنید.
2)تعیین Story point و Value point.
3) بودجه تکمیلی را محاسبه کنید.
4) ارزش کسب شده را دائما دنبال و پیگیری کنید.
5) ارزش کسب شده را با ارزش برنامهریزی شده و هزینه واقعی مقایسه کنید.
6) برنامه خود را تنظیم و بهبود ببخشید.
یکی از مزایای پروژههای چابک این است که امکان بازخورد مکرر، انطباق و بهبود را فراهم میکند. شما میتوانید از معیارها و شاخصهای EVM برای شناسایی و رسیدگی به مسائل، خطرات یا فرصتهایی که ممکن است در طول پروژه ایجاد شود، استفاده کنید. همچنین میتوانید از آنها برای برقراری ارتباط و گزارش وضعیت و پیشرفت پروژه به ذینفعان و مشتریان استفاده کنید. با اندازه گیری ارزش به دست آمده برای محصولات قابل تحویل چابک، میتوانید اطمینان حاصل کنید که پروژه شما ارزش ارائه میدهد، انتظارات را برآورده میکند و در مسیر باقی میماند.
گام اول این چرخه، تهیه بکلاگ اسپرینت مناسب هست. که با توجه به اولویتبندی صحیحی که انجام میشود، به این اطینان برسیم اولویتهای بالای بکلاگ محصول، "مورد مناسب در زمان مناسب است". و در نهایت از لیست اولویتبندی شده، برای هر اسپرینت یک پکیج برنامهریزی یا همان بکلاگ اسپرینت مناسب خروجی بگیریم.
تا کنون روشهای زیاد و متنوعی برای اولویتبندی بکلاگ محصول توسط متخصصان این حوزه در دنیا، ارائه شده است، که با یک جستجوی ساده در اینترنت، میتوانید برای یادگیری و استفاده در محصول خود، در جزئیات روش، عمیق شوید و بنا ماهیت محصول و شرایط فعلی محصول و تیم توسعه خود، یکی از روشها را برای اولویتبندی بکلاگ خود انتخاب کنید. توجه کنید که هرکدام از روشها معایب و مزایای متفاوتی دارد و نکته قابل توجه این است که هرکدام از این روشهای ارائه شده ترکیبی از دانش افراد ارائه دهنده، همراه با تجربه کسب شده از پیادهسازی روش، میباشد. لزوما تمامی روشهای ارائه شده برای محصول و شرایط ما مناسب نیست، شما میتوانید ضمن تحقیق در مورد انواع روشها، با تحقیق و مطالعه از تجربیات استفاده افراد از روشهای مختلف، با اطمینان بیشتری روش مورد نظر برای محصول خود را انتخاب کنید.
همچنین در نظر بگیرید از آنجایی که سیستم چابک، امکان بازخورد مکرر، انطباق و بهبود را در تمام مراحل توسعه و تصمیمات، در اختیار تیم قرار میدهد، درصورتیکه بعد از انتخاب و استفاده از یک روش، در حین بازرسی متوجه شدید، روش انتخابی، کارایی لازم را برای شما نداشته است، میتوانید سراغ سایر روشها بروید. هرچند که اگر نیازمندیهای شما در ابتدا، شفافتر و مشخصتر باشد، احتمال انتخاب و تعیین روش صحیح، بیشتر خواهد بود.
یکی از روشهای ارائه شده در دنیا برای اولویتبندی بکلاگ، روش RICE میباشد.
RICE، مخفف Reach ، Impact، Confidence وEffort، یک چارچوب اولویتبندی ساده برای کمیسازی ارزش بالقوه ویژگیها، ایدههای پروژه و برنامهها است. امتیاز رایس به مدیران و مالکان محصول کمک میکند تا مقدار تخمینی یک ویژگی یا ایده پروژه را کمی کنند، بنابراین در زمان تصمیمگیری برای ترتیب کار، آنها میتوانند راحتتر مرتبسازی کنند. مدیران محصول دارای صد برنامه مختلف هستند که میتوانند در هر زمان مشخص روی آنها کار کنند. مسئله اصلی اولویتبندی به این میرسد که بدانید ابتدا باید چه کار کنید. یک چارچوب آسان مانند رایس میتواند این فرایند را برای مدیران محصول استانداردسازی کند.
مانند تمام اختراعات، اولویتبندی رایس از یک ضرورت متولد شد. شان، که با تیم رشد اینترکام کار میکرد، به چیزی نیاز داشت که بتواند غریزه را از روند اولویتبندی حذف کند. شان میگوید: “ما میخواستیم به روش متداولتری برای مقایسه بسیاری از ایدههای مختلف پروژه از نظر تأثیر بالقوه آنها بر یک هدف واحد (تبدیلها) برسیم.” تیم رشد اینترکام به راهی نیاز داشت تا تعریف تأثیر را به دستههایی تقسیم کند که بعداً به صورت استاندارد در پروژههای دیگر اعمال شود و بنابراین روش رایس متولد شد.
از طریق این لینک https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ میتوانید در مورد جزئیات و مزایای این روش، مطالعه کنید.
مدل دیگری به نام روش MOSCOW برای اولویتبندی بکلاگ نیز وجود دارد.
روش اولویتبندی مسکو یکی از تکنیکهایی است که به منظور اولویتبندی بکلاگهای محصول از آن استفاده میشود. مسکو در واقع شامل حروف اول نام چهار دسته از نیازمندیها یا اولویتهای ما میباشد.
عدهای هم حرف W را به کلمه Wish به معنای آرزو ربط میدهند. این روش توسط یک متخصص نرم افزار به نام Dai Clegg ایجاد شد. او چارچوبی را طراحی کرد که به افراد تیمش در اولویتبندی وظایف، حین کار بر روی پروژههای توسعه محصول کمک میکرد. اما در حال حاضر روش مسکو توسعه یافته و از آن برای طیف وسیعی از پروژهها استفاده میشود . جزئیات این روش را میتوانید از طریق این لینک https://www.agilebusiness.org/dsdm-project-framework/moscow-prioririsation.html مطالعه کنید.
در یک تجربه عینی برای توسعه یک محصول واقعی با مطالعه در مورد این دو روش، تصمیم به پیادهسازی و استفاده از یک مدل که ترکیبی از دو روش فوق میباشد، گرفتیم. طبق نتایجی که بعد از پیادهسازی داشتیم، خروجیهای این مدل ترکیبی، برای محصول و تیم ما کارآمد بود. نکته جالب این تجربه این بود که با جابه جایی اولویت آیتمهای بکلاگ بر اساس امتیاز نهایی، این رتبهبندی گاهی ما را شگفتزده میکرد و گاهی نتیجه با تصورات ذهنی و حدسیات ما یکسان بود. زمانیکه از رتبهبندی متعجب میشدیم، به این نتیجه میرسیدیم که در اولویتبندی و امتیازدهی به نکات ظریفی توجه نکردیم، که اتفاقا اهمیت بالایی داشته است. همچنین زمانی که رتبهبندی طبق انتظارات ما پیش میرفت، به تصمیمها و تحلیلهایی که داشتیم اطمینان بیشتری پیدا میکردیم و متوجه میشدیم که در مسیر درستی قدم برمیداریم.
مدلی که استفاده کردیم به این صورت بود که در ابتدا برای مرتب سازی و فیلتر کردن فیچرها و PBI ها از مدل مسکو استفاده کردیم و سپس بطور متمرکز سراغ پیادهسازی مدل رایس برای دستههای Must have و Should have رفتیم. اهمیت انجام این کار، این بود که ابتدا یک فیلتر روی تمام موارد بکلاگ محصول انجام دهیم که بتوانیم هدفمند با موارد مهمتر پیش برویم، تا در نهایت برای جمعآوری دیتا در مدل رایس نیازی به صرف زمان زیادی برای تمام موارد بکلاگ نباشد. برای امتیازدهی بهتر و دقیقتر به مولفههای رایس، ما نیاز به انجام یک سری اقدامات زیر ساختی در جهت تهیه دیتای لازم و همچنین پایدار کردن زیرساختها بودیم، که بدون آنها محاسبه کردن رایس برای همه آیتمهای بکلاگ کار سخت و همراه با خطای زیاد، بود. به همین دلیل ابتدا پیشنیازیها را با عنوان Must در دستور کار قرار دادیم تا در ادامه با داده مستند و دقت بهتر بتوانیم باقی موارد را اولویتبندی کنیم.
یکی از نکاتی که در این مدل استفاده کردیم و به نحوی مدل رایس را متناسب با نیاز محصول شخصیسازی کردیم، به این صورت بود که معیار Confidence را به دو بخش Business Confidence و Technical Confidence تقسیم کردیم و از دو زاویه بیزینس و فنی بطور جداگانه امتیازدهی کردیم و در نهایت در نحوه محاسبات امتیاز نهایی رایس این موضوع را در نظر گرفتیم.
دلیل دیگر این تصمیم، این بود که بعد از اعمال رایس روی آیتمهای فیلتر شدهای که مدل مسکو در اختیار ما قرار میدهد، میتوانیم از چرخه یادگیری و بهبود استفاده کنیم. حین استفاده از مدل رایس، تجربه بیشتری بهدست میاوریم و برای اولویتهای بعدی از تجربههای به دست آمده استفاده میکنیم. همچنین اگر در حین بازرسیهای دورهای متوجه شدیم که مدل رایس برای ما کارآمد نخواهد بود، بدون پرداخت هزینه خیلی زیاد، میتوانیم سراغ مدل دیگری برویم که کارآمدتر باشد.
این مقاله را میتوانید از طریق لینک ارائه زیر در prezi نیز مشاهده کنید:
https://prezi.com/view/T4tlHS4XUqwszzaBEw11