نوشته های مهدی موسوی

تجربه اسباب کشی با نوبار

مهدی موسوی — Sun, 05 Sep 2021 10:23:00 +0430

به تازگی خانه‌یمان را جابه‌جا کردیم. در همان محله که زندگی می‌کردیم چند کوچه آن‌طرف‌تر. اسباب‌کشی برای من همیشه مصائب داشته و سعی کرده‌ام تا جای ممکن نقل مکان نکنم. اما شتری‌ است که بر در هر خانه می‌خوابد. با همسرم تقسیم کار کردیم. زحمت بسته‌بندی اسباب و وسایل بر دوش همسرم بود و خدایی هم کارش را خوب انجام داد. (دست درد نکنه :( خانم ). خب من هم ۵۰ درصد کار را بر عهده گرفتم و گرفتن خاور برای جابجایی به گردن من افتاد :) برای بردن اسباب و اثاثیه تصمیم گرفتم بجای روش سنتی و تماس با یکی از شرکت‌های حمل و نقل از روش ها مدرن تری استفاده کنم. از چک و چونه زدن برای قیمت و دادن انعام اضافه تر و ضربه زدن به اسباب وسایل گرفته تا سروکله زدن با کارگر و راننده. خلاصه چند گزینه داشتم. اولی استفاده از اپ‌های ارائه خدمات آنلاین مثل آچاره و استادکار و... دومی استارت‌آپ نوبار که چند وقتی است به طور تخصصی در این زمینه فعالیت می‌کند و سومی هم اسنپ که به تازگی وارد این بازار شده است. بنابر تجربه گزینه اول یعنی اپ‌های خدماتی را کنار گذاشتم هم به دلیل قیمت بیشتر و هم به دلیل نبود پشتیبانی و پیگیری. نوبار و اسنپ برایم گزینه‌های بهتری بودند هم به دلیل تجربه بیشتر در این بازار و برند و هم پشتیبانی و تخفیف‌های قیمتی. حالا باید بین اسنپ و نوبار گزینه‌ها را سبک و سنگین می‌کردم. در هر دو ثبت سفارش کردم تا مقایسه قیمتی کنم. اسنپ حدود ۱ میلیون ر تومان هزینه را محاسبه کرد و نوبار حدود یک میلیون و ۱۰۰ تومان. از طرفی اسنپ کد تخفیف ۲۰۰ هزارتومانی داشت و نوبار کد تخفیف ۱۰۰ هزارتومانی. به صرفه تر بود که از اسنپ استفاده کنم اما اسنپ تازه به این بازار اومده و احتمال می‌دادم در آخر کار باید انعام اضافه‌ای به کارگرها بپردازم که به قولی هزینه‌ پنهانی داشت. اما نوبار به دلیل قدمت بیشتر در بازار، بیمه اسباب وسایل در حین جابجایی( یک در هزار این اتفاق می‌افته :) ) و همچنین تضمین قیمتی که ارائه می‌داد یعنی اینکه لازم نیست هیچ هزینه اضافی تری بپردازم برام گزینه مطمئن تری بود. به هر روی قرعه به نام نوبار افتاد و چهارشنبه روزی و سفارش رو برای جمعه بعد از ظهر ثبت کردم. خیالم راحت شد و شروع کردیم به جمع‌وجور کردن خورده ریزه‌های باقی مانده. جمعه رسید. حوالی ساعت ۴ بعد از ظهر بود. برای هماهنگی نهایی با راننده تماس گرفتم. ناگهان جا خوردم. راننده حتی روحش هم خبر نداشت که یک ساعت دیگر اسباب کشی داریم. دست پاچه شده بود و می‌گفت فکر می کرده برای فردا بعد از ظهر قرار داریم. قول داد که با نیم ساعت تاخیر می‌رسد. من بیشتر از این تعجب کردم که آیا نوبار سیستم یادآوری و نوتیف برای راننده‌ها ندارد؟ طبیعی است راننده‌ای که روزی دوبار جابجایی بار دارد گاهی قرار‌‌ها را فراموش کند.نیم ساعت شد یک ساعت. و یک خاور خسته نارنجی سر رسید. حالا از شانس ما دو ماشین بد در کوچه پارک کرده بودند و نمی‌شد خاور به نزدیک در خانه برسد. حدود ۲۰ متری فاصله داشتیم تا در. راننده گفت به بارتان مسافت می‌خورد. گفتم چاره چیست باشد هر طور شده سریع‌تر بار کنید در انتها با هم حساب می‌کنیم. کارتون‌های ترسناک کتابخلاصه ما از ساعت ۶ شروع کردیم به بارزدن وسایل. با چهار کارگر اهل افغانستان و خود راننده هم که وظیفه چیدن بارها در کامیون را برعهده داشت. خانه ما طبقه سوم با راهروهای تنگ. تجربه اثاث‌کشی به من ثابت کرده کارگران افغانستانی کمتر غرولند میکنند و دبه در می‌آورند اگر هم حرفی داشته‌باشند به صاحب بار نمی‌گویند و راننده را واسطه قرار می‌دهند. به همین خاطر کمترین مشکل را در این اسباب‌کشی با کارگرها داشتم با اینکه چند کارتون خیلی سنگین کتاب که به گفته خودشان سنگین‌تر از اجاق گاز هست در بار بود. خاور نارنجی خسته حدود یک ساعت طول کشید تا تمام وسایل را به کامیون منتقل کنیم. حالا خاور خسته نارنجی روشن نمی‌شد. راننده هر چه از دهنش درآمد نثار مکانیک ماشین کرد که گفته بود اشکال کار از باتری است نگو باتری مشکلی نداشته. خلاصه به زور بازوی کارگرها خاور روشن شد و راه افتادیم.با دردسر کمتری خاور کنار در خانه جدید پارک شد. خانه جدید ۴ طبقه با راهروهای تنگ :) . راننده و کارگرها را با خریدن رانی و کیک و آب‌معدنی شارژ کردم. کمتر از یک ساعت هم انتقال اسباب‌ها به پایان رسید. کارگرها در انتقال اسباب محتاط نبودند و باید مدام تذکر می‌دادم. خدا را شکر آسیبی به وسایل نرسید. یکی از کارگرها گفت که اگر آسیبی به وسایل برسد شرکت با ما برخورد می‌کند. از بد ماجرا از شارژ گوشی من ۲ درصد مانده بود و خانه جدید هم برای سیم کارت ایرانسل بد آنتن. حدود ساعت ۸ بود که با پشتیبانی نوبار تماس گرفتم. سریع پاسخ دادند و مسئله مسافت را گفتم. سریع بررسی و در قیمت اعمال کردند. به ازای هر متر ۳ هزار تومان به هزینه نهایی اضافه شد. بلافاصله گوشی همراهم خاموش شد و امکان این را نداشتم در نوبار پرداخت را انجام دهم. حالا نوبت حساب و کتاب با راننده رسید. قیمتی که به راننده اعلام شد بدون تخفیف ۱۰۰ هزارتومانی بود که منطقی است. خب من توقع داشتم هزینه را پرداخت کنم و بعدا ۱۰۰ هزارتومان را از نوبار بگیرم. اما راننده و کارگرها شروع کردند به چانه زدن برای گرفتن انعام. در آن موقعیت که ۵ نفر از شما خواهش می‌کنند و برای اسباب‌واثاثیه شما عرق ریخته اند سخت است انعام ندهید. با اینکه می‌دانستم هزینه‌ای که پرداخت می کنم شامل انعام کارگران هم هست. خلاصه که انعام را هم پرداخت کردم(نمی‌گویم چقدر دادم :) ). دقیقا حس کردم که در موقعیت «هم پیاز را خورد، هم کتک را، هم پول داد» قرار دارم. از نظر من نوبار وعده نتوانست به «تضمین قیمت نهایی» خود پایبند باشد. شاید به من بگویید که تو باید به پشتیبانی زنگ می‌زدی و این مشکل را مطرح می‌کردی و چیزی هم پرداخت نمی‌کردیم .اما من فکر نمی‌کنم این درخواست انعام رویه‌ای غیر عادی باشد و نوبار هنوز نتوانسته فرهنگ درستی را در میان کارکنانش جا بینداز پس نباید هم تضمین قیمت دهد. چون ایجاد فرهنگ نو در زمینه اسباب کشی در میان قشر راننده‌های کامیون و کارگران کمی زمان بر است. تجربه این اسباب کشی به من نشان داد با اینکه استارت‌آپ‌هایی در این بازار ورود کرده اند اما هنوز راه زیادی تا به‌ هم زدن بازار دارند. چون هنوز نتوانسته اند فرهنگ جدید و قواعد جدیدی را شکل بدهند. راه‌اندازی کسب و کار آنلاین فقط ساختن یک اپ یا سایت نیست.

