Упущенные задачи – это не проблема людей
Почему упущенные задачи в управлении проектами – не вопрос дисциплины или памяти, и когда команде нужна система для их отслеживания.
By Ellis Keane · 2026-03-17
Если ваша команда настолько мала, что все могут вместе пообедать (или, по крайней мере, теоретически, если бы когда-нибудь оказались в одном городе одновременно), вам, вероятно, не нужно это читать. Закройте вкладку. Идите и создавайте что-нибудь. Проблема упущенных задач в вашем масштабе решается одним напоминанием в Slack в среду днём – и я говорю это совершенно искренне.
Всё ещё здесь? Хорошо, тогда поговорим об упущенных задачах в управлении проектами – и конкретно о том, почему стандартные советы перестают работать, когда команда достигает определённого размера.
Прежде чем мы продолжим
Мы создаём инструмент, решающий эту проблему (Sugarbug – не буду притворяться, что это не так), но честный ответ таков: большинству команд, читающих это, не нужно то, что мы строим. Ещё нет. Возможно, никогда. Им нужно прежде всего понять, почему задачи вообще упускаются, потому что решение зависит от причины – а причина почти никогда не та, о которой люди думают.
Почему задачи упускаются
Спросите большинство менеджеров, почему задачи упускаются, и вы услышите знакомый список: кто-то забыл, кто-то не обращал внимания, кто-то не следовал процессу. Следовательно, решение – лучшие процессы, больше напоминаний, может быть, бот для стендапов, который каждое утро подталкивает людей.
И знаете, иногда это действительно так. Если один инженер забыл обновить тикет в Linear, а PM не проверил перед ревью спринта – это человеческая ошибка и пробел в процессе. Справедливо. Добавьте чеклист. Двигайтесь дальше.
Но это не тот вид упущенных задач, который не даёт спать менеджерам по инжинирингу. По-настоящему больно, когда все выполнили свою работу, следовали процессу, обновили инструменты – а что-то всё равно провалилось в щель. Потому что щель находится не между человеком и его задачей. Она находится между одним инструментом и другим.
Вот что я имею в виду. Инженер создаёт PR, который закрывает ишью на GitHub. Ишью была связана с тикетом в Linear, и тикет переходит в состояние «Готово». Отлично. Только исходный запрос пришёл из переписки в Slack три недели назад, где PM также упомянул дополнительное требование, которое никто никогда не зарегистрировал как отдельную задачу. Это дополнение живёт в треде Slack из февраля. Его нет в Linear. Его нет на GitHub. Его нет ни в чьём спринте. Технически это упущенная задача, но никакой конкретный человек её не упустил – она провалилась в структурную щель между Slack и трекером задач.
Этот паттерн встречается повсюду, как только начинаешь его замечать. Дизайнер оставляет комментарий в Figma, что граничный случай противоречит спецификации в Notion, но инженер, работающий над функцией, никогда не проверяет Figma, а PM не видит комментарий, потому что живёт в Linear. Руководитель клиентского успеха обещает функцию на звонке, кратко излагает её в письме, и она никогда не попадает в инженерный бэклог, потому что никто не перекидывает мост через эту конкретную щель. Ретроспектива инцидента выявляет три пункта для отработки, документ публикуется в Slack, и два из трёх пунктов так и не становятся отслеживаемыми задачами, потому что человек, который обычно этим занимается, был на больничном на той неделе.
Наиболее разрушительные упущенные задачи в управлении проектами случаются в щелях между инструментами, а не в щелях между людьми и их списками задач.
Процессное решение (и где оно перестаёт работать)
Я искренне верю, что хорошие процессы решают большинство этих проблем для большинства команд. Вот что работает – и я делюсь этим без каких-либо скрытых мотивов, потому что (если честно) мы ещё на стадии до запуска, и лучшее, что мы можем сейчас сделать, – это строить доверие, принося пользу.
Еженедельный обзор. Один человек – в идеале PM или руководитель по инжинирингу – тратит 30 минут каждую пятницу на просмотр тредов Slack, заметок со встреч и почты, чтобы выловить всё обсуждавшееся, но не зарегистрированное. Утомительно? Безусловно. Эффективно? Удивительно, до определённого момента.
Журнал решений. Каждое решение, принятое в треде Slack или на встрече, вставляется в общий документ (Notion, Google Docs – неважно) с датой, именем принявшего решение и следующими шагами. Звучит просто, и так оно и есть – до тех пор, пока вы не принимаете пятнадцать решений в неделю по четырём каналам и никто не помнит, какие были зарегистрированы.
Дисциплина ссылок. Каждый PR ссылается на тикет в Linear. Каждый тикет в Linear ссылается на тред Slack, где обсуждалось требование. Каждая спецификация в Notion ссылается на свой эпик в Linear. Если кто-то нарушает цепочку (а кто-то нарушит – это вопрос когда, а не если), видимость рушится вместе с ней.
Всё это – хорошие практики. Мы сами используем версии всех трёх. Но у них есть общий режим отказа: они зависят от того, что люди последовательно делают маленькое, скучное дело каждый раз, вечно. А исследования на эту тему не обнадёживают (не нужно цитировать исследования – если вы управляли командой более пяти человек, вы это уже знаете).
Когда процессное решение перестаёт масштабироваться
Существует порог, и я бы хотел назвать точную цифру, но мы её ещё не определили (честно говоря, она, вероятно, варьируется в зависимости от команды и дисциплины людей). Наша рабочая эвристика – и я хочу подчеркнуть, что это именно эвристика, а не эталонные данные – состоит в том, что проблемы начинаются где-то в районе четырёх-пяти инструментов, десяти и более людей и нескольких параллельных рабочих процессов.
Не потому, что кто-то стал ленивым. Не потому, что процесс был плохим. Но потому, что объём связей между инструментами превосходит способность любого одного человека отслеживать их вручную. Еженедельный обзор занимает 90 минут вместо 30, и PM начинает просматривать по диагонали. Журнал решений устаревает, потому что человек, который его вёл, ушёл в отпуск, и никто не подхватил. Дисциплина ссылок сохраняется в Linear и GitHub, но рассыпается в Slack и Figma, потому что эти инструменты не имеют того же типа структурированных ссылок.
Это (и я хочу это прояснить) проблема масштабируемости, а не дисциплины. Я видел, как действительно превосходные PM-ы и руководители по инжинирингу с этим борются – люди, которые ведут чёткий корабль и глубоко заботятся о том, чтобы ничто не ускользнуло. На определённом масштабе проблема перерастает решение. Это не провал человека – это провал инструментальной экосистемы, которая не обеспечивает связи между собой.
"Наградой за изощрённость в работе с инструментами является более сложная поверхность для упущенных задач. Я нахожу это глубоко ироничным." – Ellis Keane
И вот что я считаю откровенно несправедливым: чем лучше ваша команда использует свои инструменты, тем большую площадь поверхности вы создаёте для щелей между ними. Команда, которая неукоснительно использует Linear, поддерживает спецификации в Notion в актуальном состоянии, проводит активные ревью в Figma и общается в хорошо организованных каналах Slack, имеет больше точек передачи, чем команда, которая использует только электронную почту и таблицу.
Почему ваши инструменты не могут помочь
Вот что я нахожу по-настоящему интересным в этой проблеме и о чём, как мне кажется, говорят недостаточно: ваши инструменты делают именно то, для чего они были разработаны. Linear превосходно отслеживает ишью Linear. GitHub превосходно отслеживает изменения кода. Notion превосходно организует документы. Slack превосходно... является Slack (к добру или к худу).
Но ни один из них не был разработан для отслеживания связей между собой. А работа – настоящая работа – не происходит внутри одного инструмента; она протекает через все них. Точки передачи между инструментами – это место, где вещи исчезают, и никакое улучшение отдельного инструмента этого не исправит. Вы можете сделать Linear лучше в отслеживании ишью, но это не поможет, когда ишью вообще должна была быть создана на основании переписки в Slack, которая произошла в канале, который руководитель по инжинирингу не отслеживает.
Что действительно решает эту проблему
В этом посте я намеренно был расплывчат насчёт продукта – я хотел, чтобы он был полезен независимо от того, будете ли вы когда-либо использовать то, что мы создаём. Но раз вы дочитали до этого места (я ценю это), позвольте честно рассказать, как я вижу реальное решение.
Это не более совершенный трекер задач. Не более совершенный процесс. Не бот для стендапов, еженедельный обзор или общая таблица. Всё это помогает и на малом масштабе достаточно эффективно, но все они лечат симптом.
Реальное решение – это нечто, наблюдающее за связями между вашими инструментами и отмечающее, когда что-то не сходится. Когда решение из Slack не превращается в тикет. Когда PR на GitHub закрывает ишью, но есть неразрешённые комментарии. Когда спецификация в Notion ссылается на требование, которое было деприоритизировано в переписке, которую автор спецификации никогда не видел.
Чтобы сделать это конкретным, давайте разберём, как это выглядит. Допустим, ваша система наблюдает и за Slack, и за Linear. Она видит разговор в #engineering, где кто-то говорит «нам также следует обработать случай, когда пользователь не подтвердил свой email» – это новое требование. Если это требование не появляется как тикет в Linear в течение, скажем, 48 часов, система его отмечает. Не уведомлением, которое кричит на вас (никому не нужно больше таких), а записью в представлении «решения ещё не зарегистрированы», которое PM может просматривать во время пятничного обзора. Та же идея для PR на GitHub, которые закрыли тикеты в Linear, но у которых всё ещё есть открытые комментарии к ревью, или спецификаций в Notion, которые ссылаются на функции, деприоритизированные с момента написания спецификации.
Построите ли вы это внутри компании (некоторые команды делают это с помощью вебхуков, очереди сообщений и небольшого количества связующего кода), используете ли что-то готовое, или просто примете упущенные задачи как стоимость ведения бизнеса – это ваш выбор. Мы создаём одну версию этого ответа, но это не единственная версия, и для многих команд она пока ещё не является правильной.
Если вы хотите знать, когда она может стать правильной для вас, вот моя честная эвристика: если ваш еженедельный обзор занимает более 30 минут, а вещи всё равно ускользают, вы переросли ручной подход.
---
Когда еженедельный обзор занимает более 30 минут, а вещи всё равно ускользают, вы переросли ручной подход. Sugarbug автоматически следит за щелями.
Q: Как Sugarbug предотвращает упущенные задачи в управлении проектами? A: Sugarbug строит граф знаний по всем вашим инструментам – Linear, GitHub, Slack, Figma, Notion – и отслеживает задачи, разговоры и решения по мере их перемещения между ними. Когда что-то зависает или теряет связь с исходным запросом, Sugarbug выводит это на поверхность прежде, чем оно упадёт в щель. Это не система напоминаний – она понимает связи между элементами в разных инструментах и отмечает, когда эти связи рвутся.
Q: Может ли Sugarbug выявить задачи, обсуждавшиеся в Slack, но так и не зарегистрированные? A: Да. Sugarbug отслеживает разговоры в Slack и определяет, когда решение или пункт действия обсуждался, но так и не появился в виде задачи в Linear или тикета в GitHub. Он отмечает щель, чтобы кто-то мог принять меры. Мы всё ещё совершенствуем агрессивность сигнализации (никому не нужна усталость от уведомлений поверх всего остального), но базовое обнаружение работает.
Q: Нужен ли мне инструмент для устранения упущенных задач, или это проблема процесса? A: Честно говоря, всё зависит от масштаба. Небольшие команды с двумя-тремя инструментами, как правило, справляются с этим лучшими привычками – еженедельным обзором, общим документом и дисциплиной ссылок. Но как только у вас четыре-пять инструментов и десять-более человек, ручной подход перестаёт масштабироваться, и вам нужно что-то, что автоматически отслеживает связи. Порог варьируется в зависимости от команды, но вы почувствуете, когда его достигнете.
Q: В чём разница между трекером задач и системой сигнальной разведки для управления проектами? A: Трекер задач записывает то, что вы ему говорите. Система сигнальной разведки следит за тем, что реально происходит в ваших инструментах, и отмечает, когда что-то не сходится – задача помечена как выполненная, но с неразрешёнными комментариями, решение принято в Slack, но так и не отражено в спецификации. Она выявляет то, что люди забывают занести в журнал – что, по нашему опыту, является местом, где большинство этих щелей на самом деле и берут начало.