{"id":14293,"url":"\/distributions\/14293\/click?bit=1&hash=05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","hash":"05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","title":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043d\u043e\u0432\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441 \u043d\u0435 \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0432 \u043d\u0438 \u043a\u043e\u043f\u0435\u0439\u043a\u0438","buttonText":"","imageUuid":""}

12 советов, как запустить мобильное приложение и не поседеть

Планируете сделать мобильное приложение? Ваш покорный слуга уже прошел через 10 кругов ада создания приложения для своего стартапа. На основе чего вывел 12 советов, которые помогут вам сэкономить время, нервы, деньги и в целом получить качественный результат.

Вводный и самый важный совет – не делайте мобильное приложение. Это долго, дорого и почти всегда не так ахфигенно, как вы задумали. Возможно для вашего MVP подойдет веб-приложение, лендинг или вовсе аккаунт в Инстаграме. Вы ведь уже знаете про проверку гипотез и прочие популярные нынче стартаперские приемы?

Но вот вы все взвесили и поняли, что без приложения никак? Тогда погнали дальше. Я не буду рассматривать аспекты создания прототипов, дизайна и выкладывания в маркеты, это отдельная большая история. В этой статье будут советы по написанию программной части.

1. Все начинается с поиска программиста. И вот вы пишите друзьям, коллегам и даже публикуете пост на фейсбуке о поиске такового. Все не зря, как минимум одного человека вам посоветуют. Тут и заключается первая ловушка: узнайте почему вам советуют этого человека. Долго ли работали вместе с ним и есть ли отзывы других людей об этом исполнителе? Человек может отлично отработать один короткий заказ и полностью провалится на другом, особенно более продолжительном, где он не рассчитает свой тайминг и силы.

2. Отсюда второй совет: устанавливайте четкие сроки и штрафные санкции за их нарушение. Ничего так не мотивирует, как недополучение средств. Санкции должны быть и в вашу сторону, уважайте чужое время.

3. Все это нужно прописать в договоре. Да, нельзя работать на честном слове. Именно в договор нужно указать сроки и этапы работ. В какой момент происходит оплата, в какой момент вам передают часть уже оплаченного кода и где он должен храниться. Для этого, кстати, неплохо подходит bitbucket.org.

4. Если у вас есть серверная часть – разворачивайте ее сразу на своих серверах, чтобы не делать двойную работу по ее переносу в дальнейшем и застраховать себя от исчезнувшего с кодом исполнителя.

5. Проговорите стоимость дополнительных работ и впишите это так же в договор. У вас стартап, все меняется на ходу, доработки по-любому всплывут.

6. Узнайте будет ли время и желание у программиста заниматься поддержкой вашего проекта в дальнейшем. Это удобно и правильно, когда один человек занимается кодом приложения.

7. Знаменитая диаграмма закономерности качества, цены и сроков не врет. Если у вас горят сроки, то за дешево хорошо и вовремя не получится. Лучше обратитесь к исполнителю классом выше.

8. Помните о том, что вы заплатили дизайнеру за крутой визуал приложения и надо следить, чтобы он не растерялся при написании кода. Попросите вашего дизайнера контролировать качество работы фронтендера.

9. Вам очень повезло, если ваш программист понимает принципы живого интерфейса. Изучите его портфолио, скачайте и потыкайте в написанные им приложения. Они так же кайфово работают, как ваши любимые приложения или вам кажется, что вы тыкаете в бетонную стену, а не пружинящую желешку?

10. ТЗ. Оно должно быть крайне подробным. На любое действие в интерфейсе. Если вам кажется очевидным, что всплывающее снизу окно должно закрываться свайпом вниз, а не только крестиком, то это будут в итоге ваши проблемы и расходы на дополнительную работу.

11. Узнайте на каком языке будет написано приложение, это должно быть популярное решение, чтобы вам не составило проблем найти нового программиста.

12. iOS, Android или все сразу? Если ваше приложение может работать в начале на одной платформе, то делайте только ее. Не тратьте деньги на разработку сразу двух. Велика вероятность, что вы все еще 10 раз переделаете на стадии MVP. Если же ваше приложение нуждается в двух платформах сразу – берите кроссплатформенные решения, например Flutter.

Как понять, что ваше решение нуждается в двух платформах? Условный сервис позволяющий следить за местоположением друзей нуждается в кроссплатформе, ведь у кого-то из друзей может быть iOS или Android устройство. Приложение для обработки фотографий в Instagram может существовать на одной платформе.

Пожалуй это основные советы, которые я сформировал на основе своего опыта создания MVP мобильного приложения. Буду рад услышать ваши.

0
2 комментария
Ol Ka

А что делать программистам, которые уже поседели, пытаясь сделать MVP самостоятельно? Заканчивать?

Ответить
Развернуть ветку
Михаил Ивлев
Автор

Сценарий примерно тот же – делиться опытом. А еще можно объединять усилия. Мы вот как раз сейчас ищем программиста. Пишите мне на fb: https://www.facebook.com/mihail.ivlev/

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда