ساخت اپلیکیشن با بودجه محدود

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

ابتدا هدف مشخصی تعریف کنید

مادامی که پروژۀ شما در چارچوب اهداف تعیین شده باقی بماند، بودجه در همان حدی خواهد بود که پیش‌بینی کرده‌اید. چک‌لیست پایین را در ابتدای راه‌اندازی هر پروژه بررسی کنید تا مطمئن شوید که اهداف واضح و روشنی انتخاب کرده‌اید:

• چه کسانی از برنامۀ شما استفاده خواهند کرد؟ مخاطبان شما چه کسانی هستند؟
• چرا مشتری به محصول شما نیاز دارد؟ او دنبال انجام چه کاری است؟ سفر مشتری را از ابتدای جستجو تا اینکه سر از اپلیکیشن شما در می‌آورد تجسم کنید.
• رقبای شما چه کسانی هستند؟ مهم‌ترین ویژگی محصولات آن‌ها چیست و شما با چه مزیت‌های رقابتی می‌توانم در کنار آن‌ها فعالیت کنید؟
• بعد از لانچ محصول چه انتظاری دارید؟ دقیقاً مشخص کنید دنبال چه هستید. مثلاً انتظار اینکه در طی یک هفته، برنامه ۱۰۰۰ بار دانلود شود.

اهداف بعدی:

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

توسعه‌دهندگان برای اینکه بتوانند پیشنهاد قیمت دقیق‌تری بدهند به این اطلاعات نیاز دارند.

روش مناسبی برای پرداخت حقوق برنامه‌نویسان تعیین کنید

همیشه سرِ موضوع پرداخت دستمزد توسعه‌دهندگان بحث وجود دارد. نرخ ساعتی (حقوق ماهیانه) یا قرارداد ثابت. انتخاب اول این است که برنامه‌نویسان را به صورت ساعتی به استخدام خود درآوریم. حال ممکن است این کار به صورت ریموت یا حضوری در محل شرکت انجام شود. یا اینکه با توجه به مشخصات پروژه و فیچرهای درخواستی قرارداد ثابتی امضاء شود.

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

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

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

فاکتورهای موثر بر افزایش هزینۀ ساخت محصول را شناسایی کنید

هزینه‌های ساخت یک اپلیکیشن به عوامل متعددی وابسته است:

• پلتفرم (تلفن همراه، وب، گجت‌های پوشیدنی، اپل تی وی، گوگل تی وی)
• نوع پلتفرم موبایل: اندروید، iOS، ویندوز فون
• نوع محصول: MVP (نمونه اولیه) یا محصولی با ویژگی‌های کامل
• ویژگی‌های کلیدی محصول و تکنولوژی‌های مورد نیاز
• عوامل انسانی یا به عبارتی فرد یا شرکت توسعه دهنده که بسته به اعتبار، مهارت و شهرشان، بودجۀ لازم را کم و زیاد می‌کند

در ادامه هر یک از این عوامل را به صورت جداگانه بررسی می‌کنیم.

روی یک پلتفرم مشخص تمرکز کنید

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

اندروید:

iOS:

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

با یک MVP شروع کنید

حداقل محصول پذیرفتنی (MVP) یعنی در شروع کار و برای کاهش ضررهای مالی ابتدا با یک نسخۀ ساده از محصول شروع کنیم تا بعد از دریافت بازخورد کاربران سراغ تکمیل آن برویم. در شروع کار حتی می‌توانید با ابزارهای ساخت برنامه بدون کدنویسی یک نمونۀ اولیه سریع از محصول بسازید (که البته استفاده از این برنامه‌ها توصیه نمی‌شود). آن را در مارکت‌ها قرار دهید و میزان بازخورد و استقبال مشتریان را بسنجید. دلیلی وجود ندارد برای ایده‌ای که تعداد دانلودهایش به ۱۰۰ عدد هم نرسد کلی هزینه‌های گزاف بکنید. در واقع MVP، بازار و تقاضای واقعی کاربران را ارزیابی می‌کند.

انواع مختلفی از MVP وجود دارد. با این حال در پروژه‌های موبایلی، کاربرد این موارد از بقیه بیشتر است:

