Как контролировать разработку приложения

Денис Гордиенко, руководитель Bright Mobile, о том, как организовать работу с разработчиком при создании мобильных приложений на примере мессенджера.

Недавно мне позвонил один из подписчиков моего YouTube-канала с просьбой доделать приложение. Он заказывал некоторое время назад в одной из студий разработку мессенджера под iOS. Пока делалось приложение компания развалилась, все свои обязательства, насколько могли, выполнили, но не реализовали push-уведомления. Собственно, просьба звучала так, что нужно по исходникам разобраться в проекте и доработать push.

Я отказался, потому что занимаемся кроссплатформой на Ionic, а приложение заказчика сделано на нативе. Вторая причина отказа - на рефакторинг порой уходит 90% бюджета, если сравнивать с разработкой с нуля. А в некоторых случаях это не возможно в принципе.

Возможно, ему удастся найти фрилансера, который возьмется доделывать приложение, но это будет случай из разряда "повезло". В веб-разработке более-менее устоялась практика смены подрядчика, а в приложениях подавляющее большинство разработчиков, как и мы, принципиально не дорабатывают чужие проекты - себе дороже.

Данную ситуацию можно избежать изначально с помощью более точечного контроля программистов и разработки своего проекта по коротким версиям. Об этом будет сегодняшняя статья, но для того чтобы сделать правильные выводы давайте сначала разберёмся, почему появляется желание отпустить проект из управления, а через несколько месяцев получить готовый результат и почему этот результат часто бывает плачевным?

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

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

Поэтому, материалы, которые высылаются на согласование, проверяются сквозь пальцы. Приходится заострять внимание заказчиков на моменты, которые могут быть поняты неоднозначно и критичны в конце проекта.

Кто-то из разработчиков может так досконально не настаивать на проверке, а работать в формате "согласовал и ладно". Вообще, у многих разработчиков есть тенденция, все самое сложное оставлять на конец. В итоге, разработчик может сделать приложение процентов на 80, взять оплату только за сделанное и покинуть проект или расторгнуть договор. Например, как в случае выше, разработчик был уверен, что сделает push, но не смог. По закону всё чисто - деньги взяты пропорционально выполненной работе, но кому нужен мессенджер без моментальных уведомлений о новых сообщениях? Такой продукт не имеет потребительской ценности.

Ситуация с тем, что проектирование и договор проверяются сквозь пальцы, усложняется тем, что заказчик хочет реализовать всё приложение сразу.

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

Но чем больше задача, тем меньше шансов дойти до финала. Потому что прочность цепи равна прочности самого слабого звена. Чем больше звеньев - тем больше шанс понизить прочность. Применяя к разработке это выглядит так. На каком-то из модулей (push-уведомления) программист что-то не учёл, при этом оставив его на потом. В итоге приложение посыпалось.

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

Рассмотрим на примере мессенджера. На какие версии можно разделить разработку?

Минимальный мессенджер состоит из следующих экранов:

1. Регистрация/Авторизация
2. Список контактов
3. Переписка
   
4. Создание общего чата
5. Просмотр профиля
   
6. Редактирование своего профиля
   
7. Настройки
   
8. Меню
   
9. Пользовательское соглашение
   
10. Уведомления

Разных функций, таких как запись голосовых сообщений, отметки о прочтении или возможность создания секретных чатов, можно придумать сколько угодно, но это задача второй и последующих версий, а мы разбираем как запустить первую.

Но даже из 10 функций выше можно выделить несколько, которые нужно сделать в самом начале разработки, чтобы понять, что разработчик справится с задачей. Эта микроверсия будет содержать:

1. Регистрация/Авторизация
2. Список контактов
3. Переписка
   
4. Уведомления
   

Очевидно, что этот сырец нельзя публиковать в сторы, но он и делается не для широких масс, а чтобы вы с программистом могли проверить работает ли основа. То есть в этой нулевой версии вы должны иметь возможность авторизоваться, увидеть контакты, написать сообщение, а собеседник должен получить push. Всё.

Доведите удобство этого простого мессенджера до приемлемого варианта, который будет применим в реальных условиях постепенно добавляя редактирование своего и просмотр чужого профиля и прочее.

Планировать следующую версию или блок доработок, когда у тебя перед глазами есть работающая предыдущая, гораздо легче. На малых суммах видишь, как развивается приложение и устраивает ли цена/качество разработчика. Если возникнет конфликт с разработчиком, то временные и денежные потери будут минимальны. При этом, если всё-таки расстаётесь, то шанс найти нового разработчика, когда архитектура работает и нужны косметические доработки проще, чем когда не хватает каких-то архитектурных решений.

По опыту могу привести принципиальные функциональные элементы ещё для нескольких видов проектов.

Маркетплейс услуг. Общая логика - заказчик размещает заказ, по какому-то принципу назначается или выбирается исполнитель, сервис зарабатывает комиссию.

1. Регистрация/Авторизация
2. Создание заявки
3. Просмотр и отклик, либо функционал автоназначения исполнителя
4. Контактные блоки заказчика с исполнителем (переписка, телефон или иное, что закладывается в проект)
5. Уведомления
6. Функционал монетизации

Товарный маркетплейс. Сторонние вендоры размещают свои товары, они агрегируются на площадке, кленты заказывают товары, продавцы уведомляются о заказах, площадка зарабатывает комиссию.

1. Регистрация/Авторизация
2. Загрузка номенклатуры поставщика
3. Витрина с предложениями
4. Возможность заказа (не обязательно покупка, можно просто оформление заказа или контакты продавца)
5. Уведомления
6. Функционал монетизации

Доска объявлений. Одни пользователи размещают объявления, другие связываются с авторами объявлений, площадка зарабатывает на доп. услугах.

1. Регистрация/Авторизация
2. Размещение объявления
3. Лента объявлений
4. Возможность контакта (переписка, телефон или иное, что закладывается в проект)
5. Уведомления
6. Функционал монетизации

По ходу статьи я использовал слова "программист" и "разработчик". Они подразумевают, как работу с программистом в штате или на фрилансе, так и со студиями.