Как мы перестали дублировать рабочие задачи в Telegram и за три недели изменили подход команды
Привет! Меня зовут Антон Кабанов, я руководю отделом ИТ-разработки в компании "Фабрика творчества". Мы выпускаем товары для хобби, а моя команда помогает автоматизировать рутинные операции и упорядочивать внутренние процессы.
Парадоксально, но дольше всего порядок не удавалось навести именно в работе ИТ-отдела. Мы несколько раз внедряли таск-трекеры: создавали доски, распределяли задачи, назначали ответственных и переносили туда текущие проекты. Однако достаточно было кому-то написать в Telegram: "Срочно посмотри", - и уже через несколько минут обсуждение, файлы и решения снова оказывались в мессенджере.
Почему замена таск-трекера не помогала
Каждый раз мы считали, что проблема заключается в неудачном выборе сервиса. Мы пробовали разные решения, включая WEEEK и "Битрикс24", создавали новые доски и заново переносили задачи. Но спустя некоторое время ситуация повторялась.
Позже стало очевидно: мы пытались исправить не ту часть процесса. Сам по себе таск-трекер не меняет привычки сотрудников. Даже если перенести в него все задачи, люди продолжат пользоваться Telegram, если там быстрее задать вопрос или договориться о решении.
В результате рабочая информация расползалась по нескольким каналам. Часть решений находилась в задачах, часть - в личной переписке, а важные файлы приходилось искать среди сотен сообщений. У меня, например, накопилось больше 800 непрочитанных сообщений в Telegram.
Дополнительным стимулом стали перебои в работе мессенджера. Постоянно включать VPN, проверять, дошло ли сообщение и открылся ли файл, быстро надоело. Поэтому в феврале 2026 года мы решили повторить попытку, но на этот раз изменить не только инструмент, а прежде всего правила взаимодействия.
Главное правило: рабочее обсуждение живёт внутри задачи
После предыдущих экспериментов мы сформулировали простой критерий: обсуждение должно находиться там же, где сама задача. Для этого выбрали систему управления проектами YouGile.
Но одной смены сервиса было недостаточно. Команда всё ещё могла продолжать переписываться в Telegram, поэтому мы ввели жёсткое правило: все рабочие вопросы обсуждаются внутри соответствующей задачи.
Звучало это почти как "тоталитарный" режим. На практике правило было простым: если вопрос возник в Telegram, его нужно перенести в задачу и продолжить обсуждение там. Новичкам показывали, где создавать комментарии, как прикреплять файлы и каким образом отмечать коллег. Но само требование не пересматривали после каждого исключения.
Первым нарушил правило я сам. Мне срочно понадобилась информация, и я по привычке написал разработчику в мессенджере. В ответ получил короткую фразу: "Я всё написал тебе в YouGile".
Позже к одному из проектов подключились сотрудники производства в Раменском, и Telegram снова начал оживать. Мы несколько раз повторили одну и ту же установку: если появилась идея или предложение, их нужно зафиксировать в соответствующей задаче.
Что изменилось через три недели
Главный результат проявился довольно быстро: задача перестала быть просто строкой на доске и превратилась в полноценную историю работы. В одном месте теперь находились исходный запрос, уточнения, решения, файлы, ответственные и итог.
Не требовалось вспоминать, кто и когда прислал документ, искать формулировку среди личных сообщений или восстанавливать ход обсуждения по фрагментам переписки. Любой сотрудник, подключившийся к проекту позже, мог открыть задачу и понять её контекст.
Примерно через две-три недели новый порядок стал привычным. Telegram никуда не исчез: его продолжали использовать для неформального общения и быстрых организационных вопросов. Но рабочие решения перестали приниматься там. Если обсуждение начиналось в мессенджере, его переносили в нужную задачу.
Как мы организовали общую доску
После того как коммуникация собралась вокруг задач, возникла новая проблема: пятнадцати сотрудникам нужно было договориться о едином порядке работы внутри системы.
Сначала каждый создавал доски и колонки так, как считал удобным. Для личной работы этого хватало, но совместные проекты быстро столкнулись с разными трактовками статусов, сроков и приоритетов.
Мы сознательно не стали сразу проектировать идеальную структуру. Такая попытка могла привести к бесконечным обсуждениям и настройкам, тогда как работать требовалось уже сейчас.
Первым элементом общей доски стала не рабочая колонка, а небольшая база знаний. В ней описали базовые правила:
- как формулировать задачу;
- когда назначать исполнителя;
- где указывать ожидаемый результат;
- как прикладывать документы;
- что делать с незавершёнными вопросами;
- в какой момент переводить задачу на следующий этап.
Остальную структуру достраивали постепенно - по мере появления реальных сложностей. Такой подход оказался практичнее попытки заранее предусмотреть все возможные сценарии.
Разделение идей и готовых задач
Затем мы разделили поток работы на два этапа. Сырые идеи, запросы и проблемы не должны были смешиваться с задачами, которые уже можно передавать в разработку.
Для предварительной проработки появилась колонка "Цели". В неё попадали вопросы, требующие анализа и уточнения.
Например, бухгалтерии каждый день приходится скачивать отчёт из личного кабинета маркетплейса и вручную переносить данные в таблицу. Мы не создаём сразу задачу "автоматизировать отчёт". Сначала запрос попадает в "Цели". Там выясняем:
- какие именно операции выполняются вручную;
- сколько времени они занимают;
- можно ли использовать готовую интеграцию;
- есть ли ограничения у площадки;
- кто будет пользоваться результатом;
- насколько часто возникает проблема.
Только после этого появляется конкретная задача с понятным результатом и критериями готовности.
Почему важна формулировка результата
Раньше многие задачи выглядели как короткие поручения: "проверить", "сделать интеграцию", "посмотреть отчёт". Такие формулировки оставляли слишком много пространства для разных трактовок.
Теперь мы стараемся описывать не действие, а ожидаемый результат. Вместо "автоматизировать отчёт" формулируем задачу так: "настроить автоматическую загрузку отчёта маркетплейса в таблицу каждый день до 10:00".
Это сразу делает понятными границы работы, критерии проверки и итоговую пользу для заказчика.
Приоритеты без бесконечного "срочно"
Отдельно пришлось пересмотреть отношение к срочным запросам. Раньше новая задача могла появиться в любой момент, а её важность автоматически считалась высокой.
Теперь действует другое правило: если нужно взять новую задачу немедленно, инициатор должен показать, что ради неё следует отложить. Это не бюрократическое препятствие, а способ увидеть реальную стоимость переключения команды.
Когда приоритеты фиксируются явно, становится проще объяснить заказчику, почему работа начнётся не сегодня, а после завершения текущего этапа. Одновременно снижается количество скрытых срочных поручений, которые раньше просто терялись в переписке.
Что помогло внедрению
В нашем случае сработало сочетание нескольких условий:
1. Единое место для рабочего контекста. Не только задача, но и вся связанная с ней переписка находилась в одном пространстве.
2. Понятное обязательное правило. Не было нескольких равнозначных вариантов, где продолжать обсуждение.
3. Постепенная настройка. Мы не ждали идеальной системы и исправляли её по мере использования.
4. Общая база знаний. Новым сотрудникам не приходилось каждый раз объяснять правила устно.
5. Фиксация приоритетов. Срочная работа не появлялась из ниоткуда и не разрушала план без обсуждения.
Самое важное изменение произошло не в интерфейсе и не в названии выбранного сервиса. Команда перестала воспринимать таск-трекер как формальное место для отчётности. Он стал рабочим пространством, где сохраняется контекст и принимаются решения.
В итоге мы не отказались от мессенджера и не пытались контролировать каждое сообщение. Мы просто разделили назначение инструментов: Telegram остался каналом для обычного общения, а задачи и связанные с ними обсуждения получили собственное устойчивое место. Именно это, а не очередная смена сервиса, помогло изменить процесс.