۰ تا ۱۰۰ اولویت‌بندی فیچرها به روش RICE

مهدی موسوی — Tue, 20 Jul 2021 10:52:02 +0430

یکی از شیوه های شناخته شده در اولویت بندی فیچرهای محصول روش RICE است از این روش در پروژه‌های پیچیده و با فیچرهای مشابه هم استفاده می‌شود به این دلیل که می‌تواند تخمین دقیق‌تری به ما نشان‌دهد تا بتوانیم با آن فیچرها را اولویت بندی کنیم. اصطلاح RICE کوتاه شده چهار کلمه است: Reach - Impact - Confident - Effort. از ضرب و تقسیم این چهار عامل نمره ای به دست می‌آید که به آن RICE Soccer می گویند. برویم سراغ اولین عامل که Reach (دستیابی) است. Reach به این معنی است که تخمین می‌زنید در یک بازه زمانی مشخص این فیچر به دست چند نفر می‌رسد؟ تعیین بازه زمانی به دلخواه شماست. می‌توانید دو هفته یا یک ماه یا حتی سه ماه را در نظر بگیرید. به دست چند نفر رسیدن را هم باید تعیین کنید. مثلا تعداد کاربرانی جدیدی ثبت نام می کنند یا کاربران فعلی که از این فیچر استفاده می‌کنند. نمره Reach عددی است که تخمین زده اید. اگر انتظار دارید که پروژه شما در ماه آینده، ۱۰۰ مشتری داشته باشد، پس نمره Reach شما ۱۰۰ خواهد بود. اگر تخمین بزنید که بعد از لانچ فیچر در ماه آینده ۱۰۰۰ نفر به صفحه لندینگ آن می‌آیند و ۱۵ درصد آن‌ها ثبت نام می‌کنند، آن وقت نمره ۱۵۰ خواهد بود.عامل بعدی Impact (تاثیر) است. این عامل برای تخمین زدن تاثیر فیچر جدید است. مثلا اینکه با اضافه شدن این فیچر تخمین می‌زنید که نرخ تبدیل چقدر بهبود می یابد یا اینکه وقتی کاربرها با این فیچر مواجه می‌شوند برایشان چقدر خوشایند است. یا اینکه وقتی این ویژگی جدید محصول را می‌بینند آن را خرید می‌کنند. به طور کلی اندازه گیری و تخمین زدن این اهداف کمی و کیفی دشوار و سخت است. پس سعی کنید زیاد سخت نگیرید و در مقایسه با دیگر فیچرها Impact را تخمین بزنید. برای تخمین Impact می‌توانید از این سیستم امتیازدهی برای برآورد تأثیر یک فیچر استفاده کنید:۳ = تأثیر خیلی زیاد۲ = تأثیر زیاد۱ = تأثیر متوسط۰.۵ = تأثیر کم۰.۲۵ = حداقل تأثیرعامل سوم Confident(اطمینان) است. اگر دقت کرده باشید تا الان ۲ عامل قبل RICE Soccer را حدس زده ایم اما تا چه حدی به حدس‌های خود اطمینان داریم؟ این حدس‌ها تا چه حد درست هستند؟ خوش‌بینانه هستند یا بد بینانه. Confident قرار است تا حدی تخمین‌های ما را نرمال کند. می‌توانید به این ترتیب به حدس‌های خودتان نمره بدهید. ۱۰۰٪ = اعتماد زیادی دارید(معیارهای کمی برای Reach ، Impact و Effort داریم. از تخمین خودمان مطمئنیم)۸۰٪ = اطمینان متوسط (داده هایی داریم که می‌شود با آن‌ها Reach و Impact را بهتر تخمین زد ، اما در مورد تأثیر آن مطمئن نیستیم)۵۰٪ = اطمینان کمی دارید (میزان Reach و Impact ممکن است کمتر از حد تخمین زده شده باشد و تلاش بیشتر باشد)اگر کمتر از ۵۰٪ هم به دو پارامتر دیگر اطمینان دارید کلا بی خیال استفاده از روش RICE شوید :) .عامل آخر Effort (تلاش) است. همه عواملی که تا اینجا گفتیم: Reach ،Impact ،Confident. نمایانگر مزایای بالقوه هستند در حالی که Effort تنها نمره ای است که نشان دهنده هزینه است. برخلاف سایر عوامل مثبت، Effort بیشتر چیز مفنی‌ای است، بنابراین تأثیر کل را تقسیم می کند. برای به دست آوردن این نمره باید کل زمان اعضای تیم را محاسبه کنیم. نمره Effort را به صورت «نفر - ماه » تخمین می‌زنند. مقدار کاری که یک عضو تیم می تواند در یک ماه انجام دهد. برای نحوه نمره دادن به Effort مثال می زنم. فیچر جدید حدود یک ۱ برنامه ریزی، ۱ تا ۲ هفته طراحی و ۳ تا ۴ هفته زمان برای دولوپ نیاز دارد. نمره Effort برای این فیچر می‌شود ۲ نفر در ماه.مثال دیگر این پروژه چندین هفته برنامه ریزی ، مقدار قابل توجهی از زمان طراحی و حداقل دو ماه از وقت دولوپر را می گیرد. من به آن ۴ نفر در ماه می دهم. یا مثلا فیچر متوسطی داریم که فقط به یک هفته برنامه ریزی ، بدون طراحی جدید و چند هفته زمان دولوپ نیاز دارد. من به آن نمره تلاش 1 نفر در ماه می دهم.خلاصه تا به اینجا:Reach: به دست چند نفر می رسه؟ (تخمین در یک بازه زمانی مشخص بر اساس نفر)Impact:(خیلی زیاد: ۳، زیاد: ۲، متوسط ۱، کم ۰.۵، خیلی کم ۰.۲۵) هر نفر رو چقدر تحت تاثیر قرار می‌ده؟ Confident:(زیاد = 100٪ ، متوسط = 80٪ ، کم = ٪50 ) چقدر مطمئنی از دو تا پارامتر بالا؟Effort: چند نفر ماه وقت می‌بره؟همه اینها را گفتیم تا به اینجا برسیم. RICE Soccer با این فرمول محاسبه می‌شود:بهتر است این ضرب و تقسیم را با اکسل انجام دهید. می‌توانید این فایل اکسل را دانلود و استفاده کنید.یادتان باشد هر چه RICE Soccer یک فیچر بیشتر باشد، اولویت آن بیشتر است. چارچوب اولویت بندی RICE کمک می کند تا با آگاهی بهتر تصمیم بگیریم که ابتدا روی چه کاری کار کنید و از این تصمیمات دفاع کنید. RICE را در اولویت بندی خود امتحان کنید.

