پروژه جاستیس از صفر تا صد!

در ابتدا میخوام تشکر کنم از همه ی همکاران و دوستانی که مقاله ی قبلیم در مورد « بهبود تجربه ی ثبت تیکت در اپلیکیشن سفیران» رو مطالعه کردن و کلی انرژی و فیدبک مثبت دادن،خوشحالم که تونستم این تجربه ی تیمی رو به اشتراک بزارم و امیدوارم کمکی هرچند کوچک به توسعه اکوسیستم کرده باشم.

یکی از پرتکرارترین فیدبکها این بود که مقاله رو به فارسی هم بنویسم چرا که هدف اصلی توسعه اکوسیستم خودمون هست به همین دلیل تصمیم گرفتم این یکی مقاله رو به زبان مادری بنویسم.

پ.ن : خیلی جاها کلمات فارسی و فینگلیش و انگلیسی میبینین که قاطی پاطی هم شده، حقیقتش چون در روزمره هم از همین ادبیات استفاده می کنیم من دیگه نخواستم همه رو به زبان مادری ترجمه کنم چون یه جاهایی واقعا کارو در نمیاره.

خب بریم سراغ اصل مطلب؛ پروژه‌ی Justice !

مقاله رو با سخن بزرگان شروع میکنم:

همه ما همواره به کسانی نیاز داریم که به ما بازخورد بدهند؛ چرا که از همین طریق، ما راه پیشرفت و اصلاح را پیدا می‌کنیم. ( بیل گیتس کبیر)

هر سیستم، نظام و موجودی که میخواد به یک رشد پایداری برسه نیازمند یک feedback loop به موقع، صریح، سازنده و موثر هست که بتونه نسبت به نقاط قوت و نقاط قابل بهبود خودش آگاهی پیدا کنه و اون ها رو اصلاح یا تقویت کنه.

به همین خاطر برای بهبود تجربه‌ی کاربری، تصمیم به توسعه‌ی یک سیستم فیدبک جامع گرفتیم که اسمشو گذاشتیم Justice.

هدف این بود که مکانیزمی ایجاد بشه که به مسافران و رانندگان این امکان رو بده تا به همدیگه فیدبک بدن ، تجربه‌ی سفر رو امتیازدهی کنن و دلایل نارضایتی خودشون رو مشخص کنن. این پروژه به منظور ارتقاء کیفیت خدمات، کاهش تجربیات منفی و تشویق سفیران و مسافران با عملکرد خوب، انجام شد.

یه هیستوری نسبتا تلخ هم از پروژه براتون بگم، این پروژه از سال های اول ایجاد تپسی تو ذهن تیم بود و در طی 3 ، 4 سال قبل هم در پلنینگ هر فصل اسم این پروژه میومد و حداقل یکی دیگه از پروژه ها به یه نحوی به جاستیس پیوند خورده بود.

ولی خب انقدر این پروژه سنگین و بزرگ بود که تقریبا هر بار تو جلسات input gathering یکی از اعضا یک اینپوت مهمی می گفت یا پروژه رو از زاویه ی دیگه ای میدید و در نهایت پروژه مجددا وارد فاز دیسکاوری می شد.

و طبق تجربه 5 ، 6 سال اخیرم، در هر شرکتی حداقل یکی از این پروژه های بزرگ هست که مدت هاست میخواد اجرا بشه ولی به هر دلیلی متوقف شده و در فاز دیسکاوری باقی مونده.

