Как вывести ИТ-продукт на рынок, несмотря ни на что. Часть 1: Готовим основу (MVP, инфраструктура, прототип)

Готовим основу для вывода на рынок: MVP (минимально жизнеспособный продукт)  

Несмотря на то что agile-разработка ассоциируется с уменьшенной бумажной работой и гибким подходом к планированию, перед началом проекта необходимо не только техническое задание. Нужно согласовать объем задач для разработки MVP, то есть определить, какое количество пользовательских сценариев следует разработать к первому «живому» релизу приложения, — тот базовый минимум, который и представляет собой бизнес-ценность решения.

Проект на начальном этапе может выглядеть как хаотичное изложение идей и задач, которое зафиксировано в Word, Excel и приложении «Записки». Из этого хаоса рождается немногим более упорядоченный, но при этом весьма объемный список пользовательских сценариев, которые хочется когда-нибудь увидеть в готовом приложении. К каждому спринту из этого списка берется в работу некоторое число задач.

Это выглядит как гибкий процесс управления ИТ-проектами, однако в этом подходе есть риск: никто на проекте не будет знать, как должно будет в результате выглядеть приложение.  

Joyseulay/Shutterstock

Чтобы этот хаос оформился в проект, как раз и требуется согласовать список функций для поставки к ближайшему релизу. Зафиксировать эти требования следует в доступном инструменте (например, Jira, Confluence, Basecamp, Redmine). Позже в этот план могут вноситься корректировки, однако начинать проект нужно с согласования объема работ для MVP — это лучшая практика.

Также на этапе работы с требованиями следует прояснить, как именно конечный продукт будет продаваться: будут это лицензии, триал-версии или что-то еще (так как вашей ИТ-команде предстоит создавать их).

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

Готовим основу для исполнения (хостинга) решения: когда и как продумывать инфраструктуру 

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

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

Какие моменты мы рекомендуем прояснить на этом этапе: 

• Планирует ли заказчик использовать собственную инфраструктуру для исполнения решения. Все ли оборудование имеется и учтены ли затраты на него. Каков прогноз производительности, масштабируемости и отказоустойчивости. 
• Если заказчик планирует выкладывать будущее решение для исполнения в облаке, то закуплены ли лицензии. 
• Понимает ли заказчик, сколько окружений потребуется, согласен ли с этим. 
• Есть ли у вашей команды разработки доступ ко всем необходимым окружениям. 
• Если ваше будущее решение работает с личными и тем более медицинскими данными (то есть если на ваш проект распространяются дополнительные требования закона) — убедитесь, что все используемые вами библиотеки, стороннее и прочее ПО этим требованиям отвечают.  
• Попросите DevOps-специалиста сконфигурировать CI/CD (continuous integration и continuous delivery — непрерывную разработку и поставку ПО), зафиксировать политику безопасности и продумать план выхода из внештатных ситуаций. Да, пункт объемный и потребует времени. Но уверенность в том, что вы здесь и сейчас располагаете рабочим и качественным кодом, необходима.  
• Убедитесь, что у команды DevOps есть продуманная стратегия мониторинга, что для проверки доступности сервисов они располагают инструментарием (например, Prometheus) и что им доступны другие сервисы. Скажем, Grafana для визуализации состояния приложения в реальном времени позволит реагировать на критически важные проблемы. Убедитесь также, что метрики использования ресурсов приложением доступны и сконфигурированы. 

Готовим основу для визуализации решения: как ускорить согласование дизайна  

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

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

Чтобы гармонизировать взаимодействие команды дизайна с командами разработчиков, убедитесь, что:

• У всех членов команды на стороне заказчика и исполнителя (включая дизайнеров, разработчиков, QA, PM, аналитиков) есть доступ к файлам с дизайном. Figma или Sketch в связке с Zeplin, а также InVision Studio позволят разработать интерфейс, быстро поделиться результатом и оперативно получить обратную связь. 
• Учтены все пользовательские сценарии, а дизайн не нарушает бизнес-логику приложения — совместно с бизнес-аналитиком проекта. 
• Созданный дизайн экранов возможно реализовать — совместно с техническим лидом команды.
• Разработанный UX не противоречит требованиям и гайдлайнам мобильных ОС (iOS, Material) — при мобильной разработке.
• Лица, принимающие решения, одобрили дизайн основных экранов.
• Для всех интерфейсов готов UI Guide — рекомендации по разработке интерфейса, а команды дизайна и разработки имеют общее видение проекта. 
• У дизайнера все готово: 
• есть дизайн для всех экранов во всех состояниях;
• если содержимого (текста, картинок) на экранах нет, они все равно выглядят аккуратно; 
• в случае ошибки, соответствующее сообщение в явном виде выводится на экран;
• названия кнопок хорошо выглядят и помещаются на кнопках на всех языках.

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

В следующей части нашего гайда по управлению ИТ-проектами коснемся не менее важной части работы — «полезных связей». Обсудим интеграцию ИТ-систем, а также поговорим о ролях в команде и дорожной карте проекта. А в последней части мы разберемся в том, как проверить проект на прочность.

Фото на обложке: Joyseulay/Shutterstock