• وایرفریم یا موکاپ: چیدمان و ساختار اولیه‌ای از برنامه است که صفحات مختلف و امکانات هر صفحه را به صورت گرافیکی نشان می‌دهد. در وایرفریم و موکاپ همه چیز استاتیک است و کاربر با عناصر صفحه نمی‌تواند تعاملی داشته باشد.
• پروتوتایپ: پروتوتایپ محصول، نسخۀ تعاملی برنامه است. کاربر می‌تواند در نسخۀ پروتوتایپ با عناصر برنامه تعامل داشته باشد. از صفحه‌ای به صفحۀ دیگر حرکت کند. روی دکمه‌ها کلیک کند. با این حال تمامی اطلاعات نمایشی هستند و جنبۀ واقعی ندارند. مثلاً لیست کاربران عضو شده در برنامه یک دادۀ جعلی است که در پروتوتایپ قرار می‌گیرد.
• نسخۀ اولیه: که نهایتاً ۳ ویژگی اصلی محصول را به کاربر ارائه می‌دهد. مثلاً اپلیکیشن «چیز» در شروع کار، قابلیت ارسال کامنت نداشت و تا چند ماه فقط کاربران می‌توانستند ویدیوهای خود را ارسال کنند ولی بعدها وقتی از عملکرد محصول و استقبال کاربران اطمینان پیدا کرد. قابلیت کامنت‌گذاری و سایر ویژگی‌ها را اضافه کرد.

حتی پس از دریافت بازخورد مناسب از نسخۀ MVP باید اصول انتشار حرفه‌ای برنامه را رعایت کنید. یعنی انتشار نسخۀ آلفا، بتا، بتای باز و بسته و افزایش پلکانی کاربران مثلا از ۲۰ درصد شروع می‌کنید، به مرور ۲۵ درصد، ۵۰ درصد، ۷۵ درصد و نهایتاً نسخۀ جدید محصول در اختیار عموم کاربران قرار می‌گیرد.

بودجه خود را صرف کراس‌پلتفرم نکنید

ساخت برنامه‌های کراس‌پلتفرم و هیبریدی اگرچه در ظاهر مزایای مختلفی مثل عدم نیاز به نیروی کار جدید برای پلتفرم‌های مختلف، آپدیت هماهنگ برنامه در تمامی سکوها، استفاده از مهارت‌های فعلی برای توسعۀ برنامه در سکوهای جدید و … دارد ولی معایب آن لااقل در شرایط کنونی بیشتر است. در این روش توسعه‌دهندگان با همان مهارت‌های قبلی خود برای سکوهای جدید محصول خود را گسترش می‌دهند. مثلاً در زبان سی‌شارپ با زامارین می‌توان اپ موبایلی ساخت. توسعه‌دهندگان وب این کار را با React Native انجام می‌دهند و … . یا برنامه‌هایی که به همین منظور ساخته شده‌اند؛ مثلاً فون‌گپ، آیکونیک و … .

ولی به تجربه ثابت شده هیچ یک از این روش‌ها بی‌نقص نبوده‌اند. مثلاً در زامارین شکایت توسعه‌دهندگان از حجم زیاد فایل نهایی برنامه است. در فون‌گپ مشکل سرعت کم برنامه و محدودیت در دسترسی به برخی از قابلیت‌های گوشی است. حتی در React Native که ادعای ساخت برنامه‌های Native موبایلی دارد مشکل پیچیدگی ساخت برنامه و دشواری اشکال‌زدایی گزارش شده است. در واقع هیچ از این روش‌ها از تمام قابلیت‌های گوشی آنطور که باید نمی‌توانند استفاده کنند. برنامه‌های هیبریدی شاید در پیاده‌سازی نسخۀ MVP برخی از پروژه‌ها کاربرد داشته باشد ولی در اغلب موارد کاراییی چندانی ندارد. پس بهتر است تا جای امکان پول خود را صرف ساخت برنامه با این روش‌ها نکنید.

ویژگی‌های پرخرج را شناسایی کنید

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

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

مثلاً اولویت‌بندی قابلیت‌ها در یک  اپلیکیشن ویدیوی چت به شرح ذیل است:

قابلیت‌های فورس ماژور (حیاتی):

• ثبت‌نام و ساخت حساب کاربری با استفاده از شبکه‌های اجتماعی. هزینۀ متوسط؛
• ارسال پیام متنی و ویدیویی. هزینۀ بالا؛
• اتصال به لیست مخاطبین. هزینۀ کم؛

این ویژگی‌ها برای MVP مناسب هستند. می‌توان با همین قابلیت‌ها برنامه را لانچ کرد.

قابلیت‌های مهم:

