Как IT-стартапу сохранить гибкость и человечность при масштабировании

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

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

Вести проекты в трекере задач

Трекер задач помогает фиксировать договорённости и расставлять приоритеты. В Яндекс Трекере можно собрать все задачи в одном месте, смотреть, кто за что отвечает и на каких этапах возникают задержки.

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

Разделять задачи между командами

В стартапе каждый отвечает за своё направление: маркетолог — за продвижение продукта, программист — за разработку, менеджер — за продажи. У всех разные рабочие процессы, и под каждый в Трекере можно выделить отдельное пространство — очередь. Как создавать очереди, читайте в Справке.

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

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

Пример. Разработчикам нужно, чтобы после код-ревью к работе подключался тестировщик:

1. В настройках очереди «Разработка» команда прописывает статусы, по которым будут двигаться задачи, например: «Открыто», «В работе», «Ревью», «Тестируется» и «Готово к релизу».
2. Затем настраивают триггер так, чтобы, когда задача переходит в статус «Тестируется», Трекер автоматически создавал задачу на тестирование и назначал исполнителем QA-инженера.

Задавать последовательность работ

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

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

Чтобы создать зависимость, в карточке задачи есть поле «Связать с задачей» и несколько типов связей. Нам интересны два:

• «Блокирует» — ставят в задаче, от выполнения которой зависит старт следующей;
• «Зависит от» — указывают в зависимой задаче.

Как это работает:

• В момент создания задачи на разработку фичи Трекер автоматически создаёт подзадачи: для маркетинга — на тексты для экранов и дизайна — на их отрисовку.

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

Следить за выполнением

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

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

Руководитель может следить за процессами на диаграмме Ганта. Например, он видит, что срок задачи программиста истёк, а она не закрыта. Понимает, что тот слишком загружен, и перераспределяет часть задач на других разработчиков. Связанные задачи запустятся с опозданием, но оно будет минимальным, и риск не успеть к релизу снизится.

Отслеживать определённые показатели или работу конкретных команд в Трекере можно на дашборде. Для этого нужно настроить виджеты — как это сделать, можно узнать в Справке.

По данным на дашборде можно понять, например:

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

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

Читайте также: «Фокус на главном: как в Яндекс Трекере создать дашборд с виджетами под свои задачи»

Вести базу знаний

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

Продумать структуру

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

Читайте также: «Как организовать базу знаний, чтобы она не превращалась в склад данных»

Распределить права доступа

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

Актуализировать данные

Чтобы база оставалась полезной, важно поддерживать актуальность данных. Самый быстрый способ — обсуждать изменения прямо на страницах. Если кто-то заметил ошибку или понимает, что процесс обновился, он оставляет комментарий: администратор видит его и вносит правку в документ. Изменения автоматически отобразятся у всех пользователей.

Кроме того, можно проводить:

• регулярные аудиты всех страниц — раз в квартал или год;
• точечные проверки разделов — если изменились процессы, например ввели новый порядок согласования дизайна.

Устаревшие документы лучше не удалять, а хранить в архивах. Они могут пригодиться, например, если нужно вспомнить результаты старого A/B или какие гипотезы уже отрабатывали. Чтобы добавить страницу в архив, её нужно пометить как устаревшую.