اگر برای یک ایده اپلیکیشن از چند تیم پیشنهاد گرفته باشید، احتمالاً عددها و زمان‌بندی‌هایی دیده‌اید که هیچ شباهتی به هم ندارند. معمولاً تقصیر مجریها نیست؛ هر کدام ایده مبهم شما را به شکل خودش فهمیده است. این راهنمای طراحی اپلیکیشن کمک می‌کند پیش از سفارش، تصمیم‌های اصلی را بگیرید و در یک بریف کوتاه بنویسید. خروجی کار سندی است که می‌توانید به هر مجری بدهید. در نتیجه برآوردهایی می‌گیرید که واقعاً با هم مقایسه‌پذیرند.
- پیش از انتخاب فناوری، دلیل استفاده دوباره کاربر از اپلیکیشن را روشن کنید.
- نسخه اول باید مسیر اصلی کاربر را کامل کند، نه اینکه همه ایده‌ها را داشته باشد.
- پیشنهادها را با دامنه و فرض‌های یکسان مقایسه کنید، نه فقط مبلغ نهایی.
- هزینه نگهداری، مالکیت حساب‌ها و معیارهای پذیرش را پیش از قرارداد مشخص کنید.
- خروجی تصمیم‌ها را در یک بریف کوتاه همراه با پرسش‌های باز ثبت کنید.
پیش از سفارش طراحی اپلیکیشن چه تصمیم‌هایی باید بگیریم؟
کوتاه‌ترین جواب این است: پیش از سفارش، اول مسئله کاربر را روشن کنید و ببینید اصلاً داشتن اپ ضرورت دارد یا نه. بعد امکانات نسخه اول، روش ساخت، سیستم‌عامل‌های هدف، اتصالها و بودجه ساخت و نگهداری را تعیین کنید. مسئول تصمیم‌گیری، معیارهای انتخاب مجری، مالکیت کد و حساب‌ها، شرایط تحویل و برنامه پشتیبانی را هم در همان بریف کوتاه بیاورید. هر بخش این راهنمای طراحی اپلیکیشن یکی از همین تصمیم‌ها را باز می‌کند.
در واقع این راهنمای طراحی اپلیکیشن درباره تصمیم‌های خرید است، نه آموزش اجرا. قرار نیست بگوییم تیم فنی هفته به هفته چه می‌کند. اگر ترتیب مراحل توسعه را می‌خواهید، نقشه راه ساخت اپلیکیشن موبایل از ایده تا اجرا را بخوانید. اینجا تمرکز روی چیزهایی است که شما، بهعنوان کارفرما، باید قبل از ساخت اپلیکیشن روشن کنید.
یک نکته را همین اول بگویم: لازم نیست به همه پرسش‌ها جواب قطعی بدهید. هر جا مطمئن نیستید، کنارش بنویسید «نیازمند بررسی». چون حدس قطعی بعداً به قیمت قطعی و قرارداد سفت تبدیل می‌شود. اما مجری خوب ابهام صادقانه را جدی می‌گیرد و برایش راه بررسی پیشنهاد می‌دهد.
راهنمای طراحی اپلیکیشن از تعریف دامنه شروع می‌شود
بیشتر سوءتفاهم‌ها از یک کلمه شروع می‌شوند: «طراحی». خیلی از کارفرماها طراحی اپلیکیشن را همان کشیدن صفحه‌ها می‌دانند. اما مجری وقتی این کلمه را می‌شنود، معمولاً کل کار را در نظر دارد. بنابراین پیش از هر چیز روشن کنید منظورتان کدام بخش‌هاست:
شناخت نیاز: کاربر کیست، چه کاری می‌خواهد انجام دهد و امروز کجا گیر می‌کند.
تجربه استفاده: مسیرها، صفحه‌ها و رفتار اپ در حالت‌های عادی و غیرعادی.
ساخت نرم‌افزار: نوشتن اپ، سرور، پنل مدیریت و اتصالها.
آزمون: بررسی اینکه هر مسیر روی دستگاه‌های واقعی درست کار می‌کند.
آماده‌سازی بهره‌برداری: انتشار، پایش و آمادگی تیم شما برای پاسخ‌گویی.
حالا پرسشی که زیاد می‌شنوم: اپلیکیشن اختصاصی چیست؟ نرم‌افزاری که بر اساس نیاز تعریف‌شده کسب‌وکار شما ساخته می‌شود، نه بر اساس قالبی یکسان برای همه. اما اختصاصی بودن الزاماً به این معنا نیست که برای هر سیستمعامل یک اپ جدا بنویسند. ممکن است بخش بزرگی از کد مشترک باشد و محصول باز هم کاملاً به کار شما بخورد.
همچنین دو اصطلاح در ادامه این راهنمای طراحی اپلیکیشن زیاد تکرار می‌شوند. بریف سند کوتاهی است که هدف، کاربران و محدودیتهای پروژه را می‌گوید. دامنه (Scope) مرز کار است: چه چیزی داخل سفارش است و چه چیزی بیرون آن.
برای مثال، فرض کنید سامانه نوبت‌دهی برای یک مجموعه خدماتی می‌خواهید. «اپ نوبت‌دهی» در ذهن شما یک چیز است، اما در عمل چند جزء دارد: اپ مشتری، پنل کارکنان پذیرش و شاید اپ جداگانه‌ای برای متخصص که برنامه روزش را ببیند. این‌ها یک دامنه واحد نیستند و هزینه و زمان هر کدام جداست.
پس خروجی این مرحله یک فهرست ساده است: چه نقش‌هایی با سیستم کار می‌کنند و هر نقش به چه جزئی نیاز دارد.
آیا کسب‌وکار شما به اپلیکیشن نیاز دارد؟
همیشه نه. طراحی اپلیکیشن برای کسب‌وکار وقتی توجیه دارد که کاربر مرتب سراغش بیاید، مسئله‌ای واقعی برایش حل شود و نصب برایش بیرزد. اینکه مدیرعامل اپ می‌خواهد یا دیگران اپ دارند، دلیل کافی نیست.
معمولاً اولین سؤالی که می‌پرسم این است: «کاربر هر چند وقت یک بار با شما کار دارد؟» کسی که سالی یک بار خرید می‌کند، به‌سختی حاضر است اپی نصب کند. اما کسی که هر هفته سفارش می‌دهد یا هر روز گزارش کارش را ثبت می‌کند، واقعاً از اپ سود می‌برد.
برای غربال اولیه از این قاعده استفاده می‌کنم:
مراجعه کم‌تکرار و نیاز ساده: اول تجربه موبایلی سایت فعلی را بسنجید و بهترش کنید.
فرایند پرتکرار، مثل سفارش دوباره یا ثبت روزانه: بررسی اپ توجیه بیشتری دارد.
وابستگی کار به قابلیتی از دستگاه که در مرورگر پایدار کار نمیکند: اپ گزینه جدی‌تری است.
با این حال، مراقب فرض‌های قدیمی باشید. دوربین، موقعیت مکانی و حتی اعلان، بسته به مرورگر و دستگاه، گاهی در وب هم در دسترس‌اند. پس جمله «ما به دوربین نیاز داریم» به‌تنهایی حکم ساخت اپ نیست. نیاز واقعی را روی دستگاه‌های مخاطبان خودتان بیازمایید.
خروجی این بخش سه جمله کوتاه است: دلیل ساخت اپ، شواهدی که امروز در دست دارید، و شرایطی که تصمیم را عقب می‌اندازد. مثلاً: «اگر بیشتر سفارش‌ها از مشتریان یک‌باره است، اول سایت را بهتر می‌کنیم.» یادتان باشد قاعده‌های این راهنمای طراحی اپلیکیشن برای غربال اولیه‌اند، نه حکم قطعی فنی.
چه مسئله‌ای باید برای کاربر حل شود؟
مسئله‌ای که ارزش ساخت دارد، معمولاً در یک جمله جا می‌گیرد. این قالب را پر کنید: «کاربرِ مشخص، در موقعیت مشخص، برای انجام کار مشخص، با مانع مشخصی روبه‌رو است.» اگر هر چهار جای خالی پر نمی‌شود، هنوز برای سفارش زود است.
یک مثال کاملاً فرضی: شرکتی خدماتی متوجه شده مشتریانش برای فهمیدن زمان مراجعه تکنسین چند بار تماس می‌گیرند. وسوسه اول این است که بگوییم «اپ ردیابی تکنسین بسازیم». اما شاید علت تماس چیز دیگری باشد. شاید پیامک تأیید ساعت دقیق ندارد، یا مشتری نمی‌داند تغییر زمان را از کجا بخواهد. پس تا علت تماس روشن نشده، راه‌حل را انتخاب نکنید.
برای پیدا کردن علت، با چند کاربر واقعی حرف بزنید. پرسش‌ها کوتاه باشند و درباره گذشته، نه درباره آرزوها:
آخرین باری که این کار را انجام دادید، دقیقاً چه اتفاقی افتاد؟
الان این کار را با چه روشی انجام می‌دهید؛ تماس، پیام‌رسان یا حضوری؟
کجای کار بیشتر وقت گرفت یا کلافه‌تان کرد؟
اگر وسط کار رهایش کردید، چه چیزی از دست دادید؟
سپس مسیر اصلی کاربر را بنویسید: نقطه شروع، اقدام مهم و پایان موفق. مثلاً «مشتری پیامک نوبت را می‌بیند، زمان را تأیید یا جابه‌جا می‌کند و پیام تأیید نهایی می‌گیرد.» نیاز مدیر به گزارش را هم با نیاز کاربر یکی نکنید. گزارش برای شما مهم است، اما کاربر برای دیدن گزارش شما اپ نصب نمیکند.
خروجی این بخش یک مسئله اولویت‌دار است، همراه با شواهدش و نتیجه‌ای که انتظار دارید تغییر کند؛ مثلاً کم شدن تماس‌های پیگیری. اگر فقط یک بخش از این راهنمای طراحی اپلیکیشن را جدی بگیرید، پیشنهاد من همین بخش است.
نسخه اولیه چه امکاناتی داشته باشد؟
فقط امکاناتی که مسیر اصلی کاربر را کامل می‌کنند و فرض اصلی شما را می‌آزمایند. به این نسخه MVP یا «کمینه محصول قابل عرضه» می‌گویند؛ یعنی کوچک‌ترین محصولی که کاربر واقعی بتواند با آن کار کند و شما از رفتارش چیزی یاد بگیرید. با این حال، MVP به معنای محصول ناقص، شکننده یا ناامن نیست.
برای جدا کردن امکانات، هر کدام را در یک دسته بگذارید و برای هر مورد ضروری یک دلیل کاربری بنویسید. جدول زیر برای فروشگاهی فرضی با ۲۰۰ کالا است:
امکان | دسته | دلیل |
|---|---|---|
مشاهده و جست‌وجوی کالا | ضروری | بدون آن مسیر خرید شروع نمی‌شود |
ثبت سفارش و پرداخت | ضروری | پایان موفق مسیر اصلی است |
وضعیت سفارش | ضروری | جلوی تماس‌های پیگیری را می‌گیرد |
فهرست علاقه‌مندی‌ها | قابل تعویق | مفید است اما مسیر اصلی را کامل نمیکند |
باشگاه مشتریان | نیازمند توجیه جداگانه | فرض متفاوتی را می‌آزماید |
فروش عمده | خارج از دامنه | کاربر و فرایند دیگری دارد |
باشگاه مشتریان شاید در آینده مهم باشد، اما پرسش دیگری را جواب می‌دهد: «آیا مشتری برمی‌گردد؟» اگر هنوز نمی‌دانید مشتری اصلاً از اپ خرید می‌کند یا نه، آن پرسش زود است.
اما یک اشتباه رایج را جدی بگیرید: حالت‌های شکست جزو دامنه‌اند، نه تزئینات نسخه بعد. اگر کالا وسط خرید تمام شود، پرداخت ناموفق باشد یا اینترنت قطع شود، اپ چه می‌کند؟ از نگاه کنترل کیفیت، بیشتر شکایت‌های هفته اول از همین حالت‌ها می‌آید، نه از امکانات حذف‌شده.
نسخه اول را کوچک بسازید، نه نیمه‌کاره؛ از امکانات کم کنید، نه از مراقبت.
به همین دلیل، خروجی این بخش از راهنمای طراحی اپلیکیشن سه فهرست است: امکانات با اولویت، یک شرط پذیرش کوتاه برای هر امکان ضروری، و فهرست صریح کارهایی که در نسخه اول انجام نمی‌شوند. فهرست سوم را دست‌کم نگیرید. بیشتر اختلاف‌های بعدی سر همین موارد نانوشته پیش می‌آید.
اپلیکیشن‌ساز، وب‌اپ یا توسعه اختصاصی؟
پاسخ به نوع نیاز شما بستگی دارد، نه به اینکه کدام روش در کل «بهتر» است. اپلیکیشن‌ساز ابزاری است که با اجزای آماده و کدنویسی کم، اپ می‌سازد. وب‌اپ نرم‌افزاری است که در مرورگر اجرا می‌شود و میتواند کاملاً اختصاصی باشد. پس این دسته‌ها کاملاً از هم جدا نیستند.
در عمل، سه مسیر پیش روی شماست. تفاوتشان در محدودیت محصول، راه رسیدن به دست کاربر و امکان رشد در آینده است:
معیار | سازنده آماده | وب‌اپ متناسب با نیاز | اپ موبایل اختصاصی |
|---|---|---|---|
تناسب با نیاز استاندارد | زیاد | خوب | خوب، گاهی بیش از نیاز |
نیاز به نصب | بسته به ابزار | ندارد؛ با پیوند باز می‌شود | دارد |
آزادی تغییر منطق کار | محدود به امکانات ابزار | زیاد | زیاد |
دسترسی به قابلیتهای دستگاه | وابسته به ابزار | وابسته به مرورگر | کامل‌تر |
وابستگی به یک تأمین‌کننده | زیاد | کم، اگر کد تحویل شود | کم، اگر کد تحویل شود |
دقت کنید که در این جدول ردیفی برای «ارزان‌تر» نیست، چون هزینه هر روش به دامنه و مدت استفاده بستگی دارد. ابزار آماده ممکن است در شروع ارزان باشد و با رشد مصرف گران شود.
اگر سراغ ابزار آماده می‌روید، پیش از انتخاب این موارد را بررسی کنید:
می‌توانید دادهها، از جمله کاربران و سفارش‌ها، را در قالبی قابل استفاده خروجی بگیرید؟
اتصال به درگاه پرداخت، پیامک و نرم‌افزار حسابداری شما ممکن است؟
سقف مصرف چیست و بعد از رسیدن به آن چه اتفاقی می‌افتد؟
اگر روزی بخواهید بروید، شرایط خروج چیست؟
همچنین یک میان‌بر رایج را بشناسید: نمایش همان سایت داخل یک پوسته نصب‌شدنی. این کار ظاهر «اپ» می‌سازد، اما اگر سایت روی موبایل کند یا گیج‌کننده است، همان مشکلات را با خودش می‌آورد. اتصال‌های ضعیف سایت هم سر جایشان می‌مانند.
خروجی: روش ترجیحی، دلیل انتخاب در دو جمله، و یک ابهام فنی که با نمونه کوچکی آزموده شود. مثلاً «آیا اسکن بارکد در مرورگر گوشی‌های انبارداران ما درست کار می‌کند؟» این بخش از راهنمای طراحی اپلیکیشن قرار نیست به‌جای شما انتخاب کند؛ فقط کمک می‌کند انتخابتان دلیل داشته باشد.
روش دسترسی کاربر و روش تولید نرم‌افزار دو تصمیم متفاوت‌اند. ابتدا قابلیت و مسیر عرضه را مشخص کنید؛ سپس درباره آماده یا اختصاصی بودن تصمیم بگیرید.
اندروید و iOS؛ تجربه مشترک با چه تفاوت‌هایی؟
تجربه اصلی میتواند در هر دو سیستمعامل یکی باشد، اما جزئیات رفتار فرق دارد و جداگانه آزمون می‌خواهد. در سفارش اپلیکیشن اندروید و ios، اول روشن کنید کدام را زودتر عرضه می‌کنید. این تصمیم را با شواهد بگیرید: مخاطبانتان با چه گوشی‌هایی می‌آیند، مسیر انتشار در هر سیستمعامل چقدر در دسترس است و پشتیبانی دو نسخه را چه کسی بر عهده می‌گیرد.
دو اصطلاح را هم بشناسید. توسعه بومی (Native) یعنی ساخت اپ با ابزارهای مخصوص هر سیستمعامل. توسعه چندسکویی (Cross-platform) یعنی بخش بزرگی از کد بین چند سیستمعامل مشترک است. انتخاب بین این دو به نیاز به قابلیتهای دستگاه، تیم نگهداری و برنامه رشد بستگی دارد. جزئیاتش را در مقایسه توسعه بومی و چندسکویی اپلیکیشن نوشته‌ایم.
اما کد مشترک به معنای آزمون مشترک نیست. این موارد در دو سیستمعامل رفتار متفاوتی دارند:
اعلان‌ها و شیوه گرفتن اجازه ارسال آن‌ها
مجوزهای دوربین، موقعیت و فایل
بازگشت بین صفحه‌ها، که در اندروید دکمه یا حرکت مخصوص دارد
پرداخت، رفتن به درگاه و برگشت از آن
کارهایی که اپ در پس‌زمینه انجام می‌دهد
برای مخاطب ایران، لایه دیگری هم هست. پیش از قرارداد بررسی کنید از چه کانالی منتشر می‌کنید، چه حساب‌هایی لازم است و به‌روزرسانی‌ها چطور به کاربر می‌رسد. مقررات کانال‌ها تغییر می‌کند، پس هنگام سفارش دوباره کنترلشان کنید. برای معیارهای کیفی، راهنمای رسمی کیفیت اپلیکیشن اندروید مرجع خوبی است.
خروجی: سیستمعامل اولویت‌دار، کمترین نسخه‌ای که پشتیبانی می‌کنید، و سناریوهایی که حتماً روی دستگاه واقعی آزموده شوند، نه فقط روی شبیه‌ساز. در جدول بریف انتهای این راهنمای طراحی اپلیکیشن، همین موارد در فیلد «روش ساخت و سیستمعامل» می‌نشینند.
چه تجربه‌ای باید پیش از کدنویسی تأیید شود؟
مسیر اصلی کاربر را پیش از کدنویسی روی یک نمونه تعاملی بیازمایید و تأیید کنید. نمونه تعاملی (Prototype) نمایش قابل کلیک صفحه‌هاست، بدون منطق کامل نرم‌افزار. کاربر روی دکمه‌ها می‌زند و از صفحه‌ای به صفحه دیگر می‌رود، انگار اپ واقعی است. اما تأیید رنگ‌ها و صفحه اصلی جای این آزمون را نمی‌گیرد.
برای مثال، در سامانه فرضی رزرو خدمت، کل مسیر را با سه یا چهار کاربر هدف مرور کنید: انتخاب خدمت، انتخاب زمان، تأیید، و بعد لغو یا جابه‌جایی. بیشتر گره‌ها در همین قسمت آخر پیدا می‌شوند، چون معمولاً کسی برایش وقت نگذاشته است.
در طراحی، این حالت‌ها را هم ببینید؛ این راهنمای طراحی اپلیکیشن آن‌ها را جزو دامنه می‌داند، نه جزئیات تزئینی:
حالت خالی: وقتی هنوز سفارشی نیست یا جست‌وجو نتیجه‌ای ندارد.
خطا و انتظار: پیام روشن هنگام شکست و نشانه بارگذاری هنگام کندی.
اندازه نوشته: وقتی کاربر قلم گوشی را بزرگ کرده است.
راست‌به‌چپ: جهت آیکون‌ها، اعداد و ترکیب متن فارسی و انگلیسی.
اینترنت ضعیف: رفتار اپ با اتصال کند یا قطع و وصل.
با این حال، همه بازخوردها هم‌وزن نیستند. «این آبی را دوست ندارم» سلیقه است؛ «کاربر دکمه تأیید را پیدا نکرد» مشکل قابل مشاهده است. پیشنهاد من این است که یک نفر را مسئول تأیید طراحی کنید و برای پاسخش مهلت بگذارید. نظرهای پراکنده چند مدیر، طراحی را هفته‌ها معطل نگه می‌دارد.
خروجی: فهرست مسیرهای تأییدشده و ابهام‌هایی که هنوز باقی‌اند. ادعای «طراحی کامل تمام شد» معمولاً دقیق نیست، پس بهتر است آن را در هیچ صورت‌جلسه‌ای ننویسید.
اتصال به سایت، پنل مدیریت و سرویس‌های دیگر
اپ شما تقریباً همیشه به جاهای دیگر وصل است: سایت، انبار، درگاه پرداخت، پیامک یا حسابداری. این اتصالها از راه رابط برنامه‌نویسی یا API برقرار می‌شوند؛ یعنی مسیری تعریف‌شده که دو سامانه از آن داده رد و بدل می‌کنند. در تجربه من، اتصالها بیشترین غافلگیری را در برآورد می‌سازند. به همین دلیل در این راهنمای طراحی اپلیکیشن بخش جداگانه‌ای دارند.
اول منبع اصلی هر داده را مشخص کنید؛ یعنی هر داده کجا «اصل» است و کجا فقط نمایش داده می‌شود:
داده | منبع اصلی (مثال فرضی) | چه کسی تغییرش می‌دهد |
|---|---|---|
موجودی | نرم‌افزار انبار | کارمند انبار |
قیمت | پنل مدیریت فروشگاه | مدیر فروش |
پروفایل مشتری | سرور اپ | خود مشتری |
وضعیت سفارش | سرور اپ | کارکنان پردازش سفارش |
اگر دو پنل مستقل بدون قاعده یک داده را تغییر دهند، دیر یا زود قیمتی می‌بینید که در سایت یک عدد است و در اپ عددی دیگر.
سپس برای هر اتصال این موارد را بنویسید: هدف، مالک سرویس، وجود مستندات، دسترسی به محیط آزمایشی، و هزینه یا محدودیت مصرف. مثلاً نبود محیط آزمایشی برای درگاه پرداخت به‌تنهایی میتواند زمان‌بندی را به هم بریزد.
یک سناریو را حتماً از مجری بپرسید: اگر هنگام ثبت سفارش سرویس پرداخت لحظه‌ای قطع شود، چه اتفاقی می‌افتد؟ کاربر طبیعتاً دوباره دکمه را می‌زند. بنابراین اپ نباید با این تلاش دوباره، سفارش یا پرداخت تکراری بسازد.
همچنین برای پنل مدیریت به فهرست صفحه‌ها بسنده نکنید. نقش‌ها را تعریف کنید و بگویید هر نقش چه چیزی را میتواند تغییر دهد. تاریخچه اقدامات را بخواهید تا معلوم باشد چه کسی قیمت را عوض کرد. پنلی که برای ثبت یک مرجوعی ده کلیک بخواهد، کارکنان را به دفترچه برمی‌گرداند.
خروجی: فهرست اتصالها و مسئول آماده‌سازی هر کدام در سمت شما. اگر قرار است از سایت فعلی استفاده کنید، این تصمیم را به بررسی فنی سایت گره بزنید، چون همه سایت‌ها برای اتصال به اپ آماده نیستند.
چه داده‌هایی باید جمع‌آوری و محافظت شوند؟
فقط داده‌ای را جمع کنید که برای ارائه خدمت لازم است. دسترسی به مخاطبان گوشی، موقعیت مکانی یا فایل‌ها را صرفاً چون از نظر فنی ممکن است، درخواست نکنید. هر مجوز اضافه هم اعتماد کاربر را کم می‌کند و هم مسئولیت شما را بیشتر.
بعد برای هر نقش روشن کنید به چه داده‌ای دسترسی دارد. مثلاً کارمند پشتیبانی شاید باید شماره مشتری را ببیند، اما سابقه کامل پرداختش را لازم ندارد. مدت نگهداری دادهها و روش حذف حساب یا داده کاربر را هم از همین حالا بنویسید.
به همین دلیل، امنیت را شرط پذیرش بدانید، نه کاری برای «بعداً». چند آزمون ساده که نباید جا بیفتد:
آیا کاربری میتواند با تغییر یک شناسه، سفارش یا پروفایل کاربر دیگری را ببیند؟
بعد از خروج از حساب، اطلاعات حساس روی گوشی باقی می‌ماند؟
رمزها، کلیدها و اطلاعات پرداخت چطور نگهداری و منتقل می‌شوند؟
اگر در حوزه‌ای حساس مثل سلامت یا خدمات مالی کار می‌کنید، بررسی تخصصی امنیت را جدی بگیرید. الزامات حقوقی هم از حوزه‌ای به حوزه دیگر فرق دارد و نسخه عمومی ندارد؛ هیچ راهنمای طراحی اپلیکیشن جای مشاور حقوقی شما را نمی‌گیرد. پس این بخش را با او کنترل کنید.
خروجی: فهرست دادهها، مجوزهای درخواستی از کاربر و کنترل‌های ضروری. برای عمق بیشتر، الزامات امنیت در طراحی اپلیکیشن‌های موبایلی را ببینید.
چطور بودجه ساخت و نگهداری را برآورد کنیم؟
بودجه را بخش‌بخش برآورد کنید و هر عددی را فقط کنار دامنه‌اش جدی بگیرید. یک رقم کلی برای «یک اپ فروشگاهی» چیزی نمی‌گوید، چون معلوم نیست چه چیزی داخلش است. این تفکیک کمک می‌کند پیشنهادها را کنار هم بگذارید:
بخش | شامل چه کارهایی است |
|---|---|
شناخت و طراحی | گفت‌وگو با کاربران، مسیرها، نمونه تعاملی |
توسعه | اپ، سرور، پنل مدیریت |
اتصالها | پرداخت، پیامک، انبار، حسابداری |
آزمون | مسیرها روی دستگاه واقعی، آزمون امنیت پایه |
انتشار | حساب‌ها، فایل‌ها و اطلاعات کانال‌ها |
هزینه‌های جاری | زیرساخت، سرویس‌ها، پشتیبانی |
اما هزینه‌های جاری را خیلی‌ها فراموش می‌کنند. سرور، پیامک، سرویس‌های بیرونی مثل نقشه یا ارسال اعلان، ابزار پایش خطا و پشتیبانی همه هزینه دوره‌ای دارند. سازگاری با نسخه‌های تازه سیستم‌عامل‌ها هم همین‌طور. اپی که نگهداری نشود، بعد از مدتی روی گوشی‌های جدید درست کار نمیکند.
قالبی که در این راهنمای طراحی اپلیکیشن برای برآورد پیشنهاد می‌کنم، چهار جزء دارد. از مجری بخواهید برآوردش همین شکل را داشته باشد:
هزینه پایه برای دامنه توافق‌شده
گزینه‌های اختیاری، هر کدام با قیمت جدا
اقلامی که صریحاً خارج از قرارداد است
فرض‌هایی که برآورد بر آن‌ها بنا شده است
بند چهارم از همه مهم‌تر است. اگر برآورد فرض کرده درگاه پرداخت مستندات کامل دارد و ندارد، هزینه تغییر می‌کند و کسی هم مقصر نیست. برای ابهام‌های پرریسک، یک بررسی فنی محدود پیش از قیمت قطعی منطقی‌تر است؛ در نیاسا هم معمولاً همین را پیشنهاد می‌کنیم. ذخیره بودجه را با ریسک‌های فهرست‌شده تعیین کنید، نه با درصدی دلخواه.
حالا فرض کنید برآورد از سقف شما بالاتر است. کم کردن امکانات کم‌اولویت، مثل علاقه‌مندی‌ها یا اشتراک‌گذاری، کاملاً منطقی است. ولی حذف آزمون یا امنیت برای رسیدن به همان عدد، یعنی خرید ریسکی که بعداً گران‌تر پرداختش می‌کنید.
بودجه را با کم کردن کار پایین بیاورید، نه با کم کردن دقت.
خروجی: سقف بودجه داخلی که پیش خودتان می‌ماند، بازه برآورد مشروط از هر مجری، و برنامه پرداختی که به تحویل‌های قابل بررسی وصل است، نه به گذشت زمان.
اگر یک اتصال هنوز بررسی نشده، از مجری بخواهید اثر آن را جدا از هزینه پایه توضیح دهد. این کار اختلاف برآوردها را قابل فهم‌تر می‌کند.
زمان‌بندی و مسئولیت‌های کارفرما چگونه مشخص می‌شوند؟
برنامه زمانی خوب فهرستی از تحویل‌های قابل بررسی است، هر کدام با پیش‌نیازهایش؛ نه فقط یک تاریخ پایان. مثلاً «نمونه تعاملی مسیر رزرو، به شرط دریافت متن خدمات» قابل پیگیری است. اما «اپ تا آخر فصل آماده است» قابل پیگیری نیست.
بخشی از این پیش‌نیازها در دست شماست، نه مجری. پیش از شروع، این‌ها را مشخص کنید:
مسئول تصمیم نهایی؛ یک نفر، نه یک جلسه
مهلت پاسخ‌گویی به پرسش‌ها و تأییدها
تهیه محتوا: متن‌ها، تصویر کالاها، قوانین و شرایط
دسترسی به سرویس‌ها: درگاه، پیامک، سرور، نرم‌افزارهای داخلی
تأیید حقوقی و مالی، اگر لازم است
برای مثال، فرض کنید دسترسی به درگاه پرداخت چند هفته دیر برسد. از پیش روشن کنید چه چیزی متوقف می‌شود و چه چیزی ادامه پیدا می‌کند. آزمون نهایی پرداخت می‌ایستد، اما ساخت بقیه مسیرها و پنل مدیریت جلو می‌رود. این را در برنامه بنویسید تا بعداً بحث تأخیر به مقصریابی نکشد.
همچنین فرایند تغییر دامنه را از روز اول تعریف کنید، چون تغییر حتماً پیش می‌آید:
درخواست تغییر را مکتوب ثبت کنید.
مجری اثرش را روی هزینه و زمان بررسی و اعلام کند.
شما پیش از اجرا تأیید کنید.
خروجی: فهرست مسئولیت‌ها، وابستگی‌ها و قاعده تأیید. ترتیب کامل مراحل اجرا را در همان نقشه راهی ببینید که ابتدای این راهنمای طراحی اپلیکیشن معرفی شد.
چگونه مجری و پیشنهاد فنی را ارزیابی کنیم؟
پیشنهادها را فقط وقتی منصفانه مقایسه می‌کنید که همه بر پایه یک بریف یکسان نوشته شده باشند؛ همان بریفی که این راهنمای طراحی اپلیکیشن قدم‌به‌قدم می‌سازد. اگر مجری‌ای فرض متفاوتی گرفته، مثلاً فقط اندروید، بخواهید این تفاوت را جداگانه بنویسد. وگرنه دو چیز ناهم‌جنس را با هم مقایسه می‌کنید.
نام فناوری به‌تنهایی معیار کیفیت نیست. به جای آن، این پرسش‌ها را از هر مجری بپرسید:
چرا این روش ساخت را برای ما پیشنهاد می‌کنید؟
بزرگ‌ترین ریسک این پروژه از نظر شما چیست؟
آزمون را چه کسی انجام می‌دهد و روی چه دستگاه‌هایی؟
چه چیزهایی در پیشنهاد شما نیست؟
پاسخ پرسش آخر خیلی چیزها را نشان می‌دهد. مجری‌ای که اقلام خارج از قرارداد را صادقانه فهرست می‌کند، معمولاً در اجرا هم شفاف‌تر است.
نمونه‌کار را هم با دقت ببینید. سؤال اصلی زیبایی صفحه‌ها نیست؛ سؤال این است که چه مسئله‌ای حل شده و تیم دقیقاً چه نقشی داشته: طراحی، ساخت یا هر دو؟
علاوه بر این، پیشنهاد باید تحویل‌دادنی‌ها، مسئولیت هر طرف، روش گزارش‌دهی و نحوه تغییر دامنه را روشن کند. این بخش از راهنمای طراحی اپلیکیشن فقط حداقل معیارها را برای تکمیل بریف می‌گوید. برای فهرست کامل‌تر، چک‌لیست انتخاب شرکت طراحی اپلیکیشن را ببینید.
خروجی: پرسش‌های باز هر پیشنهاد و دلیلی قابل دفاع برای انتخاب یا رد آن؛ دلیلی که بتوانید برای شریک یا هیئت‌مدیره هم توضیح دهید.
تحویل، مالکیت دسترسی‌ها و معیارهای پذیرش
پذیرش را با سناریوهای قابل آزمون تعریف کنید. جمله «اپ بدون مشکل کار کند» اندازه‌گرفتنی نیست و دقیقاً همین جمله روز تحویل اختلاف می‌سازد. در مقابل، سناریوی خوب می‌گوید چه کاری انجام می‌شود و چه نتیجه‌ای باید دیده شود.
برای مثال: «پس از پرداخت تأییدشده، فقط یک سفارش ثبت شود و وضعیت آن در پنل و اپ مشتری یکسان باشد.» هر کسی میتواند این جمله را بیازماید و نتیجه‌اش جای بحث ندارد.
فهرست تحویل را هم پیش از شروع بنویسید:
کد منبع، طبق آنچه در قرارداد آمده
مستندات اجرا و راه‌اندازی دوباره روی سرور
فایل‌های طراحی
تنظیمات و فایل‌های لازم برای انتشار
راهنمای بهره‌برداری برای کارکنان
سپس مالکیت را تفکیک کنید. مخزن کد، یعنی جایی که نسخه‌های کد نگهداری می‌شود، باید روی حسابی در اختیار شما باشد. حساب‌های انتشار، سرور، سرویس‌ها و کلیدهای انتشار هم همین‌طور. کلید انتشار را جدی بگیرید، چون بدون آن به‌روزرسانی همان اپ ممکن است دشوار یا ناممکن شود.
البته مالکیت داده با مالکیت همه ابزارها یکی نیست. دادهها ممکن است مال شما باشد، اما سرویس پیامک یا نقشه متعلق به شرکت دیگری است و شرایط خودش را دارد. مالکیت حقوقی کد و مجوز استفاده از اجزای ثالث را در قرارداد روشن کنید.
از نگاه کنترل کیفیت، سه چیز دیگر را هم بنویسید: دستگاه‌ها و نسخه‌هایی که آزمون روی آن‌ها انجام می‌شود، شدت خطاهای مانع پذیرش، و فرصت شما برای بررسی تحویل. یک غلط تایپی در صفحه‌ای کم‌اهمیت نباید پذیرش کل نسخه را متوقف کند. سفارش تکراری باید.
خروجی: پیوست پذیرش و فهرست دسترسی‌ها، که هر دو ضمیمه قرارداد شوند. از میان خروجی‌های این راهنمای طراحی اپلیکیشن، این دو بیشترین اثر را روز تحویل دارند.
ایمیل بازیابی و روش تأیید هویت حساب‌های اصلی هم باید تحت کنترل مالک توافق‌شده باشند. دسترسی موقت یک عضو تیم، جای تحویل مالکیت حساب را نمی‌گیرد.
برای انتشار اپلیکیشن چه چیزهایی باید آماده باشد؟
انتشار فقط فایل نصب نیست؛ حساب‌ها، اطلاعات معرفی و آمادگی تیم خودتان هم باید سر جایش باشد. پس انتشار را از تحویل فنی جدا ببینید، چون آماده بودن فایل اپ تضمین نمیکند کانال انتشار آن را تأیید کند.
این موارد را پیشاپیش آماده کنید:
حساب انتشار به نام و هویت مالک واقعی کسب‌وکار
توضیحات محصول و تصاویر معرفی
راه ارتباط با پشتیبانی
اطلاعات حریم خصوصی و سیاست نگهداری داده
مسیر انتشار را بر اساس دسترسی مخاطبان در ایران و مقررات جاری هر کانال انتخاب کنید. این مقررات تغییر می‌کنند و راه‌حل دائمی یا تضمینی وجود ندارد. بنابراین پیش از ارسال، متن رسمی را بخوانید؛ برای نمونه ضوابط رسمی بررسی و انتشار اپ در اپ‌استور می‌گوید چه مواردی به رد شدن اپ می‌انجامد.
در واقع، در این راهنمای طراحی اپلیکیشن آمادگی عملیاتی هم بخشی از انتشار حساب می‌شود. کارکنان باید بدانند به پرسش‌های کاربران چه جوابی بدهند. داده اولیه، مثل قیمت‌ها و موجودی، باید درست باشد. پایش خطا هم فعال باشد و از پیش بدانید اگر مشکل جدی پیش آمد، آسیب را چطور محدود می‌کنید؛ مثلاً با عرضه تدریجی یا خاموش کردن موقت یک قابلیت.
خروجی: مسئول هر پیش‌نیاز، کانال یا کانال‌های عرضه، و شرطی که تا برقرار نشود انتشار را شروع نمی‌کنید.
پشتیبانی و تغییرات پس از عرضه چگونه تفکیک می‌شوند؟
کار پس از عرضه سه نوع است و هر کدام قاعده خودش را دارد. رفع خطا یعنی اصلاح رفتاری که با دامنه توافق‌شده نمی‌خواند. قابلیت جدید یعنی چیزی که در دامنه نبوده است. نگهداری سازگاری یعنی به‌روز نگه داشتن اپ با نسخه‌های تازه سیستمعامل و سرویس‌ها. اگر این سه در قرارداد قاطی شوند، هر درخواستی به بحث می‌کشد.
همچنین زمان پاسخ اولیه را با زمان حل مشکل یکی نگیرید. «ظرف چند ساعت پاسخ می‌دهیم» یعنی کسی مشکل را دیده، نه اینکه حلش کرده است. سطح اهمیت رخدادها را تعریف کنید. برای رخداد جدی، مثل از کار افتادن پرداخت، یک مسیر تماس اضطراری داشته باشید.
چند مسئولیت عملیاتی هم صاحب می‌خواهد: پایش خطاها، تمدید سرویس‌ها و دامنه، نسخه پشتیبان و آزمون بازیابی داده. داشتن فایل پشتیبان به‌تنهایی کافی نیست؛ چون تا بازیابی را یک بار امتحان نکنید، نمی‌دانید آن فایل به کارتان می‌آید یا نه.
یک نمونه فرضی را با مجری مرور کنید: سرویس پرداخت شما روش اتصالش را عوض می‌کند. چه کسی تغییر را تشخیص می‌دهد؟ چه کسی اثرش را بررسی و هزینه تغییر را اعلام می‌کند؟ اگر جواب‌ها روشن نیست، قرارداد پشتیبانی هنوز کامل نیست.
خروجی: محدوده پشتیبانی، موارد استثنا، مسئول عملیات، و روش تحویل پروژه به تیم بعدی، اگر روزی مجری عوض شد. این همان بخشی از راهنمای طراحی اپلیکیشن است که کارفرماها معمولاً تا اولین مشکل جدی سراغش نمی‌روند.
موفقیت اپلیکیشن بعد از عرضه چگونه سنجیده می‌شود؟
معیار موفقیت باید به همان مسئله‌ای وصل باشد که برایش اپ ساختید؛ همان که در بخش مسئله این راهنمای طراحی اپلیکیشن در یک جمله نوشتید. تعداد نصب به‌تنهایی نشانه ارزش تجاری نیست، چون اپی که نصب شده و استفاده نمی‌شود، فقط جای گوشی را گرفته است.
برای مثال، در همان شرکت خدماتی فرضی این شاخص‌ها معنادارترند: سهم درخواست‌های شروع‌شده‌ای که تکمیل می‌شوند، تعداد کسانی که برای درخواست بعدی برمی‌گردند، و روند تماس‌های ناشی از ابهام زمان مراجعه.
اندازه‌گیری هم به رویداد تحلیلی نیاز دارد؛ یعنی ثبت یک اقدام مشخص کاربر، مثل «درخواست ثبت شد». نام هر رویداد، زمان ثبت و اطلاعات مجاز همراهش را پیش از توسعه تعریف کنید. اضافه کردنشان بعد از عرضه ممکن است، اما داده هفته‌های اول را از دست داده‌اید.
با این حال، در تفسیر محتاط باشید. اگر همزمان با عرضه اپ، تبلیغات تازه‌ای شروع شده یا ترکیب مشتریان عوض شده، مقایسه قبل و بعد گمراه‌کننده است. هم‌زمانی دو تغییر ثابت نمیکند یکی علت دیگری است.
خروجی: چند شاخص محدود، هر کدام با تعریف، منبع داده و مسئول بازبینی. هر بازبینی هم باید به تصمیمی برسد: ادامه، اصلاح یا توقف یک قابلیت.
چک‌لیست آماده‌سازی درخواست برآورد
اگر می‌پرسید برای ساخت اپلیکیشن چه باید کرد، پاسخ عملی این است: تصمیم‌های این راهنمای طراحی اپلیکیشن را در یک بریف یک‌صفحه‌ای جمع کنید و موارد نامعلوم را جدا نگه دارید. بریف کوتاه خوانده می‌شود؛ سند بیست‌صفحه‌ای معمولاً نه.
برای مثال، بریف فرضی همان شرکت خدماتی که می‌خواست ابهام زمان مراجعه را کم کند، در هشت فیلد این شکل را دارد:
فیلد | نمونه |
|---|---|
هدف | کاهش تماس‌های پیگیری درباره زمان مراجعه تکنسین |
کاربر اصلی | مشتری خانگی که درخواست خدمت ثبت کرده است |
مسیر اصلی | ثبت درخواست، دریافت زمان، تأیید یا جابه‌جایی، پیگیری وضعیت |
امکانات ضروری | ثبت درخواست، نمایش زمان، جابه‌جایی نوبت، اعلان تغییر |
روش ساخت و سیستمعامل | نیازمند بررسی؛ ترجیح اولیه وب‌اپ، با آزمون اعلان روی گوشی مشتریان |
اتصالها | نرم‌افزار زمان‌بندی تکنسین‌ها، سرویس پیامک |
محدودیت‌ها | سقف بودجه داخلی؛ داده محدود به نام، نشانی و شماره تماس |
معیار پذیرش | تغییر زمان در پنل، بلافاصله پس از ذخیره در اپ مشتری دیده شود |
این بریف اولیه جای مشخصات فنی یا پیوست قرارداد را نمی‌گیرد؛ کارش این است که همه مجریها از یک نقطه شروع کنند. هنگام پر کردن فیلد روش ساخت، به مقاله مقایسه بومی و چندسکویی در بخش اندروید و iOS برگردید. برای انتخاب مجری چک‌لیست انتخاب شرکت به کارتان می‌آید و برای برنامه اجرا، نقشه راهی که ابتدای راهنما معرفی شد.
سپس درخواست برآورد را با این سه جزء بفرستید:
دامنه مشترک، یعنی همین بریف، برای همه مجریها
پرسش‌های باز با برچسب «نیازمند بررسی»
درخواست تفکیک هزینه‌های جاری از هزینه ساخت
قدم بعدی ساده است. این هفته جدول بالا را با تیم خودتان پر کنید و جاهای خالی را صادقانه خالی بگذارید. اگر خواستید، همین بریف را با ما در خدمات طراحی و ساخت اپلیکیشن موبایل نیاسا مرور کنید. معمولاً اول پرسش‌های باز را با هم روشن می‌کنیم و بعد سراغ برآورد می‌رویم.
هدف، امکانات ضروری و پرسش‌های باز پروژه را برای گفت‌وگو درباره دامنه و روش ساخت با نیاسا مطرح کنید.
پرسش‌های پرتکرار
۵قبل از ساخت اپلیکیشن چه اطلاعاتی باید آماده کنیم؟
کاربر هدف، مشکل اصلی، امکانات ضروری و محدودیتهای بودجه و انتشار را بنویسید. اگر سایت یا سامانه فعالی دارید، وضعیت دادهها و امکان اتصال آن را هم مشخص کنید؛ پاسخ نامعلوم را بهعنوان موضوع بررسی ثبت کنید.
آیا باید اپلیکیشن اندروید و iOS را همزمان سفارش بدهیم؟
نه همیشه؛ اگر بیشتر کاربران شما در یک سیستمعامل هستند، عرضه محدودتر میتواند فرصت یادگیری ایجاد کند. پیش از حذف نسخه دیگر، اثر این تصمیم بر مشتریان، کانال انتشار و هزینه توسعه بعدی را بسنجید.
اپلیکیشن اختصاصی بهتر است یا اپلیکیشن‌ساز؟
برای فرایندهای استاندارد، ابزار آماده ممکن است نیاز را برطرف کند، به شرط آنکه محدودیت اتصال و خروج داده پذیرفتنی باشد. وقتی قواعد کسب‌وکار یا اتصالها در قالب آماده جا نمی‌گیرند، توسعه اختصاصی ارزش بررسی بیشتری دارد.
چرا برآورد شرکتهای طراحی اپلیکیشن متفاوت است؟
ممکن است هر پیشنهاد دامنه، کیفیت آزمون، اتصالها یا پشتیبانی متفاوتی را فرض کرده باشد. از همه مجریها بخواهید اقلام تحویل و موارد خارج از قرارداد را روی یک بریف مشترک مشخص کنند.
آیا میتوان سایت فعلی را به اپلیکیشن تبدیل کرد؟
گاهی میتوان از دادهها و منطق سایت استفاده کرد، اما این موضوع به کیفیت زیرساخت و امکان اتصال بستگی دارد. نمایش همان سایت داخل اپ، بهخودیخود تجربه استفاده یا قابلیتهای دستگاه را بهتر نمیکند.
