Однажды меня спросили, какой я могу дать один-единственный важный совет молодому и перспективному менеджеру. Сперва я хотел дать такой совет: «Иди убей себя». Но потом вспомнил, как туго мне поначалу пришлось в армии, когда в возрасте 18 лет я командовал взводом (мы проходили курс молодого бойца). Поэтому самый важный совет, который я дал бы любому хорошему начинающему менеджеру, будет таким:
Контроль должен сочетаться с ответственностью
Под контролем я понимаю право принимать решения. Как правило, работой управляет человек, принимающий решения, а не человек, который делает эту работу. Многие менеджеры и тимлиды считают, что поскольку они поручили команде выполнять работу, то команда управляет ею и, соответственно, несет за это ответственность. Но если менеджер определяет применяемый инструментарий, условия труда, температуру в помещении, качество стола, кресла, бюджет проекта и все остальное, то и ответственность за выполнение работы лежит на менеджере.
Под ответственностью я понимаю раздачу премий и наложение взысканий за результат работы. Люди с готовностью принимают на себя ответственность, если по итогам работы им наверняка придется заниматься раздачей плюшек, но как только дела ухудшаются, некоторые менеджеры начинают спихивать ответственность на других. Ответственность несет именно тот человек, который получает наказание, когда дела идут плохо, или премию — когда дела идут хорошо. Я повторяю это, так как данное обстоятельство становится очень важным, особенно если вы начинаете сваливать ответственность на членов команды, пытаясь таким образом исправить недоработки.
Нет ничего хуже в менеджменте, чем когда работой управляет один человек, а ответственность за ее исход несет кто-то совершенно другой. Когда складывается такая ситуация, управленцы начинают творить что хотят, а люди, на которых они спихнули свою ответственность, оказываются униженными, увольняются, сходят с ума или пускают все на самотек. Именно по этой причине возникает большинство конфликтов в любой организации, и если вы совершаете такую ошибку, то исправить ее довольно сложно.
Но если ответственность несет именно тот человек, который руководит работой, конфликты не возникают. Достичь такой гармонии можно либо передав управление тому человеку, от которого действительно зависит ее исход, либо просто приучив руководящих работников нести ответственность за свои действия.
Начните с себя
Будучи руководителем, вы должны вдохновлять подчиненных своим примером и давать понять, что именно вы несете ответственность за общее дело. Плохой менеджер говорит людям, что им делать, а сам отсиживается у них за спинами. А настоящий лидер выходит вперед и говорит: «Идите за мной, если хотите жить!». Даже если вы передаете управление команде и перекладываете на людей ответственность за результат, только вы будете виноваты, если что-то пойдет не так. Четко донесите это до подчиненных и демонстрируйте это при необходимости. Делайте это, и если кому-то из ваших подопечных доведется совершить ошибку, он будет лучше готов к тому, чтобы отвечать за нее.
Как только вы состоитесь как лидер, а люди будут знать, что именно вам придется отдуваться за ваши неверные решения (и вы прикроете команду от гнева начальства), вы можете начинать перестраивать зоны контроля и ответственности в команде. Это будет непросто, так как вам придется отбирать полномочия у людей, которые этих полномочий не заслуживают, а также прививать подчиненным умение нести ответственность за совершаемые поступки. Никому это сразу не понравится, но в итоге вы окажетесь в более здоровой ситуации, в которой люди будут ощущать свою истинную роль в работе.
Есть еще несколько моментов, которые необходимо учесть, чтобы такая система работала. Во-первых, четко дайте людям понять, чего вы от них ожидаете, сформулируйте задачи так, чтобы результат их выполнения можно было измерять. Так люди поймут, что вы точно знаете, что именно от них хотите, и что вы умеете добиваться выполнения поставленных требований. Во-вторых, я стараюсь придерживаться принципа «доверяй, но проверяй». Я даю людям понять, что верю в их способность решать задачи, которые ставились перед ними при приеме на работу, но в то же время могу проверить, насколько соответствует истине то, что они мне говорят. Наконец, я никогда не указываю людям, как им работать, а заостряю внимание только на результатах процесса. Если мне приходится вмешаться в какой-либо рабочий процесс, то я считаю для себя обязательным сесть рядом с разработчиком, несущим ответственность за конкретную задачу, работать в паре с ним и помогать по мере необходимости.
Истории из практики
Ниже приведены некоторые примеры и изложены истории, которые помогут лучше понять мою концепцию. Она и так очень проста, но обычно примеры из жизни дополнительно проясняют любую ситуацию. В любом случае они интересные, и почти с каждым случалось что-то подобное.
Пример: ЧМО (чертов мерзавец-оператор)
Мой любимый пример неправильного сочетания контроля и ответственности взят не из опыта менеджеров, а из практики системных администраторов. Один админ смог убедить менеджеров, что огромные простои в работе сети возникают по вине разработчиков. Он заявил это совершенно бездоказательно и потребовал полного контроля над всеми машинами, после чего просто выдавил нас оттуда. Мы, конечно, возмутились и даже смогли показать, что все простои на самом деле возникают из-за этого негодяя, но менеджеры не стали нас слушать.
Итак, этот чертов оператор завладел доступом на все машины, и теперь любой разработчик мог попасть на свой компьютер только с его разрешения. Админ контролировал все: от прав доступа к файлам до того, какая работа выполняется на каком сервере и какими должны быть наши логины на каждой машине. Тем не менее, когда ложился сервер, кто-то ломал систему, возникало переполнение файла логов или возникали любые другие проблемы, админ все сваливал на нас, и нам приходилось работать даже в выходные, чтобы исправить проблему.
Самое печальное заключалось в том, что в каждом конкретном случае мы действительно могли доказать вину админа. Отличный пример: как-то раз я проторчал на работе все воскресенье и понедельник, пытаясь докопаться до того, почему же не работает наш сервер, пока не убедился, что он просто не ротирует логи Apache. Размер логов вырос до двух Гбайт, после чего Linux поперхнулся каким-то файлом, и Apache принудительно разорвал соединение. Тем не менее админ все равно сумел выкрутиться и опять свалить вину на нас, хотя он и контролировал абсолютно все на этих машинах.
Менеджеры прокололись, потому что наделили этого человека властью, но не заставили его нести ответственность за результат. Они продолжали песочить разработчиков, хотя никто из нас не мог войти в систему и исправить проблему без разрешения админа. Хуже того, менеджеры игнорировали все наши доводы и постоянные жалобы, так как стоило админу сосредоточить в своих руках все управление сетью, как он стал клеветать на других, пытаясь удержаться на этой работе.
Если бы менеджеры повели себя иначе и возложили на это ЧМО ответственность за перегрузку машин, а также все тщательно измерили бы, итог был бы другим. Кстати, мне удалось внедрить такую практику в нескольких организациях. Как только это происходило, админ начинал с готовностью раздавать разработчикам пароли и привлекать их к планированию рабочего процесса.
Админ настраивал систему мониторинга, чтобы иметь возможность обосновать свои данные по показателям максимальной нагрузки и получить желаемый бонус. Он не расставался с пейджером и стремился участвовать в планировании развертывания кода вместе с командой разработчиков.
В других ситуациях мне приходилось отбирать полномочия у администратора и передавать их разработчикам, так как он отказывался брать на себя ответственность. Эта история произошла уже в другой компании, но парень тратил целые часы на развертывание приложений, тогда как команде разработчиков для этого требовалась только отмашка и пять минут. Админ наделал драконовских брандмауэров, выстроил смехотворные ограничения «по соображениям безопасности» и не слушал нас, когда мы ему рассказывали, как нужно развертывать приложение.
Когда дела стали плохи и он во всем обвинил нас, так, что нам даже пришлось дорабатывать проект вне офиса и выполнять все администрирование самостоятельно, чтобы получить необходимый контроль над ситуацией. Мы взяли все на себя, и внезапно показатели под высокой нагрузкой улучшились, развертывание пошло как по маслу, а работа с консультантами упростилась до предела. Этот админ в конце концов уволился, и это было к лучшему. Однажды он сказал мне: «Вы хороший программист, но ничего не понимаете в развертывании». Речь тогда шла о проекте на Rails с использованием Mongrel. Ну да, конечно, ничего я не понимаю.
Пример: стриптизерши и бифштексы
Если говорить о менеджерах, то наиболее красноречивым будет пример, который я называю «Маневр со стриптизом и бифштексами». Все происходит примерно так:
- специалист по продажам приглашает вашего менеджера сытно отужинать бифштексом, причем деловой ужин незаметно превращается в поход в стрип-бар;
- после такой культурной программы (в некотором подпитии) менеджер подписывает контракт на покупку какой-то дряни;
- на следующий день этот «самохвалов» с головной болью является на работу и заявляет, что все переходят на использование нового продукта, который он вчера приобрел;
- у всей команды уходит целая неделя на то, чтобы как-то интегрировать это убожество в свой инструментарий и в рабочие процессы, пока наконец все не убедятся, что эта новинка — полная дрянь;
- но руководство уже изрядно на нее потратилось, и вас ставят перед фактом: работаем с этим.
Другой вариант — некий недалекий менеджер прочитает статейку на каком-нибудь сайте Fast Company или CIO Magazine. И решает испробовать какой-то инструмент или какую-то методологию, которые, как там утверждается, где-то отлично работают. Для этого выбирается проект, на котором всем на все плевать.
Это классический пример несоответствия контроля и ответственности. Менеджер определяет инструменты и методологии, которые будут использоваться в работе, но, будучи не вполне информированным, принимает неверные решения. И менеджер никогда не согласится взять на себя ответственность, если предложенный им инструмент окажется дрянью, потому что «ну ведь в НАСА он сработал!». Если программисты не могут заставить эту штуку фурычить — значит, они идиоты. Сам инструмент вне подозрений.
Чтобы не сталкиваться с такими проблемами, никогда не принимайте скоропалительных решений о приобретении нового инструмента. Контракт может быть заключен только после того, как продавец побеседует с самым авторитетным из ваших разработчиков, а сам разработчик протестирует этот продукт. Кроме того, никогда не заставляйте людей пользоваться новым инструментом, особенно если не готовы признать, что новинка может не прижиться и придется отказаться от нее. Моя позиция такова: если продавец не может за один день организовать интерактивную презентацию, в ходе которой моя команда поработает с продуктом, то этот продукт нам точно не нужен. Обосновать? Если компания, разработавшая инструмент, не может объяснить десятерым программистам, как пустить его в работу в течение дня, то как моя необученная команда будет его осваивать?
Предупреждения
Первое предупреждение: если вы опробуете такую стратегию, но она не сработает — не упорствуйте и не пытайтесь ее внедрить. Все мы знаем, как гики втягиваются в процесс и прикипевают к нему, даже если он никуда не годится. Потратьте время, проанализируйте, почему эта стратегия не приживается, а потом откорректируйте ее, чтобы она вписывалась в вашу ситуацию. Я обрисовал лишь общие правила, которые, по моему опыту, являются действенными, но никогда слепо им не следовал.
Второе правило — не настаивайте на увольнении сотрудников, если только они не страдают дремучей некомпетентностью и необучаемостью. Мне удавалось научить практически любого, поэтому увольнять приходилось лишь самых высокомерных, которые не желали учиться из-за собственного эго. Обычно я не увольняю людей, а просто перевожу в другую команду, где им лучше удается реализовать себя.
Наконец, лишь одна описанная здесь стратегия не сделает из вас компетентного менеджера. Вам придется изучить массу других материалов о том, как измерять ход процессов, как мотивировать людей, как воспитывать правильное отношение к труду, и, наконец, научиться планировать время. Я прочитал такое множество подобных книг, что уже не нахожу в них ничего нового. Всегда старайтесь извлекать из информации рациональное зерно и все постепенно опробуйте, и в конце-концов новый метод начнет приносить вам пользу.
Кроме того, я хотел бы пожелать каждому амбициозному менеджеру удачи. Без нее не обойтись.
Зед Шоу
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.