یکی از روش‌های اندازه‌گیری رضایت مشتریان شاخص Net Promoter Score هست که میزان وفاداری یک مشتری را به محصولات شرکت اندازه‌گیری می کند. این شاخص درک و احساس مشتریان را در مورد محصول کمی سازی کرده و به مدیر محصول کمک می‌کند در مورد برنامه آینده توسعه تصمیم‌گیری کند. در ادامه با این تکنیک برای نحوه اندازه‌گیری رضایت مشتریان و همچنین برنامه آتی توسعه محصول نرم‌افزاری آشنا می‌شویم: در این روش ابتدا در یک فرم نظرخواهی NPS یک سوال در مورد محصول پرسیده می‌شود، برای مثال در اینجا سوال شده است که “چقدر مایل هستید که محصول Confluence را به دوستان و همکاران خود پیشنهاد دهید”؟ پاسخی که کاربر فراهم خواهد کرد در سه گروه Passives، Promoters و  Detractors دسته‌بندی خواهد شد. گروه اول کسانی هستند که امتیاز ۹ و ۱۰ را انتخاب می‌کنند و جزو مروّجین محصول هستند، گروه دوم امتیاز ۷ و ۸ را انتخاب کرده و به‌عنوان کاربر منفعل در نظر گرفته می‌شوند و گروه آخر گروهی هست که امتیاز ۰ تا ۶ را انتخاب خواهد کرد و مشتری ناراضی محصوب می‌شود. شاخص NPS با کم کردن درصد کاربران Detractors از کاربران Promoters محاسبه خواهد شد. برای مثال در حالتی که از ۱۰۰ فیدبک دریافت شده ۴۰ نفر Promoter؛ ۲۵ نفر Passive و ۳۵ نفر Detractors داشته باشیم، شاخص NPS برای آن برابر ۵% خواهد بود. این شاخص می تواند از ۱۰۰%- تا ۱۰۰%+ درصد متغیر باشد. بعد از انتخاب امتیاز توسط کاربر از وی خواسته می‌شود، نظر خود را در ارتباط با امتیاز داده شده لحاظ کند: مرحله ۱: دسته بندی صدای مشتری مدیر محصول می‌تواند تمامی این فیدبک‌ها را مشاهده کرده و آن‌ها را به صورت دستی آنالیز و دسته‌بندی کند، حالت دیگر با استفاده از ابزارهای آنالیز متن جهت دسته‌بندی این درخواست ها اقدام می‌شود. در این تصویر دو فیدبک مختلف از مشتری برای Confluence دریافت شده است. مورد اول در گروه Promoters ها قرار دارد و اگرچه ما از دیدن آن خوشحال خواهیم‌شد، اما هیچ اطلاعاتی در مورد اقدامات آتی برای ما فراهم نخواهد کرد. اما مورد دوم، به صورت خاص حاوی اطلاعاتی است که مشتری بابت آن‌ها از محصول ناراضی بوده است. نارضایتی مشتری در این درخواست در یک پایگاه داده به صورت زیر با دو لیبل Usability و Formatting وارد می‌شود. حال فرض کنید درخواست زیر را نیز دریافت کرده‌ایم: این درخواست ۲ لیبل جدید به جدول قبل اضافه خواهد کرد: با دریافت فیدبک‌های جدید این جدول به مرور کامل تر خواهد شد. لازم به یادآوری است که در اینجا برای فیدبک‌های مثبت لیبلی به جدول اضافه نخواهد شد. به طور مثال چنانچه فیدبک زیر را دریافت کنیم لازم است که لیبل مربوطه را برای Performance محسوب کنیم و ارتباطی با لیبل Table  ندارد. Table features are great! But I wish Confluence was faster. مرحله ۲: تجزیه و تحلیل نتایج برای تجزیه‌و‌تحلیل اطلاعات حاصله در این مرحله لازم است ابتدا تعداد کل آیتم‌های هر لیبل رو بشماریم: سپس زیرمجموعه‌ها را پاک کرده و جدول را اولویت بندی کنیم: چنانچه اطلاعات دیگری در اختیار نداشته باشیم، براساس این جدول سراغ Performance که آیتم دارای بالاترین اولویت هست، خواهیم رفت. اما لزوما قرار نیست این آیتم بیشترین رضایت و خوشحالی را برای مشتریان فراهم سازد. برای حل این مشکل شاخص NPS مجددا برای هر حوزه محاسبه شده و در ستونی دیگر مطابق زیر آورده می شود: با لحاظ کردن این شاخص مشاهده می کنیم اگر چه شاخص Performance تعداد دفعات بیشتری در فیدبک کاربران ذکر شده است، اما امتیاز رضایت بالاتری در مقایسه با گزینه Tables دارد و اگر هدف ما خوشحال سازی و افزایش رضایت مشتریان هست، بهتر است سراغ موارد مربوط به Tables برویم. شما از چه روشی برای پروژه های خود استفاده می کنید؟ برای تهیه این نوشه از منابع زیر استفاده شده است: http://blogs.atlassian.com/2015/11/prioritize-features-using-nps/

