از ایده تا تحویل: چطور یک فیچر خوب در محصول دیجیتال شکل می‌گیرد

همه ما شنیده‌ایم که «این نانی که می‌خوریم مسیر پرپیچ و خمی را طی کرده و زحمات زیادی برایش کشیده شده تا به دست ما برسد.» همین تصویر برای ساخت یک فیچر در یک محصول دیجیتال کاملا مصداق دارد: از یک ایده ساده تا تجربه‌ای که کاربر از آن رضایت داشته باشد، مسیر طولانی و پرزحمتی وجود دارد.

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

محصول: مراحل اصلی از ایده تا اجرا

1. تولد ایده و سنجش اولیه

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

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

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

2. مشورت با تیم فنی

بعد از اینکه از وجود نیاز این فیچر در محصول خود مطمئن شدید، باید با CTO یا مدیر فنی تیم مشورت کنید و ابعاد این فیچر را با او در میان بگذارید.

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

3. آماده‌سازی PRD

در همین حین مدیر محصول مشغول نوشتن یک PRD کامل و باجزئیات می‌شود و به تمام جوانب فیچر فکر می‌کند تا آن فیچر از همه جهات قابل ارائه و قابل دفاع باشد.

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

مدیر محصول یک PRD کامل می‌نویسد که شامل:

• هدف فیچر

• سناریوهای کاربری / User Flows

• مسیرهای مختلف مواجهه کاربر با فیچر

• معیارهای پذیرش یا Acceptance Criteria

این سند قرار است در آینده مبنای همه تیم‌ها شود.

4. فازبندی و برنامه‌ریزی اسپرینت

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

5. طراحی UX/UI

بعد از این، فیچر به تیم دیزاین ارسال می‌شود و دیزاینرها شروع می‌کنند به ساخت Wireframe و Prototype. البته این را فراموش نکنید که تیم دیزاین هم می‌تواند و البته بهتر است به‌طور مجزا بنچمارک خود را از جنبه طراحی محصول انجام دهد و طراحی و Flow های مختلف برای آن فیچر را از نقطه نظر خود به دست آورد و به مدیر محصول پیشنهاد بدهد.

6. جلسه Feature Grooming

سپس در یک جلسه Feature Grooming با حضور تیم محصول، دیزاین و Dev (توسعه‌دهندگان) و گاهی هم QA / تضمین کیفیت، فیچر با تمام جزئیات و سناریوهای ممکن از 0-100 توضیح داده می‌شود تا هیچ بعدی از ابعاد آن فراموش نشده باشد.

اینجا باید همه تیم‌ها نظرات تخصصی خود را بیان کنند و نگرانی و دغدغه‌ها را با شفافیت توضیح دهند.

7. خرد کردن تسک‌ها (User Story Mapping)

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

مثلاً در یک فلوی Sign-up روی سایت، اینکه ساین آپ با ایمیل و پسورد انجام شود یا با اکانت گوگل یا اصلا با یک OTP ساده، یا اینکه حتی فلوی Forgot Password در صورت فراموشی رمز عبور توسط کاربر چه باشد هر کدام یک یوزر استوری مجزا هستند و باید برای آن فکر شود.

8. تعیین AC و DoD

بعد از این مرحله نوبت به تعریف AC یا معیارهای پذیرش می‌رسد. باید دقیقاً مشخص شود تحت چه حالتی فلویی که تیم Dev توسعه داده است پذیرفته خواهد شد و با چه DoD هایی انجام‌شده تلقی می‌شود. همه این بخش‌ها باید پیوست PRD ما باشند.

حالا که PM به کمک تیم تسک‌ها را خرد و مشخص کرد، تیم می‌تواند 1 هفته روی AC ها فکر کند تا کاملاً با همه ابعاد آن آشنا شود.

9. جلسات Backlog Grooming و Planning

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

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

10. پیاده‌سازی، تست و تحویل

توسعه طبق اسپرینت پیش می‌رود، تیم QA سناریوها و Edge Case ها را تست می‌کند و در نهایت فیچر به مرحله انتشار و بررسی پس از انتشار می‌رسد.

نکات مهمی که در ساخت فیچر نباید نادیده بگیرید

• بنچمارک دقیق: بنچمارک برای شناخت سلیقه کاربر و فضای مارکت بسیار مهم است و هم PM و هم تیم دیزاین باید به‌دقت این کار را انجام دهند و برای آن وقت و توجه کافی صرف کنند.

• دقت روی Edge Case ها: بعضی مواقع سناریوهایی برای استفاده از یک فیچر وجود دارد که حتی خود تیم هم متوجه آن نشده اما ممکن است کاربری یک راه نادر برای انجام آن پیدا کند. برای همین تیم و به‌خصوص نیروهای QA باید تمام دقت خود را در بررسی انواع سناریوها به خرج دهند.

• شفافیت تسک‌ها: تسک‌ها باید کاملاً شفاف شده باشند و اگر هر کدام از اعضای تیم Dev به هر دلیلی با ابعاد هر یک از تسک‌ها مسئله دارد نباید آن تسک را بپذیرد تا زمانی که کاملاً بفهمند چرا و چگونه آن تسک قرار است انجام شود.

• ارتباط بین تیمی: موفقیت فیچر به هماهنگی تیم محصول، طراحی، توسعه و QA وابسته است. جلسات منظم و مستندسازی خوب در این مراحل بسیار ضروری است.

• فازبندی معنادار: تقسیم فیچر به فازهای منطقی کمک می‌کند زودتر ارزشی که داریم روی آن کار می‌کنیم به کاربر برسد و ریسک‌های آن کاهش یابد.

• فیدبک‌گیری پس از انتشار: تنها تحویل فیچر کافی نیست؛ بلکه باید نتایج استفاده را نیز اندازه‌گیری کرد و فیچر را در به‌روزرسانی‌های بعدی براساس آن بهبود داد.

جمع‌بندی

ساخت یک فیچر خوب از پختن نان هم پیچیده‌تر است: نیاز به مواد اولیه مناسب (ایده و نیازسنجی)، دستور پخت دقیق (PRD و فازبندی)، تیم آشپز ماهر (طراحی و توسعه) و در نهایت تست مزه توسط مشتری (QA و فیدبک پس از انتشار) دارد. وقتی هر مرحله با دقت انجام شود، احتمال رسیدن به تجربه‌ای که کاربر واقعا آن را دوست داشته باشد بسیار بیشتر می‌شود.