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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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