فهرست امکانات اپلیکیشن می‌تواند سریع رشد کند: حساب کاربری، پرداخت، نقشه، چت، گزارش و اعلان. ابتدا بپرسید کاربر باید کدام کار را از ابتدا تا انتها انجام دهد. بدون مسیر روشن، صفحه‌های آماده هم محصول قابل استفاده‌ای نمی‌سازند.
ما در اسکای دولوپرز برای تعریف نسخه اول، از کار روزمره مخاطب شما شروع می‌کنیم. نسخه اولیه باید مسئله مشخصی را حل کند و امکان بررسی نتیجه را بدهد. حذف قابلیت‌های کم‌اولویت، دلیلی برای کنارگذاشتن ثبت درست اطلاعات، سطح دسترسی یا رفتار روشن هنگام خطا نیست.
مثال فرضی: تیم سرویس تجهیزات در محل مشتری
فرض کنید کسب‌وکاری دارید که نیروهایش برای بازدید و سرویس تجهیزات به محل مشتری می‌روند. امروز مسئول دفتر مأموریت‌ها را در پیام‌رسان می‌فرستد و گزارش انجام کار در چند گفت‌وگو پراکنده می‌شود. مسئله اولیه می‌تواند این باشد: هر مأموریت به فرد مشخص برسد و نتیجه کار، همراه توضیح و تصویر، در همان پرونده ثبت شود.
برای شروع، دو نقش کافی به نظر می‌رسند: مسئول دفتر و نیروی اجرایی. مسئول دفتر مأموریت ایجاد و تخصیص می‌دهد؛ نیروی اجرایی آن را می‌بیند و گزارش می‌فرستد؛ مسئول دفتر نتیجه را بررسی می‌کند. این فقط یک نمونه برای تمرین است، نه نسخه آماده برای همه کسب‌وکارها. نقش‌ها و محدودیت‌های شما ممکن است متفاوت باشند.
مسیر اصلی را با فعل بنویسید، سپس امکانات را انتخاب کنید
مسیر مثال ما این است: ورود ← دیدن مأموریت‌های خود ← بازکردن جزئیات ← ثبت گزارش ← ارسال ← تأیید دریافت در دفتر. حالا برای هر مرحله بپرسید چه داده و اختیاری لازم است. کاربر نباید مأموریت همکارش را ببیند، گزارش باید به مأموریت درست وصل شود و وضعیت ارسال نباید با ذخیره محلی اشتباه گرفته شود.
اگر نقشه مسیریابی را حذف کنید، آیا نیرو می‌تواند با نشانی و ابزار موجود به محل برسد؟ اگر چت داخلی نباشد، آیا هماهنگی ضروری با تماس انجام می‌شود؟ پاسخ مثبت می‌تواند آن قابلیت را به مرحله بعد ببرد. اما اگر نبود ثبت گزارش، مسئله اصلی را حل‌نشده باقی می‌گذارد، حذف آن برای سبک‌کردن نسخه اول تصمیم مناسبی نیست.
برای هر قابلیت، دلیل اولویت و روش آزمون بنویسید
به هر امکان یکی از سه برچسب بدهید: «برای مسیر اصلی ضروری»، «قابل تعویق با راه جایگزین» یا «فعلاً خارج از پروژه». کنار برچسب، دلیل کوتاه بنویسید. این کار از تصمیم‌گیری بر اساس جذابیت ظاهری امکانات جلوگیری می‌کند و کمک می‌کند در گفت‌وگو با اسکای دولوپرز، محدوده برآورد مشخص بماند.
| قابلیت در مثال | اولویت پیشنهادی | معیار قابل آزمون |
|---|---|---|
| مشاهده مأموریت‌های خود | ضروری | هر نیرو فقط مأموریت‌های مجاز خودش را ببیند. |
| ثبت گزارش و تصویر | ضروری | گزارش به پرونده درست برسد و وضعیت دریافت روشن باشد. |
| چت داخلی | قابل تعویق | هماهنگی اولیه از راه تماس موجود انجام شود. |
| گزارش تحلیلی پیشرفته | قابل تعویق | فهرست ساده وضعیت مأموریت‌ها برای بررسی اولیه کافی باشد. |
| باشگاه امتیاز مشتریان | فعلاً خارج از پروژه | به مسئله ثبت و پیگیری مأموریت ارتباط مستقیم ندارد. |
«آفلاین باشد» را به چند تصمیم مشخص تبدیل کنید
دیدن اطلاعات قبلی بدون اینترنت با ثبت و ویرایش آفلاین یکسان نیست. راهنمای معماری Android هم خواندن و نوشتن داده را جدا بررسی می‌کند. در مثال ما ممکن است نیرو داخل ساختمان اینترنت نداشته باشد؛ لازم است مأموریت از قبل دریافت‌شده را ببیند و گزارش را روی دستگاه ذخیره کند. اما ثبت گزارش روی گوشی هنوز به معنی دریافت آن در دفتر نیست.
پیش از اجرا مشخص کنید چه اطلاعاتی محلی ذخیره می‌شود، ارسال چه زمانی تکرار می‌شود و اگر دفتر همان مأموریت را تغییر داد، تعارض چگونه حل می‌شود. متن وضعیت می‌تواند «ذخیره روی دستگاه؛ در انتظار ارسال» باشد. آزمون پذیرش هم روشن است: گزارش را بدون اینترنت ثبت کنید، برنامه را ببندید، دوباره باز کنید و پس از اتصال، ثبت یک‌باره آن در مقصد را بررسی کنید.
اعلان را برای رویداد مهم تعریف کنید
درخواست «اعلان داشته باشد» را دقیق‌تر بنویسید: وقتی مأموریت تازه به یک نیرو اختصاص یافت، او از تغییر باخبر شود. گیرنده، رویداد، صفحه مقصد و امکان خاموش‌کردن اعلان را مشخص کنید. برای نسخه اول، اعلان تغییر وضعیت ممکن است از پیام‌های تبلیغاتی مهم‌تر باشد؛ انتخاب به کاری بستگی دارد که کاربر باید انجام دهد.
در Android 13 و بالاتر، اعلان‌های مشمول مجوز به اجازه کاربر نیاز دارند. بنابراین دریافت اعلان را قطعی فرض نکنید؛ کاربر باید با بازکردن اپ هم مأموریت‌های جدید را ببیند. راهنمای Android پیشنهاد می‌کند درخواست مجوز در موقعیت مرتبط و با توضیح کاربرد آن مطرح شود. در آزمون‌ها، حالت رد مجوز را هم بررسی کنید.
پنل، داده و انتشار را در محدوده نسخه اول ببینید
صفحه‌های گوشی تمام پروژه نیستند. در مثال خدماتی، مسئول دفتر به ابزاری برای ایجاد مأموریت و بررسی گزارش نیاز دارد. اگر سامانه موجود دارید، وضعیت اتصال و مستندات آن را بررسی کنید؛ اگر ندارید، این بخش باید در محدوده ساخت دیده شود. حساب‌های آزمایشی، مجوز نقش‌ها و مسئول نگهداری داده را نیز مشخص کنید.
برای نخستین بررسی می‌توانید گروهی محدود از کاربران واقعیِ کسب‌وکارتان را انتخاب کنید و از آن‌ها بخواهید همان مسیر اصلی را طی کنند. خطاها و مراحل مبهم را ثبت کنید. انتشار عمومی، حساب فروشگاه و پشتیبانی نسخه‌ها تصمیم‌های جداگانه دارند و باید پیش از وعده زمان تحویل روشن شوند؛ از این فهرست امکانات به‌تنهایی نمی‌توان بودجه یا زمان ثابت نتیجه گرفت.
با یک برگه کوتاه وارد جلسه برآورد شوید
کاربر اصلی، مشکل امروز، مسیر نسخه اول، نقش‌ها و معیار آزمون را در یک برگه بنویسید. اگر پاسخ فنی ندارید، موقعیت واقعی استفاده را توضیح دهید. ما در اسکای دولوپرز بر همین اساس، انتخاب‌های فنی و وابستگی‌های پروژه را با شما بررسی می‌کنیم.
چک‌لیست شما
موارد را مرور کنید و برای گفت‌وگو با ما در اسکای دولوپرز آماده نگه دارید.
منابع و مطالعه بیشتر
این راهنما را به پروژه خودتان وصل کنید
ما در اسکای دولوپرز از هدف و اولویت‌های شما شروع می‌کنیم. نیازتان را توضیح دهید تا درباره مسیر مناسب سایت یا اپلیکیشن، محدوده اجرا و برآورد پروژه گفتگو کنیم.