Как хорошему разработчику не стать плохим менеджером

История про ненужные сложности

Как-то устроился я менеджером в одну небольшую разработческую контору. И мне почти сразу после выхода на работу сказали, что одного моего разработчика, Сергея, надо срочно уволить. Мол, от него проблемы уже много лет, и попробовали уже всё, и ничего не помогает, и надо увольнять. И владелец компании мне это говорил, и руководитель HR. Очень уверенно говорили.

Но когда я спросил, почему Сергея ещё не уволили, ответа я не получил. Так как я с Сергеем ещё не работал, то и увольнять мне его было не за чем. О чём я и сообщил. Я знал, что своих людей надо защищать, так что Сергей получил ещё один шанс.

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

Я сообщил об этом владельцу компании и отделу HR, получив в ответ ожидаемое: “Мы же говорили!” Владелец сказал, чтоб я увольнял Сергея, как можно быстро, так как тот и так много вреда компании принёс.

С увольнением проблем не ожидалось. Сергей прекрасно понимал, что его поведение непрофессионально, и увольняться “по статье” не хотел. Так что он согласился расстаться миром и написать заявление по собственному желанию. Заявление на увольнение нужно было подписать у владельца компании, к нему я Сергея и отправил.

А вот дальше случилось неожиданное для меня. Владелец сказал Сергею, что он совсем не хочет Сергея увольнять, что это этот менеджер, Константин Борисов, почему-то требует увольнения, а так бы Сергей работал и работал. В результате Сергей уверился, что я испытываю какую-то личную неприязнь к нему, и что владелец компании поддерживает его. Мне же владелец напомнил, что Сергея нужно срочно увольнять.

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

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

Исправление ошибок

Исправление ошибок – это больная тема. Часто от разработчиков можно слышать про менеджеров: “Ну он же не с компьютерами работает, а с людьми! Тут ошибки исправить нельзя! Поэтому и допускать их нельзя!”

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

А вот насчёт исправления ошибок ситуация интересней. Что подразумевает разработчик, когда говорит, что он исправил ошибку? Он подразумевает, что в код внесены изменения и баг, который там был, теперь отсутствует. Но разве такое “исправление” достаточно, чтобы действительно исправить весь нанесённый ущерб? Конечно, нет. Тестировщики потратили время, работая с неисправным билдом. А теперь еще новый заново тестировать. Другие разработчики мучались при реализации своих кусков, так как код работал некорректно. Заказчик, видел баг в трекере и терял доверие ко всей команде.

Если разработчик исправит злой баг, из-за которого долго лежал сервер, то ему не стоит говорить заказчику: “Я всё исправил, теперь всё хорошо!” Так как с точки зрения заказчика всё совсем не хорошо, и ему нужно что-то делать с толпой недовольных пользователей.

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

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

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

В результате вы получаете от этого разработчика заявление на увольнение и понимаете, что затянули с переводом. Вы зовёте разработчика к себе и говорите: “Всё-всё Вася, я понял, что тебе действительно хочется на другой проект. Вот я уже оформил твой перевод. Начинай вникать сегодня. А заявление забери, я всё исправил”.

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

Гораздо более правильным было бы признать свою ошибку и не говорить ни о каком “исправлении”, а говорить о будущем. Примерно так: “Вася, мне очень жаль, что ты решил нас покинуть. Очевидно, что это моя вина. Я недостаточно приложил усилий к твоему переводу. Мне жаль тебя терять и я хотел бы сделать всё, чтобы ты остался. Могу предложить тебе переход на любой другой проект вот из этого списка прямо с сегодняшнего дня. Текущему проекту будет тяжело, если ты уйдёшь, но ты с него уйдёшь в любом случае, а мне хотелось бы, чтобы ты остался в компании”. При таком подходе, когда менеджер признаёт свои ошибки и даёт человеку какой-то выбор, шанс на то, что человек останется в команде гораздо выше.

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

Люди, приносящие плохие известия

Менеджеры по роду своей деятельности решают проблемы. Это не вызывает вопросов и любой менеджер этого ожидает. Менее очевидно и ожидаемо следствие: люди к вам идут только с проблемами. Если у разработчика стряслась какая-то беда, он обязательно даст знать своему менеджеру. А вот если у разработчика всё хорошо или даже лучше, чем ожидалось, то менеджер об этом узнает, только если спросит.

