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

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

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

  1. Вылетели из расписания и не успели выпустить приложение вовремя.

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

  3. Решили добавить новые функции, но потеряли задачу и забыли это сделать.

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

  5. Подвела третья сторона.

  6. Не смогли вовремя подготовить нужные материалы: фотографии, тексты, переводы. Срок затянулся ещё больше.

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

  8. Сделали приложение, а оно не прошло модерацию в сторах.

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

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

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

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

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

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

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

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

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

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

ХОЧЕШЬ БЫТЬ В ТЕМЕ?
Авторы подготовили бесплатный email-курс
"Как запустить мобильное приложение"

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

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

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

Как подстраховаться. Проверьте, что в договоре указано, в каком формате вам передадут результат. Исходные файлы дизайна, которые вам пригодятся в будущем, создаются в специальных программах, например Adobe Photoshop (файлы формата .psd) или Adobe Illustrator (.ai). Код разработчики обычно передают архивом.
9. Изменилось законодательство
Ситуация. Раньше персональные данные россиян можно было хранить где угодно. А с 2014 года по Федеральному закону № 152-ФЗ хранить персональные данные граждан Российской Федерации нужно в базах данных, которые находятся на территории РФ.

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

  1. Вы объективно оценили сроки и назначили дедлайн.

  2. Вы точно знаете, что происходит с проектом: как идет разработка, какие есть сложности, что сделано, что будут делать.

  3. Вам понятно всё, что написано в техническом задании. В макетах нарисовано и написано именно то, что потом пользователи увидят в приложении, а не «тут мы сделаем примерно так».

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

  5. У вас есть генеральный подрядчик, который контролирует всех, кто завязан на проекте.

  6. Вы фиксируете все договоренности по проекту в письменном виде.

  7. У вас готовы все материалы: изображения, фотографии, тексты и тп.

  8. Доменное имя и учетные записи в магазинах приложений заранее оформлены на вас или вашу компанию.

  9. Дизайнер отдал вам исходники, разработчик передал код, после релиза в сторы.

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

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

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

Хотите опубликовать статью?
Оставьте заявку здесь.
Онлайн-курс
Управление проектами с p3express
Скидки при предварительной регистрации
Made on
Tilda