در این نوشته راه‌حل شرکت اطلسیان برای جمع اوری نظرات کاربران بررسی شده است. مرحله اول: جمع آوری نظرات کاربران در توسعه نرم‌افزار چابک،فرایند دریافت بازخورهای مشتریان همزمان با ارائه ویژگی‌های جدید محصول آغاز خواهد شد. برای جمع‌آوری فیدبک‌های مشتریان ممکن است از کانال‌های زیر استفاده می‌شود: اطلاعات دریافتی از این کانال‌ها به UserStory تبدیل خواهند شد. چنانچه برای شما امکانپذیر باشد، شاید بهتر  باشد که ارتباط حضوری با مشتری برقرار کرده و از نزدیک با وی صحبت کنید. با این کار هم درک بهتری از نیاز مشتری خواهید داشت و هم متوجه خواهید شد که اکنون چه مشکلاتی با محصول دارد و در صورت رفع آن مشکل به چه چیزی دست خواهد یافت. در شرکت اطلسیان یکی از کانال‌های ورودی درخواست های مشتریان، پرتال jira.atlassian.com است که کاربران جیرا می توانند درخواست‌های رفع باگ، توسعه و ویژگی جدید خود را مطرح کنند و یکی از امکانات آن این است که باقی کاربران با مشاهده آن می‌توانند موافقت خود برای پیاده سازی آن را توسط Vote دادن به issue  اعلام کنند.   مرحله دوم: مستند سازی نظرات کاربران در ادامه تمامی فیدبک‌های دریافت شده از کاربر در داخل Confluence در تمپلیت Product Requirement به ازای هر ایشو ایجاد خواهد شد. در این صفحه لینک تمامی منابع و کانال‌هایی که یک Story خاص از آن اقتباس شده است، مشخص خواهد شد تا تمامی ذینفعان پروژه در هر زمان که نیاز داشته باشند به آن دسترسی داشته باشند. مرحله سوم: انتقال نظرات به بک‌لاگ محصول هر ویژگی که قرار است در محصول/پروژه در آینده انجام شود باید در بک‌لاگ مربوطه لیست شود. Storyهایی که داخل بکلاگ قرار می‌گیرند، به روش‌های مختلف اولویت‌بندی شده و تیم توسعه براساس این اولویت‌ها برنامه اسپرینت‌های اتی خود را مشخص خواهد کرد. یکی از تکنیک‌های معمول برای اولویت بندی ایشو‌ها تکنیک MoSCoW است. این تکنیک خلاصه شده چهار عبارت زیر است:    – Must Have: موارد لازم و ضروری که در برنامه‌ریزی فعلی باید به آن پرداخته شود. مفهموم Failure یک اسپرینت در این موارد وجود دارد و چنانچه آیتمی در این گروه در انتهای اسپرینت به اتمام نرسد، پروژه در آن بازه ناموفق بوده است.  – Should Have: موارد مهم و غیر ضروری که چنانچه در برنامه زمانی فعلی به آن برسیم خوب است، اما لزومی نیست. این موارد در اسپرینت های اینده به Must Have تبدیل می‌شوند.  – Could Have: این موارد در راستای بهبود تجربه کاربر و رضایت مشتریان است، این موارد مطلوب هستند و غیر ضروری.  – Won’t Have: این موارد دارای کمترین اهمیت انجام هستند و می توانند هرگز انجام نشوند. در توسعه محصولات نرم افزاری (محصول به این مفهوم که سفارش مشتری نبوده است.) تمرکز بر ارائه خواسته های مشتری، کلید موفقیت سازمان و رضایت بیش از پیش مشتریان است. اما لزوما آیتم‌های بک‌لاگ براساس درخواست‌های مشتریان اولویت‌بندی نخواهند شد. به طور مثال ممکن است برای پیاده‌سازی یکی از خواسته‌های مشتری نیاز باشد که تغییرات بنیادینی در نرم‌افزار پیاده شود، مثلا برای بهبود تجربه‌کاربری ممکن است نیاز به طراحی یک API داشته باشیم که طبیعتا طراحی API مورد نظر از اولویت بالاتری برخوردار خواهد بود. مورد دیگر حائز اهمیت این مورد است که لزوما آیتم‌های با اولویت بالا وارد برنامه‌ریزی اسپرینت جدید نخواهند شد؛ بلکه همگام بودن این موارد نیز مهم است، به عبارت دیگر برای هر اسپرینت یک هدف مشخص تعریف شده و آیتم هایی که مرتبط با آن هدف باشند، برای اسپرینت مورد نظر انتخاب خواهند شد. اولویت بندی بک‌لاگ محصول هم می تواند متکی بر art و تجربه مدیر پروژه/محصول و اعضای تیم توسعه باشد و هم می‌تواند بر اساس Science و روش‌های علمی انجام پذیرد و انتخاب یکی از این دو حالت یا حالت بینابین بستگی به مدیر محصول و تیم مربوطه دارد. در این نوشته روش Net Promoter Score با به اختصار NPS معرفی شده است. براساس نظر مدیر محصول Confluence آیتم های بکلاگ محصول در یکی از ۳ دسته زیر قرار خواهند گرفت:  – Now (اسپرینت جاری)  – Next ( اسپرینت های آتی)  – Some Day    – آیتم های Some Day نیازی به صرف وقت ندارد، منتهی چند وقت یکبار اولویت بندی خواهند شد.  – برای موارد Next و Now باید به اندازه کافی وقت بگزاریم.  – در اولویت بندی آیتم های Some Day برخلاف آیتم های Next و Now به صورت Time-box عمل می کنیم و در پایان ۲ یا ۳ بار اولویت بندی این آیتم‌ها، آیتم‌هائی که هرگز اولویتشان جا‌به‌جا نشده باشد، برای همیشه بسته خواهند شد. شما آیتم‌های بک‌لاگ خود را با چه روشی اولویت‌بندی می کنید؟ برای تهیه این نوشه از منابع زیر استفاده شده است: http://blogs.atlassian.com/2015/12/how-to-capture-and-prioritize-customer-feedback-in-agile-development/ http://blogs.atlassian.com/2015/12/inside-atlassian-prioritizing-customer-feedback-backlog-grooming/