این نوشته قراره یکی از تکنیک های خیلی هیجان انگیز تو دنیای ساخت نرم‌افزار رو برامون توضیح بده، تشریح کنه و مثال بزنه. از اونجایی که این پست رو میخونید احتمالا به ساختن اپلیکیشن، وب‌سایت و خلاصه برنامه علاقه دارید. قطعا تو مسیر ساختن برنامه به لحظه‌هایی برمی‌خورید که فکرتون پر از ایده شده ولی چون دارید به همه چیز با هم فکر می‌کنید، دیگه نمیدونید کدوم مسیر رو برید و یا اصلا چی شد که به اینجای کار رسیدید.
اگه تو این مرحله از تلاش کردن دست نکشیده باشید، و دنبال راه حل بوده باشید حتما به اصول‌ها و روش‌هایی برای مدل کردن نرم‌افزار رسیدین که نه تنها نجات دهنده این شرایطن، بلکه تنها راه حل هم هستن! هرچقدر هم صنعت تولید نرم‌افزار پخته‌تر میشه، سر و کله این مدل‌ها بیشتر پیدا میشه؛ چون تیم‌ها خیلی از روش‌های Agile-که تمرکز اون‌ها تولید نرم افزار به صورت چابک با تقسیم کل پروژه به بخش‌های کوچک‌تره که کلی فایده داره-خوششون اومده و مدل‌سازی‌های کارآمد و تکنیک‌های جدید، خیلی به ابزارهای خوبی برای پیش بردن پروژه به روش Agile هستن تبدیل شده.
بانی اصلی این نوشته یک فرد با سِمَت "مشاور طراحی اپلیکیشن" هست، به اسم "Jeff Patton" که یک مدلی ارائه کرد به نام "User Story Mapping" که تو این چند ساله خیلی مورد استفاده تیم های Agile قرار گرفته. این روش بیشتر اوقات برای تبدیل یک ایده به یک برنامه مورد استفاده قرار میگیره ( البته اون ایده میتونه یک ویژگی باشه که قراره به برنامه‌مون اضافه بشه). تو این روش، ما نیازهامونو با عینک یک کاربر می بینیم، و با نمایش دادن اون نیاز به صورت تصویری دید خوبی از کلیات پیاده سازی برنامه می‌گیریم؛ تصور کنید ما هر نیازی که کاربر داره رو نوشتیم و برنامه‌مون هم همه اون رو برآورده میکنه، خب پس عملا کار تموم شده دیگه، نه؟ قبول دارم که یه برنامه‌نویس با تجربه میگه نه، ولی قطعا تایید میکنه که به همین مرحله رسیدن تو یه برنامه و برآورده کردن نیازهای کاربر، خودش یکی از بزرگترین موانع کاره.
برای به دست آوردن و تصویر سازی نیازهای کاربر، به روش آقای Patton ما باید چندتا اصطلاح رو بلد باشیم. ولی قبل از اون یه تعریف کلی از این مدل میکنیم: مدل مپ کردن داستان کاربر مدلیه که با استفاده از جدا کردن نیازهای هر کاربر استفاده کننده از برنامه، طبق نظر تیم، میتونه تمامی نیازهای کاربر رو پوشش بده. در نمایش این نقشه، از قوانین، اصول و اصطلاحاتی استفاده میشه. نمایش نهایی، جدولیه که از چب به راست، ترتیب حدودی انجام فعالیت‌ها و از بالا به پایین، اهمیت ویژگی(Feature که جلو تر همون فیچر می‌نویسم) مد نظر را نشان می‌دهد.
در این روش تصور میکنیم کاربر تو هر قسمت از برنامه چه چیزهایی از ما (مایی که طراحیم) میخواد و با جدا جدا نوشتن اون‌ها میتونیم منظم‌تر و هماهنگ تر کار کنیم. در کنار این مورد، این روش و نمایش اون خیلی قابل فهمه که میشه با همه به اشتراک گذاشته بشه و از پیشنهادات افراد مختلف تیم استفاده بشه؛ در حالی که میدونیم بسیاری از مدل سازی‌های نرم افزار نیاز به اطلاعات فنی بیشتری دارند.
با این تعاریف، اگه بخوایم این روش رو یاد بگیریم اول باید با هم از یک ادبیات استفاده کنیم که اینها رو در ادامه مشخص میکنیم:
پرسونا (Persona) : معمولا هر نرم افزار از چند نوع کاربر تشکیل میشه که این کاربرها قطعا نیازشون از برنامه متفاوته؛ مثلا در یک سیستم دانشگاهی، استاد، دانشجو، مدیریت و مسئول آی‌تی با این که همه دارن از یه برنامه استفاده میکنن، انتظارشون از اون برنامه مثل هم نیست. مسئول آی تی باید دسترسی هایی داشته باشه که بتونه اتفاقات پشت سیستم رو ببینه یا در سیستم برای افراد، استثنا قائل بشه(که معمولا مقاومت میکنه)، در صورتی که دانشجو، انتظار داره بتونه واحدی که میخواد رو اخذ کنه. این مثال نشون میده که انتظارات پرسوناها از سیستم یکسان نیست پس ما هم باید آن‌ها رو از هم جدا در نظر بگیریم.
فعالیتهای درشت دانه(High Level Activities): در اکثر برنامه‌هایی که استفاده میکنیم، هر کنش و ورودی ما یک فعالیت حساب میشه، که خب میتونیم این فعالیت‌ها رو با یک ذره‌بین ضعیف‌تر نگاه کنیم و گروه بندی‌شون کنیم به فعالیت‌هایی کلی‌تر. به عنوان مثال، تو نرم‌افزار اسنپ، فعالیت اسنپ گرفتن از فعالیتهای کوچکتری مثل وارد کردن آدرس مبدا، آدرس مقصد، نوع اسنپ، گزینه‌های سفر و غیره تشکیل شده که اگر ما بخوایم این رو از بالاتر(با همون ذره‌بین ضعیف‌تره) نگاه کنیم، به کل این فعالیت ها میگیم درخواست اسنپ(منظور درخواست برای رانندس). پس برای پیاده سازی این مدل، لازم داریم فعالیتهای درشت‌دانه برنامه رو بشناسیم و آن‌ها رو مشخص کنیم.
محور اصلی (Backbone): در بالای این مدل، فعالیتهای درشت‌دانه به عنوان ستون‌ها قرار می‌گیرن که محور اصلی رو تشکیل میدن. اما همونطور که پیش‌تر گفته شد، این فعالیت‌ها به یک محور اصلی تبدیل میشن؛ که از چپ به راست ترتیب فعالیتهای درشت‌دانه کاربر رو مشخص میکنن. مثلا در بسیاری از برنامه‌ها نیاز ثبت نام و ورود به برنامه با حساب کاربری داریم که اینها فعالیتهای ابتدایی کار کاربر هستند و در نتیجه در ابتدای محور(سمت چپ) قرار میگیرند.
اپیک(Epic): به هر نیاز کاربر که سطح پایینی داره(نیازی که دقیقا و کامل بیان شده)، و این در نقشه ما به صورت یک جمله از زبان کاربر نوشته میشه، یک اپیک (Epic) گفته میشه. این واژه در انگلیسی معنی‌های مختلفی داره ولی این‌جا خودمون رو درگیر معانی دیگر و دلیل استفاده از این کلمه برای این مفهوم نمی کنیم و فقط به تعریفی که برای این مدل ارائه شده بسنده میکنیم. نکته ای که در ادامه به اون میرسیم اینه که ما داخل جدول‌مون(مپ، نقشه یا هرچی که تا الان بهش گفتم)، کار اصلی‌ای که باید انجام بدیم نوشتن اپیکهای درست در محل درسته که درواقع نیاز کاربر رو برای ما توصیف کنه. به طور اصولی اپیک‌ها از سه بخش تشکیل شدن که برای نوشتن درست اون‌ها باید این سه بخش رعایت بشن:
مشخص کردن پرسونا - "من به عنوان مدیر برنامه ..."، "من به عنوان دانشجو ..."، "من به عنوان کارمند ..." و غیره. این جملات مشخص میکنه که اپیک نوشته شده بر اساس نیاز کدام نوع کاربر (پرسونا) مطرح شده
مشخص کردن کار (Action) - "... میخواهم بتوانم در قسمت اسامی جستجو کنم ..." ، "...میخواهم افراد طرح را مشاهده کنم ..." ، "...میخواهم بتوانم از حساب کاربری خود خارج شوم...". این جملات در واقع نیاز فرد رو در دسته بندی (همون فعالیتهای درشت دانه) مورد نظر مشخص میکنن.
پاداش ( Reward) - "...که بتوانم دسترسی سریع‌تری به اسامی افراد مورد نظرم داشته باشم."، "...بخاطر افزایش امنیت اطلاعاتی خودم."، "...زیرا در غیر این صورت استفاده از این بخش دشوار است.". این پاداش‌ها نیز در اپیک ذکر میشن که به تیم طراحی دلیل خوبی برای قرار دادن چنین ویژگی‌ای در برنامه را بِدن(بعضی وقت‌ها ممکنه ما اپیک‌ها رو در روند طراحی برنامه تغییر بدیم و یا جایگزین کنیم و مطرح کردن دلیل ممکنه بهمون یادآوری کنه که این نیاز در قسمتی دیگر به کاربر داده می‌شود و دیگر نیازی به این اپیک نیست).
اگه بخوایم یک مثال از یک اپیک کامل داشته باشیم، میتونه چنین گزاره‌ای باشه: "من به عنوان دانشجو در قسمت انتخاب واحد میخواهم بتوانم درس هایی که برای من قابل اخذ نیست را مشاهده نکنم که بتوانم دید بهتری نسبت به درس‌های قابل اخذ داشته باشم."
توجه داشته باشیم که بنا به تشخیص خود و تیم می‌توانیم جهت مدیریت بهتر برخی موارد را کامل ننویسیم. مثل شکل :
در ابتدا باید چارچوب این نقشه فراهم بشه که در نتیجه مواردی مثل پرسوناها و محور اصلی مشخص بشه. برای تعیین کردن پرسونا، بر اساس نیازهای کاربر (یا تحقیقات انجام شده)، تصمیم گیری تیم فنی مورد نیازه که بشه تمامی دیدهای مختلف نسبت به برنامه را استخراج کرد. برای محور اصلی باید فعالیت های درشت‌دانه تعیین شه. دسته بندی درست آن‌ها به میزان قابل توجه به سادگی و اصولی بودن کار کمک خواهد کرد. میشه جلسات متعددی برای این دسته‌بندی‌ها تشکیل داد و یا حتی از مدل‌ها و تکنیک‌های دیگر دنیای Agile استفاده کرد.
پس از تعیین شدن پرسوناها و محور اصلی نقشه، طبق انتظار، باید شروع به نوشتن اپیک‌ها کنیم. گفتیم که اپیک‌ها برای هر پرسونا باید جداگانه نوشته بشه، و پیشنهاد میشه که در ابتدا از پرسونایی استفاده کنیم که بیشترین تاثیر رو از برنامه میگیره و جامعه بیشتری از برنامه رو تشکیل میده(بهش میگن chunk بزرگ تر)؛ مثل دانشجویان در یک سیستم دانشگاهی و یا مسافران در اپلیکیشن‌هایی مانند اسنپ و تپسی
البته لازمه که در تمامی مراحل به این نکته دقت کنیم که رعایت کردن چنین اصولی همیشه اجباری نیست و با تشخیص افراد تیم میشه تغییراتی در اون اعمال کرد، همونطور که در ابتدا گفته شد، این تکنیک توسط یک مشاور طراحی اپلیکیشن مطرح شده و به سپس نظر بسیاری رو به خودش جلب کرده. پس هیچوقت نمیتوان به قطع گفت که چنین اصولی همیشه بهترین نتیجه رو میده؛ همونطور که آقای Jeff Patton اصول جدیدی رو برای طراحی نرم‌افزار خلق کرده. لازم به ذکره که قبل از این مدل، مدل‌های مشابهی بودن که قصدشون برطرف کردن چنین نیازی بوده و نقص‌هایی نیز داشتن، همونطور که این مدل نقص‌های خودش رو داره.( برای افرادی که میخوان بیشتر بدونن میتونن کلید واژه "Flat Backlog" رو جستجو کنن).
در جدولی که تا به این مرحله ایجاد کردیم، محور اصلی تعیین شده و پرسونایی که میخوایم نیازهای اون رو در هر فعالیت بنویسیم نیز مشخص شده. برای نوشتن اپیک‌ها بهتره در جلسه‌ای با حضور بسیاری از افراد کلیدی تیم(مانند جلساتی که برای پرسونا ها و محور اصلی تشکیل شده) و با هم‌نظری آن‌ها فرایند رو پیش ببریم. و جلسه ای/هایی رو با محوریت این موضوع تشکیل بدیم.
در اون جلسه یک مسئول و پیش برنده جلسه حضور داره که ترجیحا بهتره مسئول جلسه و تصمیم گیرنده نهایی فردی باشه که در این پروسه تخصص بیشتری دارد، مثل: Product Owner، Product manager یا به طور کل کسی که با کارفرما بیشتر در ارتباطه و با چنین اصولی آشنایی بیشتری داره.
دیگر افراد این جلسه می‌توانند افرادی از جمله : Business Owner - Developers - Testers - UI/UX Designers - Scrum Master - Marketers باشند. این افراد ممکن است متغیر باشند و تاکیدی بر وجود همگی نیست.
باید توجه داشت که در این جلسات بیش از 10نفر(حالا برخی جاها میگن 10 نفر، من میگم حتی خیلی کمتر اگه پروژه خیلی مقیاس بالایی نداره) همزمان حضور نداشته باشن؛ چون با این که دیدهای متفاوت استحکام تصمیم‌گیری رو بیشتر میکنه، بیش از حد بودن نظرات، ممکنه جلسه رو کند و یا تکمیل نقشه را غیرممکن کنه. تکمیل این نقشه با این اصول، بسته به پروژه، ممکنه یک یا چند هفته طول بکشه. تمرکز بالای افراد در این جلسات امری حیاتیه؛ زیرا که هر ایده‌ای که به صورت استیکر بر روی نقشه چسبانده شده و تایید می‌شود سنگ بنایی برای تمامی پروژه است و مسیری را تعیین می‌کند. خیلی اوقات قوانین سختی برای افزایش تمرکز افراد این جلسه در نظر گرفته میشه، مثلا مسئول جلسه گوشی‌های همراه شرکت کننده‌ها رو در سبدی قرار میده که تو جلسه بهش دسترسی نداشته باشن و تمرکزی رو بهم نزنه.
پس از نوشتن اپیک‌ها و داستان‌های کاربرها و رسیدن به مرحله‌ای که کلیت کار مشخص شده، برای دادن دید بهتر به تیم و کارفرما، در هر ستون، اپیک ها رو به ترتیب اهمیت، از بالا به پایین قرار می‌دیم. این ترتیب نمایش دادن، نیازهای بنیادی اپلیکیشن را بالاتر و فیچرهای غیر ضروری را پایین تر نشان میده؛ این کار خودش میتونه مسیری برای راحت‌تر و واضح‌تر کردنِ ساخت و توسعه برنامه باشه.
تا این قسمت نوشته یاد گرفتیم که این تکنیک چیه و چطوری از اون برای پیش‌برد ایده‌مان استفاده کنیم. در ادامه یک مثال رو از اول تا آخر پیش میریم که ببینیم به چه ابهاماتی توی حل این مثال برمیخوریم و چطور حلشون میکنیم. اما قبل از اون، لازم به ذکره که هر مدلی جزئیات و ریزه‌کاری‌های خودش رو جدا از روند کلی ساختن اون داره و قطعا ما تو این نوشته تمومش رو پوشش ندادیم. ولی از اونجایی که من و شما دوست داریم که درباره چیزهایی که در موردشون کنجکاویم بیشتر بدونیم، قبل ارائه مثال، چند مورد رو به صورت تیتر‌گونه مطرح می‌کنم که اگه علاقه داشتید برید و در موردش بیشتر و با کیفیت بهتر بخونید:
تعریف پروژه ( این در واقع صورت مسئله هست که برای این مثال داریم تولیدش میکنیم وگرنه اکثرا این رو از قبل داریم): فرض میکنیم یک کارفرمای زرنگ و بازی‌دوست با سرمایه خوبی که داره اومده از ما درخواست ساخت یک پلتفرم بازی رو کرده(ما هم یه تیمیم که از افراد متخصص تو حوزه‌های مختلف تشکیل شدیم). به گفته خودش، چند بازی رو تیم خودش ساخته و قصد این رو داره که بازی‌های تیمش رو به علاوه بازی‌های موجود در بازار رو تا جای ممکن به بازیکنان از طریق این پلتفرم ارائه بده و عرضه کنه. به طوری که هر کاربر برای بازی کردن، وارد این پلتفرم بشه و بازی مورد نظرش رو خریداری کنه و تحت کاربری خود بازی کنه.خودش ادعا میکنه که تعداد بازی ها نسبتا بالاست و انتظار میره کاربران هم تعدادشون کم نباشه(فرض کنید مشابه پلتفرم Steam که توسط بزرگ‌مردی به اسم Gabe Newell ساخته شده). کارفرما قطعا لازمه که اطلاعات بسیار بیشتری در اختیار ما قرار بده، ولی نمی‌خوایم تو این مثال خودمون رو با جزئیات خسته کنیم و از جزئیات بیشتر رد میشیم(ولی بدانید و آگاه باشید که اگه مشتری نیازشو دقیق نگه و یا ما مجبورش نکنیم که این کارو بکنه اصلا نمیشه چنین مدلی رو پیاده سازی کرد).
شروع مدلسازی این پروژه با "نقشه‌سازی از داستان کاربر"
انتخاب پرسونا: در این قسمت پرسونایی که در ابتدا،جدول برای اون پیش میره، بازیکن انتخاب میشه چون اکثریت کاربران این سیستم بازکنان اون هستن.
به دست آوردن فعالیتهای درشت دانه (High Level Activities): این قسمت همان سطر افقی جدول رو تشکیل میده که روند طی شدن تجربه کاربر رو منتقل میکنه. با کمک تیم و متخصصین، طی جلسات متعدد، عناوین را برای این قسمت به دست میاریم که در واقع با تکمیل اون محور اصلی جدول را تشکیل دادیم که شروع کار در چپ و کارهای پایانی در راست آن قرار داره. در نهایت با کمک تیم به چنین ساختاری رسیدیم. دقت کنیم که این ساختار میتونه متفاوت باشه(خب طبق نظرات تیمه و نظرات متفاوتن) ولی باید تمامی قسمت‌های پروژه مورد نظر رو در بر بگیره.
Create an account / Log in -> Browse games -> Buy games -> Download and install games -> Play games - > Review and rate games -> Interact with community
----------------------------------------------------------------------------------------------------------------------------------------------->
با فرض این که این عناوین همگی در یک خط قرار دارن با کشیدن فلش زیر آن عملا محور اصلی تعیین میشه(راستش این فلش خیلی تو این مدل طرف‌دار داره چون یجورایی به جز جداسازی فعالیت‌ها مسیر کاربر رو نشون میده و حتی در کنار اون داره میگه دیگه تمام و ما ترجیحا بعد این که اپیک رو شروع کردیم دست به این فعالیت‌هایی که نوشتیم نمزنیم!).
نوشتن اپیک‌ها برای یکی از فعالیت‌ها، که در این قسمت، فعالیت Buy games رو انتخاب کردیم شروع به نوشتن اپیکهای اون میکنیم. این اپیک‌ها هر کدوم با استیکرهایی از طرف تیم حاضر در جلسه مشخص میشن که به تایید میرسن و به جدول اضافه میشن. در ادامه هم مسئول جلسه به همراه تیم سعی میکنه ترتیب اولویت اینها رو رعایت کنه. که اپیکهای ما که زیر Buy games نوشته شده به این شکل میشه در نهایت:
1- Browse Games:
2- Search for Games:
3- Game Selection:
4- Purchase Process:
5- Post-Purchase:
این اپیک‌ها توسط تیم، در جلسات متعدد به دست اومده، که شرح دهنده اینه که از طرف پرسونای بازیکن چه نیازهایی در قسمت خرید بازی در این نرم‌افزار وجود داره. باید دقت کنیم که تا جای ممکن نیازهای غیر ضروری پایین تر و نیازهای پایه ای و اسای بالاتر قرار بگیرند. و نکته دیگه که تو مثال به ما نشون داده میشه اینه که این اپیک‌ها خودشون عضو یک دسته هستن، که خب عملا اومدیم فعالیت درشت دانه رو یه درجه ریزتر کردیم بعد برای این فعالیت جدیدها اپیک نوشته(هر ایده‌ای که به کار کمک کنه باید استفاده بشه). این دسته بندی کردن نوشتن اپیک‌ها اهمیت بالایی داره زیرا که دید افراد درون جلسه رو متمرکز تر میکنه و البته کنترل مپ رو راحت تر میکنه.
تکمیل مدل با تکرار مرحله نوشتن اپیک اتفاق می‌افته که برای هر فعالیت کاربر اپیکهای متعددی نوشته شده و با زیاد شدن اپیک‌ها، رده بندی آن‌ها بیشتر معنی پیدا میکنه. در طول پروسه پیشرفت نرم‌افزار ممکنه تغییراتی در نقشه تکمیل شده اتفاق بیفته و اصلاحاتی بر اساس شرایط جدید به مدل اعمال بشه. و لازمه که مکررا به این مدل رجوع شود( در موارد "اختیاری برای مطالعه" به این مورد اشاره شده که رجوع مجدد و بهتر کردن مدل چطور اتفاق میفته).
در این نوشته سعی شد بتونیم روش به‌وجود آوردن تکنیک مپ کردن داستان کاربر(User Story Mapping) رو توضیح بدیم و اجزاء و روش پیاده سازی اون رو قدم به قدم بگیم. سر نخ‌هایی جهت مطالعه بیشتر و قطعا مطالعه بر روی مدل‌های مورد پسند پروژه‌ها و تیم‌های Agile داده شد. و در نهایت نیز مثالی برای رفع ابهامات تا جای ممکن رو مطرح کردیم.
این نوشته جهت آشنایی با این تکنیکه و قطعا برای پیش بردن یک پروژه این یکی از چندین مدل و تکنیکیه که به کار گرفته میشه. و لزوما در همه پروژه‌ها مجبور مجبور نیستیم از این تکنیک استفاده کنیم. پیشنهاد میشه برای پروژه‌هاتون اگر مدلی کارآمد بود یادش بگیرید ولی مدل‌های مشابه اون رو هم جستجو کنید. چون کارآمد بودن یه مدل agile نشون میده پروژه‌هایی که کار می‌کنید از چه جنسیه و اگه پروژه‌هاتون نسبتا شبیهن و صرفا مشتری‌هاتون سلیقه‌هاشون متفاوته، قطعا یاد گرفتن مدل‌های مشابه خیلی به کارتون میاد.
هدف شخصی بر این بود که این متن شاید دید و ایده‌ای جدید برای افراد کنجکاو باشه، که البته خودش هم صرفا از دید یک فرد کنجکاو دیگه بازگو و منتقل شده. ممنونم که وقت گذاشتید و حوصله کردید. 3>
کنجکاو بمونید :)
