Когда-то таск-трекер был софтом, куда рядовой сотрудник заходил только по большой необходимости и обычно сразу жалел об этом. Там жили баги, спринты, релизы, эпики и статусы разработчиков, которые нельзя было понять без отдельной встречи. Однако за последние годы трекеры заметно изменились — в них переехали найм, согласования, закупки, дизайн, офисные заявки и вообще все то, что раньше «расползалось» по чатам, таблицам, почте и устным договоренностям.
Мы поговорили с Данилом Майорским, Product Lead-ом направления Трекер, Вики и Формы в «Яндекс 360», о том, почему современный трекер больше не может быть только «для айтишников», зачем компании нужна гибкость в управлении задачами и как ИИ поменяет рынок трекеров задач.
— Многие решения для управления задачами пересекаются функционально, но отличаются подходом к UX/UI. Какие тенденции вы видите сегодня в сегменте таск-трекеров? Что важно для современного пользователя?
Главный сдвиг в том, что пользователь хочет сам выбирать, как смотреть на свои данные. Менеджер открывает диаграмму Ганта, разработчик работает с канбан-доской, руководитель смотрит сводный дашборд, и если трекер навязывает только один способ отображения задач, он быстро теряет половину аудитории.
Второй важный момент — скорость. Люди привыкли к отзывчивости мессенджеров, поэтому, если создание задачи требует десяти обязательных действий и пяти кликов, это провал. Типовые действия должны занимать минимум шагов.
Третье — трекер задач должен быть понятен человеку, который никогда не слышал слово «эпик», потому что сейчас в нем сидят не только разработчики, но и HR, юристы, маркетологи.
И наконец, контекст должен быть под рукой. Пользователь не хочет прыгать между интерфейсами сервисов в поисках связанной документации или истории обсуждений. Все должно быть видно прямо из карточки задачи или связанных тикетов.
— Как изменилась роль трекеров задач за последние 3–5 лет — действительно ли пройден путь от инструмента «для айтишников» до инструмента для самых разных департаментов? И что стало главным драйвером этих изменений?
Раньше трекеры действительно были территорией разработки — там жили спринты, баги, релизы, и остальные отделы туда не заходили. Сдвиг произошел, когда компании поняли, что HR ведет найм в экселе, маркетинг планирует запуски в Яндекс Документах, а юристы трекают согласования в почте — и все это никак не связано между собой. Компания одна, а процессы живут параллельной жизнью.
Главными драйверами стали ковид и удаленка, ведь когда нельзя подойти к коллеге и спросить «ну что там по моей задаче?», нужен инструмент, где видно статус любого процесса. А уход западных решений в 2022-м дал второй толчок — компании, вынужденные мигрировать, заодно пересмотрели подход и начали заводить в трекер сразу все подразделения, а не только ИТ.
Сейчас для нас типичный клиент — это компания, где в одном трекере живут и спринты разработки, и онбординг сотрудников, и заявки на закупку растений в офис. Например, недавно я в Яндексе сообщил об отсутствии мыла в диспенсере через камеру смартфона, навел ее на QR-код и в открывшейся Яндекс Форме описал проблему одним предложением. Трекер сам создал тикет, подтянул правильную локацию и мгновенно поставил задачу дежурному сотруднику АХО. Аналогично это работает для любых офисных задач — от неполадок в переговорке до проблем с кофемашиной.
— То есть не согласны со стереотипом, что Трекер больше подходит для разработчиков и дизайнеров, или АХО в него не пересадить?
Это было справедливо несколько лет назад, но сейчас уже нет — мы целенаправленно работаем над тем, чтобы Трекер был удобен для нетехнических команд. Например, у нас есть шаблоны рабочих областей с простыми бизнес-процессами, где АХО ведет заявки на ремонт или закупку — создал задачу, прикрепил фото, назначил исполнителя, все.
Дизайнеры у нас внутри Яндекса, кстати, прекрасно живут в Трекере — им важны визуальные вложения, связки с другими задачами и понятные дедлайны, а не Scrum-терминология. Стереотип держится потому, что компании часто настраивают трекер «как для разработки» и ожидают, что бухгалтерия сама разберется — не разберется, но это вопрос настройки и онбординга, а не ограничений продукта.
— Кстати о скраме. Agile-методологии сейчас многими критикуются. Scrum-мастера становятся профессией из прошлого. Трекер как-то настраивается под новые подходы работы с командами и проектами? Будет ли он удобен бирюзовым командам?
Мы сознательно не привязываем Трекер к одной методологии. Он не заставляет вас жить по Scrum и не требует заводить спринты, если они вам не нужны. Хотите канбан без ролей и церемоний — пожалуйста, хотите свободный поток задач, где команда сама решает, кто что берет — это тоже нормально настраивается.
Кроме того, для бирюзовых команд как раз важна гибкость. Нет жесткой иерархии, нет навязанного процесса, есть прозрачность — кто над чем работает, где затык, что в приоритете. Трекер эту боль закрывает, потому что он структурирует информацию, а что касается критики Scrum, мы видим, что команды все чаще берут из разных подходов то, что работает именно для них, и нам важно этому не мешать, а поддерживать.
— Есть ли универсальные ошибки, которые совершают компании при внедрении таск-трекеров? Что мешает трекеру жить в команде, а не оставаться пустым репозиторием задач?
Ошибка номер один — попытка сразу зарегулировать все, например, придумать кучу обязательных полей и статусов задач, создать строгие регламенты на каждый шаг. Команда смотрит на это, понимает, что создать задачу сложнее, чем ее выполнить, — и уходит обратно в чаты и заметки.
Вторая классика — внедрить трекер «сверху» без объяснения, зачем он нужен конкретному сотруднику. Если человек не видит пользы для себя лично — он будет саботировать процесс.
И третья вещь, которая убивает трекер, — это когда руководство само в нем не работает, ставит задачи в мессенджере, спрашивает статусы на созвонах, а трекер существует просто для отчетности. Команда считывает, что это формальность, и трекер превращается в кладбище задач, куда заходят раз в неделю перед статус-митингом.
— Какие стратегии вы находите успешными в борьбе с «темными уголками» работы, которые остаются вне трекера (чаты, бумажные записи, устные договоренности)?
Думаю, полностью победить это невозможно, да и не нужно пытаться. Лучше сделать так, чтобы занести задачу в трекер было проще, чем написать в чат. Пример с QR-кодом как раз про это.
Второй рабочий прием — договориться в команде о простом правиле: «Если задачи нет в трекере, она не существует». Главное, чтобы руководитель сам его соблюдал, а не продолжал спрашивать статусы голосом на созвонах.
Кстати, из задачи Трекера можно в один клик создать чат в Яндекс Мессенджере. Все участники задачи будут автоматически добавлены в собеседники чата. Кроме того, ссылка на чат будет прилинкована к задаче.
— Какие тренды в области управления задачами и командами вам кажутся важными в ближайшие 2–3 года? ИИ-ассистенты или новые форматы визуализации?
Сейчас большинство реализаций ИИ в трекерах — это скорее что-то формата «суммаризируй обсуждение» или «составь описание задачи», но реальная ценность появится, когда ИИ начнет подсказывать. Например, «эта задача, скорее всего, не уложится в срок, потому что исполнитель перегружен» или «похожую задачу три месяца назад решала другая команда — вот как они это сделали».
По визуализации я вижу движение в сторону адаптивных представлений, когда система сама предлагает нужный вид:
- менеджеру показывает дашборд с рисками или дедлайнами;
- исполнителю — его личный список задач на сегодня, без ручных переключений.
Но тут еще вопрос, насколько такой дашборд станет привычным для пользователей.
И третий тренд — стирание границы между трекером и коммуникацией. Не «обсудили в чате, потом зафиксировали в трекере», а единый поток, где решение, задача и контекст живут вместе.
— Верите ли вы в сценарий, где Трекер сам ведет процессы, скажем, с использованием ИИ-агентов и подсказывает, как их улучшить, а не просто фиксирует задачи?
Верю, и частично это уже работает, например, автоматические триггеры, которые двигают задачу по статусам, назначают согласующего или эскалируют просроченное. Это по сути зачатки своего рода «самоуправляемого» трекера.
Следующий шаг — когда ИИ-агент анализирует паттерны. Видит, что задачи определенного типа стабильно застревают на этапе согласования, и предлагает конкретное изменение процесса — убрать лишнего аппрувера или разбить этап на два.
Но я реалист и считаю, что полностью автономный трекер, который сам управляет процессами без человека — это утопия, и команды к этому не готовы, да и не нужно это. В ближайшие годы ИИ будет «умным советником», который говорит: «Смотри, вот тут у тебя узкое место, вот данные, вот варианты», а решение принимает человек.
— Трекер часто сравнивают с Jira в плане технологичности, уровня возможностей для кастомизации, но и в плане нетривиальности работы с ним и его настройки. Как думаете, Яндекс Трекер — действительно русская Jira или аналогия неверна?
Эту аналогию я слышу нередко, и она понятна — оба продукта мощные, оба умеют в сложные воркфлоу и глубокую кастомизацию, оба рассчитаны на масштаб. Но компаниям важно понимать, что Jira как продукт фактически заморожена для российского рынка — без обновлений, без поддержки. По сути, компании все свои бизнес-процессы и задачи делегируют в продукт, который уже принял решение не присутствовать на рынке. Вероятность столкнуться с ситуацией, когда процессы и задачи зависнут где-то во внешнем контуре, к которому нет доступа, становится чрезвычайно высока.
Мы со своей стороны активно улучшаем Трекер: упрощаем и адаптируем его под небольшие команды, чтобы они могли сразу начать работать, без чтения длинных инструкций и прохождения обучающих курсов. В то же время наращиваем возможности кастомизации для энтерпрайза, где нужны сложные автоматизации и интеграции.
Мы изначально строили Трекер как часть экосистемы — Вики и Формы интегрированы очень нативно, также есть интеграции с Яндекс Мессенджером, Календарём, Почтой, да и тот же DataLens рядом, не нужно искать правильный плагин из пятисот и молиться, что он совместим с твоей версией.
Так что я бы сказал, что мы не «российская Jira», мы — продукт, который взял лучшее от enterprise-подхода, но не собирается повторять ошибки, которые сделали Jira синонимом слова «сложно».
— Вся деятельность компаний порой завязана на тикеты, макросы и триггеры в их Трекере. Как митигируете риски того, что в какой-то момент из-за сбоя Трекер может быть недоступен и компании лишатся доступа к своим проектам-процессам?
Трекер — критичная для многих клиентов инфраструктура, потому что содержит в себе не просто набор тикетов и задач, а замыкает на себя процессы и обсуждения в компаниях. Наша базовая защита — это максимальное резервирование архитектуры.
Мы работаем на инфраструктуре Yandex Cloud, а это георезервирование в плане расположения дата-центров, резервное копирование, SLA по доступности — все то, что Яндекс строил годами для собственных сервисов с миллионами пользователей. Ну и плюс регулярные учения, где мы отрабатываем регламенты и внештатные ситуации.
Лучшая иллюстрация надежности — то, что Яндекс как компания полностью живет в Трекере. Мы доверяем продукту все процессы и задачи всех команд, и у нас есть прямая мотивация обеспечивать его бесперебойную работу.