Как вывести ИТ-продукт на рынок: интеграция систем, проектная команда, roadmap
Связь между системами: что предусмотреть для грамотной системной интеграции
Возможно, вы создаете продукт для внутреннего использования и сами решаете, с какими системами его интегрировать. Может быть, у вашего ИТ-продукта есть потенциальные покупатели, для которых решающим фактором приобретения подписки будет поддержка интеграции с конкретными системами. Разрабатываемое вами решение все равно будет интегрировано с другими информационными системами, поэтому чем раньше вы решите этот вопрос, тем лучше.
Проясните, какие данные будут экспортироваться и импортироваться в вашу систему и из нее. Вот краткий список пунктов на проверку:
- Выясните, интеграция с какими системами потребуется.
- Выясните, будут ли эти интеграции синхронизировать данные в одном направлении или в обоих и какие именно это данные (здесь потребуется маппинг — отображение связей между сущностями как во внешней, так и в разрабатываемой системе).
- Выясните, какие меры предусмотрены для синхронизации данных на случай, если в какой-то точке между двумя системами данные окажутся неполными.
- Убедитесь, что есть доступ в тестовое окружение, в котором инсталлированы эти системы.
- Убедитесь, что API для интеграции с этими системами известно.
Связь между людьми: формирование проектной команды и ее численность
Как проекты, так и проектные команды по размеру могут быть разными. Команда разработки может состоять из юнитов: один юнит работает над поставкой фич, другие — над реализацией.
Состав ролей напрямую зависит от типа разработки (продуктовая или проектная) и требований, предъявляемых к реализации и методологии (например, SCRUM-разработка, проект с фиксированной ценой). На наш взгляд, оптимальное число людей в одной продуктовой команде — от трех до девяти. Если людей больше, рекомендуем делить группу на меньшие команды.
Команда проекта может содержать следующие роли (мы не говорим о количестве людей на каждой роли, поэтому используем названия ролей в единственном числе):
- Менеджер продукта.
- Проектный менеджер.
- SCRUM-мастер.
- Бизнес-аналитик / системный аналитик.
- DevOps-специалист.
- Архитектор.
- Техлид.
- Разработчик.
- Тестировщик.
- Дизайнер.
- Технический писатель.
Вовлеченных людей может быть меньше по количеству, но должна быть ясность относительно того, кто какие роли исполняет. Все эти роли должны быть четко распределены между членами команды.
Связь между этапами проекта: дорожная карта и метрики
Менеджер проекта — капитан корабля. Этот человек должен ясно понимать, куда ведет проектную команду, и владеть инструментами, необходимыми для определения параметров движения, чтобы вовремя отреагировать, если какой-то из параметров начинает вызывать вопросы.
Вот что поможет грамотно вести «корабль»:
- Убедитесь, что бюджет на разработку утвержден.
- Убедитесь, что есть определение проекта (оно же — устав проекта, project charter), в котором описаны все правила и ограничения, включая матрицу коммуникаций.
- Убедитесь, что есть дорожная карта проекта (roadmap).
- Убедитесь, что в проекте обозначены контрольные точки (milestones), по которым указаны конкретные даты, а не только планируемые затраты человеко-часов.
- Убедитесь, что менеджер проекта понимает ограничения по бюджету, срокам и задачам, запланированным в ресурсах проекта (project scope).
- Ежедневно узнавайте, сколько фичей команда внедрила с момента последнего релиза (контрольной точки).
- Узнавайте, сколько фичей команде необходимо внедрить к следующему релизу.
- Рассчитайте скорость команды с точки зрения внедренных фичей.
- Проверьте ситуацию с багами: сколько их, насколько они серьезные, повторяются ли они.
- Убедитесь, что после каждого спринта проектный менеджер или даже разработчики проводят показ добавленной в этом спринте функциональности. После каждой такой демонстрации сразу видно, есть ли прогресс. Чем больше команда, тем чаще вы рискуете обнаружить, что отдельные участники, а то и целые подкоманды ничего не сделали за спринт. Выясните причину и перенастройте неэффективные процессы.
- Убедитесь, что проводятся ретроспективы спринтов (исследование спринта, сбор данных о том, как прошел этот этап). Убедитесь, что исполнитель зафиксировал все обсуждения и решения с вами и своей командой.
- Убедитесь, что поддерживается актуальная документация проекта/продукта. Убедитесь, что есть план управления рисками (риски выявлены и минимизированы).
На какие метрики нужно все время обращать внимание
- Сколько часов есть в запасе на выполнение запланированных работ.
- График сгорания задач (burndown rate): сколько задач готово, сколько осталось сделать до релиза или до конца текущего спринта. Он покажет и соответствие рамкам бюджета.
- Отношение актуального бюджета к запланированному. Если коэффициент не превышает единицы, то проект в перспективе, скорее всего, останется в рамках бюджета.
- Какую часть времени тестирование, дизайн, аналитика занимают в проекте в соотношении с разработкой.
- Количество багов на единицу функциональности.
- Процент использования вовлеченных ресурсов.
