«Набирайте команду постепенно, ориентируйтесь на метрики, всё документируйте» — главное из доклада IT-руководителя KAMAZ Digital о том, как организовать работу продуктовых команд

Понравился доклад эксперта на стыке IT и бизнес-аналитики, который работал над проектами для Шереметьево, РЖД, Ренессанс Страхования. Посмотрел за вас и сделал выжимку самого главного.

Иногда слежу за Teamly, отечественной платформой по управлению знаниями. Недавно у них прошла конфа, и мне понравился один из докладов — вот его версия в моей редакции.

Далее текст от лица спикера.

Меня зовут Никита Зыликов, я руководитель направления аналитики и методологии бизнес-процессов в компании KAMAZ Digital, внешнем акселераторе цифровых решений и стартапов КАМАЗа. Ту же должность занимаю в NATCAR — логистическом партнёре с 80+ клиентов по всей России.

Поделюсь своим опытом и практическими советами по организации работы продуктовых команд.

Я начинал свой путь в транспортной сфере, работая в аэропортах Домодедово и Шереметьево — для последнего спроектировал бизнес-процессы в новом терминале. В то время мы определяли, куда двигаться дальше: строить третью полосу, залезая в лес или расширяя существующие полосы, зачем нужны новые терминалы, как работать с Аэрофлотом, как обеспечить перемещение пассажиров и багажа между терминалами за 10 минут. Это было время, когда бизнес-аналитика выходила на первый план, а автоматизация становилась необходимостью.

Бизнес-аналитики в то время писали функциональные требования, которые потом превращались в технические задания. Однако часто разработчики не понимали, что именно требуется. Я понял, что нужно развиваться в сфере IT, чтобы понимать обе стороны и эффективно объяснять разработчикам, что нужно заказчику.

Также у меня было много проектов в insure tech. Например, в компании Ренессанс Страхование, которая сейчас является одним из лидеров отрасли.

Разработал и внедрил «Цифровую железнодорожную станцию» для РЖД, где автоматизация оказалась чуть ли не бесконечным процессом. Работа над этим проектом была вызовом, так как железнодорожники привыкли работать по своим устоявшимся правилам. Автоматизация процессов была сложной задачей, но благодаря усилиям команды проект удался. Мы внедрили систему, которая значительно улучшила работу станций, но процесс автоматизации продолжается — это сверхзадача, ведь сам процесс масштабный и нескончаемый.

Команда – это ключевой ресурс. На рынке IT в России сейчас дефицит кадров. Курсы от SkillFactory и Skillbox помогают, но новичкам все равно нужна практика.

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

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

Объясняйте, зачем всё это. Также важно донести до команды ценность продукта и цели его создания. Это повысит мотивацию и эффективность работы. Когда команда понимает, почему ее работа важна, она будет более вовлечена и замотивирована.

Часто проект начинают с конца, забывая про основы. Важно оценить ресурсы, данные и инфраструктуру.

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

Необходимость начинать с основ хорошо иллюстрирует пример со строительством дома. Мы спроектировали красивый дом и спланировали жизнь в нем, начали строить — а дом «поехал», потому что строить на такой земле нельзя. Прежде чем переходить к разработке, нужно начинать с проверки доступности данных и инфраструктуры.

Когда заказчики не понимают, что происходит, они злятся. В одном из проектов я столкнулся с ситуацией, когда предыдущий руководитель строил систему, довольно закрытую от заказчиков. Это вызывало недовольство: заказчики не понимали, что происходит. Мы изменили подход и стали показывать даже минимальные результаты работы. Это помогло улучшить отношения и снизить напряжение.

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

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

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

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

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

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

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

Живое общение с целевым сегментом позволяет проверить ценностное предложение и получить важные инсайты.

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

Когда мы выбирали платформу для корпоративной базы знаний, то смотрели на удобство интерфейса, возможность совместной работы и доступ с мобильных устройств. В процессе получили множество предложений, не соответствующих нашим требованиям. Выбрали Teamly, которая на 99% соответствовала нашим нуждам.

Полный доклад и остальные доклады конференции Teamly 2024 на Ютубе:

В телеграм-каналье делюсь опытом, как делаю сайты, кейсы, статьи и другие информационные продукты.

А вот канал Teamly о том, как эффективно управлять знаниями.