Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.

Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.

Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.

Почему возникает ложь про задачи

1. Страх показаться слабым

Люди боятся признаться, что не разобрались. Особенно если в команде культивируется культ «сильных разработчиков», а ошибки не приветствуются.

«Если я скажу, что не понял — подумают, что я слабый. Лучше потяну время, потом разберусь.»

2. Непонимание задачи

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

3. Потеря интереса или энергии

Человек перегорел. Или задача скучная. Или просто устал. Он прокрастинирует, но не говорит об этом — потому что «это же его работа» и стыдно сказать, что не тянет.

4. Отсутствие доверия

Если ты как менеджер реагируешь жёстко, не даёшь пространства для диалога, у человека включается защита. Ему проще соврать, чем сказать правду и получить по шапке.

5. Просто привычка тянуть

Есть такие ребята. Они всегда на грани дедлайна. Живут на автопилоте «почти готово», пока не припечёт. Системная история — и тут нужна не ругань, а подход.

6. Две работы - привет волкам

У человека две удалёнки, он пытается успеть везде, но, по факту, не успевает нигде. Поэтому и врёт: «делаю», хотя реально решает чужую задачу в другой компании.

7. Работа по остаточному принципу

Человек просто держится за место, пока не найдёт что‑то получше. Он не вкладывается, не вовлечён, просто «тянет» до оффера, и с каждым днём делает всё меньше. Сказать прямо — не может, боится потерять что есть.

Как это выглядит в жизни (симптомы)

• Каждый день на стендапе — одно и то же: «делаю ту же задачу». Или, что ещё хуже, через время внезапно всплывает, что якобы уже сделано — хотя по факту нет.

• Много воды, мало конкретики. Если менеджер не силён технически, а в команде нет опытного девелопера, который может дать здравую оценку — такой разработчик может легко «всковырнуть мозг» и заморочить голову терминами и полусмысленными объяснениями.

• Ответы на уточняющие вопросы — расплывчатые. Без конкретики, без ссылок, без уверенности.

• Коммиты либо пустые, либо все вываливаются за ночь до демо. Классика «догнать за выходные».

• Часто в обороте одни и те же причины: «баг мешает», «локально не воспроизводится», «что‑то со сборкой», «старый, плохой код» — и всё это вместо конкретных шагов.

Если ты это видишь — не проходи мимо. За фасадом «всё нормально» почти всегда что‑то гниёт. Как минимум — обрати внимание на динамику: если симптомы повторяются, значит, проблема системная.

Что с этим делать (без угроз и тотального контроля)

1. Перевести коммуникацию в честный режим

Объясни, что красиво — не значит правильно. Лучше знать о залипании на старте, чем потом спасать сроки всей командой. Разработчик должен понимать, что от его темпа зависят не только задачи в трекере, но и работа коллег, планирование, демо, интеграции.

Поделись кейсом, где сам застревал, ошибался, или делал что‑то неэффективно. Даже если ты красавчик уровня «сын маминой подруги» — это сближает. После этого человек уже не боится сказать: «Бро, я реально не вывожу».

2. Ввести демо

Показывать прогресс не в конце спринта, а каждые 2–3 дня. Даже если это мок, даже если недоделано. Смысл — в процессе. Когда человек знает, что будет показ — он меньше залипает и раньше поднимает флаг, если что‑то не так.

3. Работать с мотивацией

Если кто‑то тупит — не значит, что он лентяй. Иногда у человека в жизни творится трэш. Иногда он просто перегорел. Иногда он не понимает, зачем делает задачу.

Не лечи всех одинаково. Один залип — потому что скучно. Другой — потому что боится. Третий — потому что его никто не слушает. И каждому нужен свой подход.

4. Использовать таймбоксинг

Не «сделай, когда сделаешь», а «поработай 2 часа — и скажи, зашло или нет». Это снижает тревожность, даёт точку выхода, и позволяет вовремя вытащить человека из тупика, а не после трёх дней молчания.

5. 1:1 как точка перехвата

Раз в неделю/две — короткая личная встреча. Без контроля. Просто поговорить. Часто люди на стендапе играют уверенность, а на 1:1 выдыхают и говорят, как есть. Слушай, не перебивай, не лечи. Иногда просто выговориться — уже половина решения.

6. Немного чайки - иногда работает

Да, чайка‑менеджмент — зло. Но иногда подлететь, пингануть и улететь — это встряска. Главное — не делать это стилем управления, а применять осознанно и дозировано как лекарства. Иногда это позволяет разбудить команду.

7. Парное программирование

Если задача критична — подключи второго. Даже если это джун. Когда работает пара, залипнуть труднее. А если один решит уйти в закат — второй хотя бы будет в курсе, что происходит.

8. Регулярное ревью кода и процессов

Не формальное, а живое. С разбором решений, обсуждением сложностей, поиском альтернатив. Часто человек тянет, потому что не уверен. А ревью снимает это напряжение и не даёт уйти в глухую оборону.

Кейс из практики

Был у меня фронт, который всегда уверенно рапортовал: «почти готово». На daily — бодрый, в таск‑трекере — всё зелёное, идёт как по маслу. А потом — бах, релиз через два дня, а прогресса по сути нет.

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

Сейчас он один из самых сильных разработчиков в команде, реально топ. Но тогда помогло только одно: введение чётких чекпоинтов. Не просто «сделай фичу», а «покажи вот это к среде, вот это к пятнице». Мы убрали пространство для неопределённости, и это позволило направить его перфекционизм в нужное русло.

Вывод? Иногда человек не тупит — он просто старается быть слишком хорошим. Но без внешней рамки он теряется. И задача менеджера — эту рамку дать.

Итог

Бро, когда тебе говорят «всё под контролем», всегда смотри вглубь. Врать не всегда значит врать злонамеренно. Иногда это просто страх, усталость или попытка сохранить лицо.

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

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

И не забывай, Бро — даже самый уверенный dev может сидеть в тупике. Просто не всегда хватает смелости это сказать.