Вернуться к блогу
04.07.2025
На связи Ярослав Ясаков, руководитель проектного офиса агентства продуктовой разработки Amiga. Сегодня разбираем ситуацию, знакомую многим: срывы сроков, обрыв коммуникаций и вечное чувство, что «что-то идет не так».
На старте это выглядит как мелкая неудача — ну не уложились в неделю, бывает. Но когда дедлайны срываются системно, команда буксует, задачи возвращаются на доработку, а проект — будто сам против себя, это уже сигнал. Сбой не в людях. Сбой — в системе.
Клиент пришел к нам с запросом: «у нас постоянно срываются сроки». На деле же все выглядело глубже:
— дедлайны не соблюдались;
— половина задач возвращались на доработку;
— в команде накапливалось напряжение.
Это организационная усталость, когда процессы не выдерживают нагрузки, а роли и зоны ответственности размыты.
В этой статье покажем, как мы разобрались с проблемой пошагово до запуска новых процессов. Расскажем, как изменить не людей, а правила игры — и почему изменения стоит начинать не с регламентов, а с вопросов.
Чтобы реально решить проблему, нужно провести глубокую диагностику и понять, что именно сломалось. Разговоры, наблюдения, анализ — все помогает собрать картину.
Первым шагом стал аудит. Но не технический, а системный — про людей, процессы и структуру. Нам нужно было разобраться: где команда буксует, кто принимает решения, как выглядит путь задачи от идеи до выката. И главное — где по дороге все рассыпается.
Изменения это не просто. Нельзя просто прийти и сказать: «Сейчас все переделаем — будет лучше», люди не примут и замкнутся. Поэтому мы начали с диалога, а не директив.
Сначала обсудили все с заказчиком. Получили поддержку, выяснили, кто сейчас неформально ведет за собой команду. Эти люди — ключевые. С ними важно говорить лично, отдельно. Не на общем созвоне, а один на один. Понять, что им мешает, что их раздражает, в чем они видят тупики. Вместо того чтобы навязывать свои правила — мы втягиваем в обсуждение: «Как бы ты это сделал?», «Что бы ты поменял?». Это дает два эффекта. Во-первых, ты реально понимаешь, что нужно команде. Во-вторых, люди чувствуют участие, а значит, меньше сопротивляются, когда изменения действительно приходят.
Система ADKAR — это модель управления изменениями, она состоит из пяти ключевых этапов, каждый из которых отвечает на конкретную потребность человека в процессе трансформации:
Awareness— понять, зачем нужны изменения. Люди должны видеть причину: что не так и почему нельзя оставаться как было.
Desire — захотеть участвовать. Одного понимания мало — важно, чтобы человек сам хотел включиться в изменения.
Knowledge— знать, как действовать. Людям нужно дать инструкции, инструменты, обучение — чтобы они понимали, что делать и как.
Ability — уметь применять знания на практике: поддержка, обучение, обратная связь.
Reinforcement — закрепить поведение, чтобы изменения остались. Подкрепление может быть разным: признание, поощрение, системные обновления.
ADKAR помогает видеть, на каком этапе «буксует» команда — и точечно с этим работат.
После этого мы выходим на командный митинг. Мы познакомились с участниками проекта, провели мягкие интервью.
Интервью с командой: что тормозит работу? где боль?
Интервью с заказчиком: чего ждут, чего не хватает?
Аудит дал нам главное — картину как есть. И не по документации, а по факту: кто за что отвечает, где реальная ответственность, какие есть негласные правила и как ими управляют. Это стало отправной точкой.
Вся ли работа отображена на доске?
Если что-то не попало на доску с задачами — считай, этого не существует.
Доска — это не только инструмент, это инструмент управления и определения задач. Если обсуждение живет в чате, а решение — в личке, то ни менеджер, ни разработчик, ни заказчик не увидят полной картины.
Когда работа разбросана по мессенджерам, письмам, шапкам ТЗ и голосовым — никто не понимает, где проект. Отсюда недоверие, недоразумения и тот самый вопрос «а почему мы опять не успели?».
Сколько задач «висят» неделями?
Когда задача не двигается, она становится балластом. Возможно, ее забыли. Возможно, над ней бьются, но не знают, что делать. Возможно, она уже неактуальна, но никто не решился снять ее с доски.
Если таких задач много — значит, система не дает честной обратной связи.
А это уже управленческий риск: кажется, что работа идет, а на деле — команда буксует. На хорошей доске задачи двигаются и вытекают в прод.
Используются ли метрики CFD, Lead Time, Throughput?
Без метрик нет роста. Можно сколько угодно «чувствовать», как идет проект, но пока нет цифр — это неуправляемый хаос.
CFD (Cumulative Flow Diagram) показывает, где система расширяется или сужается.
Lead Time — сколько в среднем задача живет в процессе.
Throughput — сколько задач проходит за единицу времени.
Если вы не замеряете поток — вы не сможете его улучшить. Команды, которые не смотрят на метрики, бегут спринт вслепую: может, бегут, может, топчутся на месте — непонятно.
Метрики — не для контроля, а для анализа. Чтобы не искать виноватых, а переделать процесс и сделать лучше.
Почему задачи блокируются: внешний фактор или внутренний сбой?
Это ключевой вопрос. Потому что именно от него зависит решение.
Если стопор — внешний (ждем данные от клиента, интеграция с внешней API), значит, нужно выяснить требования по задаче и понять, почему она не выполняется на данный момент времени. А также нужно составить план по снятию блокера.
Если стопор — внутренний (непонятная постановка, нехватка ресурсов, нет ответственных у задачи), то надо чинить командную механику.
То, что мы видим на доске первые дни, обычно говорит больше, чем любой интервью.
Первый доступ — и вот он, хаос. Статусы задач не читаются. Одни задачи висят неделями «на уточнении», другие перемещаются между «в тестировании» и «проверяет постановщик» и. Команда не всегда понимает, чем эти статусы отличаются. Часть обсуждений — в мессенджерах, часть — в гугл-доках. Полноценного флоу нет. А если он и есть, то он в головах — и только у пары человек.
Отдельно важно понять, как команда общается между собой. Потому что процессы — это поверхность. А под ней — доверие, уважение, готовность договариваться. Мы заглянули в комментарии, в старые обсуждения, в тон сообщений. Где-то было видно раздражение. Где-то — полное равнодушие. Где-то — явное недопонимание между ролями.
Мы применили наш подход Amigaban: проверили доску по чек-листу, понаблюдали за движением задач и нашли все, что тормозит поток. Где висят блокеры, где теряется прозрачность. И главное — как это можно поправить, не ломая привычную систему, а перестраивая ее изнутри.
Что смотрим:
Есть ли четкое описание?
Если в задаче одно название и полстрочки текста — можно быть уверенным: каждый интерпретирует ее по-своему. А значит, работа будет переделываться, откатываться или зависать. Четкое описание отвечает на вопрос: что нужно сделать, зачем, и как поймем, что сделали правильно. Все остальное — импровизация.
Понятны ли ожидания от задачи?
Это про финальную картинку в голове. Что должен получить заказчик или пользователь, когда задача будет закрыта? Если ответ звучит как «ну, примерно вот это...» — значит, ожидания расплывчаты.
Именно здесь рождаются конфликты и доработки: разработчик думал одно, постановщик — другое, дизайнер — третье, а в итоге всем «немного не то».
Мы всегда проверяем:
есть ли конкретные критерии;
можно ли показать референсы, как должно выглядеть;
зафиксированы ли границы задачи (что точно не входит);
на какую продуктовую, техническую или бизнес-метрику повлияет выполнение определенной задачи;
разбили ли задачу на мини-таски, чтобы отслеживать постепенное выполнение;
Указаны ли DoR (Definition of Ready) и DoD (Definition of Done)?
DoR (Definition of Ready) и DoD (Definition of Done) — это фильтры качества.
Первый показывает, что задачу можно взять в работу. Второй — показывает, что задача выполнена по тз постановщика.
Если нет DoR — задачи попадают неполным контекст, неясной цель, плавающими требованиями. Команда тратит время на расшифровку, а не на выполнение.
Если нет DoD — закрываются задачи, которые не проверены, не протестированы, не зафиксированы. Вроде бы сделано, но на деле — только половина.
Мы проверяем:
Есть ли у команды общее понимание, что такое «готово к работе» и «готово к релизу»;
Висят ли на доске задачи, которые не находятся в актуальном статусе.
Когда DoR и DoD внедрены — доска начинает «дышать правильно».
Чтобы процесс стал прозрачным, а команда — более управляемой, мы внедрили базовые элементы управления проектной деятельностью в организации, которые дали опору каждому участнику.
Пилот на команду разработки
Мы не стали запускать изменения по всей компании сразу — начали с одной команды. Это позволило проверить гипотезы и отточить процессы без лишнего стресса.
Сбор фидбека
После запуска мы регулярно собирали обратную связь от команды: что удобно, где неудобно, чего не хватает. Важно — спрашивали не формально, а с интересом к деталям.
Корректировки и доработки
На основе фидбека вносили точечные изменения: донастроили статусную модель, пересмотрели каденции, упростили правила приоритезации. Главное — не бояться менять, если что-то не работает.
После отладки на пилоте — двинулись дальше. Расширили практики на всю команду, добавили автоматизацию, ввели регулярные ритуалы. Так система перестала зависеть от «везения» и начала работать стабильно.
Ну что, разобрали всю механику. От первой боли — «что-то не так со сроками» — до полной картины: где проблемы, как выстроены процессы, как выглядит доска, как команда коммуницирует внутри и почему хороший инструмент сам по себе не спасает.
Теперь вы точно знаете: срывы сроков — это не «просто не успели». Это финальный сигнал, что в команде не работают правила, нет прозрачности, не зафиксированы ожидания и не хватает регулярного менеджмента. Именно поэтому мы меняем логику процесса — чтобы каждый знал, зачем делает свою задачу и что дальше с ней будет. Мы сами прошли тернистый путь от потерянных в разговоре задач к прозрачным процессам, где все по полочкам, и суть самой сложной задачи поймет любой сотрудник вне контекста.
Если вы находитесь в похожей точке — не тратьте силы на симптом. Поищите, что в системе дает сбой, спокойно посмотрите на доску, спросите команду, проведите ретро. В Amiga мы верим: сильная команда — это не та, у кого все по гайду, а та, у кого все понятно. Мы всегда рядом, чтобы наладить ваши процессы :)
