چگونه داستان کاربر بنویسیم - مثال از تورم کشور

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

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

بعنوان ___________(کاربر/مشتری/پرسونا)

میخواهم ______________ (یک قابلیت/امکان/فیچر)

تا بتوانم ________________ (نیاز/دلیل/برآیند مورد انتظار)

در همین راستا، خواستم مفهوم واقعی داستان کاربر یا همان User Story را به او توضیح بدهم، دیدم ذهنش کلا درگیر تورم و وضعیت اقتصادی کشور هست، گفتم شاید بد نباشد که از همین به عنوان مثال واقعی استفاده کنیم. از او پرسیدم "به نظرت مردم چرا می ریزن ماشین، دلار، سکه و ... ثبت نام می کنند؟" جواب داد: "با این بی ارزش شدن پول، نگران هستند خوب..." گفتم: "پس داستان این کاربر ما با همان فرمتی که خودت نوشتی، چی میشه؟"

بعنوان کسی که نگران ارزش پولش هست (پرسونا)

من دلار میخرم (چیزی که میخواهد یا انجام میدهد)

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

حالا فرض کنید، دولت مثل تیم های فنی، به نیاز کاربر اهمیتی نمی‌دهد، و امور را از نگاه خودشان بررسی می‌کنند (تیم های فنی به همه امور فنی نگاه می کنند). در همین مثال، بانک مرکزی، یک نیازمندی تعریف می‌کند،

بعنوان بانک مرکزی

ما خرید و فروش دلار رو محدود به 2000 دلار در سال می کنیم

تا بتوانیم بازار ارز را کنترل کنیم

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

بعنوان کسی که نگران ارزش پولش هست (پرسونا)

من طلا و سکه میخرم (چیزی که میخواهد یا انجام میدهد)

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

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

عدم درک درست نیاز و مشکل مشتری باعث خواهد شد تا تصمیم های ما اشتباه باشند، مثلا در یک جلسه بگوییم،

بعنوان سیستم حاکمیتی

می‌خواهیم بر عایدی درآمد مالیات تعیین کنیم

تا با سود جویان و دلالان مقابله کنیم

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

تا زمانی که ما نیاز اصلی کاربر یا مشتری را درست تشخیص ندهیم، اقدامات یا قابلیت هایی که ارائه می‌کنیم، اثر بخش نخواهند بود. حالا چه در قالب "بعنوان ___ می خواهم ___ تا بتوانم___" بنویسم یا Use Case یا هر اسم دیگری، کاربران با همان روش هایی که بلد هستند کار خود را به پیش خواهند برد و آن قابلیت و اقدام ما بی استفاده خواهد ماند.

از کجا مشکل یا نیاز واقعی را کشف کنم؟

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

در این مسیر نیز ما امکان دارد با خطاهای شناختی مواجه بشویم، مثلا پخش یک ویدئو در فضای مجازی، اینکه مردم هجوم آوردن تا دلار بخرند، شاید ما را با این خطا مواجه کند که همه اینگونه هستند(تعمیم دادن یا Over-generalization) یعنی با یک دیتای کم نتیجه گیری کنیم. یا صرفا دنبای داده هایی بگردیم که فرضیات ما را تایید کنند(خطای میل به تایید (Confirmation Bias))، دیدی گفتم مردم همه دلال شدند.

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

مثال دیگری از داستان کاربر در فضای توسعه نرم افزار

چابک و موفق باشید

اسد صفری