چطور بفهمیم طراحی محصولمان خوب است؟ + مثال‌

مهدی موسوی — Fri, 23 Apr 2021 19:23:51 +0430

۲۷ سال پیش، جیکوب نیلسون ۱۰ اصل کلی را برای طراحی تعاملی(Interaction Design) شرح داد. این اصول اکنون با عنوان Usability Heuristics شناخته می‌شوند. این اصول بر اساس سالها تجربه در زمینه مهندسی کاربردپذیری تدوین شده و به عنوان اصولی اساسی برای تعامل انسان و کامپیوتر تبدیل شده اند.تیم‌های توسعه محصول با رعایت این اصول می‌توانند در وقت صرفه جویی کنند، طراحی بهتری داشته باشند و توجه خود را به چالش‌های پیچیده‌تر طراحی معطوف کنند. علاوه بر این، از این اصول می‌توانید به عنوان چک لیست برای طراحی محصول یا فیچر جدید استفاده کنید و همچنین برای تحلیل رقبا و بررسی دقیق آن این اصول به کار می‌آیند.#1: Visibility of system status - قابلیت دیدن وضعیت سیستمسیستم باید کاربر را از آنچه در جریان است، آگاه کند.سیستم باید به کاربر نشان دهد که اکنون در کجاست یا چقدر از کاری مانده تا انجام شود یا اینکه چه اتفاقی قرار است رخ دهد. کاری انجام شده یا نه. به قول دیالوگ معروفی از فیلم سربه مهر: «در جریان بودن مسئله مهمی است» :)منظور این هست که کاربران را منتظر نگذارید یا متعجب و سردرگم نکنید. به خصوص در فرایندی که توسط کاربر آغاز می‌شود. مثلا کاربر فرمی را ارسال یا ویرایش می‌کند در اینجا بازخورد دادن به کاربران بسیار مهم است. با بازخورد دادن به کاربر و نمایش پیام تایید درخواست کاربر متوجه شود که سیستم درخواست را دریافت کرده است. در مثالی دیگر کاربر باید بداند که چقدر باید منتظر بماند. اگر بدانیم که میانگین پاسخ به تیکت‌های یک سرویس دو ساعت است با خیال راحت‌تری پیام می‌دهیم. کالایی را سفارش دادیم و می‌خواهیم بدانیم الان در کدام مرحله از ارسال قرار دارد.بطور کلی پشت بردکرامب (Breadcrumbs)، لودینگ‌ (Loadings)، اسکلت صفحه‌نمایش (Skeleton Screens)، Upload progress و... همین اصل قرار دارد.به کاربر نشان دهیم که چقدر از آپلود فایل مانده #2: Match between system and the real world - مطابقت بین سیستم و دنیای واقعیسیستم باید به گونه‌ای حرف بزند که کاربر متوجه شود. خود ما چون با محصولمان زیاد سروکار داریم معمولا متوجه این مسئله نمی‌شویم. باید از خود بپرسیم آیا چیزی در برنامه وجود دارد که کاربر نتواند آن را درک کند؟ آیا تمام عبارت‌ها و پیام‌ها واضح هستند؟ آیا از لغات تخصصی استفاده کردیم که کاربر ممکن است متوجه نشود؟ مخاطب هدف محصول باید بتواند زبان محصول را بفهمد. واژه «کیف پول» یقینا بهتر از واژه «اعتبار حساب» به کاربر منظور را می‌فهماند. البته این اصل فقط به زبان خلاصه نمی‌شود. باید حتی بررسی کنیم که آیا آیکون‌های بکار رفته در سیستم می‌توانند بخوبی منظور ما را برسانند یا نه؟ سطل آشغال ویندوز «Recycle Bin» یکی از نمونه‌های اولیه رعایت این اصل در طراحی است. بخش پر کردن شماره کارت در درگاه‌های پرداخت یکی از نمونه‌های خوب است. صفحه پرداخت زرین پال #3: User control and freedom - دسترسی و آزادی کاربرسیستم باید به کاربر اجازه دهد تا اشتباهات خود را تصحیح کند.هیچ وقت راه توبه را نبندید. اجازه بدهید کاربران خطاهای خود را تصحیح کنند یا به عقب بازگردند یا اینکه هر وقت می‌خواهند از سیستم بیرون بروند. مثلا بتوانند هنگام دریافت کد اعتبارسنجی شماره موبایلشان را اصلاح کنند. یا اینکه تعداد سفارش خود را تغییر دهند. همیشه راه خروج اضطراری از برنامه را هم باید برای کاربر باز گذاشت.دکمه خروج از برنامه در مسیریاب بلد#4: Consistency And Standards - هماهنگی و استانداردهاسیستم نباید کاربر را متعجب کند و تا جای ممکن باید از استانداردهای طراحی پیروی شود. همانطور که می‌دانید کاربر ۹۰ درصد از وقت خود را در دیگران سایت‌های و اپلیکیشن‌ها می‌گذراند و به یکسری از قواعد و استاندارهای کلی عادت کرده است. مثلا برای پیدا کردن آدرس و شماره تماس به فوتر سایت مراجعه می‌کند یا اینکه می‌داند برای جست‌وجو باید به دنبال علامت ذره‌بین در بالای صفحه بگردد. پس کار را برای کاربر سخت نکنیم و از قواعد کلی پیروی کنیم.هماهنگی در ظاهر محصول هم مهم است مثلا دکمه ارسال باید در همه جا به یک رنگ باشد. یا اینکه فرم ها ظاهری یکسان داشته‌باشند. حتی پیام‌های میکروکپی‌ها هم باید به یک لحن باشند. نباید در جایی عامیانه با کاربر حرف بزنیم و در جای دیگر پیام سیستمی بدهیم. استفاده از دیزاین سیستم در طراحی تا حد خوبی هماهنگی ایجاد می کند.#5: Error prevention - جلوگیری از خطاسیستم تا جای ممکن باید جلوی خطای کاربر را بگیرد. کاربرها انسان هستند و انسان هم جایزالخطا. بنابراین ما باید همیشه با ارائه پیشنهادها و اعلان های مناسب از اشتباهات احتمالی جلوگیری کنیم. یکی از مثال های رایج برای این اصل انتخاب رمز عبور سیستم است. به جای اینکه اجازه دهیم کاربر رمز عبور خود را وارد کند و بعد از ارسال فرم و خطا را نمایش دهیم در هنگام وارد کردن رمز عبور خطاهای احتمالی را به کاربر بگوییم. یا وقتی که کاربر قرار است در فیلدی شماره موبایل وارد کند نباید اجازه دهیم حروف را بنویسد. #6: Recognition Rather than recall - تشخیص به جای یادآوری سیستم تا جایی که می‌تواند باید به کاربر سرنخ دهد.سعی کنید استفاده از حافظه کاربر را به حداقل برسانید. گزینه هایی را که ممکن است لازم داشته باشند به آنها پیشنهاد دهید. یا به آنها یادآوری کنید که باید کار خاصی را انجام دهند که باید به زودی انجام شود. اجازه ندهید کاربران برای انجام کارها زیاد فکر کنند یا حافظه او را بخاطر بیاورند.یکی از مصادیق این اصل نمایش آخرین صفحات دیده شده و در فروشگاه‌های آنلاین آخرین محصولات بازدید شده توسط کاربر است. با این عمل کاربر براحتی می‌تواند آخرین محصولاتی را که دیده دوباره پیدا کند. بطور کلی توصیه می‌شود از Checkbox، Radio Button و Drop-down List چون گزینه‌ها مشخص است (سرنخ بیشتری ارائه شده) به جای Text Box بیشتر استفاده شود.#7: Flexibility and efficiency of use - انعطاف پذیری و کارایی سیستم باید به کاربران میان‌بر ارائه دهد.برای تعامل بهتر کاربر با محصول بهتر است همیشه میان‌بر هایی بگذارید تا کاربرانی که تازه وارد نیستند و مدت زیادی است که از محصول استفاده می‌کنند بتوانند سریع‌تر با سیستم تعامل کنند. کاربر می‌تواند کلیک راست کند و گزینه copy را انتخاب کند و هم می‌تواند ctrl +c را فشار دهد. در اینستاگرام کاربران برای لایک کردن پست ها دو راه دارند لمس آیکون قلب و دو بار لمس کردن پست. میانبر ویرگول برای ایجاد حروف درشت ، مورب و زیر خط دار.#8: Aesthetic and minimalist design - زیبایی و طراحی مینیمالسیستم باید از اصول مینیمالیسم پیروی کند.چندی سالی است مینیمالیسم از هنر و معماری به طراحی محصولات دیجیتال راه یافته است. البته که مینمالیسم فقط به معنای زیاد کردن فضای سفید نیست. مینیمالیسم در طراحی یعنی آنچه که ضروری است باشد و بقیه حذف شوند. بطور کلی توجه کاربران را نسبت به عملی که باید در انجام شود جلب کنید. یا داده های دقیقی را ارائه بدهید که آنها می خواهند ببینند. Google.com نمونه کاملی از طراحی زیبایی شناسانه و مینیمالیستی است.#9: Help users recognize, diagnose, and recover from errors - بیان خطا و ارائه راه حلسیستم باید با زبان ساده خطاها را به کاربر بیان کند و راه حل ارائه دهد.باید به کاربران کمک کنید تا خطا را تشخیص دهند و راهی برای خلاص شدن از آن هم پیشنهاد کنید. با هر خطا کاربر یک قدم از محصول دور می شود. برای به حداقل رساندن ناامیدی، باید همانقدر که برای بقیه سیستم تلاش کردیم، در طراحی تجربه خطا هم تلاش کنیم.هر پیام خطا باید تا حد ممکن صریح و دقیق باشد و مهمتر از همه اینکه به زبان آدمی‌زاد باشد. هیچ کس نمی خواهد پیام های مبهمی مثل "مشکلی پیش آمده" را بخواند. آنچه را که رخ داده به زبان آدمی‌زاد بیان کنید. در گام بعدی به کاربر توصیه های سازنده ارائه دهید. آخرین قانون پیام های خطای خوب، ادب است. هرگز کاربر را سرزنش نکنید یا خدای نکرده القا نکنید که احمق است.کمی توهین آمیز نیست؟#10: Help and Documentation - راهنمایی و مستنداتسیستم باید کاربر را‌ آموزش دهد و راهنمایی کند.هر محصولی باید تلاش کند تا جای ممکن نیاز به راهنمایی نداشته باشد، اما هر کاربر مهارت و سطح دانش مختلفی دارد و آنچه برای ۹۰ درصد از کاربران شما آسان است ممکن است برای ۱۰ درصد باقی مانده مشکل باشد. سوالات متداول و آموزش برای حفظ کاربر سردرگم مهم است.آموزش و مستندات باید به درستی ساختار یافته ، به زبان آدمی زاد نوشته شده و مینیمالیستی باشد. گاهی اوقات ، کاربران به مستندات زیادی احتیاج ندارند. یک علامت مرجع ساده که چگونگی عملکرد این ویژگی جدید را نشان می دهد یا یک راهنمای مختصر روی صفحه که اصول اولیه را توضیح می دهد کافی است.حضور کاربر در صفحه راهنما و آموزش نشان می دهد که محصول ما آنقدر هم آسان نیست. اما اگر هنوز فکر می کنیم که طراحی محصولاتان عالی است، پس باید به آن ۱۰ درصد توجه کنیم.پی‌نوشت: اگر به این مطلب علاقه دارید پیشنهاد می کنم پست امیر تقی آبادی با عنوان کوتاه در مورد Heuristic Evaluation را هم بخوانید.از این مطلب هم برای نوشتن این پست کمک گرفتم.