Менеджер проводит львиную долю своего времени с проблемными людьми. Если в вашей команде 10 человек, из которых 9 работают идеально, а 1 находится на грани увольнения, то вы будете 90% своего времени проводить с этим единственным проблемным сотрудником. Беспроблемный сотрудник раз в день скажет, что всё идёт по плану, а детальную информацию можно всегда получить в трекере или по почте. А с проблемным всегда уходит куча времени на то, чтобы узнать, как у него дела, где ему нужна помощь, какой статус у каждой задачи. Хороший сотрудник даже проблему свою подготовит для менеджера, так что вы будете хорошо понимать, что именно произошло, и какой выбор есть. Так что на решение вопроса уйдёт несколько минут. У сотрудника нерадивого всегда всё мутно, и вам приходится тратить огромное количество времени и сил, просто чтобы разобраться в происходящем.

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

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

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

Некоторые менеджеры ломаются на другом. Вот есть просто идеальные работники, опора и отрада любого менеджера. Они быстро и качественно выполняют любую данную им задачу да ещё и тащат кучу задач не своих. Вы таких работников практически не контролируете, потому что в особом контроле они не нуждаются. Такому работнику вы доверяете. И вот в один из дней такой идеальный работник косячит. Причём косячит очень сильно и глупо, принося столько проблем, сколько обычный косячник никогда не приносил. И вот тогда менеджер страшно кричит: “И ты, Брут?!” и навсегда теряет веру в людей.

Хотя на самом деле в такой ситуации менеджеру некого винить, кроме себя самого. У каждого человека есть право на ошибку. Любая более-менее сложная деятельность полна ошибок. Масштаб ошибок напрямую зависит от уровня сотрудника. Джуниор-разработчик вряд ли может нанести серьёзный ущерб (если в организации есть минимально разумные процессы), у архитектора масштаб косяков куда выше, а генеральные директора и владельцы компаний могут делать миллионные косяки.

Так что сам масштаб ошибки не свидетельствует против человека сам по себе.  И то, что эта ошибка кажется “глупой” тоже не должно вводить в заблуждение. Такими кажутся большинство ошибок после того, как они совершены. Это совсем не значит, что эту ошибку было так легко предотвратить. Опять же такой доверенный сотрудник уже привык решать проблемы сам, не отвлекая вас. Поэтому он может довести проблему до более “запущенного состояния”.

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

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

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

Кейс “Прикрыть товарища”

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

Разработчики опытные,  проект простой, поэтому проблем не ожидается.

Но одна проблема есть: Вася, похоже, оказался тихим алкоголиком. Петя заметил с самого первого дня, что от Васи по утрам часто разит перегаром, а по понедельникам тот приходит с больной головой. Иногда Вася не появляется на митингах с заказчиками, либо приходит на работу очень поздно и явно с похмелья, либо выпивает в обед и полдня ничего толком делать не может.

Вася и Петя эту проблему не обсуждают, делая вид, что ничего не происходит. Петя иногда “прикрывает” коллегу перед менеджером или заказчиком: отвечает на вопросы по его тикетам или говорит, что Вася куда-то вышел и скоро вернётся, или исправляет какие-то ошибки, которые Вася наделал в подпитии.

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

Анализ

Распространённая ситуация, когда некоторый “Петя” хочет быть “хорошим” и творит добро в отношении некоторого “Васи”. Очень полезно в таких ситуациях поглядеть на происходящее с точки зрения морали. Давайте применим золотое правило морали: поступайте с другими так, как хотели бы, чтобы поступали с вами.

Хотели бы вы сами, чтобы в подобной ситуации кто-то рисковал своей карьерой “прикрывая” ваши косяки? Я бы не хотел. За свои ошибки я предпочитаю нести ответственность сам. Вася не просил Петю помогать, он не благодарил его за его помощь. Нет оснований полагать, что ему эта помощь нужна. Он, возможно, вообще таким способом хочет уволиться, похожие ситуации бывали на практике. Я сам крайне не люблю, когда за меня решают, что я хочу, а Петя именно это делает. В общем, петино поведение можно смело назвать аморальным, так как золотому правилу морали оно не соответствует. Так часто бывает, когда люди хотят быть “хорошими” и начинают что-то делать, чтобы соответствовать этому абстрактному ярлыку.

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

Во-вторых, отсутствие силы воли и склонность к алкоголизму не является такой страшной проблемой с точки зрения руководителя. Менеджеру очень просто придать силы воли такому сотруднику: можно поставить жёсткие условия, чтобы он присутствовал на работе в рабочее время, и чтобы его производительность не падала ниже приемлемого уровня. Если Вася работает неудовлетворительно, с ним легко расстаться. Возможно, с ним так и договаривались при приёме на работу.

