Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.
Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.
Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.
Почему возникает ложь про задачи
1. Страх показаться слабым
Люди боятся признаться, что не разобрались. Особенно если в команде культивируется культ «сильных разработчиков», а ошибки не приветствуются.
«Если я скажу, что не понял — подумают, что я слабый. Лучше потяну время, потом разберусь.»
2. Непонимание задачи
Разработчик вроде бы кивает, но на деле не до конца понял, что от него хотят. Начинает делать что‑то своё, не спрашивает — потому что уже поздно признаться. А потом становится неудобно.
3. Потеря интереса или энергии
Человек перегорел. Или задача скучная. Или просто устал. Он прокрастинирует, но не говорит об этом — потому что «это же его работа» и стыдно сказать, что не тянет.
4. Отсутствие доверия
Если ты как менеджер реагируешь жёстко, не даёшь пространства для диалога, у человека включается защита. Ему проще соврать, чем сказать правду и получить по шапке.
5. Просто привычка тянуть
Есть такие ребята. Они всегда на грани дедлайна. Живут на автопилоте «почти готово», пока не припечёт. Системная история — и тут нужна не ругань, а подход.
6. Две работы - привет волкам
У человека две удалёнки, он пытается успеть везде, но, по факту, не успевает нигде. Поэтому и врёт: «делаю», хотя реально решает чужую задачу в другой компании.
7. Работа по остаточному принципу
Человек просто держится за место, пока не найдёт что‑то получше. Он не вкладывается, не вовлечён, просто «тянет» до оффера, и с каждым днём делает всё меньше. Сказать прямо — не может, боится потерять что есть.
Как это выглядит в жизни (симптомы)
Каждый день на стендапе — одно и то же: «делаю ту же задачу». Или, что ещё хуже, через время внезапно всплывает, что якобы уже сделано — хотя по факту нет.
Много воды, мало конкретики. Если менеджер не силён технически, а в команде нет опытного девелопера, который может дать здравую оценку — такой разработчик может легко «всковырнуть мозг» и заморочить голову терминами и полусмысленными объяснениями.
Ответы на уточняющие вопросы — расплывчатые. Без конкретики, без ссылок, без уверенности.
Коммиты либо пустые, либо все вываливаются за ночь до демо. Классика «догнать за выходные».
Часто в обороте одни и те же причины: «баг мешает», «локально не воспроизводится», «что‑то со сборкой», «старый, плохой код» — и всё это вместо конкретных шагов.
Если ты это видишь — не проходи мимо. За фасадом «всё нормально» почти всегда что‑то гниёт. Как минимум — обрати внимание на динамику: если симптомы повторяются, значит, проблема системная.
Что с этим делать (без угроз и тотального контроля)
1. Перевести коммуникацию в честный режим
Объясни, что красиво — не значит правильно. Лучше знать о залипании на старте, чем потом спасать сроки всей командой. Разработчик должен понимать, что от его темпа зависят не только задачи в трекере, но и работа коллег, планирование, демо, интеграции.
Поделись кейсом, где сам застревал, ошибался, или делал что‑то неэффективно. Даже если ты красавчик уровня «сын маминой подруги» — это сближает. После этого человек уже не боится сказать: «Бро, я реально не вывожу».
2. Ввести демо
Показывать прогресс не в конце спринта, а каждые 2–3 дня. Даже если это мок, даже если недоделано. Смысл — в процессе. Когда человек знает, что будет показ — он меньше залипает и раньше поднимает флаг, если что‑то не так.
3. Работать с мотивацией
Если кто‑то тупит — не значит, что он лентяй. Иногда у человека в жизни творится трэш. Иногда он просто перегорел. Иногда он не понимает, зачем делает задачу.
Не лечи всех одинаково. Один залип — потому что скучно. Другой — потому что боится. Третий — потому что его никто не слушает. И каждому нужен свой подход.
4. Использовать таймбоксинг
Не «сделай, когда сделаешь», а «поработай 2 часа — и скажи, зашло или нет». Это снижает тревожность, даёт точку выхода, и позволяет вовремя вытащить человека из тупика, а не после трёх дней молчания.
5. 1:1 как точка перехвата
Раз в неделю/две — короткая личная встреча. Без контроля. Просто поговорить. Часто люди на стендапе играют уверенность, а на 1:1 выдыхают и говорят, как есть. Слушай, не перебивай, не лечи. Иногда просто выговориться — уже половина решения.
6. Немного чайки - иногда работает
Да, чайка‑менеджмент — зло. Но иногда подлететь, пингануть и улететь — это встряска. Главное — не делать это стилем управления, а применять осознанно и дозировано как лекарства. Иногда это позволяет разбудить команду.
7. Парное программирование
Если задача критична — подключи второго. Даже если это джун. Когда работает пара, залипнуть труднее. А если один решит уйти в закат — второй хотя бы будет в курсе, что происходит.
8. Регулярное ревью кода и процессов
Не формальное, а живое. С разбором решений, обсуждением сложностей, поиском альтернатив. Часто человек тянет, потому что не уверен. А ревью снимает это напряжение и не даёт уйти в глухую оборону.
Кейс из практики
Был у меня фронт, который всегда уверенно рапортовал: «почти готово». На daily — бодрый, в таск‑трекере — всё зелёное, идёт как по маслу. А потом — бах, релиз через два дня, а прогресса по сути нет.
Начали разбираться — и выяснилось: он не филонил, он залипал в рефакторинге. Пытался довести до идеала всё, что делал: компоненты, стили, архитектурные решения. Хотел как лучше. Но при этом терял фокус на конечном результате — пользовательской ценности, которую мы должны были показать.
Сейчас он один из самых сильных разработчиков в команде, реально топ. Но тогда помогло только одно: введение чётких чекпоинтов. Не просто «сделай фичу», а «покажи вот это к среде, вот это к пятнице». Мы убрали пространство для неопределённости, и это позволило направить его перфекционизм в нужное русло.
Вывод? Иногда человек не тупит — он просто старается быть слишком хорошим. Но без внешней рамки он теряется. И задача менеджера — эту рамку дать.
Итог
Бро, когда тебе говорят «всё под контролем», всегда смотри вглубь. Врать не всегда значит врать злонамеренно. Иногда это просто страх, усталость или попытка сохранить лицо.
Твоя задача — создать такую культуру, где можно говорить «я не вывожу» и не получать за это по щам. Где можно залипнуть, но не остаться с этим один. Где честность — это не слабость, а часть процесса.
Короче: меньше фасада, больше реальности. Команда, в которой можно говорить правду — сильнее той, где все притворяются продуктивными.
И не забывай, Бро — даже самый уверенный dev может сидеть в тупике. Просто не всегда хватает смелости это сказать.
Комментарии (21)
aasokovykh
16.05.2025 17:14Вижу АИ картинку в статье - скипаю.
Metotron0
16.05.2025 17:14Такую картинку, да ещё в целях КДПВ странно было бы рисовать руками.
А если мне применение какой-нибудь функции подсказала нейросеть, я честно написал об этом в комментах, и вам дали этот код на поддержку?
Rive
16.05.2025 17:14Если картинка привлекает внимание, но вызывает агрессию публики - это плохая КДПВ (независимо от того, сделана она нейросетью, куплена на фотостоках или нарисована руками).
BadNickname
16.05.2025 17:14А это ещё и статья АИ. С форматированием скопированым сразу из АИ.
Ещё и заплюсованая.
Как же цветёт хабр при ChatGPT.
nv13
16.05.2025 17:14Ну ответ на вопрос кто Вы такой есть в авторстве - деливери менеджер. Поэтому и пара сценариев из личного
Мой менеджер был подвинут вбок двумя другими, более близкими к начальству. Причём деньги зарабатывались нашим продуктом, а те пилили демки на вроде как близкую перспективу, но снизу было очевидно, что там ещё пилить и пилить. Ну, а поскольку деньги зарабатывали именно мы, то и проблемы возникали только у нас, но как их правильно решать определяло руководство с советов тех перспективных менеджеров. Я пару раз пытался эскалировать проблемы шефу, тот выслушивал, обсуждал, но не мог их двигать в другие подразделения, откуда они и росли. На третий и последующие разы я перестал их эскалировать, только оповещал, и пытался просто заткнуть как мог у себя, экономя время и нервы. Со стороны это так себе выглядело, наверно, в смысле я и то что я делал
У нас в команде была построена некоторая инфраструктвра для разработки, пока все её осваивали, я работал в другом окружении. Потом его неожиданно прикрыли, а у меня появилась новая и достаточно серьёзная задача, которая требовала работающего окружения. Четверо коллег сказали, чем они пользовались, дали доступ на своих серверах к каким то скриптам и образам, которые не устанавливались как надо. И вот два спринта я отчитывался, что я конфигурирую енвайронмент, и нифига не делаю по задаче. Менеджер и коллеги не могли понять в чём у меня проблема - у них то работало, и под конец вообще не верили что я выхожу на работу) за это время я разобрался с ошибками, скорректировал скрипты, обновил образы, и начал разбираться с задачей. Ещё через два спринта сломались енвайронменты у коллег, и все четверо брали мой сетап и ставили себе, потому что тоже оказались не в курсе, как его чинить самим. Я к тому, что некоторые очевидные для менеджера вещи бывают не соответствующими реальности. И это проблема менеджера, а не выпадающего из плана разработчика. Менеджер может эти проблемы не воспринимать или игнорировать, разработчик - нет
AnnMaslova
16.05.2025 17:14Мне кажется, важно создать атмосферу, где можно честно сказать: «Я не успеваю» или «Я не понимаю», без страха осуждения.
Informatik
16.05.2025 17:14Как-то раз давно я сказал начальнику, что люди не выполняют задачи не потому что не хотят, а потому что не могут. Он посмотрел на меня непонимающим взглядом. Начальство не хочет слышать о проблемах потому что это будет означать, что они наняли недостаточно квалифицированного сотрудника, а в этом они себе никак признаться не могут, их психика защищает их обходя такие острые углы.
pesh1983
16.05.2025 17:14Это в том случае, если начальство не умеет признавать свои ошибки. Но мы же все люди. Поэтому начальство начальству - рознь. Нормальный начальник как раз попытается разобраться в реальной проблеме. Потом исправить ситуацию всеми возможными способами, если это в его силах. А то, что вы описали - на мой взгляд ненормально. Потому что все мы люди, и все мы ошибаемся. И мудрый человек понимает это.
TTA
16.05.2025 17:14Все по делу, спасибо. На удаленке лет 10 уже. Как перешёл на неё, очень часто такое было. Помогли микроделайны которые сам просил, типа встречи в конце рабочего дня чтоб показать что сделано. ну и из дома работать не могу, семья ребёнок мешают сосредоточиться. снял себе мини офис, ухожу туда когда припекает
Habr4687544
16.05.2025 17:14У меня настолько скучные скрипты, что только парное программирование помогает.
johnfound
16.05.2025 17:14Это про меня:
Дао программирования 5.3:Однажды ученику дали задание написать несложный финансовый пакет.
Ученик неистово работал много дней, но когда его Учитель просмотрел его программу, он обнаружил, что она содержит экранный редактор, множество универсальных графических подпрограмм, естественноязыковый интерфейс и ни малейшего намёка на что-нибудь финансовое.
Когда Учитель спросил об этом у ученика, тот возмутился. “Не будьте таким нетерпеливым”, — сказал он, — “когда-нибудь я добавлю в программу финансовую часть.”
Поэтому я и не работаю программистом.
apcs660
16.05.2025 17:14у меня была ситуация - вел один продуктовый проект (полный рефакторинг морально устаревшего, т.е. понимали что делали и зачем) состоящий из нескольких приложений. Вначале нас было трое, двое разработчиков присоединились временно - каждый выполнил свою часть, хорошо поработали, запустили, парни вернулись в свой отдел. Единственная причина почему позволили переборку с нуля и изменение архитектуры - платил клиент. Иначе бы опять на сопли и изоленту делали заплатки.
Первое, заложили везде точки расширения, обработчики запросов, ответов, исполнение команд - можно делать врезки если нужно в любом месте pipeline.
Spring boot приложения были добавили им стандартно поддержку плагинов - в оригинале валили все зависимости в общую кучу... Как помойку - что поверх ляжет, то и будет работать. Как мавен разрулит, так и запустим (до него руками так как ант был). Попутно разобрался с одним опен сорсным проектом класслоадера и поправил его. Плагины мне понравились, разделяй - властвуй принцип. Сейчас мог цеплять разные версии одной и той же библиотеки в монолит. А так клади в папку plugins или в ext ( если основной класслоадер) плагин для клиента, и расслабляйся. Можно в zip формате.
Как то от скуки, плагины в war web приложение засунул для пробы, хоть это и не по фен-шую - тем не менее, работало, а почему нет.
Самое основное - покрыл все тестами. Вначале старался, конечно, но потом стал не успевать. Процентов 60 кода было покрыто минимум.
Интеграционные тесты на докере (базы и тд) хотя официально докер был запрещен.
В общем, хоть мерить строками кода устаревший подход, примерно 60 тыс строчек было, около 90 модулей maven ( часть ресурсные).
Это был один из трех проектов что вел, основной.
Что было замечено сразу - тестеры были опечалены. Реально не могли схватить ошибки.
Если ошибки хватались, то как правило, это было приложение для интеграции, похожего размера но с командой от 8 до 12 человек, с высокой текучкой и без рефакторинга. В приложении царил ад, содом и гоморра - даже опытные люди с ходу кубок размотать не могли. Лид флегматично тянул время, зарплату платят и ок. Улыбался руководству. Был на хорошем счету.
Со временем я стал терять интерес и начал забивать на качество. Смысл стараться, если рядом бардак. Просил хотя бы одного разработчика к себе в пару - а зачем, у тебя и так все работает а мы не успеваем! Как в анекдоте - админ Вася ленивый, ничего не делает, а Петя админ трудолюбивый - каждые полчаса систему переустанавливает. Угадаем какой админ медаль получил?
Informatik
16.05.2025 17:14Тоже пытался как-то все упорядочить. Потом с грустью осознал, что пока наводишь порядок в одной стороне, с другой стороны начинается хаос потому что коллегам то ли пофиг на системность и лишь бы закрыть задачу, то ли нет глубокого понимания и делают как могут. В итоге приходится признать поражение и поставить крест на мечтах о стройном будущем проекта.
apcs660
16.05.2025 17:14более того, бардак необходим чтобы заменить тебя было труднее.
Если навязал Гордиев ушёл в котором кроме тебя никто не разберется, то и заменить тебя труднее.
p07a1330
16.05.2025 17:14Проблема в том, что разработчик может усложнять систему до степени своей некомпетентности
Т.е. и сам не факт что разберешься
Хотя это будет сильно легче, чем с нуля конечноapcs660
16.05.2025 17:14у меня в начале 2000х был пример одного товарища - сидел коптил небо в одной страховой конторе в Торонто.
Пересидел много кого на in house продукте - народ уходил быстро потому что legacy , зарплата так себе.
В общем, он в определенный момент тоже ушел, перед уходом еще больше костылей сделав.
Потом сделал условие по оплате 300 CAN в час за передачу опыта когда к нему обратились , уже как контрактнику. Пока сидел в конторе, получал 20 в час (по низам считай).
Больше полугода покормился, дембельский аккорд.
У меня похожая была тема, тоже в Торонто - ушел с 22 в час. Через полгода в той же конторе как контрактник проект по open tv (на С) доделывал по 70 в час, с оплатой еженедельно, отелем и билетом из России, ибо пригорело а замену не найти быстро.
leon-mbs
обычное дело в начинающих разрабов.
сам такой был - нахватаешся проектов думаешь что раз два а там раз дватри...
а по молодости и потусоватся хочется :)
AlexSav_21 Автор
Да, по факту - история ультра базовая. Корни часто разные: кто-то переоценил силы, кто-то залип в перфекционизм, кому-то просто тяжело сказать "я не успеваю". Но сталкиваются с этим почти все
andreygn
Если бы только начинающих. Опытные не менее подвержены. Да и сам был, если честно.
Ситуация. Есть класс задач которые лучше решать другим способом, чем привыкли в команде. Показал на своем примере. Обсудили в команде. Все согласились. Пришли две подобные задачи. Молодые пытаются. Старые, опытные - больше по привычке. Поэтому что ответственность, привыкли - знают, что точно сделают и прочее, прочее, включая прокрастинацию.
Это в той или иной форме есть у всех.