برای اینکه یک شمای کلی از محصول و خدماتمون داشته باشیم ما بر اساس پروداک هیراکی(Product Hierarchy) یک لول بندی برای محصول اصلیمان ایجاد کردیم. محصولی که روی آن کار میکنیم یک اپلیکیشن زیر مجموعه PSP است که میخواد در راستای سوپر اپ شدن خدمات جانبی را اضافه کند. مشابه آن در اپلیکیشن های Alipay, WechatPay, Paytm, Tinkoff و غیره است.
هدف و چشم انداز ما مشخص بود و خدماتی که قابل ارائه داشتیم نیز در بازه کوتاه مدت تست کردیم و فیدبک گرفتیم. لازم بود که برای پروداکت اصلیمون که اپلیکیشن بانکینگ و پرداخت بود دو زیر دسته (زیر لول و سطح بندی) را تعریف کنیم.
همگی این ساختار بر اساس SPL که مخفف Software Product Line است تشکیل شد. ما بر اساس هدف لاین محصول خود را تعریف کردیم. همچنینی سطح بندی درون این لاین ها را از روی هرم هیراکی مشخص کردیم. در انتها گرافی را برای محصول اصلی بیرون دادم که مشمول همگی این موارد بود. لاین ها را تفکیک میکرد. روی این لاین ها پروداکت تایپ ها مشخص شد که در واقع دسته خدماتی بودند که اجماع آنها همگن و مسیر توسعه آنها در یک راستا بود. و در انتها زیرسرویس یا زیر پروداکت برای هر تایپ محصول نوشتم.
حال نیاز بود که یک رود مپ ۱ساله با چهار کوارتر مشخص شود و بر اساس ظرفیت، اشتیاق، پتانسیل، هزینه، درآمد و موارد دیگر درون رود مپ تعیین شود که در این بازه زمانی مشخص چه سرویس ها یا چه پروداکت هایی را توسعه دهیم. اینجا بود که اولویت بندی قدم مهمی به حساب می آمد.
چون ما اطلاعات و دیتای خوبی از خدماتمون داشتیم رفتم سراغ دیتا. هممون این کار رو میکنیم. یک سری سرویس بود که درون پروداکت تایپ خودش دیتا داشت و یک سری سرویس هم خام بودن. اولویت بندیی را روی پروداکت تایپ انجام دادیم. این مسیر سادگی بیشتر و نتایج درستتری را به دنبال دارد از اینکه اولویت بندی را روی زیر سرویس انجام دهیم. روش رایس را انتخاب کردم. میون تمام روش های اولویت بندی بین دو مورد شک داشتم. دو روش وزن دهی و رایس متد های مد نظرم بود. رایس را انتخاب کردم چون دیتا داشتم و در میانه مسیر بودیم که این روش در این حالت بیشتر به درد میخورد. اگر در ابتدای تولید و اولویت بندی تعیین نقشه یک محصول نو بودم شاید روش دیگری بهتر بود اما برای ما رایس راه گشا بود.
اینجا خیلی خلاصه بهش اشاره کرده و میتونه کمک کلی ای بکنه. اما یادتون باشه روش ها باید بر اساس اهداف شما و تیمی که داخل آن هستید کاستومایز بشن. من هم این کار رو کردم اما این تغییراتیی که درون روش لحاظ کردم ربطی به فرمول و تعریف آن نداشت. بلکه روی پارامترها تعریف ها را به نحوی کردم که به سازمان بشینه.
این فریم ورک توسط Intercom معرفی شده که یه نوع سیستم امتیازدهی تا هر ایده رو بر اساس چهار معیار زیر مورد بررسی قرار دهیم :
Reach, Impact, Confidence, ٍEffort
تخمین زدن اینکه در یک دوره ی معین (ما ۱۲ ماهه در نظر گرفتیم) چه تعداد مشتری را تحت تاثیر قرار خواهیم داد. ما برای هر لاین محصول تعداد درگیری هر سرویس رو مد نظر قرار دادیم.
برای تمرکز روی سرویس هایی که ما را به به سمت اهدافمون هدایت میکنند، تاثیر آنر را روی جامعه هدف خاص میسنجیم. مثلا در با استفاده از این فیچر یا سرویس تخمین می زنیم که هر مشتری که این را می بیند تاثیر زیادی برای تبدیل به اکشن یا افزایش اینگیجمنت خواهد داشت.
در اینجا مقدارهای کیفی را به عدد تبدیل میکنیم مثلا : 3 برای "تأثیر زیاد" ، 2 برای "زیاد" ، 1 برای "متوسط" ، 0.5 برای "کم" و در آخر 0.25 برای "خیلی کم" و از آن ها استفاده کنید.
شور و شوق برای ارائه این سرویس یا فیچیر یا زیرمحصول؛ ممکن است در استدلال کردن برای ارائه فیچر داده های قابل استناد زیادی نداشته باشیم ولی فکر می کنیم تاثیر بسیار خوبی داشته باشد، اینجاست که به این پارامتر نمره ی بالایی اختصاص خواهید داد؛ می توانید مقدارهای کیفی را به عدد تبدیل کنید مثلا : 100% برای "شوق زیاد" ، 80% برای "معمولی" ، 50% برای "کم" و از آن ها استفاده کنید.
برای حرکت سریع و تأثیرگذاری با کمترین تلاش ، کل زمان مورد نیاز یک پروژه را از همه اعضای تیم خود تخمین بزنید: محصول ، طراحی و مهندسی.
تلاش با "فرد – ماه" تخمین زده می شود (کاری که یک عضو تیم می تواند در یک ماه انجام دهد). در اینجا ناشناخته های زیادی وجود دارد ، بنابراین من برآورد خود را با رعایت اعداد کامل (یا 0.5 برای هر چیزی که کمتر از یک ماه باشد) تخمین می زنم.
مثلا یک سرویس حدود یک هفته برنامه ریزی ، 1-2 هفته طراحی و 2-4 هفته زمان مهندسی طول خواهد کشید. من به آن نمره تلاش 2 ماهه می دهم.
یا یک سرویس چندین هفته برنامه ریزی ، مقدار قابل توجهی از زمان طراحی و حداقل دو ماه از وقت یک مهندس به طول خواهد انجامید. من به آن نمره تلاش 4 نفر در ماه می دهم.
یا سرویسی فقط به یک هفته برنامه ریزی ، بدون طراحی جدید و چند هفته زمان مهندسی نیاز دارد. من به آن نمره تلاش 1 نفر در ماه می دهم.
بعد از اجرای این موضوع متوجه شدم که گزینه ریچ پارامتر اصلی برای تعیین اولویت بندی است. من برای افزایش اعتبار اولویت بندی و امتیاز بندی رایس فرمی که خودم تکمیل کردم را بین مدیران برتر نیز برای تکمیل پخش کردم. خب اینجا بود که سوالات و ابهامات شروع میشود و خلاها پر میشود.
مهمترین تصمیم گیری انتخاب پارامتر ریچ درون بازه ی زمانی ۱ساله گذشته بود یا یک ساله آینده؟!
در ابتدا تمامی پروداکت تایپ ها بر اساس دیتاهایی که داشتیم پر کردیم. این موضوع رو بر اساس ۱ سال گذشته تکمیل کردیم. مواردی هم بود که جدید بود و تازگی داشت. اونها رو هم در مقام قیاس به نسبت سرویس های مشابه تکمیل کردیم. اما موضوعی که مطرح شد و منطقی نیز به نظر میرسید این بود:
وقتی در حال توسعه هستی و میخواهی خدمات و سرویس های خود را افزایش دهی باید افق اولویت بندی بر اساس آینده باشد. نگاه بر اساس دیتاهای گذشته گرچه واقعی تر میکند و منطقی تر میشازد نتیجه را اما معیار و طرز تفکر سازمان را اغنا نمیکند.
لذا این شد که ما پارامتر Reach را برای ۱سال آینده اما بر اساس دیتاهای گذشته تکمیل کردیم. تفاوت نتیجه نهایی اولویت بندی پروداکت تایپ کم بود اما در موارد حساس که تصمیم گیری مجموعه را تحت تاثیر قرار میداد، بسیار همسوتر و همگن تر شد.
گفتن این داستان هدفش بیان موضوعی بود که همگی درگیر آن شده ایم. اینکه روش و منطق همیشه پاسخگو است؟ شکستن چهارچوب همه چیز را خراب میکند؟ همیشه باید تفکر جمعی را در نظر گرفت؟
برای من استفاده از چهارچوب و متدها و روشهای بین المللی همیشه کمک کننده بوده اما اینکه شرایط، تیم، اهداف و بسیاری موارد دیگر چه هستند، نشان مشدهد که مهمترین وظیفه یک فرد در سازمان این است که بتواند به نحوی برنامه ریزی کند و عمل کند که بتواند در قدم اول آن برنامه اجرایی شود و در قدم بعدی کیفیت و بازدهی بالایی داشته باشد.
تمام این متن نظر یک فرد است.
*سرویس و پروداکت رو از یک جنس در نظر گرفتم