اما بالاخره طلسم شکست و در یکی از cycle planning هامون تصمیم گرفتیم پروژه رو تا جای ممکن به فازهای کوچک و deliverable فازبندی کنیم، اولین اقدام در فاز روانی هم که براش انجام دادیم این بود که اسم پروژه رو از Justice تغییرش دادیم به Just this ( :

مرحله اول : پرابلم دیسکاوری

درک مسئله

اولین گام، شناسایی نقاط درد و مشکل های هر دو گروه مسافران و رانندگان بود. ما با انجام مصاحبه‌ها و نظرسنجی‌های عمیق با نمونه‌ای از کاربرانمون ، سعی کردیم مشکلات رایج رو شناسایی کنیم. هدف اصلی ما، شناسایی مسائلی از سمت سفیر مانند رفتار و برخورد سفیر ، نظافت خودرو و دقت در مسیریابی و از سمت مسافر هم رفتار و برخورد مناسب ، رعایت نظافت خودرو ، به موقع حاضر شدن در مبدا و سایر دلایل بود که می‌تونست روی تجربه‌ی کلی سفر تاثیرگذار باشه.

تحلیل داده‌های موجود

برای اینکه بتونیم داده های کیفی تجربه سفر رو به کمی تبدیل کنیم ، نیاز به یک ابزاری داشتیم مثل پرسشنامه ی CSAT یا NPS و غیره.

در این قسمت ما از NPS استفاده کرده بودیم و از مسافر/ سفیر می‌خواستیم که به تجربه ی خودشون از سفر از 0 تا 10 یک امتیازی بدن و البته دلایل این انتخاب هم به ما بگن حتما.

نکته کنکوری: اینکه چرا از NPS برای این قسمت استفاده کردیم و مثلا چرا CSAT نه؟ خودش حداقل دو تا مقاله‌ی دیگه میخواد، لزوما تصمیم درست یا غلطی نیست، پشت این انتخاب ها معمولا دلایل زیادی هست.

سپس داده‌های موجود در سیستم فعلی رو تحلیل کردیم، که شامل امتیازها و فیدبک‌های مثبت و منفی بود، این تحلیل بهمون کمک کرد تا مشکلات تکراری رو شناسایی و معیارهای پایه‌ای برای سیستم فیدبک جدید تعیین کنیم. همچنین، تحلیل رقبا مثل اسنپ و اوبر رو برای یادگیری از نقاط قوت و ضعف اون ها انجام دادیم.

نکته کنکوری 2 : خوراک دیتایی ما صرفا rate انتهای سفر نبود. ما کلی تماس و تیکت داریم که سفیر یا مسافر از طریق این چنل ها از هم شکایت یا تشکر میکنن. اینکه این دیتاها رو چجوری جمع آوری و یکپارچه کردیم و در سیستم فیدبک جدید قرارشون دادیم به علت پیچیدگی های خیلی زیاد در این مقال نگنجد ( :

تعیین تارگت

با درک جامعی از نیازهای stakeholder های جاستیس (شامل سفیران، مسافران، تیم عملیات، تیم پشتیبانی، تیم حقوقی، تیم روابط عمومی، تیم سوشال مدیا، تیم مارکتینگ، تیم های محصول و فنی و c level های سخت گیر ولی دوست داشتنی مجموعه)، اهداف پروژه رو مشخص کردیم:

بهبود تجربه‌ی سفیران و مسافران از طریق جمع‌آوری فیدبک دقیق و رسیدگی سریع به مشکلات.

تشویق خدمات با کیفیت: از طریق سیستمی که به امتیازدهی بالا پاداش میده و عملکرد ضعیف رو هم تنبیه میکنه.

افزایش وفاداری سفیران و مسافران با ایجاد حس ارزشمندی در کاربرانمون و بهبود تجربه که باعث نرخ بازگشت مسافران میشه.

پ.ن : مقدار کمی این تارگت ها و پروکسی متریک هاشونو نمیتونستم مستقیما بنویسم، به کیفی شده اش رضایت بدید لطفا ( :

مرحله دوم : طراحی مکانیزم و پروتوتایپ

طراحی مکانیزم "جاستیس"

خب میتونم بگم سخت ترین و چالش برانگیزترین و گریه آور‌ترین و طولانی‌ترین بخش همین بخش بود!

همین یه تیکه فسقلی باعث شده بود چندین سال پروژه تو همین فاز باقی بمونه ( :

بعد از اینکه مسافر/ سفیر به تجربه ی سفر خودشون یک امتیازی بین 0 تا 10 میدن لازمه که ما یک عدد نهایی رو به سفیر/ مسافر نمایش بدیم تا از وضعیت کلی امتیازش مطلع بشه.

نکته کنکوری 3 : اگر روزی خواستید فرمولی برای نمایش این عدد نهایی بسازید بنظرم حداقل این پنج سوال میتونه کمک خوبی بهتون بکنه :

یک) در چه بازه ی زمانی (یا بازه های زمانی) باید امتیازها رو در نظر بگیرید؟

دو) فرض کنید بازه ی 6 ماه به 6 ماه رو انتخاب کردین، آیا امتیاز 6 ماهه اول باید روی 6 ماهه دوم تاثیر بزاره یا همه چی از نو شروع بشه ؟

سه) با توجه به اینکه انتظار داریم رفتار اصلاح بشه، آیا امتیازهای آخر بازه مدنظر، ارزش بالاتری از امتیازهای قدیمی تر دارن یا همه امتیازها ارزش برابری دارن ؟

چهار) از چه تابعی (میانگین ، میانه ، واریانس ، فرمول ابداعی و غیره) برای محاسبه این فرمول استفاده کنیم که نیازهای ما رو بهتر پوشش بده ؟

