Как развивать IT-продукт: практический опыт команды «Оптимакрос»

В основе успешного развития любого IT-продукта лежит правильно выстроенный процесс работы. За 6-7 лет продуктовая команда «Оптимакрос» обработала тысячи задач и выстроила эффективную систему развития продукта. Как это работает?

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

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

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

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

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

К внешним относятся оценки от клиентов, CSM-менеджеров (Customer success manager) и техподдержки. Внутренние приоритеты формируются продуктовым отделом. Каждая задача относится к определенному функциональному блоку, а за развитие каждого блока отвечает конкретный продуктовый менеджер. Например, если клиент запрашивает улучшение функции сортировки, ответственный за этот блок оценивает необходимость доработки, ее срочность и потенциальную пользу для других клиентов.

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

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

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

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

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

Интересно, что даже отсутствие обратной связи может быть показательным. «Если никто не пишет, что работает плохо, значит все хорошо» — это, конечно, шутка, но доля истины в ней есть.

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

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