بهعنوان Product Owner، اگر بخواهید از Evidence-Based Management (EBM) استفاده کنید، باید نگاه خودتان را از «برنامهریزی مبتنی بر حدس و گمان» به «مدیریت مبتنی بر شواهد و داده» تغییر دهید.
- EBM یک چارچوب اسکرام برای مدیریت محصول با داده واقعی است.
- به جای اینکه بگیم “احساس میکنم این فیچر خوبه“، میپرسیم “چه شواهدی داریم که این فیچر واقعا برای بیزنس و مشتری ارزش ایجاد میکنه؟“.
۱. تعریف و فلسفهٔ EBM
EBM (Evidence-Based Management) یک چارچوب ارائهشده توسط سازمان اسکرام است که هدف آن ارتقای توانایی سازمانها در بهبود مستمر ارزش محصولات و خدمات از طریق استفاده از دادهها و شواهد واقعی است.
در این رویکرد:
- تصمیمگیریها مبتنی بر دادههای معتبر و قابلاندازهگیری انجام میشوند.
- تیم محصول و استیکهولدرها بهجای اعتماد به شهود یا فشارهای بیرونی، بر شواهد و نتایج واقعی تمرکز میکنند.
- ارزش محصول نه فقط بر اساس تحویل فیچر، بلکه با توجه به میزان اثربخشی آن در دنیای واقعی ارزیابی میشود.
۲. چهار حوزهٔ کلیدی ارزش (Key Value Areas – KVAs)
EBM چهار حوزهٔ کلیدی برای ارزیابی موفقیت یک محصول معرفی میکند. هر Product Owner باید تصمیمها و سنجههای خود را در چارچوب این حوزهها تنظیم نماید:
- ارزش فعلی (Current Value – CV)
- بیانگر میزان ارزشی است که مشتریان و سازمان در حال حاضر از محصول دریافت میکنند.
- مثال: درآمد فعلی، رضایت مشتری، سهم بازار، شاخص وفاداری مشتری (NPS).
- پرسش کلیدی: آیا محصول ما اکنون برای مشتریان و کسبوکار ارزشمند است؟
- ارزش بالقوه (Unrealized Value – UV)
- نشاندهندهٔ فرصتهای ارزشآفرینی است که هنوز بالفعل نشدهاند.
- مثال: بخشهای بازار دستنخورده، نیازهای برآوردهنشده مشتریان، نوآوریهای بالقوه.
- پرسش کلیدی: کجا میتوانیم ارزش بیشتری برای مشتریان خلق کنیم؟
- توان نوآوری (Ability to Innovate – A2I)
- میزان توانایی تیم و سازمان در تحویل تغییرات، نوآوریها و قابلیتهای جدید.
- مثال: سرعت توسعه، کیفیت کد، انعطافپذیری زیرساختها، توان پاسخگویی به نیازهای جدید.
- پرسش کلیدی: آیا ما توانایی ایجاد تغییر و نوآوری در محصول را داریم؟
- زمان رسیدن به بازار (Time to Market – T2M)
- سرعتی که با آن میتوان ایدهها، قابلیتها یا تغییرات را به مشتری ارائه کرد.
- مثال: مدتزمان چرخهٔ توسعه تا انتشار، فرکانس استقرار (deployment frequency)، میانگین زمان رفع باگ.
- پرسش کلیدی: چقدر سریع میتوانیم ارزش جدید را در اختیار مشتری قرار دهیم؟
۳. چرخهٔ عملیاتی EBM (گامبهگام برای PO)
گام اول: اندازهگیری وضعیت فعلی
- دادههای کمی و کیفی محصول را جمعآوری کنید.
- دادهها را در چهار KVA بالا دستهبندی نمایید.
- وضعیت فعلی را بهصورت تصویری یا گزارشی شفاف برای تیم و استیکهولدرها ارائه دهید.
گام دوم: تعیین اهداف قابلاندازهگیری
- اهداف باید مشخص، قابلاندازهگیری و مرتبط با ارزش باشند.
- مثال: «افزایش رضایت مشتری از ۶۰٪ به ۸۰٪ در شش ماه آینده» یا «کاهش زمان انتشار فیچر از سه ماه به شش هفته».
گام سوم: ساخت فرضیهها
- برای دستیابی به هدف، فرضیههایی تدوین کنید.
- مثال: «اگر فرآیند پرداخت در اپلیکیشن سادهتر شود، نرخ بازگشت کاربران افزایش خواهد یافت».
گام چهارم: اجرای آزمایشها
- تغییر یا فیچر را در مقیاس محدود پیادهسازی کنید (مانند A/B تست).
- نتیجه را در محیط واقعی بسنجید.
گام پنجم: اندازهگیری و تحلیل نتایج
- دادهها را قبل و بعد از تغییر مقایسه کنید.
- بسنجید آیا فرضیه تأیید یا رد شده است.
گام ششم: تصمیمگیری مبتنی بر شواهد
- در صورت تأیید فرضیه، آن را در مقیاس بزرگ پیادهسازی کنید.
- در صورت رد فرضیه، آن را کنار بگذارید یا اصلاح کنید.
گام هفتم: تکرار چرخه
- این فرآیند یک چرخهٔ مداوم است، نه یک اقدام یکباره.
- با هر تکرار، تیم محصول دانش بیشتری کسب کرده و ارزش بیشتری تولید میکند.
۴. نقش Product Owner در EBM
بهعنوان PO، وظایف شما در بهکارگیری EBM عبارت است از:
- شفافسازی دادهها: اطمینان حاصل کنید که همهٔ اعضای تیم و استیکهولدرها به دادهها دسترسی داشته باشند.
- تمرکز بر ارزش واقعی: اولویتبندی بکلاگ باید براساس شاخصهای ارزش (نه صرفاً فشار بیرونی یا ترجیح فردی) صورت گیرد.
- تسهیل یادگیری مستمر: حتی آزمایشهای ناموفق، داده و تجربه ارزشمند تولید میکنند که باید در تصمیمهای بعدی استفاده شوند.
- گفتوگو با ذینفعان: دادهها را به زبان ساده و قابلفهم منتقل کنید تا اعتماد و همسویی ایجاد شود.
۵. مثال کاربردی (مطالعهٔ موردی ساده)
فرض کنید شما مالک محصول یک اپلیکیشن خدمات خودرو هستید:
- ارزش فعلی: ۵۰۰ کاربر فعال ماهانه و درآمد ثابت از سرویسها.
- ارزش بالقوه: بازار شهرهای دیگر که هنوز ورود نکردهاید.
- توان نوآوری: انتشار یک فیچر جدید بهطور متوسط سه ماه زمان میبرد.
- زمان رسیدن به بازار: رفع باگهای حیاتی حدود دو هفته طول میکشد.
هدف
«کاهش زمان انتشار فیچر از سه ماه به یک ماه».
فرضیه
«اگر فرآیند تست نرمافزار خودکار شود، مدتزمان انتشار به نصف کاهش خواهد یافت».
آزمایش
یک فیچر کوچک را با تست خودکار پیادهسازی و منتشر کنید.
نتیجه
زمان انتشار واقعی را بسنجید و با چرخهٔ قبل مقایسه نمایید.
EBM به Product Owner کمک میکند تا:
- از دادهها برای هدایت تصمیمها استفاده کند.
- ریسک سرمایهگذاری روی فیچرهای کمارزش را کاهش دهد.
- همسویی تیم و سازمان را حول اهداف ارزشآفرین ایجاد کند.
- بهطور مداوم، ارزش محصول را برای مشتری و سازمان افزایش دهد.
چطور دادههای کمی و کیفی محصول را جمعآوری کنید؟
در EBM وقتی میگوییم «دادههای کمی و کیفی محصول را جمعآوری کنید»، منظور این است که بهعنوان Product Owner باید تصویر جامعی از وضعیت محصول داشته باشید.
این تصویر تنها با نگاه به اعداد خام ساخته نمیشود؛ باید هم دادههای عددی (Quantitative) و هم دادههای توصیفی/تجربی (Qualitative) را در نظر بگیرید. اجازه دهید مرحلهبهمرحله توضیح دهم:
۱. دادههای کمی (Quantitative Data)
این دادهها قابلاندازهگیری و عددی هستند و به شما امکان میدهند وضعیت محصول را با معیارهای مشخص دنبال کنید. نمونهها:
- رفتار کاربر
- تعداد کاربران فعال روزانه/ماهانه (DAU/MAU)
- نرخ حفظ کاربر (Retention Rate)
- نرخ ریزش (Churn Rate)
- تعداد تراکنشها یا استفاده از یک فیچر خاص
- شاخصهای کسبوکار
- درآمد ماهانه یا سالانه (MRR/ARR)
- ارزش طول عمر مشتری (Customer Lifetime Value – CLV)
- نرخ تبدیل (Conversion Rate) از ثبتنام تا خرید
- شاخصهای تحویل محصول
- میانگین زمان تحویل فیچر (Lead Time)
- تعداد استقرار (Deployments) در هر ماه
- میانگین زمان رفع باگهای بحرانی (Mean Time to Repair – MTTR)
- شاخصهای کیفیت
- تعداد کرشها یا خطاهای گزارششده
- درصد تستهای خودکار موفق
- زمان پاسخ سرور یا اپلیکیشن
ابزارهای معمول: Google Analytics، Mixpanel، Amplitude، دیتابیس داخلی، گزارشهای فروش و پشتیبانی.
۲. دادههای کیفی (Qualitative Data)
این دادهها برداشتها، نظرات و تجربیات کاربران را منعکس میکنند. بدون این نوع داده، اعداد خام معنی واقعی خود را از دست میدهند. نمونهها:
- بازخورد مستقیم مشتریان
- مصاحبههای کاربری (User Interviews)
- گروههای کانونی (Focus Groups)
- تماسهای پشتیبانی یا تیکتهای مشتریان
- مشاهدات رفتاری
- ضبط جلسات کاربری (Screen Recording)
- تست کاربردپذیری (Usability Testing)
- نقشهٔ حرارتی (Heatmap) در وبسایت یا اپلیکیشن
- تحلیل نظرات و احساسات
- تحلیل متن بازخوردهای کاربران (Sentiment Analysis)
- بررسی کامنتها در مارکتها (مانند Google Play یا App Store)
- دادههای شبکههای اجتماعی درباره محصول
ابزارهای معمول: Hotjar، FullStory، Typeform، ابزارهای نظرسنجی داخلی، Social Listening Tools.
۳. نحوهٔ ترکیب دادهها
برای تصمیمگیری مبتنی بر EBM، شما به ترکیب دادههای کمی و کیفی نیاز دارید:
- اگر نرخ ریزش (کمی) بالاست → با مصاحبه کاربری (کیفی) علت را پیدا کنید.
- اگر درآمد رشد نکرده (کمی) → با نظرسنجی مشتریان (کیفی) بفهمید چه چیزی ارزشمندتر خواهد بود.
- اگر زمان تحویل فیچر طولانی است (کمی) → با جلسات تیمی (کیفی) بررسی کنید مشکل از کجاست (فرایند، ابزار، یا دانش).
۴. چارچوب ساده برای PO
بهعنوان Product Owner، میتوانید یک جدول دو ستونه طراحی کنید:
ستون اول: دادههای کمی
- درآمد، تعداد کاربر، زمان تحویل فیچر، نرخ ریزش
ستون دوم: دادههای کیفی
- چرا کاربر محصول را ترک میکند، چه چیزی در اپلیکیشن برایش گیجکننده است، کدام نیازهایش هنوز رفع نشده
با این روش، هم «چه اتفاقی افتاده» (کمی) و هم «چرا اتفاق افتاده» (کیفی) را درک میکنید.
۵. اقدام عملی برای شروع
۱. یک داشبورد تحلیلی برای دادههای کمی ایجاد کنید (مثلاً در Google Analytics یا یک ابزار BI داخلی).
۲. ماهی یکبار مصاحبهٔ کاربری با ۵ تا ۱۰ مشتری واقعی برگزار کنید.
3. بازخوردهای تیم پشتیبانی را دستهبندی کنید و در بکلاگ داشته باشید.
۴. دادهها را به چهار حوزهٔ KVA (ارزش فعلی، بالقوه، توان نوآوری، زمان تا بازار) نسبت دهید.
مثال برای جمعآوری دادههای کمی و کیفی محصول
خوب، بیایید یک نمونهٔ عملی برای اپلیکیشن خدمات خودرو (مثل CaraRepair) بسازیم. در این مثال، شما بهعنوان Product Owner میخواهید با استفاده از EBM دادههای کمی و کیفی جمعآوری کنید تا تصمیمهای بکلاگ شما مبتنی بر شواهد باشند.
۱. دادههای کمی (Quantitative) – قابلاندازهگیری
این دادهها از ابزارهای تحلیلی، دیتابیس یا گزارشهای سیستم به دست میآیند:
- ارزش فعلی (Current Value)
- تعداد کاربران فعال ماهانه (MAU): ۳۲۰۰
- میانگین درآمد ماهانه: ۵۰۰ میلیون تومان
- میانگین امتیاز کاربران در اپاستور: ۳٫۸ از ۵
- ارزش بالقوه (Unrealized Value)
- ۶۰٪ از مشتریان بالقوه در شهرهای اطراف هنوز ثبتنام نکردهاند.
- فقط ۲۰٪ مشتریان از بخش رزرو آنلاین کارواش استفاده میکنند، در حالی که نیاز تقاضا بسیار بالاست.
- توان نوآوری (Ability to Innovate)
- میانگین زمان توسعه یک فیچر: ۹ هفته
- درصد استقرار موفق بدون بازگشت: ۸۵٪
- ۳۰٪ از تستها هنوز دستی هستند.
- زمان تا بازار (Time to Market)
- میانگین زمان رفع باگ بحرانی: ۵ روز
- میانگین فاصله بین دو انتشار نسخه: ۶ هفته
۲. دادههای کیفی (Qualitative) – تجربی و احساسی
این دادهها از طریق تعامل مستقیم با کاربران و تیم جمعآوری میشوند:
- مصاحبههای کاربری
- کاربران میگویند رزرو آنلاین پیچیده است و فرآیند پرداخت طولانی به نظر میرسد.
- برخی رانندگان از نبود امکان پیگیری مکان تعمیرکار شکایت دارند.
- بازخورد پشتیبانی
- ۳۵٪ از تماسها مربوط به مشکلات پرداخت است.
- مشتریان ناراضی از دیر رسیدن تعمیرکارها، ولی راضی از کیفیت خود خدمات.
- تحلیل نظرات اپاستور و شبکههای اجتماعی
- کاربران خواستار شفافیت بیشتر در قیمتها هستند.
- تعدادی از کاربران نسخه اندروید از کندی اپلیکیشن روی گوشیهای قدیمی گلایه دارند.
- مشاهدات تیم داخلی
- توسعهدهندگان میگویند فرایند تست دستی باعث کندی در انتشار میشود.
- تیم مارکتینگ معتقد است در شهرهای دیگر، آگاهی از برند بسیار پایین است.
۳. ترکیب دادههای کمی و کیفی
برای تصمیمگیری در بکلاگ باید این دو دسته داده را کنار هم قرار دهید:
- داده کمی: فقط ۲۰٪ کاربران از رزرو آنلاین کارواش استفاده میکنند.
- داده کیفی: کاربران میگویند رزرو آنلاین پیچیده است و پرداخت زمانبر است.
→ تصمیم PO: فیچر «پرداخت یکمرحلهای» یا «بهینهسازی UX رزرو» باید اولویت بالاتری داشته باشد.
۴. تصویری ساده برای PO (نمونهٔ جدول)
| Current Value | MAU = ۳۲۰۰، درآمد = ۵۰۰M | کاربران ناراضی از سرعت اپلیکیشن | بهبود Performance اپلیکیشن |
| Unrealized Value | بازار شهرهای اطراف دستنخورده | آگاهی از برند پایین در شهرهای دیگر | کمپین مارکتینگ هدفمند |
| Ability to Innovate | فیچر جدید = ۹ هفته توسعه | تیم از تست دستی شکایت دارد | اولویت با تست خودکار |
| Time to Market | باگ بحرانی = ۵ روز رفع | کاربران از دیر رسیدن تعمیرکار میگویند | بهبود سیستم Dispatch |
۵. اقدام عملی برای CaraRepair
- کوتاهمدت (۱–۲ ماه): مصاحبه کاربری، بهبود UX رزرو آنلاین، پیادهسازی تست خودکار پایه.
- میانمدت (۳–۶ ماه): ورود به یک شهر جدید، اضافهکردن امکان ردیابی تعمیرکار.
- بلندمدت (۶–۱۲ ماه): بازطراحی کامل سیستم پرداخت و ارتقای زیرساخت برای گوشیهای قدیمی.
دانلود راهنمای فارسی مدیریت مبتنی بر شواهد در اسکرام – EBM
مقاله مرتبط: سرعت یا ارزش؟ چطور متریکها میتوانند مسیر تیمهای اسکرام را گمراه کنند
دیدگاهتان را بنویسید