惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
Securelist
有赞技术团队
有赞技术团队
WordPress大学
WordPress大学
V
V2EX
Google DeepMind News
Google DeepMind News
B
Blog RSS Feed
The Register - Security
The Register - Security
Recorded Future
Recorded Future
Y
Y Combinator Blog
小众软件
小众软件
Jina AI
Jina AI
V2EX - 技术
V2EX - 技术
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Proofpoint News Feed
Engineering at Meta
Engineering at Meta
宝玉的分享
宝玉的分享
The Hacker News
The Hacker News
C
Cybersecurity and Infrastructure Security Agency CISA
K
Kaspersky official blog
博客园 - 三生石上(FineUI控件)
T
Threatpost
博客园 - 聂微东
Scott Helme
Scott Helme
IT之家
IT之家
N
Netflix TechBlog - Medium
T
The Exploit Database - CXSecurity.com
S
Schneier on Security
MongoDB | Blog
MongoDB | Blog
T
Tor Project blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
A
About on SuperTechFans
酷 壳 – CoolShell
酷 壳 – CoolShell
C
CERT Recently Published Vulnerability Notes
P
Palo Alto Networks Blog
Spread Privacy
Spread Privacy
C
Check Point Blog
L
LINUX DO - 最新话题
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Last Week in AI
Last Week in AI
Attack and Defense Labs
Attack and Defense Labs
T
Tailwind CSS Blog
罗磊的独立博客
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Webroot Blog
Webroot Blog
Help Net Security
Help Net Security
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
爱范儿
爱范儿
PCI Perspectives
PCI Perspectives
Security Latest
Security Latest

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Почему команды берут на себя слишком много — и как руководителю не загонять их в перегруз
kmoseenk (OT · 2026-04-28 · via Все публикации подряд на Хабре

Почему команды берут на себя слишком много — и как руководителю не загонять их в перегруз

Уровень сложностиСредний

Время на прочтение9 мин

Охват и читатели312

Туториал

Эта статья для руководителей, которые хотят получать от команд честные оценки, не вынуждая их создавать иллюзию определённости.

Большинству команд не нужен руководитель, чтобы взять на себя чрезмерные обязательства.

Они, как правило, делают это сами.

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

Но он также проявляется и в их оценках.

Спросите команду, сколько она сможет сделать за спринт, квартал или до конца года, — и большинство возьмет на себя немного больше, чем реально успеет. Иногда — значительно больше.

Это не значит, что они безответственны. Это значит, что они просто люди.

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

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

Это не сработало.

Проблема не в том, что команда была безответственной. Она была в том, что я относился к оптимизму как к контракту.

Команды изначально настроены оптимистично

Я хотел бы, чтобы руководители поняли: чрезмерные обязательства обычно возникают ещё до того, как руководитель вообще что-либо скажет.

Команды разработки часто строят вполне разумные планы, опираясь на неполную информацию. Они делают всё возможное. Смотрят на стоящие перед ними задачи. Делают предположения о том, что пойдёт хорошо. Представляют путь выполнения работы и оценивают сроки, исходя из этого сценария.

Это нормально.

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

Представьте, что вы едете через весь город на встречу. Вы учитываете расстояние, время суток и трафик. Делаете вывод, что 30 минут достаточно — и в большинстве случаев это действительно так. Но однажды поезд перекрывает переезд на 10 минут, и вы внезапно опаздываете.

Ваша оценка не была неправильной или глупой. Это была лучшая возможная оценка. Просто она не сработала в конкретной ситуации из-за неудачного стечения обстоятельств.

С командами происходит то же самое.

Иногда команда действительно плохо планирует. Но иногда она выбирает наиболее вероятный сценарий и всё равно не укладывается в сроки, потому что неопределённость проявляется в неудобной форме.

Руководителям важно учитывать эту реальность.

Как давление со стороны руководства приводит к перегрузу команды обязательствами

Поскольку команды уже склонны к оптимизму, давление играет гораздо более важную роль, чем многие руководители думают.

Иногда давление создаётся намеренно. Руководители хотят больше и быстрее — и прямо об этом говорят.

Но давление может возникать и непреднамеренно.

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

Она не вкладывала в это ничего плохого. Более того, её главным приоритетом было качество. Она хотела, чтобы команда могла замедляться до нужной степени, чтобы делать работу хорошо. Но сотрудники воспринимали это как ежедневное давление по поводу продуктивности.

Когда я поделился с ней своим наблюдением, она изменила своё приветствие на намеренно шуточное вроде: «Сегодня без багов?»

Это небольшое изменение оказалось важным. Оно показало, что для неё действительно имеет значение. А благодаря лёгкой иронии оно разрушило прежний шаблон восприятия.

Этот пример мне запомнился, потому что он показывает, как легко руководитель может транслировать одно, а восприниматься при этом — совершенно иначе. Даже простой вопрос «Как дела?» может ощущаться как давление, если команда слышит в нём: «Скажи, что вы всё успеваете».

Что давление делает с командами

Давление не устраняет неопределённость. Оно меняет поведение команд в условиях неопределённости.

Когда команда ощущает давление, она склонна выбирать наиболее оптимистичную оценку вместо наиболее реалистичной. Люди становятся менее готовы открыто говорить о рисках. Они перестают внимательно искать, что может пойти не так — отчасти потому, что обнаружение плохих новостей вызывает психологический дискомфорт.

Риски никуда не исчезают. Они просто уходят в тень.

Это один из самых опасных эффектов давления. Оно искажает не только то, что команда говорит, но и то, что она готова исследовать.

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

А когда качество начинает проседать, команды часто усугубляют ситуацию, начиная спешить. Начинают проскакивать фразы вроде: «Потом поправим» или «Сделаем в следующем спринте».

Срочность — это нормально. Спешка — нет.

Мне нравится фраза, которую часто приписывают John Wooden: «Будь быстрым, но не суетись». Именно этого и должны хотеть руководители от команд — двигаться энергично, но без паники.

Прогноз vs план vs обязательство

Одна из причин, почему руководители и команды попадают в сложные ситуации, — они используют одни и те же слова в разных значениях.

Прогноз — это предположение о будущем.

План — это то, что мы собираемся сделать на основе этого прогноза.

Обязательство — это то, что мы уверенно обещаем сделать, с реалистичным запасом по времени, чтобы успеть в срок.

И это не взаимозаменяемые понятия.

Команда может оценить отдельные элементы бэклога и на основе этих оценок собрать план спринта или трёхмесячный план этапа. Такой план может быть продуманным, дисциплинированным и полезным. Но это всё ещё не гарантия.

Обязательство — другое дело. Оно требует запаса.

Если я думаю, что могу доехать через весь город за 30 минут — это план. Если мне нужно действительно гарантировать прибытие вовремя, я, скорее всего, выеду за 40 минут. Это дополнительное время — не потеря, а цена надёжности.

Руководители могут придерживаться этого принципа в разных сферах бизнеса. Компания может внутри прогнозировать прибыль в 5 долларов на акцию. Но во внешних коммуникациях она может более консервативно взять обязательство на уровне 4,5 доллара. Тот же бизнес, те же руководители, та же реальность. Просто есть понимание, что для обязательства нужен запас на случай отклонений.

Разработка программного обеспечения ничем не отличается.

Да, руководители могут запрашивать обязательства. Они могут просить взять обязательство по спринту, по фиче или по цели на несколько месяцев вперёд. Но важно понимать: объём, по которому даётся обязательство, должен быть меньше запланированного, а запланированный объём, как правило, меньше оптимистичного.

Как эффект привязки подталкивает команды к чрезмерным обязательствам

Часто руководители навязывают чрезмерные обязательства через так называемый эффект привязки.

Он возникает, когда руководитель задаёт рамку ответа ещё до того, как команда успела самостоятельно всё обдумать. Например, он спрашивает: «Вы сможете сделать эти фичи за три месяца?»

Звучит безобидно. Но на самом деле это не нейтральный вопрос. Команда уже услышала и объём работы, и желаемый срок. Она понимает, какого ответа от неё ждут. Люди хотят быть полезными. Хотят оправдывать ожидания. Поэтому вместо того, чтобы независимо определить реалистичные сроки, они начинают искать способ сказать «да».

Я ясно увидел это много лет назад, когда был вице-президентом по разработке в одной компании. Мой руководитель спросил, получится ли выпустить определённый продукт до конца года. Нам нужна была выручка в текущем году, и этот продукт мог её обеспечить.

Я вернулся к команде, и мы начали прорабатывать план. Изначально наш ответ был где-то в районе середины февраля. Мы сократили объём, пересобрали план и в итоге получили вариант с серединой декабря. Отлично, решили мы — бизнес-задача будет выполнена.

Но я не учёл, что клиенты не смогут выделить людей для бета-тестирования в ноябре и декабре. У них был высокий сезон, они были заняты. В итоге релиз сдвинулся на январь.

Теперь давайте посмотрим на ситуацию в целом. Для проекта длительностью 11 месяцев мы промахнулись всего на пару недель. С точки зрения планирования это очень неплохо. Но поскольку ключевой целью было зафиксировать выручку именно в этом году, результат оказался провальным.

И, на мой взгляд, ошибка началась именно с формулировки вопроса.

Если бы мой руководитель спросил: «К какому сроку получится завершить проект?», я, скорее всего, вернулся бы с оценкой в феврале или марте. Это привело бы к правильному бизнес-решению: не делать этот проект ради данной цели. Но вопрос «Получится ли успеть до конца года?» задал нам вполне конкретный ориентир, и мы нашли способ почти уложиться.

Правда, в этом случае «почти» оказалось недостаточно.

Просите правду, а не успокоение

Лучшие руководители ясно дают понять, что именно они хотят получить. Им нужен прогноз? План? Или обязательство?

Они также создают условия, в которых безопасно говорить правду.

Такая безопасность возникает из вопросов, которые приглашают к реальному анализу:

  • Какие предположения вы делаете, и какие из них могут не оправдаться?

  • Что может сорвать этот план?

  • Какие зависимости здесь заложены?

  • Это ваш оптимистичный сценарий, наиболее вероятный или пессимистичный?

  • Что важно знать о том, как вы пришли к этим выводам?

Это принципиально отличается от вопросов, которые подразумевают: «Успокойте меня».

Разница существенна. Здоровый синхрон — это не тот, после которого команда говорит, что всё в порядке. Это тот, который помогает выявить, что может быть не в порядке.

И когда руководитель слышит плохие новости, самым важным первым ответом может быть простое: «Спасибо, что сказали».

Эта фраза показывает команде, что правда ценится (и за ее не наказывают).

Планирование — это общая задача

Это управленческая привычка, которую я больше всего хотел бы изменить.

Слишком часто руководители воспринимают планирование как исключительно задачу команды. Руководитель просит план. Команда его предоставляет. После этого руководитель либо принимает его, либо, по сути, говорит: «Недостаточно хорошо. Всё равно уложитесь в срок».

Это не планирование. Это давление.

Планирование должно быть диалогом.

Команда должна предложить свой план. Руководитель — признать вложенные усилия. И если он рассчитывал на более быстрый результат, ответ может звучать так: «Я рассчитывал на больший объём и более ранний срок. Что я могу сделать, чтобы помочь нам этого добиться?»

Это меняет всё.

Теперь разговор проходит в формате сотрудничества. Возможно, можно убрать одну крупную фичу. Возможно, менее приоритетный результат стоит перенести на более поздний релиз. Возможно, дополнительные пару недель существенно снизят риски. Возможно, поможет добавление ещё одного человека в команду. Возможно, мобильное приложение можно выпустить позже.

Суть не в том, что у каждой проблемы есть простое решение. Суть в том, что решение не должно целиком перекладываться на команду.

Планирование — это общая задача.

Цена постоянных чрезмерных обязательств

Когда команды систематически берут на себя слишком много, первое, что замечают руководители, — это невыполненные цели.

Но более серьёзный ущерб — это потеря доверия.

Если команда из раза в раз не достигает целей спринта или контрольных этапов, в какой-то момент ей перестают верить. Это тяжело для всех. Руководителям становится сложно получать достоверную информацию. Команде — потому что даже когда она наконец говорит правду, ей уже не доверяют.

Повторяющиеся чрезмерные обязательства приучают организацию не доверять реальности.

Именно поэтому эта проблема так важна. Речь не только о том, чтобы один спринт прошёл лучше. Речь о сохранении способности команды и её руководителей вести честные и полезные разговоры о планировании.

Какие вопросы стоит задавать руководителю

Если вы руководитель, вот самое простое изменение, которое можно внедрить.

Перестаньте задавать вопросы, в которых уже заложен желаемый ответ.

Когда руководитель спрашивает: «Сможете сделать это за три месяца?», команда уже попадает под влияние эффекта привязки. Она понимает, какой срок ожидается, и многие начинают искать способ, как сказать «да».

Гораздо лучше задать вопрос так: «Вот что нам нужно. Когда вы сможете это сделать?»

Сначала дайте команде самой ответить на этот вопрос. Затем сравните их ответ с желаемым вами сроком. Если ответ позже, чем вам хотелось бы, не превращайте это в давление. Начните обсуждение.

После этого задайте вопросы вроде:

  • Какие допущения вы делаете относительно того, что всё пойдёт хорошо?

  • Что может сорвать этот план?

  • Какие зависимости здесь критичны?

  • Это прогноз, план или обязательство?

  • Что мы можем сделать вместе, чтобы улучшить результат?

Такие вопросы не снижают ответственности. Они её усиливают. Они помогают командам мыслить более ясно, говорить более честно и строить более надёжные планы.

Именно этого руководители и должны добиваться.

Команды берут на себя слишком много не потому, что они безответственны. Это происходит потому, что оптимизм — естественное состояние, разработка программного обеспечения связана с неопределённостью, а поведение руководства влияет на то, что команды считают безопасным озвучивать.

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

Именно так появляются более качественные планы. А со временем — и более предсказуемые результаты.

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

—> 30 апреля в 19:00. «МОК-интервью на позицию Руководитель Проектов» — разбор типичных ошибок на интервью, демонстрация ответов на сложные вопросы и логики, по которой оценивают кандидатов. Записаться на вебинар

—> 12 мая в 19:00. «Управление ресурсами в условиях жестокого дефицита» — как принимать решения, когда ресурсов не хватает, и при этом сохранять управляемость и результат. Записаться на вебинар

Системно освоить эффективные методики управления проектами в IT можно на практическом курсе «Руководитель ИТ проектов».