پنج) از همین ابتدای دیسکاوری از بچه های فنی اینپوت بگیرید و با پروژه اشناشون کنید. ممکنه به یک فرمول خوب برسید ولی از لحاظ پرفورمنسی و هزار تا دلیل فنی دیگه feasible نباشه.

حالا چندتا سوال مهم برای استک هولدر‌هامون پیش اومد :

اولین سوال مهمی که پیش اومد اینه که اگر یک کاربری امتیازش 9.3 شد این خوبه یا بد ؟

شاید در نگاه اول بگیم خب خوبه دیگه همش 0.7 کمتر از 10 هست، ولی باید عرض کنم که متاسفانه خیر!

ممکنه کاربری از امتیاز 8.5 با کلی زحمت خودشو رسونده به 9.3 ، این بهبود قطعا جای تشکر و قدردانی داره.

ولی اگر کاربری از امتیاز 9.9 رسیده باشه به 9.3 چی؟ خب قطعا نیازمند تذکر و تلاش برای اصلاح در نقاط قابل بهبود خودشه .

پس ما انگار دو جور عدد 0 تا 10 داشتیم، یکی اعدادی که کاربران با پیشرفت به اون میرسن و یکی اعدادی که متاسفانه با رعایت نکردن یه سری نکات به اون میرسن.

دومین سوال مهمی که پیش اومد اینه که : وقتایی که امتیازمون خوبه ولی می‌خوایم بهتر بشه تا بیشتر تشویق بشیم، باید چیکار کنیم؟ یا امتیاز پایین‌مون رو چطوری جبران کنیم و یا حتی چطوری پیشگیری کنیم که اصلا امتیازمون پایین نیاد ؟

سومین سوال مهم بحث سگمنت راننده‌ها و مسافر‌ها بود : مثلا راننده ای که سیگار میکشه و ماهی 1 سفر میره آیا با راننده ای که سیگاریه ولی روزی 100 تا سفر میره فرق داره؟

ما باید جور دیگه ای به این فرد فیدبک بدیم یا نه تفاوتی نباید داشته باشه؟