آیا اسفنجی فکر می‌کنی؟

مهدی موسوی — Thu, 25 Mar 2021 08:50:55 +0430

تا بحال شده مطلبی را بخوانید یا بشنوید و با خود بگویید ای کاش این را زودتر فهمیده بودم! ای کاش چند سال پیش این را می‌دانستم یا اینکه ای کاش این کتاب را زودتر می‌خواندم یا چرا این فیلم را ۵ سال قبل ندیدم، این سریال تا الان کجا بوده که من ندیدمش؟ حتما این تجربه را داشتید و باز هم خواهید داشت. کتابی را سال پیش خواندم که آرزو می کردم، ۱۰ سال پیش کسی آن را به من معرفی می‌کرد و می‌گفت فلانی بشین این را بخوان! بدرد زندگی‌ات می‌خورد. اما متاسفانه کسی این کار را نکرد :) و به طور اتفاقی با کتابی مواجه شدم. جلد مشکی رنگ، در گوشه‌ای از کتاب‌فروشی در بخش خلوت فلسفه. عنوانش این بود «راهنمای تفکر نقادانه». اول فکر کردم شبیه به این کتاب‌های موفقیت و خودیاری است اما در بخش فلسفه چه می‌کرد؟ نگاهی به فهرست و مقدمه انداختم. مجذوبم کرد.فهمیدم که در جاهایی مثل اسفنج فکر می‌کردم. مثل اسفنجی که آب را سریع به خود جذب می‌کند و با یک فشار آن را پس می‌دهد به بیرون. فهمیدم که بعضی حرف‌ها را خیلی راحت قبول کرده ام، فریب آماری را خورده‌ام یا بر اثر تبلیغات چیزی را خریده‌ام که به آن احتیاج نداشتم. می‌خواهید بدانید شما هم اسفنجی فکر می‌کنید؟ ادامه مطلب را بخوانید.اسنفجی فکر می‌کنی یا غربالی؟ما به دو شیوه فکر می‌کنیم: اولی اسفنجی و دومی غربالی. در طرز فکر اسنفجی ما اطلاعات را صرفا جذب می‌کنیم که راهی آسان است. این روش تفکر به فعالیت چندانی احتیاج ندارد و با کمی تمرکز و استفاده از حافظه می‌توانیم کارمان را راه بیندازیم و مطالب جدید را حفظ کنیم. این روش عیب‌های بزرگی هم دارد. روش تفکر اسنفنجی راهی را برای تصمیم گیری درباره اطلاعاتی و نظرات به ما نمی دهد. مثلا کسی که مطالعه می کند اگر به روش اسفنجی فکر کند، ممکن است به آخرین چیزی که خوانده اعتقاد پیدا کند. یا در مواجه با سوال‌های تازه و حرف‌های جدید تصمیماتش عوض شود و به سردرگمی دچار شود. به راحتی فریب تبلیغات را بخورد یا در مناظره‌های انتخاباتی هر بار طرف یکی را بگیرد. در روش غربالی، سبک سنگین کردن اطلاعات مستلزم این است که تعدای سوال از خودمان بپرسیم که این سوال ها به آشکارکردن بهترین تصمیم یا بهترین عقیده ای که می توان به آن رسید طراحی شده اند یا نه؟ در این روش باید ادعای‌های مختلفی را که با آن‌ مواجه می‌شویم، زیر سوال ببریم و مطلب را نقادانه ارزیابی کنیم و بر اساس این ارزیابی به نتایج‌ خودمان برسیم.می‌خواهی بفهمی غربالی فکر می‌کنی؟ به این سوالات پاسخ بده: آیا پرسیدم که «چرا» فلان کس می‌خواهد فلان چیز را باور کنم؟آیا درباره فلان موضوع به نتیجه خاص خودم رسیدم؟آیا سخنان گوینده را ارزیابی کردم؟چرا باید سوال بپرسیم؟ چون استدلال آدم‌ها معمولا واضح و بدیهی نیست و چیزهای مهم در استدلال‌ها معمولا واضح گفته نمی‌شود. با سوال کردن می‌توانیم استدلال‌ها را تشخیص دهیم. مزیت دیگر سوال پرسیدن این است به ما این امکان را می‌دهد که درباره موضوعی که اطلاعات کمی داریم سوال‌های کاوشگرانه بپرسیم. برای مثال لازم نیست متخصص مراقب از کودکان باشیم تا بتوانیم درباره کیفیت کار مهدکودک ها سوال بپرسیم. اگر می خواهیم افسار زندگیمان را خودمان به دستمان بگیریم و آلت دست دیگران نباشیم باید با نگرشی پرسشگرانه به همه چیز نگاه کنیم و سعی کنیم با حرف‌های تازه، بده‌بستان فکری داشته باشیم.و قبل از قبول حرف و عقیده‌ای یکسری سوالات درباره آن بپرسیم و آن را ارزیابی کنیم سپس آن را در گوشه‌ای از ذهنمان جای دهیم.تفکر نقادانه حداقلی و حداکثریما درباره خیلی از مسائل شخصی و اجتماعی عقایدی داریم. این عقاید هر وقت که چیزی را می‌شنویم یا می‌خوانیم همرامان هستند. مثلا همین الان دربارهٔ این سوالات موضع گیری کنید: آیا احمدی‌نزاد رئیس جمهور موفقی بود؟ آیا حجاب باید اجباری باشد؟ آیا مصرف مشروبات الکلی اعتیاد است یا رفتار ارادی؟ و...تفکر نقادانه را می‌توان به دو صورت استفاده کرد: ۱- برای دفاع از عقاید قبلی‌مان ۲- برای ارزیابی و تجدید نظر در آن‌ها. اگر شما از تفکر نقادانه برای دفاع از عقایدتان استفاده کنید می‌شود تفکر نقادانه حداقلی و اگر برای ارزیابی همه ادعاها و عقاید، به خصوص عقاید خودمان از آن استفاده کنیم می‌شود تفکر نقادانه حداکثری. چرا حداقلی است؟ زیرا اینطور استفاده کردن از این مهارت یعنی بی‌تفاوت بودن به حرکت به سوی حقیقت و فضیلت. اما اگر حداکثری فکر کنیم آنگاه سوال‌های نقادانه‌ای را درباره هر ادعا حتی ادعای خودمان به کار می‌ببریم. البته تفکر نقادانه حداکثری باعث نمی‌شود از عقایدمان دست بکشیم بلکه می‌تواند مبانی برای محکم تر کردن عقایدمان باشد.موقعی حق داریم از داشتن یک عقیده به خود ببالیم که آن عقیده را انتخاب کرده باشیم. انتخابی از میان عقاید مختلفی که آن‌ها را درک و سبک سنگین کرده‌ایم. این کتاب بطور عملی به ما یاد می‌دهد که چطور حرف‌های تازه را حلاجی کنیم و بدون اجازه بهشان راه ندهیم تا بیایند و مغزمان را اشغال کنند. این کتاب درباره نحوه مواجه با معلوماتی که وارد مغزمان می‌شود صحبت می‌کند و بطور عملی به ما یاد می‌دهد که چطور با افکار، معلومات و هرچیزی که با آن مواجه می‌شویم برخورد کنیم. ۱۱ سوالی که باید بپرسی!برای دست پیدا کردن به تفکر نقادانه باید یاد بگیریم که چه سوالی را چه وقت و چگونه بپرسیم. در هر فصل از کتاب هر یک از سوالاتی را که باید از خودمان بپرسیم را یاد می‌گیریم و تمرین می‌کنیم. سوالات این‌ها هستند:۱- مسئله چیست و نتیجه/مدعا کدام است؟۲- دلایل استدلال کدام‌اند؟۳- کدام واژه‌ها یا عبارت‌ها مبهم‌اند؟۴- تضادهای ارزشی و فرض‌های ارزشی کدام‌اند؟۵- فرض‌های توصیفی کدام‌اند؟۶- آیا مغالطه‌ای در کار نیست؟۷- شواهد چقدر محکم‌اند؟۸- آیا علت‌های بدیل در کار نیستند؟۹- آیا آمار عرضه شده فریب‌دهنده نیست؟۱۰- چه اطلاعات مهمی بیان نشده است؟۱۱- چه نتیجه/مدعاهای معقول دیگری می‌توان مطرح کرد؟تمرین، تمرین و تمرینتقریبا محال است بدون تمرین به این مهارت دست پیدا کنیم. بدون اینکه فسفرهای مغزمان را بسوزانیم نمی‌توانیم تفکری نقادانه داشته باشیم. در انتهای هر فصل از کتاب تمرین‌هایی هست تا آموخته‌های خود را بسنجیم. تمرین ها پاسخ دارند و می توان پاسخ‌هایمان را هم مقایسه کنیم و بیشتر یاد بگیریم. نویسندگان کتاب تشبیه جالبی درباره یادگرفتن مهارت تفکر نقادانه دارند و می‌گویند آموختن تفکر نقادانه مثل یاد گرفتن یک مهارت جسمانی است و صرفا با تماشای دمبل زدن دیگران ورزشکار نمی شوید. بلکه باید خودتان، برای پرورش این مهارت برنامه داشته باشید و تمرین کنید.جلد کتاب راهنمای تفکر نقادانهکی ترجمه کرده و از کجا بخریم؟ کتاب راهنمای تفکر نقادانه از آن دست کتاب‌هاست که هر کسی باید آن را در کتاب‌خانه‌اش داشته باشد مثل یک جلد قران یا حافظ. اگر توانسته‌ باشم کنجکاوی شما را قلقلک دهم تا الان کمی به کتاب علاقه‌مند شده‌اید. می‌خواستم در این متن ایده اصلی کتاب را کمی تشریح کنم و مقصودم خلاصه نبود پس برای یاد گرفتن تفکر نقادانه پیشنهاد می‌کنم کتاب را مطالعه کنید.کتاب «راهنمای تفکر نقادانه | پرسیدن سوال‌های بجا» را «ام، نیا براون» و «استیوارت ام. کیلی» نوشته اند. «کورش کامیاب» آن را ترجمه و انتشارات «مینوی خرد» هم آن را منتشر کرده است.

