مدیریت محصول - بخش پنجم

برای خواندن مدیریت محصول بخش چهارم روی لینک زیر کلیک کنید:

https://vrgl.ir/yFdCl

نکات مهم:

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

داستان کاربر چیست و چگونه باید آن‌ها را نوشت؟

داستان‌های کاربر (User Stories) واحدهای کوچکی از توسعه هستند که توصیف کننده‌ی عملکرد یک محصول از دید کاربر می‌باشند. برخلاف توضیحات فنی، یک داستان کاربر به وضوح بیان می‌کند که کاربر با استفاده از آن چه چیزی را می‌خواهد به دست آورد.

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

بسیاری از تیم‌های توسعه همچنان از توضیحات فنی نیز استفاده می‌کنند؛ با این حال، مهم است که تمرکز بر داستان‌های کاربر و دیدگاه کاربر حفظ شود.

چرا به داستان‌های کاربر نیاز داریم؟

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

چگونه داستان‌های کاربر را بنویسیم؟

این داستان‌ها معمولاً توسط مدیر محصول یا مالک محصول نوشته می‌شوند؛ اما باید تا حد امکان ساده باشند و در حد یکی دو جمله خلاصه شوند. اگر نوشتن یک داستان بیش از حد پیچیده است، ممکن است لازم باشد آن را به چندین داستان کاربر کوچک‌تر تقسیم کنید.

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

قالب استاندارد برای نوشتن داستان‌های کاربر

یک قالب رایج برای نوشتن داستان‌های کاربر به این شکل است:

• "به عنوان یک [نوع کاربر]، می‌خواهم [هدف مورد نظر] را به دست آورم تا [دلیل]."

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

نمونه‌هایی از داستان‌های کاربر

این داستان کاربر می‌تواند به چندین داستان کوچک‌تر تقسیم شود. چند نمونه از این داستان‌های کاربر به شرح زیر است:

• "به عنوان یک کاربر، می‌خواهم بتوانم وظایف خود را بر اساس تاریخ سررسید مرتب کنم تا بتوانم کارهای روزمره خود را اولویت بندی کنم."
• "به عنوان یک کاربر، می‌خواهم بتوانم وظایف خود را بر اساس مسئولیت آن‌ها مرتب کنم."
• "به عنوان یک کاربر، می‌خواهم بتوانم وظایف خود را بر اساس اولویت مرتب کنم."

فهرست نیازهای محصول و مدیریت آن در اسکرام

فهرست نیازهای محصول یا Product Backlog، لیستی اولویت‌بندی‌شده از نیازمندی‌ها و وظایف محصول است که شامل تمام موارد لازم برای ساخت محصول، مانند ویژگی‌ها، رفع اشکالات و کارهای فنی دیگر می‌شود. این فهرست در فرآیند اسکرام به‌طور مداوم به‌روزرسانی و اولویت‌بندی می‌شود تا تیم توسعه بتواند بهینه‌ترین مسیر را برای توسعه محصول تعیین کند.

مدیریت فهرست نیازهای محصول

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

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

در یک فهرست محصول، چهار نوع اصلی از وظایف وجود دارد که به تفصیل زیر توضیح داده می‌شوند:

1. داستان‌های کاربر (User Stories): بیشتر تسک های فهرست نیازهای محصول شامل داستان‌های کاربر است. این داستان‌ها توصیف‌کننده‌ی ویژگی‌های محصول از دیدگاه کاربران هستند و به‌گونه‌ای بیان می‌شوند که تیم توسعه متوجه نیاز و ارزش این ویژگی‌ها برای کاربر شوند.
2. اشکالات و خطاها (Bugs): اشکالات به خطاهای نرم‌افزاری گفته می‌شود که در کد پیدا می‌شوند و معمولاً پس از گزارش کاربران یا اعضای تیم به فهرست محصول افزوده می‌شوند. این وظایف اغلب دارای اولویت بالایی هستند و در جلسات اسکرام مورد بحث قرار می‌گیرند تا به سرعت رفع شوند.
3. بازنویسی کد (Refactoring): بازنویسی به بهبود ساختار کد بدون تغییر عملکرد ظاهری نرم‌افزار اشاره دارد. این فرآیند باعث بهبود خوانایی کد و کاهش پیچیدگی آن می‌شود.
4. کسب دانش و آموزش (Knowledge Acquisition): تسک های آموزشی به جمع‌آوری اطلاعات و دانش لازم برای توسعه‌های بعدی می‌پردازند. به‌عنوان مثال، اگر تیم نیاز به آشنایی با کتابخانه‌های پلاگین وردپرس داشته باشد، وظیفه‌ای برای تحقیق در این زمینه ایجاد می‌شود .

اولویت بندی تسک ها / یوزر استوری ها با روش MoSCoW

در فرآیند توسعه محصول، روش‌های متعددی برای اولویت‌بندی وظایف فهرست محصول وجود دارد. یکی از محبوب‌ترین روش‌ها، روش MoSCoW است. این روش به تیم کمک می‌کند تا به توافق عمومی با تمامی ذی‌نفعان برسند و اطمینان حاصل کنند که نیازهای مهم‌تر ابتدا انجام می‌شوند. در روش MoSCoW، اولویت‌ها به چهار دسته تقسیم می‌شوند:

1. موارد ضروری (Must have): نیازهایی که باید حتماً در نسخه بعدی محصول پیاده‌سازی شوند.
2. موارد مورد نیاز (Should have): نیازهایی که بهتر است پیاده‌سازی شوند، اما در صورت نبود منابع کافی، می‌توان آنها را به تأخیر انداخت.
3. موارد مناسب (Could have): ویژگی‌هایی که اگر زمان و منابع کافی باشد، پیاده‌سازی خواهند شد.
4. موارد غیرضروری (Won’t have): ویژگی‌هایی که فعلاً نیازی به پیاده‌سازی آنها نیست .

برای مشاهده و ادامه موضوع مدیریت محصول به قسمت های بعدی این مقاله در ویرگول مراجعه کنید.