Один для всех: как использовать один таск-трекер для всех производственных команд

Продакт‑менеджер отвечает за жизненный цикл продукта и выстраивает взаимодействие между всеми участниками этого процесса: разработчиками, проектировщиками, дизайнерами, UX‑писателями, продуктовыми маркетологами и другими специалистами. Он формулирует требования, ставит задачи каждой команде, согласовывает сроки и ресурсы, контролирует прогресс. Фактически продакт обеспечивает выпуск продукта, координируя работу разных отделов.

О том, как продакт-менеджер может использовать в своей работе таск-трекер и как этот инструмент может объединить работу всех команд, участвующих в создании ИТ-решений, рассказывает Екатерина Шеленкова, заместитель директора по продукту Битрикс24.

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

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

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

Сам продакт может работать с задачами в таск-трекере в любом удобном ему представлении. Наши менеджеры чаще используют либо простой список, либо «Мой план» — аналог канбан-доски в Битрикс24, где можно создавать собственные стадии для задач, а также визуально распределять их по разным командам, по исполнителям и другим критериям. Например, использовать отдельные колонки или цвета для задач отдела разработки, дизайна, маркетинга и др. И что самое важное для разработки ИТ-продуктов — распределять задачи по срокам исполнения, по приоритетам: что-то передавать в работу срочно, а что-то отложить в колонку, из которой в дальнейшем сформируется бэклог для разработки.

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

Значительная часть работы продакт‑менеджера связана с взаимодействием с отделом разработки, который работает по методологии Scrum. В рамках этого подхода продакт аккумулирует в бэклоге продукта все идеи и задачи: текущие, запланированные на ближайшие спринты и перспективные. Затем систематически актуализирует и приоритезирует его: вносит новые идеи, корректирует приоритеты и передаёт задачи в работу.

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

На основе этих описаний происходит приоритезация элементов бэклога. Затем продакт совместно с командой разработки отбирает задачи для включения в спринт, декомпозирует их на более мелкие подзадачи, а затем запускается стандартный цикл разработки в рамках Scrum‑подхода.

Разработка интерфейсов и создание дизайна — это поток творческих задач, которые далеко не всегда удается свести к типовым решениям. Однако даже их можно уложить в одно русло. Наши проектировщики используют для этого Битрикс24 Потоки – инструмент для управления задачами, которые стоят перед конкретным отделом

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

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

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

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

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

Задача продакта — объединить все процессы и результаты в одном «полотне», иметь общую картину проекта, понимать, на какой стадии работы находится каждый отдел, вовремя передать результаты от одной команды другой.

Если в компании каждый отдел использует собственный таск-трекер, потому что выбрал для себя конкретную методологию работы с задачами, то продакту придется коммуницировать с каждой командой по-отдельности: с разработчиками в таск-трекере, который поддерживает Scrum, с проектировщиками в — в приложении с удобной канбан-доской, с маркетологами — в несложном таск-трекере, который работает со списками задач. Это означает, что задачи придется вручную переносить из приложения в приложение. Это сложно, долго и рискованно: чем больше ручной работы, тем выше риск ошибок, потери информации. А кроме того, у продакта теряется общая картина проекта, он не может быстро отслеживать, на какой стадии разработка, есть ли запас времени у проектировщиков или UX-авторов, как быстро будет готова тестовая версия для маркетологов.

В идеале инструмент для работы с задачами должен быть единым для всех команд, но при этом поддерживать разные методологии работы, разные способы отображения задач. У нас в компании процесс выглядит так: продакт ставит задачу в своем интерфейсе, назначает ответственных из нужной команды, а они уже видят ее у себя так, как им удобно — в Scrum, в Битрикс24 Потоке, на канбан-доске или просто в списке. Это одна и та же задача — и для постановщика, и для исполнителя. Но процесс работы с ней каждый настраивает по-своему.

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

одного сервиса, а затем переносить их в другой.

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