مروری بر کتاب اصول دیزاین خدمات

مهدی موسوی — Thu, 11 Mar 2021 08:02:39 +0330

معتقدم گاهی باید کتاب قسمت آدم باشد تا آن را بخواند برای همین همیشه هر ماه به کتاب فروشی می‌روم و بی هدف می‌چرخم و کتاب‌ها را بر می‌دارم و ورق می‌زنم و می‌خوانم و گاهی هم می‌خرم.کتاب اصول دیزاین خدمات ۱-۱۰۰ هم از آن دست کتاب‌هایی است که قسمتم شده. نه آن در صفحه اینستاگرامی دیدم، نه ناشر آن را می‌شناختم و نه کسی آن را به من معرفی کرده. همینطور که داشتم در شهرکتاب شریعتی می‌چرخیدم نگاهم به جلدش افتاد. کتاب را بر داشتم. پشت جلدش را خواندم:«اگر می‌خواهید درک درستی از دیزاین خدمات در حوزه های عملی و اجرایی آن پیدا کنید، این کتاب میتواند شروعی خوب در این مسیر باشد»و باید بگویم که واقعا هم شروع خوبی است. این کتاب مثل راهنماست هر صفحه ای از آن را می‌توان باز کرد و شروع به خواندن کرد. در این کتاب ۱۰۰ اصل از دیزاین خدمات در قالب یک قانون دم دستی و ساده مطرح شده و هر اصل در یک صفحه می‌گنجد. و می‌تواند نقش یک سرنخ را در دنیای دیزاین خدمات را ایفا کند. برخی از اصول گفته شده در کتاب: نسخه اولیه هر ایده‌ای افتضاح است.مدت زمان انتظار را به مشتری بگویید.مشتری را مجبور نکنید تا با شما تماس بگیرد.مشتریان را به سمت رقبا هدایت کنید.این کتاب ترجمه Service Design Principles 1-100 نوشته دنیل کاتالانوتو است و مهدی اصل فلاح آن را ترجمه و نشر مشکی آن را منتشر کرده است.

