От разработчика до руководителя. Менеджмент для IT-специалистов - читать онлайн книгу. Автор: Камиль Фурнье cтр.№ 29

Если вас вообще приводит в ужас мое предложение, чтобы менеджеры не бросали писать код, не беспокойтесь! Позже я в деталях расскажу о моменте, когда уже совсем нет смысла оставаться в коде. Уверена, что такой момент существует. Но на данном этапе постарайтесь остаться в коде, хотя бы ненадолго. Уверяю вас, это сделает работу легче.

Как отладить слабо работающую команду

Иногда вам придется руководить плохо работающей командой. Она не выдает вовремя положенный результат. Люди чувствуют себя несчастными. Они уходят с работы. Менеджер продукта злится. Команда злится на менеджера продукта. Или, может быть, им просто не хватает энергии или энтузиазма в текущих проектах. Вы понимаете: что-то в команде не так, но не можете точно сказать, что именно. В работе команд, связанных с производством софта, могут возникнуть некоторые типичные недостатки. Здесь я коротко охарактеризую их, чтобы вы знали, на что обращать внимание и как решать проблемы.

Команда не укладывается в сроки

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

Будучи руководителем команды, вы можете иногда беспокоиться, что вам приходится подталкивать ее к работе, поэтому вы без особого шума начинаете позволять коллективу не укладываться в сроки. Здесь весь фокус в том, чтобы сбалансировать принуждение команды двигаться вперед и разрешение иногда немного придерживать темп. Если вы все еще пишете код вместе с командой, то самое время засучить рукава и помочь ей выдать результат или докопаться до той части проекта, где происходит отставание, и поработать с ведущими инженерами, отвечающими за общее понимание ситуации.

Иногда команда не укладывается в сроки из-за того, что используемые процессы и методики не позволяют работать быстро. Простой пример: ваша команда пытается осуществлять релиз изменений к запущенным в производство программам всего лишь один раз в неделю, а то и реже. Такие редкие релизы могут порождать болезненные моменты, например несовершенство методов разработки, излишнюю громоздкость программ или слабое участие разработчиков, не умеющих правильно разбить работу на более мелкие участки. Будучи менеджером команды, вы должны сразу же приниматься за устранение узких мест.

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

Конфликтный член коллектива

Иногда мы позволяем себе слишком долго зависеть от блестящего негодяя. Вы знаете, что его некем заменить, потому что он очень работоспособен и квалифицирован. Он не командный игрок и раздражает всех вокруг (больше о таком вредном работнике см. «Блестящий негодяй»). Один из вариантов такого типажа — человек, будоражащий коллектив, буквально живущий негативом, распространяющий слухи или организовывающий противостояние «своих и чужих».

Вы должны без колебаний подавлять конфликты в зародыше. Можно попросить помощи у руководителя, особенно если вы впервые сталкиваетесь с такой ситуацией. Но помните: ваш руководитель может испытывать в решении проблемы с «блестящим негодяем» еще большие сложности, чем вы. Ведь он не видит ситуацию изнутри; он имеет дело с тем, кто ее разрешает. Будьте готовы к серьезным разговорам и с самим блестящим негодяем, и с боссом. Может статься, что вам придется перейти в другую команду.

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

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

Недовольство слишком большим объемом работы

Эту проблему решить проще. Обычно недовольство излишним объемом работы порождается проблемами, поддающимися решению. Например, если переработки обусловлены нестабильностью работы систем, то ваша задача как менеджера состоит в некотором «сдерживании» производственных планов с целью стабилизировать ситуацию. Установите четкую систему фиксации простоев, ошибок и непредвиденных отказов и старайтесь снизить их число. Я рекомендую 20% времени при планировании любого проекта посвящать вопросам стабильности системы (именно стабильности, а не общей технической надежности).

Если излишне большой объем работы вызван срочным и неотложным релизом, помните две вещи. Первое — вам нужно быть заводилой. Поддерживайте команду настолько, насколько она нуждается в поддержке, в том числе и личным участием в общей работе. Закажите всем обед. Скажите команде, что благодарны за самоотверженный труд. Дайте понять, что после напряженного периода будет время передохнуть. Старайтесь внести в работу команды приподнятую атмосферу. Иногда такой решающий момент связывает членов команды воедино. Сотрудники обязательно запомнят, был ли их менеджер рядом в напряженный период или находился где-то еще, занятый своими делами.

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