• به اشتراک‌گذاری محتوا. هزینۀ پایین؛
• فیلترها و استیکرهای سفارشی. هزینۀ پایین؛
• پیش‌نمایش ویدیوها.هزینۀ متوسط؛

بعد از تایید MVP می‌توانید با اضافه کردن ویژگی‌های جدیدی به برنامه، مزیت رقابتی هم داشته باشید.

قابلیت‌های اضافه:

• ویدیوچت گروهی. هزینۀ بالا؛
• تنظیمات حریم خصوصی پیشرفته. هزینۀ متوسط؛
• اشتراک ویدیوها به صورت عمومی روی نقشه و با توجه به موقعیت جغرافیایی.هزینۀ بالا؛

اکنون با خیال راحت می‌توانید برای اضافه کردن ویژگی‌های جدید برنامه‌ریزی کنید.

هزینه‌های جاری

تعدادی از قابلیت‌های برنامه هستند که به صورت مداوم نیازمند پرداخت هزینه هستند. به عنوان مثال ارسال پیامک به کاربران ویژگی هزینه‌بری است. شما باید ماهیانه، سالیانه یا طبق سایر پلن‌ها، هزینه‌های یک پنل پیامکی را بدهید. یا درگاه‌های واسط پرداخت، سرویس‌های میزبانی، فضاهای ابری، رایانش ابری و … . همۀ این‌ها بودجه می‌خواهد. به همین دلیل اکثر برنامه‌های هواشناسی پولی هستند. البته با کمی جستجو تعدادی از این سرویس‌ها توسط برنامه‌نویسان در قالب API پیاده‌سازی شده و در دسترس کاربران قرار گرفته است. یک توسعه‌دهنده خوب و با انصاف هنگام عقد قرارداد همۀ انتخاب‌های ممکن را با شما در میان می‌گذارد. بنابراین یکی از روش‌ها برای تشخیص صلاحیت یک توسعه‌دهنده بخصوص در بین فری‌لنسرها همین موضوع است.

استفاده از شتاب‌دهنده‌ها

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

شتاب‌دهنده سازمانی (معمولاً خصوصی) است که ایدۀ شما را در قالب یک طرح کسب‌وکار دریافت می‌کنند. سپس تعدادی از کارشناسان و کارآفرینان با تجربه با توجه به تجریات کارآفرینی و شناخت خوبی که از بازار دارند پتانسل موفقیت ایدۀ شما را بررسی می‌کنند. در صورت تایید، پذیرش می‌شوید و به مرحلۀ بعد می‌روید که معرفی هم‌بنیان‌گذار یا همان هم‌تیمی‌های شماست.  در این مرحله باید حداقل یک نفر وجود داشته باشد که پیاده‌سازی ایده شما را بر عهده بگیرد. شما با هم‌تیمی خود به صورت رایگان در یک دفتر کار اشتراکی و تحت مشاورۀ کارشناسان اقدام به پیاده‌سازی طرح اولیۀ پروژه می‌کنید (همان MVP). هر جایی به بودجۀ نیاز داشتید تا سقف مشخصی به شما کمک مالی می‌شود.  سپس در جلساتی که سرمایه‌گذاران حضور دارند، طرح خود را مجاب کردن سرمایه‌گذاران به سرمایه‌گذاری معرفی می‌کنید.

البته شتاب‌دهنده‌ها از سر خیرخواهی محض این کار را نمی‌کنند. درصدی از سهام استارتاپ بعد از ورود به بازارکار متعلق به آن‌هاست. با توجه به استفادۀ انبوه استارتاپ‌های مشهور از شتاب‌دهنده‌ها – که در نقشه استارتاپی ایران هم می‌توانید ببینید – جای هیچ شک و بدبینی باقی نمی‌ماند. به عنوان مثال اپلیکیشن‌های بزرگی مثل اسنپ، مایکت، کافه‌بازار، آپارات، فیدیبو، دیجیاتو، بیپ‌تیونز، تپسل و … همگی از دل شتاب‌دهنده‌ها بیرون آماده‌اند. بعد از گذر از مراحل اولیه و کمی بعد از اینکه در بازار کار جان گرفتید و اندکی غلطک کسب درآمد از برنامه راه افتاد می‌توانید اقدام به اضافه کردن قابلیت‌های جدید کنید؛ البته در چارچوب بودجه و با در نظر گفتن نکاتی که در مطلب حاضر خواندید.