Книга: Мама, я тимлид! Практические советы по руководству IT-командой
Назад: 6. Микроменеджмент. Бьем себя по рукам
Дальше: 8. Защищаем подчиненных
7

Ответственность за успех и за провал

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

Почему это важно? Прежде всего, нет ничего лучше, чем ощущать себя частью команды, которая делает что-то полезное. Это в хорошем смысле наркотик: если ты один раз испытал это, тебе очень хочется поучаствовать в деле еще разок, чтобы снова ощутить радость от совместного труда. Признавая вклад каждого участника команды, вы обеспечиваете мощный задел на будущее: несколько успешных запусков подряд, и вы получите слаженную мотивированную команду, заряженную покорять новые вершины. Замечательно о «кристаллизации команды» написали Том Демарко и Тимоти Листер все в той же книге «Человеческий фактор», одной из лучших работ о создании слаженной команды:

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

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

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

Подытожим: в случае успеха открыто радуйтесь, хвалите команду и смежников публично, старайтесь «затащить всех на борт».

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

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

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

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

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

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

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

Назад: 6. Микроменеджмент. Бьем себя по рукам
Дальше: 8. Защищаем подчиненных