داستان کاربر تعاریف و توصیف‌هایی شفاف از ویژگی‌های مورد انتظار کاربران است که پرداختن به آن می‌تواند در نهایت ارزش محصول را از دید مشتری مشخص کند. با ما همراه باشید تا بیشتر با این مفهوم آشنا شویم.
داستان کاربر (User Story) معمولا اصطلاحی در توسعه نرم افزار و مدیریت در حوزه‌های مختلف محسوب می‌شود که برای توصیف نیازهای مشتری گردآوری خواهد شد. درواقع اگر مطالبی از این دست را در پلازا مطالعه کرده باشید، حتما با رویکرد چابک آشنا هستید. اگر هم نه، خواندن مقاله سیستم نرم افزاری چابک چیست؟ را به شما پیشنهاد می‌دهیم. در سیستم نرم افزاری چابک اشاره کردیم که بررسی نیازهای مشتری در اولویت قرار دارد.
پس داستان کاربر در توسعه نرم افزار استفاده می‌شود تا ویژگی‌هایی که یک نرم افزار از دید کاربر باید داشته باشد، بیان شوند. اما نه تنها User Story در مهندسی نرم افزار، بلکه در بخش‌های دیگر دنیای فناوری اطلاعات که با مشتری سروکار داریم هم استفاده می‌شود؛ مانند فرایند تولید محتوا که مثال خوبی در این زمینه است. درواقع داستان کاربر به ما می‌گوید که مخاطب چه کسی است و چه انتظاری از نرم افزار و سیستم مورد نظر دارد.
آنچه در ادامه می‌خوانید:
- داستان کاربر در توسعه نرم افزار چابک
- چگونه داستان کاربر در توسعه نرم افزار نوشته می شود؟
- ارزیابی داستان کاربر
- داستان کاربر در تولید محتوا
- داستان کاربر چگونه باشد تا محتوای موثرتری نوشته شود؟
- سخن پایانی
داستان کاربر در توسعه نرم افزار چابک
همان‌طور که در مقدمه بیان شد، داستان کاربر در توسعه نرم افزار چابک باعث خواهد شد تا مهندسین توسعه نرم افزار تعریف ساده‌ای از نیازهای مشتری در اختیار داشته باشند. با همه این‌ها این مستند با توجه به نوع پروژه ممکن است توسط کاربران، مشتری، مدیران و اعضای تیم نرم افزاری نوشته شود.
اما حالا که تا حدی دانستیم داستان کاربر چیست، ببینیم که چرا اهمیت دارد. زمانی که یک پروژه نرم افزاری در حال توسعه است هر چه مشتریان و تیم بیشتر در کار پیش می‌روند، ممکن است اطلاعات جدیدی از سیستم یاد بگیرند. در نتیجه این موضوع باعث خواهد شد، در برخی از پروژه‌های نرم افزاری نیازها به صورت مداوم در حال تغییر باشند. پس به مستنداتی نیاز خواهد بود. روش User Story باعث صرفه‌جویی در زمان خواهد شد؛ چراکه طبق نظر کاربران اصلاح شده و پیشرفت می‌کند. در نتیجه کیفیت در فرایند توسعه نرم افزار یا محصولی دیگر بیشتر شده و پروژه پیش رو مورد پسند و سلیقه مشتری نیز خواهد بود.
چگونه داستان کاربر در توسعه نرم افزار نوشته می شود؟
داستان کاربر به زبانی ساده نوشته می‌شود که باید هدف مشخصی را دنبال کند و دلیل مشخصی داشته باشد. کاربری که در داستان از آن صحبت می‌شود باید واقعی باشد و نباید عضوی از اعضای تیم توسعه محسوب شود. شاید در سیستم چند داستان کاربر وجود داشته باشد که مزایای یکسانی داشته باشند. این موضوع طبیعی است. بهتر است در شروع نوشتن User Story، یک پیش‌نویس تهیه کنید. پیش نویس باید در ابتدا به نیازهای ضروری شما پاسخ دهد. اینکه:
- برای چه کسی طراحی می‌شود
- چه انتظاراتی از سیستم می‌رود
- چرا مهم است
با همه این‌ها، باید بگوییم که داستان کاربر درواقع فرایندی است که طی آن نیازها کشف می‌شود و نباید به عنوان سندی برای تحلیل نیازها از آن استفاده شود. در روش‌های سنتی معمولا تحلیلگر سیستم سعی می‌کرد تا نیازهای مشتری را درک کند، اما در روش‌های مدرن باید مراحل زیر برای شناسایی User Story طی شوند:
- باید با کاربران گفتگو کرد.
- نیازهای کاربران به عنوان داستان کاربر در کاغذهای کوچکی نوشته می‌شود. دلیل انتخاب کاغذهای کوچک هم این است که نیازی به توضیحات اضافه یا بیان جزئیات نخواهد بود. در این نوشته باید مشخص باشد که با چه نوع کاربری در ارتباط هستیم، کاربر چه نیازی دارد و چه هدفی نیز دنبال می‌شود.
- بعد از نوشتن نیازها با منبعی از نیاز کاربران رو به رو خواهیم بود که باید توسط تیم کاملا درک شوند.
- تیم باید بتواند ویژگی‌های نمونه را برای پاسخگویی به نیازهای کاربر آماده کند.
- بعد از این مرحله در مراحل بعدی نیز جزئیاتی می‌تواند به این طرح اضافه شود.
ارزیابی داستان کاربر
حالا با مواردی که اشاره شد، باید معیاری برای ارزیابی نیز داشته باشیم و ببینیم که داستان کاربر که نوشته‌ایم تا چه اندازه خوب و کاربردی خواهد بود. در این قسمت باید از مفهوم INVEST کمک بگیریم. این مفهوم توسط بیل ویک ارائه شد و شش معیار (مستقل بودن، قابل بحث، ارزشمند، تخمین زدنی یا برآورد کردنی، کوچک، قابل آزمایش) را برای بررسی User Story بیان می‌کند. اگر داستان نوشته شده با معیارهای INVEST همخوانی نداشته باشد، باید دوباره گردآوری شود تا داستانی که استاندارد باشد داشته باشیم. این معیارها در ادامه آمده‌اند:
مستقل از سایرین (Independent)
داستان کاربر باید مستقل بوده و ارتباط زیادی با سایر داستان های کاربر در سیستم نداشته باشد؛ چراکه نظم بخشیدن به داستان‌های مستقل ساده است، به هر نحوی قابل اجرا خواهند بود و وابسته به داستان کاربر دیگری نیستند. پس باید هر User Story را به دور از هر گونه وابستگی به سایر داستان‌های کاربر بنویسیم.
قابل مذاکره بودن (Negotiable)
داستان کاربر باید به گونه‌ای نوشته شود که قابل بحث و مذاکره باشد. به یاد داشته باشید، داستان‌های کاربر در گفتگوها هستند که شکل می‌گیرند. پس در طول گفتگوها باید روی جزئیات مذاکره شود. هرچند داستان‌های خوب به طور دقیق نوع عملکرد را شرح می‌دهند، اما باید به گونه‌ای باشند که اعضای تیم توسعه و ذینفعان نیز درباره‌اش بتوانند مذاکره کنند. دقت داشته باشید، هدف این است که خواسته‌های کاربر برآورده شوند، اما نباید به موضوعات غیرکاربردی در User Story اشاره کرد.
ارزشمند (Valuable)
داستان کاربری که نوشته می‌شود باید برای کاربر واقعی یا مشتری ارزشمند باشد. درواقع اگر داستان کاربری برای مشتری مفید نباشد، پس لازم نیست که بخشی از گزارش باشد. هر چند تیم نمی‌تواند میزان ارزشمند بودن داستان کاربر یا نیازی را مشخص کند، اما کاربر یا مشتری این را به خوبی نشان می‌دهد. پس اگر داستان کاربری از نظر مشتری ارزشمند نیست، یا باید تغییر کند یا اینکه نادیده گرفته شود.
تخمین پذیر بودن (Estimable)
داستان کاربر باید طوری باشد که تیم اسکرام بتوانند آن را برآورد کنند و بدانند که برای طراحی، توسعه، ساخت و آزمون چه مراحلی را پیش رو خواهد داشت. تیم اسکرام باید بتواند داستان‌ها را برآورد کند. اولویت‌بندی داستان‌های کاربر (برای طراحی، توسعه، ساخت و آزمون) بر اساس همین برآوردها انجام می‌شود. واژه برآورد به اندازه داستان کاربر و پیرو آن به تلاش موردنیاز و ارزش‌آفرینی داستان دلالت می‌کند. بدیهی است داستان‌های بزرگ‌تر از کشش بیشتری برخوردار هستند و به بودجه بیشتری هم نیاز دارند. گاهی اوقات هم داستان‌های بزرگ باید به چند داستان کوچک‌تر تقسیم شوند.
کوچک (Small)
یکی از مهم‌ترین خصوصیات در داستان کاربر، کوچک بودن آن است. درواقع برش‌هایی که داستان کاربر را به بخش‌های معنا دار کوچکی تقسیم می‌کند، می‌تواند موثرتر باشد. در حقیقت اگر داستان کاربر کوچک باشد، می‌توان مسائلی مانند عدم قطعیت را راحت‌تر در آن شناسایی کرد.
قابل تست (Testable)
هر داستان کاربر باید معیاری برای تست شدن داشته باشد. درواقع اگر قابل آزمایش کردن نباشد، نمی‌توان از آن به عنوان یک داستان کاربر خوب یاد کرد؛ چراکه ما در هر مرحله باید ببینیم آیا نیازهای اشاره شده در User Story برآورده شده است یا خیر. از طرف دیگر قابل آزمون بودن باعث خواهد شد تا داستان کاربر طی آزمون‌های مکرر بهتر شود.
داستان کاربر در تولید محتوا
زمانی که اهمیت نرم افزارها در دنیای فناوری بسیار بالا بود، مهندسین نرم افزار و برنامه نویسان پروژه‌های خود را بر اساس آنچه که مشتریان نیاز داشتند، تولید می‌کردند؛ اما گاهی کارها با آنچه که مشتریان می‌خواستند، متفاوت بود و تلاش‌ها در این زمینه بی فایده می‌شد و هزینه زیادی صرف طراحی نرم افزار یا محصولی می‌شد که مشتری از آن رضایت ندارد. با این حال با مطرح شدن ابزارهای توسعه نرم افزار مانند سیستم نرم افزاری چابک، مسئله User story در مهندسی نرم افزار مطرح شد که موفقیت‌هایی را برای دنیای فناوری به ارمغان آورد.
از آنجا به بعد بود که اثبات شد داستان کاربر خارج از دنیای برنامه نویسی و نرم افزار نیز می‌تواند مورد استفاده قرار بگیرد. درواقع یکی از این بخش‌ها حوزه تولید محتوا است. به طوریکه امروزه تولید کنندگان محتوا و فعالین عرصه دیجیتال مارکتینگ نیازهای خوانندگان و مخاطبین خود را در اولویت قرار می‌دهند.
داستان کاربر باعث می‌شود تا تیم تولید محتوا تلاش‌های خود را با نیازهای مشتری همسو کند. اما آنچه که در تولید محتوا ما از داستان محتوا معرفی می‌کنیم، هرچند در مفهوم مشابه داستان کاربر در توسعه نرم افزار است، اندکی در تعریف متفاوت خواهد بود. ولی داستان کاربر در توسعه نرم افزار و تولید محتوا دو مفهوم کاملا متفاوت نیستند. در بخش بعدی با یک مثال این مفهوم را بیشتر توضیح می‌دهیم.
داستان کاربر چگونه باشد تا محتوای موثرتری تولید شود؟
تصور کنید یک شرکت دیجیتال مارکتینگ دارید. یکی از مشتریان شما که داروخانه‌ای آنلاین دارد و می‌خواهد محصولات آرایشی و بهداشتی خود را آنلاین بفروشد، از شما می‌خواهد مطالبی در زمینه زیبایی برایشان تولید کنید تا مردم با خواندن محتوا به خرید محصولات و آشنایی با آنها نیز ترغیب شوند. هدف این است که مخاطبین وبلاگ با روش‌هایی برای داشتن پوست و مویی شفاف و درخشان آشنا شوند. حالا تیم تولید محتوای شما ممکن است برای هر مطلبی که قرار است بنویسد، یک داستان کاربر با پاسخ به سوالات زیر طراحی کند:
- چه کسی می‌خواهد مطلب را بخواند
- چه چیزی در مطلب بیان می‌شود
- چرا خواننده به مطلب علاقه مند خواهد بود
اگر بتوان تیم تولید محتوا را در داستان کاربر درگیر کرد، می‌توان به داشتن محتوای منسجم و باکیفیت‌تر نیز امیدوار بود. می‌توان از ایده‌هایی که نویسنده، طراح و سردبیر دارند، استفاده کرد و داستان کاربر را به صورت کتبی نوشت؛ بطوریکه همسوی نیازهای مخاطب باشد. با نوشتن داستان کاربر حالا دیگر تیم تولید محتوا، کمتر محتوای بی‌ارزش و بدون استفاده تولید خواهند کرد و مخاطبین و خوانندگان با محتواهای فکر شده و مرتبط به هم روبه‌رو خواهند بود.
امروزه بهره‌مندی از چنین ابزارهایی کمک می‌کنند تا حتی بدون ابزارهای خاص مدیریت پروژه مانند اسکرام و کانبان بتوان هماهنگی داخلی بهتری در روند اجرای کار ایجاد کرد. در اینجا می‌توانید بیشتر با مدل اسکرام آشنا شوید.
سخن پایانی
با توجه به مطالب بیان شده می‌دانیم که مشتری و کاربری که قرار است با سیستم نرم افزاری کار کند یا مخاطب یک پلتفرم دیجیتال است، در موفقیت آن سیستم، نقش مهمی خواهد داشت. پس باید نیازهایش شناسایی شود و روند کار طوری باشد که با تغییر نیازها بتوان به صورتی بهینه بدون اتلاف وقت به آنها رسیدگی کرد. اینجاست که User story در مهندسی نرم افزار یا برای اهداف مشابه به کمک تیم توسعه یا تحلیل می‌آید و کمک خواهد کرد تا نیازهای کاربر شناسایی شوند. همچنین بیان کردیم که می‌توان از مفاهیم داستان کاربر در فرایندهای مختلفی مانند تولید محتوا نیز استفاده کرد.