نوشتن نیازمندی ‌های محصول - بخش دوم

مهدی موسوی — Fri, 05 Mar 2021 09:29:21 +0330

بخش اول این متن را ابتدا بخوانید:مختصری درباره نوشتن نیازمندی‌های محصولبیاید بقیه بحث را با یک مثال جلو می بریم. فرض کنید می‌خواهیم سیستمی برای یک شرکت خدماتی ایجاد کنیم که کاربران بتوانند صورت حساب‌هایشان را بطور آنلاین ببینند. کار را با این یوزر استوری شروع می کنیم:به عنوان یک مشتری، میتوانم وارد سیستم شوم و صورت حسابم را مشاهده کنم و بنابراین مجبور نیستم منتظر ایمیل صورت حساب بمانم.یکسری سوال وجود دارد که باید به آن‌ها پاسخ بدهیم: چطور باید وارد شوم؟اگر حساب کاربری نداشتم چه؟در کدوم قسمت می‌توانم صورت حسابم را ببینم؟داستان‌های فرعی را تکرار می‌کنیم. صورت حساب به‌تنهایی می‌تواند چند بخش شود:من می توانم صورت حسابم را در قالب html ببینم.من می‌توانم صورت حسابم را در قالب pdf ببینم.من می‌توانم سه صورت حساب آخرم را مشاهده کنم.برای بخش ورود ممکن است این‌ها را داشته باشیم:به عنوان کاربری که قبلا در سامانه بوده می‌توانم با نام کاربری و رمز عبورم وارد سیستم شوم.به عنوان کاربر جدید باید بتوانم در سیستم ثبت نام و اطلاعات کاربری خود را وارد کنم.در این قسمت شاید بهتر باشید یک دیاگرام بکشیم تا بتوانیم دقیق‌تر درباره جزئیات ورود فکر کنیم. این کار برای ما مشخص می‌کند که «ورود» چندان هم ساده نیست و مراحل گوناگوی دارد که هر کدام خودشان یک داستان هستند.داستان‌های دیگر کم کم آشکار می‌شوند. نام کاربری و رمزعبور فراموش شده، لینک اعتبارسنجی، شماره موبایل، پیامک و... . کشیدن صفحه‌ها و طراحی نمونه اولیه می تواند به ما در این مرحله کمک کند تا داستان‌های بیشتری کشف کنیم.شرایط رضایت - Conditions of Satisfactionحالا بیایید جزئیات را به داستان هایمان اضافه کنیم: شرایط رضایت (Conditions of Satisfaction). شرایط رضایت ملاک هایی هستند باید برای پذیرفتن داستان‌. شرایط رضایت (COS) داستان را «آزمایش پذیر» می‌کند. این کار باعث می‌شود ابهامات ما کمتر شود. نوشتن داستان کاربر ممکن است آسان باشد، اما ثبت و ضبط کردن همه شرایط رضایتمندی کار زیادی می طلبد. خب بیایید ببینیم برخی از شرایط رضایت احتمالی داستان زیر چیست؟به عنوان کاربر جدید با وارد کردن نام کاربری، رمزعبور و ایمیلم می‌توانم حساب کاربری برای خود ایجاد کنم.برخی از شرایط رضایت:نام کاربری وارد شده باید بین ۴ تا ۲۰ نویسه باشد:نام کاربری باید منحصر به فرد باشد.نام کاربری به حروف کوچک و بزرگ حساس است.نام کاربری فقط می تواند شامل اعداد و حروف باشد.رمز عبور وارد شده باید بین ۴ تا ۲۰ نویسه باشد:رمز عبور می تواند فقط شامل اعداد و حروف باشد.رمز ورود باید حداقل حاوی 1 عدد و 1 حرف باشد.یک ایمیل باید ارائه شود:ایمیل باید در قالب معتبر وارد شود.ایمیل باید از طریق دوبار ورود تأیید شود.ایمیل نباید از قبل در سیستم وجود داشته باشد.و...مثال‌های بیشتری هم ‌می‌توانم در این قالب‌ها نوشت:چه پیام های خطای اعتبار سنجی که باید در صورت عدم وجود یا نامعتبر بودن یک ورودی فیلد ظاهر شوندنیازهای ذخیره سازی برای هر داده چیست؟منطق شرطی که بر اساس داده های وارد شده رخ می دهد را شرح بدهیدنوشتن تمام COS ها کار سخت و وقت‌گیری است اما به ما اطمینان می‌دهد آن‌ چیزی که قرار است ساخته شود همان چیزی است که فکر می کردیم. جزئیات پشتیبان: وایرفریم‌ها - Wireframesشرایط رضایت به ما کمک می‌کنند تا منطق و قوانین کسب و کارمان را در پشت داستان‌ها حفظ کنیم اما کلمات که نمی‌توانند UI را توصیف کنند. درباره داستانی که در حال بررسی آن بودیم، از وایرفریم‌ها استفاده می‌کنیم تا:تصویرکلی صفحات سیستم و فرم‌ها مشخص می کنیمشیوه و محل قرارگیری پیام ها و هشدارها را مشخص می کنیمهر عنصر شرطی یا پویای UI را حاشیه نویسی می کنیم شاید نیاز باشد برای داستان وایرفریم داشته باشیم.نیازمندی‌های غیرعملیاتی - Nonfunctional Requirements با تعریف داستان‌های کاربر و COS معمولا نیازمندی‌های غیرعملیاتی فراموش می‌شوند و می‌توانند بعدا آسیب‌زا باشند پس باید مراقب این نوع از نیازمندی‌ها باشیم و آن‌ها را تعریف کنیم. الزامات غیر عملکردی به الزامات مبتنی بر کیفیت و عملکرد گفته می‌شود. به عنوان مثال ، اگر سیستم نیاز به پشتیبانی از 10،000 کاربر همزمان را داشته باشد ، این نیازی غیر عملیاتی است. مثالهای دیگر:حداقل زمان پاسخ یا انتقال اطلاعاتپروتکل های امنیتیسیستم های پشتیبان گیری سازگاری با سیستم عامل های دیگرقابلیت های خاص برای توسعه‌ در آیندهو... نیازمندی‌های غیرعملیاتی ممکن است در داستان های خاص اعمال شود یا خود یک داستان باشد.نمونه‌های اولیه با جزئیات کم - Low Fidelity Prototypes"نمونه اولیه با جزئیات کم" کلمه کلیدی است که می‌توان به چیز‌هایی نسبت داد که به تجسم یا شبیه سازی عملکرد کمک می کند. می‌تواند یک وایرفریم قابل کلیک باشد که با ابزار نمونه سازی اولیه، اکسل با ماکرو یا حتی یک انیمیشن تعاملی ساخته شده است. فراتر رفتن از کلمات و تصاویر ثابت می تواند در رسیدن به نیازها بسیار مفید باشد. جدول‌های تست و اسکریپت‌های تستسطح نهایی جزئیات نیازمندی‌ها نوشتن جدول های تست و اسکریپت‌های تست است. به عبارت دیگر سطح نهایی جزئیات تعریف آزمایشی است که می تواند برای تأیید تأمین شرایط رضایت استفاده شود.تعریف تست باید بعنوان بخشی از نیازمندی‌ها در نظر گرفته شود، تعیین تست‌ها در هنگام نوشتن نیازمندی‌ها یکی از کارآمدترین روشهای اطمینان از کیفیت مصحول است. این کار بسیار مطمئن تر از این است که کسی پس از توسعه محصول آن را تست و بررسی کند (که احتمالاً خیلی چیزها را از دست خواهد داد) و از همه مهمتر ، کل تیم را درگیر تلاش برای افزایش کیفیت و کاهش خطاها می کند.این رویکرد گاهی اوقات به عنوان TDD یا توسعه مبتنی بر تست شناخته می شود و شاما best practices های زیادی، از جمله روش های خودکار کردن بسیاری از تست‌ها با استفاده از تست های واحد و یکپارچه سازی مداوم و... است.در اینجا به چگونگی تعریف تست ها می پردازیم. برای تست‌های ساده ، به یک ساختار جدول از ورودی های احتمالی و خروجی های مورد انتظار فکر می کنیم. بیایید یک جدول تست برای COS زیر ایجاد کنیم:نام کاربری باید بین ۴ تا ۲۰ نویسه باشد.برای تست، به یک اسکریپت تست نیاز داریم که یک سری اقدامات با نتایج مورد انتظار است. این به وضوح سناریوهایی را مشخص می کند که باید به توسعه دهندگان ارائه شود:۱- ثبت نام حساب جدید۲- با نام کاربری و رمزعبور ایجاد شده با حساب جدید وارد شوید۳- تأیید کنید که صفحه خوش آمدید در ورود اولیه نشان داده شده است۴- از سیستم خارج شوید و دوباره وارد شوید۵- تأیید کنید که صفحه خوش آمدید در ورود به سیستم بعدی نشان داده نمی شودنوشتن جداول و اسکریپت های تست برای حالت های مختلف از آنچه ممکن است اتفاق بیفتد، مسلماً کار بسی دشوار است. جزئی کردن داستان‌های کاربری می‌تواند در اینجا به ما کمک کند. اما در نهایت، نوشتن نیازهای خوب کار سختی است و هر که هم طاووس خواهد باید جور هندوستان را بکشد. و دلیل اینکه بسیاری ازنیازمندی‌هایی که نوشته می‌شوند از کیفیت خوبی برخودار نیستند این است که تلاش کافی در مرحله نوشتن نیازمندی‌ها انجام نشده و این سختی با ضریب چند برابر در فرایند تست نهایی خود را نشان خواهد داد. این تست‌ها برای این است که تا اطمینان حاصل شود که آنچه ساخته می شود همان چیزی است که در نظر گرفته شده است و همانطور که در نظر گرفته شده کار می کند.

