Колонки

Как вывести ИТ-продукт на рынок, несмотря ни на что. Часть 2: Полезные связи

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

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

Дарья Мызникова

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

Как вывести ИТ-продукт на рынок, несмотря ни на что. Часть 2: Полезные связи
Присоединиться

Связь между системами: что предусмотреть для грамотной системной интеграции

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

Проясните, какие данные будут экспортироваться и импортироваться в вашу систему и из нее. Вот краткий список пунктов на проверку:

  • Выясните, интеграция с какими системами потребуется. 
  • Выясните, будут ли эти интеграции синхронизировать данные в одном направлении или в обоих и какие именно это данные (здесь потребуется маппинг — отображение связей между сущностями как во внешней, так и в разрабатываемой системе). 
  • Выясните, какие меры предусмотрены для синхронизации данных на случай, если в какой-то точке между двумя системами данные окажутся неполными. 
  • Убедитесь, что есть доступ в тестовое окружение, в котором инсталлированы эти системы. 
  • Убедитесь, что API для интеграции с этими системами известно.  

Связь между людьми: формирование проектной команды и ее численность   

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

Состав ролей напрямую зависит от типа разработки (продуктовая или проектная) и требований, предъявляемых к реализации и методологии (например, SCRUM-разработка, проект с фиксированной ценой).

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

Команда проекта может содержать следующие роли (мы не говорим о количестве людей на каждой роли, поэтому используем названия ролей в единственном числе):  

  1. Менеджер продукта.
  2. Проектный менеджер.
  3. SCRUM-мастер. 
  4. Бизнес-аналитик / системный аналитик.
  5. DevOps-специалист.
  6. Архитектор.
  7. Техлид.
  8. Разработчик.
  9. Тестировщик.
  10. Дизайнер.
  11. Технический писатель.

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

RB.RU рекомендует лучших поставщиков цифровых решений для вашего бизнеса — по ссылке

Связь между этапами проекта: дорожная карта и метрики

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

Вот что поможет грамотно вести «корабль»:  

  • Убедитесь, что бюджет на разработку утвержден. 
  • Убедитесь, что есть определение проекта (оно же — устав проекта, project charter), в котором описаны все правила и ограничения, включая матрицу коммуникаций.
  • Убедитесь, что есть дорожная карта проекта (roadmap). 
  • Убедитесь, что в проекте обозначены контрольные точки (milestones), по которым указаны конкретные даты, а не только планируемые затраты человеко-часов. 
  • Убедитесь, что менеджер проекта понимает ограничения по бюджету, срокам и задачам, запланированным в ресурсах проекта (project scope).
  • Ежедневно узнавайте, сколько фичей команда внедрила с момента последнего релиза (контрольной точки). 
  • Узнавайте, сколько фичей команде необходимо внедрить к следующему релизу. 
  • Рассчитайте скорость команды с точки зрения внедренных фичей. 
  • Проверьте ситуацию с багами: сколько их, насколько они серьезные, повторяются ли они. 
  • Убедитесь, что после каждого спринта проектный менеджер или даже разработчики проводят показ добавленной в этом спринте функциональности. После каждой такой демонстрации сразу видно, есть ли прогресс. Чем больше команда, тем чаще вы рискуете обнаружить, что отдельные участники, а то и целые подкоманды ничего не сделали за спринт. Выясните причину и перенастройте неэффективные процессы.
  • Убедитесь, что проводятся ретроспективы спринтов (исследование спринта, сбор данных о том, как прошел этот этап). 
  • Убедитесь, что исполнитель зафиксировал все обсуждения и решения с вами и своей командой. 
  • Убедитесь, что поддерживается актуальная документация проекта/продукта. 
  • Убедитесь, что есть план управления рисками (риски выявлены и минимизированы).

На какие метрики нужно все время обращать внимание

  • Сколько часов есть в запасе на выполнение запланированных работ. 
  • График сгорания задач (burndown rate): сколько задач готово, сколько осталось сделать до релиза или до конца текущего спринта. Он покажет и соответствие рамкам бюджета. 
  • Отношение актуального бюджета к запланированному. Если коэффициент не превышает единицы, то проект в перспективе, скорее всего, останется в рамках бюджета. 
  • Какую часть времени тестирование, дизайн, аналитика занимают в проекте в соотношении с разработкой. 
  • Количество багов на единицу функциональности. 
  • Процент использования вовлеченных ресурсов. 

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

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

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

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

  1. 1 Как вывести ИТ-продукт на рынок, несмотря ни на что. Часть 1: Готовим основу (MVP, инфраструктура, прототип)
  2. 2 Как создать IT-продукт для малого и среднего бизнеса в сфере, где всё заточено под корпорации
  3. 3 Цифровой проект в крупной компании: 11 важнейших действий, которые надо выполнить на старте
AgroCode Hub
Последние новости, актуальные события и нетворкинг в AgroTech-комьюнити — AgroCode Hub
Присоединяйся!