#Риски:
чего ждать, если создаёшь мобильное приложение

Работа с рисками – часть "рутины" любого менеджера проекта. Обсуждать эту тему можно бесконечно, но в этой статье наши друзья Heads and Hands смогли коротко и ёмко в формате ситуация–решение поделиться опытом управления рисками при создании мобильного приложения.
Читайте и страхуйте свои проекты, коллеги!

Поехали!

Вот только некоторые косяки и риски, которые поджидают на пути создания мобильного приложения:

1. Вылетели из расписания и не успели выпустить приложение вовремя.
2. Описали техническое задание общими словами, без подробностей и конкретики. В итоге приложение получилось совсем не таким, каким вы его представляли.
3. Решили добавить новые функции, но потеряли задачу и забыли это сделать.
4. Захотели внедрить в дизайн приложения фирменный стиль компании, но обнаружили, что ни у кого нет исходников.
5. Подвела третья сторона.
6. Не смогли вовремя подготовить нужные материалы: фотографии, тексты, переводы. Срок затянулся ещё больше.
7. Когда приложение все-таки выпустили, выяснилось, что оно плохо работает из-за багов.
8. Сделали приложение, а оно не прошло модерацию в сторах.
9. Государство подкинуло сюрприз на законодательном уровне.

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

Как подстраховаться. Следите за ходом каждого этапа проекта, честно оценивайте сроки согласования.

Если у приложения сложная логика, то график работы сложно рассчитать с большой точностью. Грамотные менеджеры сами будут регулярно рассказывать вам о ходе разработки, показывать промежуточные результаты. Если этого не происходит — уточняйте, всё ли идет по графику. Чем скорее узнаете о задержках, тем скорее сможете принять меры: сдвигать дедлайн или сокращать объем работ, чтобы успеть в срок.

Честно оценивайте сроки согласования. Если в вашей компании важные документы и промежуточные результаты разработки согласовывают два директора и один айтишник — пусть так и будет. Согласование обычно занимает два месяца — закладывайте два месяца, до двух дней этот процесс сократить не получится.

Ситуация. Сделали макет — экран приложения, который появляется после того, как покупатель оформил заказ. Впопыхах написали «Какой-то текст». Разработчики приняли это как задачу. Заказчик неприятно удивился, пришлось снова согласовывать подробности и переделывать.

Как подстраховаться. Как написано на бумаге, так и будет реализовано. Поэтому установите правило: никаких общих формулировок. Уточняйте всё, что кажется непонятным или неточным.

С разработчиками вы подпишете договор на разработку. Специалисты будут писать техническую документацию:

• подробное техническое задание с указанием версий операционных систем;
• дизайн экранов и карта переходов;
• требования к API, полная документация с описанием рисков и возможных ошибок.

Если вы в эти документах чего-то не понимаете — не пускайте на самотек. Требуйте понятных формулировок и внятной структуры. Через год после релиза приложения техническая документация будет единственным надежным источником сведений об этом проекте.

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

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

Ситуация. В студии разработки уволился проджект-менеджер: назначили нового человека, и он решил продолжать работу не так, как раньше. Или ТЗ не было актуализировано. Или вы решили избавиться от какой-то функции, поменять уже согласованный дизайн.

Как подстраховаться. Договоритесь сразу: согласовывать все изменения. Важные моменты сразу вносить в договор. Если изменения на договор не влияют, достаточно описать их в электронном письме. Так ни одно принятое решение не потеряется.

Ситуация. Ваш менеджер оформил на себя доменное имя и все учетные записи. Выходит, приложение по закону принадлежит ему.

Как подстраховаться. Убедитесь, что в договоре на разработку прописано, кто владеет готовым продуктом разработки. Оформите на себя или свою компанию доменное имя приложения и учетные записи в App Store и Google Play. Выделите место на серверах компании или в облачных папках для рабочих материалов по проекту.

Ситуация. Готовое приложение загрузили в магазин, но модераторы отклоняют публикацию. Это случается, если содержимое приложения нарушает чьи-то авторские права, содержит запрещенную информацию или противоречит политике сторов.

Как подстраховаться. Заранее прочитайте правила публикации, изучите требования App Store или Google Play и убедитесь, что они соблюдаются. Если что-то просмотрели — модераторы пришлют сводку, которая подскажет, что нужно исправить.

Ситуация. Выпустили приложение, а оно тормозит и вылетает.

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

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

Как подстраховаться. Проверьте, что в договоре указано, в каком формате вам передадут результат. Исходные файлы дизайна, которые вам пригодятся в будущем, создаются в специальных программах, например Adobe Photoshop (файлы формата .psd) или Adobe Illustrator (.ai). Код разработчики обычно передают архивом.

Ситуация. Раньше персональные данные россиян можно было хранить где угодно. А с 2014 года по Федеральному закону № 152-ФЗ хранить персональные данные граждан Российской Федерации нужно в базах данных, которые находятся на территории РФ.

Как подстраховаться. К таким законодательным сюрпризам нельзя подготовиться заранее, — придется действовать по обстоятельствам. В случае с Федеральным законом № 152-ФЗ всем, кто имеет дело с персональными данными, пришлось срочно принимать меры, чтобы выполнить закон: переносить данные на сервера российских дата-центров или покупать в России собственные сервера.

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

1. Вы объективно оценили сроки и назначили дедлайн.
2. Вы точно знаете, что происходит с проектом: как идет разработка, какие есть сложности, что сделано, что будут делать.
3. Вам понятно всё, что написано в техническом задании. В макетах нарисовано и написано именно то, что потом пользователи увидят в приложении, а не «тут мы сделаем примерно так».
4. Техническое задание, график разработки и макеты поддерживаются в актуальном состоянии.
5. У вас есть генеральный подрядчик, который контролирует всех, кто завязан на проекте.
6. Вы фиксируете все договоренности по проекту в письменном виде.
7. У вас готовы все материалы: изображения, фотографии, тексты и тп.
8. Доменное имя и учетные записи в магазинах приложений заранее оформлены на вас или вашу компанию.
9. Дизайнер отдал вам исходники, разработчик передал код, после релиза в сторы.
10. Вы изучили современное законодательство и убедились, что в последнее время не приняли внезапных законов, которые отразятся на вашем бизнесе.
11. Берегите свои нервы проекты!

Авторы: Heads and Hands
Подписаться на email-курс "Как запустить мобильное приложение"

Узнавайте больше о проектах в канале @pmclub