چهارمین سوال بحث ضمانت اجرایی و سیستم تشویق و تنبیه هست ( :

اگر یک کاربری امتیازش بد بود و دائما هم داشت بدتر میشد چه نوع اکشنی باید برداریم؟

و اگر کاربری امتیازش بالا بود و بالاتر رفت چی؟ آیا انتظاری از ما داره؟

پنجمین سوال بحث سفیران و مسافرانی بود که new joiner بودن و یا مدت ها بود با ما همکاری نمی کردن و مجددا فعال شده بودن : به این افراد باید چطوری فیدبک بدیم؟ آیا باید فرقی با سایر سفیران مون داشته باشن؟

ششمین سوال بحث communication بود، تقریبا یکی از چالشی‌ترین قسمت‌ها این بود که ما فهمیدیم چه فیدبکی باید به سفیر یا مسافر بدیم، ولی اینکه چطوری و با چه ادبیاتی بگیم که هم صریح باشه هم مفید و سازنده باشه و باعث دلخوری و ناراحتی نشه واقعا چالش برانگیز بود.

هفتمین سوال بحث threshold های rating از 0 تا 10 بود، اینکه در چه threshold هایی ما به یک سفیر یا مسافر میگیم وضعیتت خوبه، بده، عالیه، نگران کننده است یا غیره.

در نهایت پاسخ به همه‌ی این سوالات و اینپوت‌ها به ما کمک کرد تا بتونیم لاجیکی رو بنویسیم که اکثر concern های استک هولدرهارو برطرف کرد.

ایجاد رابط کاربری

تیم طراحی‌مون بر ایجاد یک تجربه‌‌ی کاربری ساده و روان تمرکز کرد. ما وایرفریم‌ها و نمونه‌های اولیه‌ای طراحی کردیم که استفاده از اون‌ها حتی برای کاربران کمتر آشنا با فناوری نیز آسون باشه. این طراحی‌ها با گروه‌های کوچکی از کاربران تست شدند تا بازخوردهای اولیه جمع‌آوری و طراحی مون بهینه بشه.

نمونه ای از طراحی های اولیه رو میتونید در زیر مشاهده کنید :

دیزاین نهایی :

**توسعه‌ی سیستم تشویق و تنبیه**

همونطور که در قسمت طراحی مکانیزم جاستیس اشاره کردم ما باید ابزاری برای تشویق و تنبیه در نظر میگرفتیم.

برای تشویق در threshold های مشخص ، از سیستم loyalty club ، tapsi garage و همینطور incentive های رانندگان مثل کمیسیون رایگان و غیره استفاده کردیم و برای سیستم تنبیه در threshold های مدنظر ، از چنل های ارتباطی مختلف ابتدا visibility مناسب دادیم و warn مشخصی رو ارسال کردیم و در نهایت type ای از Block شدن رو در یک threshold مشخص تعریف کردیم که باعث بلاک شدن موقت کاربر میشه .

و البته با توجه به اینکه در توبه همیشه بازه ، ما هم راه هایی برای unblock شدن و برای جبران و اصلاح فیدبک های منفی به کاربران‌مون دادیم.

مرحله سوم : دولوپ و تست

همکاری با تیم فنی

همونطور که در قسمت طراحی مکانیزم فیدبک هم بهش اشاره کردم ما از ابتدای پروژه تیم فنی رو دخیل کردیم و اینپوت های اونا رو داشتیم.

به عنوان تجربه میتونم بگم مهندسین نرم افزار بهترین منبع الهام بخش شما هستن و همیشه اینپوت ها و فیدبک هایی که میدن باعث رشد و پیشرفت پروژه میشه.

نکته کنکوری: هیچ وقت هیچ پروژه و حتی "یک فیچر بنظر خودتون ساده" رو قبل از مشورت با تیم فنی نهایی نکنید ( :

پس از نهایی شدن طراحی‌ها، grooming های زیادی رو با تیم های backend و front و android و Test و infrastructure و data analyst ها رفتیم و بعد از رفت و برگشت ها و تغییرات لازم در دیزاین ، به یک درک مشترک از پروژه رسیدیم و در انتها مستندات فنی دقیقی تهیه شد تا فرآیند توسعه به خوبی پیش بره و همه‌ی ذینفعان درک روشنی از نیازمندی‌ها داشته باشن .

بعد از اینکه Timeline پروژه مشخص شد وارد فاز توسعه شدیم. تیم فنی در اسپرینت‌های پیوسته کار خودشون رو انجام دادن و با ارتباط مستمر، اطمینان حاصل شد که پروژه در مسیر درست پیش میره.

تضمین کیفیت

ما تو تپسی چندین نوع و چندین مرحله تست داریم که متناسب با پروژه تست هارو انتخاب می کنیم که برای پروژه جاستیس میتونم بگم همه ی موارد زیر رو انجام دادیم :

علاوه بر تست های فنی که کمی پایین تر راجبشون صحبت میکنم، بچه های دیزاین مون زحمت Usability تست و برعهده داشتن(به عنوان PM حتما تو این جلسات شرکت کنید، کاملا اجباریه).

سایر تست های فنی unit test و end to end تست هایی بود که خود بچه های فنی نوشتن و مطمئن میشدن که کدها به درستی کار میکنه و حتی در نهایت خودشون هم یک بار به صورت manual تست میکنن که خیالشون راحت باشه جنس مون سالم به دست QA میرسه ( :

پس از اینکه جنس مون روی محیط Development یا همون محیط Test آماده شد، در ادامه تیم QA دست به کار میشه و شروع به نوشتن یه سری automation تست و سناریو تست میکنه.

در نهایت خودم هم سعی کردم سناریوهای مختلف رو به صورت منوال بررسی کنم که اکسپرینس نهایی کاربر رو تجربه کنم.

مرحله چهارم: لانچ و پست لانچ

برای ارزیابی محصولمون یک A/B تست run کردیم و متریک های مدنظرمون که ارتباط مستقیم با اهداف این پروژه داشتن رو به دقت مانیتور کردیم.

نتایج P-value و T-statistic به وضوح بهمون نشون داد که جاستیس تاثیر قابل توجهی روی متریک های مدنظرمون شامل(تغییرات در میانگین امتیازات مسافران و تاثیر اون‌ها بر شاخص‌های رضایت) گذاشته که همین باعث شد مرحله به مرحله حجم انتشار رو بیشتر کنیم و در حال حاضر تمامی سفیرانمون این محصول رو در اختیار دارن.

بهینه سازی پروژه

پس از لانچ کامل جاستیس، داشبوردی دائمی رو برای مانیتور عملکرد سیستم و تحلیل دیتا ایجاد کردیم و معیارهای کلیدی رو به صورت فصلی ارزیابی می‌کنیم و بر اساس این اطلاعات، بهبودهای دوره‌ای انجام میدیم.

نتیجه‌گیری و تشکر

خب به پایان آمد این دفتر، حکایت همچنان باقیست

این پروژه واقعا بزرگ بود و تیم‌های خیلی زیادی به ساخت و پیشرفتش کمک کردن که از همین جا از یکایک شون قدردانی و تشکر میکنم.

امیدوارم نکات مطرح شده براتون مفید بوده باشه و خیلی مفتخر و خوشحال میشم که سوالات و نظراتتون رو برام بنویسید.