مختصری دربارهٔ نوشتن نیازمندی‌های محصول

مهدی موسوی — Wed, 24 Feb 2021 17:22:10 +0330

بسیاری از شرکت‌ها نوشتن نیازمندی برای محصول را کاری اضافی و وقت گیر می‌دادند و شروع می‌کنند به بداهه نویسی و در آخر هم فایل وردی را سرهم‌بندی می‌کنند و تا آخر پروژه هم آن را نمی‌خوانند. اکثر گرفتاری‌ها و مشکلات در هنگام پیاده‌سازی و توسعه محصول از همین غفلت‌های کوچک و بزرگ در هنگام نوشتن نیازمندی ها می‌آید. از همین رو نوشتن فایل نیازمندی برای نرم افزار از اوجب واجبات است و بر عهده مدیر پروژه یا مدیر محصول است تا این کار سخت را به سرانجام برساند.اگر نیازمندی مبهم باشد و خوانایی نداشته باشد از آن بد برداشت می‌شود.اگر بخشی از جزئیات از قلم بیفتد ممکن است منجر طراحی محصول ناقصی شود.اگر خط قرمز های بیزینس بطور کامل و دقیق تعریف نشده باشند ممکنه عملکرد نهایی محصول ناقص یا نامناسب باشد.در آخر اگر نیازمندی ها شفاف و واضح نباشد، آن چیزی ساخته می‌شود با آن چیزی که قرار بود ساخته شود زمین تا آسمان فرق خواهد کرد.اما می توانیم با انجام یکسری از موارد کاری کنیم که در دام این تله نیفتیم. در این ادامه، یکسری تکنیک های جواب پس داده برای نوشتن نیازمندی‌ را مرور خواهیم کرد که شامل این موارد می شود:نوشتن داستان کاربرتعریف شرایط رضایتایجاد نمودارهای گردش‌کاراستفاده از وایرفریم و طراحی بصریتعریف نیازمندی‌های غیرعملیاتیایجاد جدول های تست و سناریوی تستاصل اساسی نیازمندی‌های نرم افزاربیاید با یک اصل بنیادی برای پروژه‌های نرم افزاری پیچیده شروع کنیم که اغلب قدرش دانسته نمیشه: نیازمندی‌ها کم کم آشکار می‌شوند.برای هر پروژه پیچیده، تصور طراحی مناسب و دیدن همه جزئیات پیش بینی کردن چالش های فنی و هر وضعیتی که ممکن است در طول مسیر رخ دهد، ناممکن است. پیدا کردن نیازمندی ها فرایندی مداوم است و باید درگیر محصول شویم. در هر نقطه از فرایند توسعه محصول چیزی برای مرور و بررسی وجود دارد. حتی ممکن است با بیش از یکبار نگاه کردن به چیزی به ایده‌‌ها و نیازمندی های جدید برسیم. نیازمندی ها در طول پروژه تعریف، اصلاح، اضافه و حذف می‌شوند.البته بهتر است همه چیز را با جزئیات طراحی کنید و سپس بسادگی از روی برنامه اجرا کنید که همان رویکرد Waterfall «آبشاری» است. رویکرد آبشاری برای پروژه‌هایی که پیش‌بینی پذیر هستند یا از یک فرمول تکرارپذیر پیروی می کنند خوب کار می‌کند مثلا طراحی یک فروشگاه معمولی یا سایت معرفی خدمات یک شرکت اما برای پروژه هایی که نتیجه نهایی نامشخص است این رویکرد مناسب نیست. حتی با وجود تحقیقات مفصل و طولانی به ندرت نیازمندی‌ها نهایی می‌شوند و حتی بعد از پایان پروژه با نیازمندی‌های واقعی مشتری ها فاصله داشته و نتیجه رضایت بخش نمی‌شود. برای اکثر شرایط، روش Agile (چابک) راحت تر است و نتیجه بهتری دارد. هنگامی که جزئیات را به نیازمندی‌های اضافه می کنیم نیازداریم تا آن ها را قالب‌های مختلف ثبت کنیم: داستان‌های کلی (high level stories - epics) برای ثبت مفهوم و ارزش کسب و کار. داستان های جزیی (low level stories - backlogs) برای ثبت ویژگی‌های منحصر بفرد و تقسیم نشدنی. نمودارها برای ترسیم جریان کار و منطق کسب و کار. وایرفریم و طرح های تصویری برای رابط کاربری، نگاه و احساس. اکسل و فرمول‌ها که ورودی های احتمالی و خروجی های مورد انتظار را تعریف می کنند. پروتوتایپ با جزئیات کم (low-fidelity prototypes) برای بازخورد گرفتن و ایجاد تنظیمات.مختصری درباره داستان های کاربر داستان های کاربر (User Stories) چهارچوب مناسبی را برای بازتعریف نیازها از مفهومی سطح بالا و کلی به ریز جزئیات فراهم می‌کند. داستان‌های کاربر نقطه شروع دیگر قالب‌ها هستند و برای بیان ارزش پیشنهادی کسب‌وکار، برنامه‌ریزی و تخمین دقیق مفید هستند. رایج ترین الگو نوشتن داستان کاربر، الگویی است که مک کوهن آن را باب کرد: من به عنوان < نوع کاربر >، می‌خواهم < هدف > تا < دلیل >.به بیان دیگر، ما با جمله بالا به این سوالات پاسخ می دهیم: چه کسی (who): ما برای چه کسی این کار را می کنیم.چه چیزی (what): چیکار داریم می‌کنیم؟چرا (why): چرا داریم این کار را می‌کنیم؟ این الگو ساده و قابل فهم است و ارزش کسب و کار را نشان میدهد و به معنی راه حل یا پیاده سازی خاصی نیست. این مهم است به این دلیل که نیازهای سطح بالا باید مسئله را تعریف کند و نه راه حل را. داستان های کاربر برنامه ریزی و درک پروژه را در گفتگو با اعضای - فنی و غیرفنی - تیم را تسهیل می کند. مفید است که به داستانهای کاربر در دو سطح فکر کنیم. اپیک ها و بک لاگ ها، که رابطه پدر و فرزندی با یکدیگر دارند. می توانیم چند مرحله برای ترسیم داستان ها در نظر بگیریم. مرحله اول این است که نیازمندی‌ها را بازگو کنیم. برای مثال، تعریف اپیک ها محدوده کلی شرایط اپلیکیشن را مشخص می‌کند. این مقدار از جزئیات برای برنامه ریزی انتشار و برآورد میزان تلاش کافی است. مرحله دوم تعریف بک لاگ هاو (sub-stories) است که هر اپیک از آن‌ها تشکیل شده است. این زیرداستان‌ها هر کدام یک ویژگی (feature) یا جز (component) از برنامه هستند و ذیل یک اپیک قرار می‌گیرند. بخش «why» در این زیرداستان‌ها ضروری نیست اما مشخص کردن «what» و «how» مهم است. این سطح از جزئیات برای برنامه ریزی‌ دقیق‌تر و تخمین زدن مقدار منابع و تعیین زمان تقریبی (در حد روز و هفته) کافی است. مراحل بعدی برای اضافه کردن جزئیات بیشتر به زیرداستان‌هاست. جزئیاتی مثل شرایط رضایت(Conditions of Satisfaction)، وایرفریم‌ها، جدول‌های تست و موارد دیگر. این سطح از جزئیات تخمین ها را در چند ساعت امکان پذیر می کند.مختصری درباره نوع کاربر (user type)یکی از اشتباهات رایج در هنگام نوشتن نیازمندی از قلم انداختن انواع کاربرهایی است که ممکن است با سیستم تعامل کنند. کاربران مختلف، داستان‌های کاربری متفاوتی دارند و در نتیجه نیازمندی هایشان هم متفاوت است. حذف هر کدام از کاربران باعث می‌شود بخشی از فیچرهای نهایی حذف شود.اجازه دهید فهرستی تصادفی از انواع مختلف کاربر را که ممکن است بسته به سیستم تعریف شود، نام ببریم:- کاربر جدید- کاربر ثبت نام شده - کاربر VIP - کاربر غیرفعال شده - کاربر مجدد - مدیر- کاربر با یک حساب کاربری واحد- کاربر با چندین حساب- و...بطور طبیعی تعریف انواع کاربرها به محصول شما بستگی دارد. باید به یاد داشته باشیم کاربران مختلف ممکن است به گردش‌ کارهای متفاوتی نیاز داشته باشند و حتی تفاوت های جزئی کاربرها از دید بیزینسی ممکن تفاوت های عمده در ساختار محصول ایجاد کند.در بخش بعدی با مثالی عملی دیگر بخش های یک نیازمندی را بررسی می کنیم.