Колонки

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

Колонки
Илья Фейгин
Илья Фейгин

основатель и технический директор WaveAccess

Ольга Лисина

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

WaveAccess уже более 20 лет не только разрабатывает ПО, но и консультирует по управлению сложными ИТ-проектами и помогает налаживать процессы. В этом цикле статей основатель и технический директор компании Илья Фейгин рассказывает, как управлять разработкой, чтобы даже самые сложные проекты всегда доводились до успешного завершения. 

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

Как вывести ИТ-продукт на рынок, несмотря ни на что. Часть 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

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Как применять методику Customer Development в IT. Реальный опыт
  2. 2 Эта методология поможет вам быстро и качественно разрабатывать IT-продукты. Как она работает?
RB в Telegram
Больше полезного контента в Telegram
Подписывайтесь!