Кажется рискованным иметь такого Васю в команде, но это потому, что мы уже видим его почти в стадии запоя. А начинались же проблемы постепенно. Вася был просто оболтусом, который пришёл в компанию, где за ним слабо приглядывает начальство и начал пробовать границы дозволенного. Если бы в самом начале его “выкрутасов” менеджер объяснил ему возможные последствия, то он бы работал без особых проблем.

А что же пошло не так? А не так пошло то, что Васю начал прикрывать Петя. Причём очевидно, что Петя ключевой сотрудник (ну не Вася же) и вокруг него будет организовываться весь филиал. Петя явно сильный разработчик, так как тянет свою работу да ещё и васину. Если бы он просто не делал ничего, то менеджер заметил бы проблему с Васей и сделал что-нибудь с ней. Но Петя мало того, что не помог, а он активно мешал, давая неправильную информацию. Он мешал менеджеру делать свою работу. Из добрых побуждений, конечно, но с ужасным результатом.

Чтобы лучше понять, как на это может отреагировать менеджер, давайте рассмотрим симметричную ситуацию. Представьте, например, что менеджер по-тихому отключит запуск unit-тестов на ежедневном билде. Аккуратно, чтобы никто не заметил. А на недоумение команды ответил бы: “Ну, я помочь хотел. Вы много времени на unit-тесты тратили, а они же низкоприоритетные. Ими и потом можно заняться”.

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

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

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

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

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

Мотивация и жёсткость

Иногда слышу, как руководители говорят: “Мотивация – это хорошо, конечно, но сколько можно разработчиков гладить по головке? Надо делом заниматься!” Почему-то в массовом сознании отпечаталось, что чтобы мотивировать, менеджер должен быть “добреньким” и позволять команде делать, что угодно.

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

Я сам себя считаю довольно жёстким руководителем. У меня есть большой опыт антикризисного управления, когда дело требует принятия быстрых и непопулярных решений. Часто я работаю в таких проектах, которые сами по себе диктуют жёсткие условия (Fixed Price, требовательные заказчики, меняющийся бизнес). Но когда я про свою жёсткость говорю со своими разработчиками (бывшими для чистоты эксперимента), то они со мной не соглашаются:

– Да ну, Константин, какой же ты жёсткий? Не орёшь никогда, всегда выслушиваешь и по-человечески относишься.

– А ничего, что я за пару месяцев уволил людей больше, чем предыдущий менеджер уволил за прошлый год?

– Ну, у тебя работа такая. Там и так понятно, почему каждый был уволен. В проекте кризис, требуются решения.

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

– Ты знаешь, то, что ты признаешь свои ошибки, уже достаточно редко. Ты просто жёстких менеджеров не видел.

Я уже не спорю. Не жёсткий, так не жёсткий. Меня очень радует, что команда понимает, что я делаю свою часть работы, и позволяет мне делать то, что нужно для проекта. Людям достаточно, что я объясняю, что и зачем я делаю, что я реально слушаю других, и что я признаю свои ошибки. Удивительно насколько мало нужно команде, чтобы уважать менеджера. И вдвойне удивительно, что команда так редко это малое получает.

История про очередь на увольнение

В столице нашей родины, Москве, в большом офисном центре работала небольшая разработческая команда. Это был филиал международной компании с главным офисом во Франции. И у этой компании настали тяжёлые времена, из-за чего ей пришлось увольнять разработчиков.

Но так как компания была французской, то и внутренние policy были написаны с оглядкой на трудовые законы Франции. Поэтому, если человек увольнялся сам, то он просто уходил, а вот если компания его увольняла, то человек получал компенсацию. Компенсация зависела от стажа работы в компании, но примерно равнялась зарплате за год-другой. Учитывая, что зарплаты были совсем не низкими, компенсация была просто громадной кучей денег.

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

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

– Андрей, я работаю на тебя с самого дня открытия филиала. Ты должен мне пойти на встречу. Уволь меня, из меня ипотека все соки выжимает!

– Не могу я тебя уволить. Без тебя наш проект загнётся.

– Уволь, а? Я буду вечерами работать. Ты даже не заметишь, что я уволен!

…

– Андрей, уволь меня, а то я уволюсь сама!

– Полиси компании рекомендуют не вести переговоры с террористами.

– Тогда я не уволюсь, а ребёнка рожу! Будешь знать!

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

…

– Андрей, почему ты уволил этого рукожопа Олега?! На его месте должен был быть я!

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

– И теперь он счастливый бухает в баре, а я по-прежнему пашу! Где справедливость?!

– Справедливости в жизни нет. Не могу же я уволить всех ключевых сотрудников. Как мне проекты делать? Работай иди.

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