Константин Евгеньевич Борисов
Как хорошему разработчику не стать плохим менеджером
Не ругать свою команду
Одна из вещей, которые менеджер не должен никогда делать – это ругать своих подчинённых. Начинающему менеджеру как обычному человеку хочется поныть про свои беды: “Вот Петя такой косячник, такой косячник. У меня из-за него сплошные проблемы. Он вообще не понимает, что он делает”. Так вот каждый менеджер должен над собой работать, чтобы подобные желания у него даже не просыпались ни при каких условиях.
Быстрее всего менеджер учится не ругать свою команду при своих подчинённых, потому что это самый простой путь потерять доверие людей и разрушить команду. Поймите правильно, не нужно делать вид, что вы слепы к недостаткам других, но любую критику нужно давать очень аккуратно, не навешивая ярлыки и правильно расставляя акценты. Очень большая разница между формулировками “Петя невыносим, это всем известно! Мне на него все жалуются!” и “Я знаю, что Пётр не самый приятный в общении человек и только его уникальный опыт перевешивает его недостатки. Я понимаю, что с ним бывает трудно, и готов помогать. Если есть какие-то конфликты, то скажи мне, и я возьму на себя неприятную часть общения с ним”.
Гораздо сложнее менеджеру даётся понимание, что нельзя ругать свою команду своему начальству. Неопытный менеджер часто хочет оправдать проблемы на своём проекте ошибками подчинённых: “Мы релиз задержали из-за того, что Игорь пропал без объяснения причин и не сделал свои задачи!”
Казалось бы, хорошее оправдание? Нет. По нескольким причинам. Во-первых, оправдания никого не интересуют. Не только в менеджменте, но и в любой области бизнеса.
Во-вторых, менеджер работает с людьми, это его область ответственности. Ругать своих людей менеджеру так же бессмысленно, как разработчику, ругать свой код. Менеджер тем ценней, чем с большим количеством разных людей он может работать. Никому не нужен менеджер, который работает только с идеальными исполнителями. Потому что таких нет, а если они и есть, то с ними может работать кто-то другой, менее опытный и ниже оплачиваемый. Мало ценится разработчик, который может писать только простые алгоритмы. Также и менеджер ценится, когда он может работать с трудными людьми.
Так что не надо рассказывать своему начальству, подчинённым и знакомым, что вы завалили свои задачи из-за трудностей с командой. Лучше поругайте себя за то, что не справились со своей работой.
“Не хочу, не буду!”
Часто нежелание человека делать свою работу представляют как “смертный грех”, который ставит крест на работнике как профессионале, и с которым менеджер ничего не может поделать. Говорят: “Ничего нельзя сделать, если человек просто не хочет работать”. Как и большинство прочих расхожих истин, эта "истина" ложная и часто заводит менеджеров не туда.
Первая причина порочности такого подхода выходит из самого понятия “мотивация”. Менеджеры обязаны мотивировать свою команду, в случае необходимости. А что такое мотивация? Это как раз стимуляция желания делать какие-то действия. То есть команда не хочет делать то, что надо менеджеру, а он её мотивирует, чтобы она таки это делала.
Обычно под мотивацией понимают какие-то высокие свершения, вроде сверхинтенсивной работы без выходных. Но на практике вот такая ежедневная мелкая мотивация на ежедневные, часто рутинные задачи важнее, так как именно от неё зависит средняя производительность команды.
К счастью в IT команды обычно высокомотивированные и они сами хотят работать, как можно лучше. Менеджеру не приходится сталкиваться с ситуацией, что без него никто ничего не делает. Но это не значит, что мотивация нужна редко.
Легко вспомнить ежедневные ситуации, когда человек высказывает своё “не хочу, не буду”. Например, от заказчика приходит очередное изменение давно реализованных требований и надо переписывать код. Или менеджер хочет, чтобы оценка в часах была вписана во все тикеты Jira. Или кто-то сломал билд, а от непричастного к этому разработчика ждут, что он его починит. Или заказчик организовал ежедневные митинг в неудобное время. Или нужно задержаться для исправления мелкого, но неприятного бага.
Во всех перечисленных ситуациях естественной реакцией многих будет: “Не хочу!” Кто-то справится с этой реакцией сам, кто-то пойдёт жаловаться менеджеру и тому придётся заниматься этой самой мотивацией. Но в любом случае в IT командах нежелание что-то делать даже из того, что делать надо обязательно, является нормальным. Это часто удивляет людей, от IT далёких.
Более того, такая “демотивированность” часто является полезной, так как жгучее нежелание что-то делать – это вполне себе движущий фактор. Например, если заказчик принимает непопулярное техническое решение, то разработчики могут очень быстро провести исследование, подготовить обоснование выбора другой технологии и даже реализовать прототип, которые убедит заказчика. Или нежелание ходить на ежедневные митинги в неудобное время может замотивировать вовремя обновлять все тикеты и писать письма с подробным описанием сделанного.
К тому же люди в IT часто бывают высочайшими профессионалами. И даже, если они почему-то чего-то не хотят, то они всё равно могут выдавать очень хороший результат.
Хотя иногда люди наотрез отказываются делать то, без чего работать невозможно, и это нормально. Например, как-то целый проект переводили с Java на .Net. Естественно, некоторые из разработчиков не захотели менять специализацию. А в другой раз запланированная автоматизация тестирования была отменена и многие тестировщики, планировавшие стать автоматизаторами, не захотели продолжать работать в ручном тестировании.
Ситуации бывают разными и следствия из них бывают разными, но надо чётко понимать, что простое нежелание что-то делать, может иметь очень интересные корни, до которых менеджер должен докопаться. И ответ: “Не хочу,” не должен автоматически навешивать какой-то ярлык. Желание и нежелание – это обычный материал любого менеджера, работающего с людьми.
История про способ уволиться
Маша работала не в IT, она была менеджером по продажам. Маша делала “холодный обзвон”, каталась по офисам компаний и заключала новые контракты. И она очень не любила увольняться. Никто не любит, конечно, но она прямо терпеть не могла эти последние разговоры, эти упрёки: “Ну что ж ты так нас подводишь?” от уже бывшего начальника, эти ненужные никому вопросы и ответы и эту бессмысленную двухнедельную отработку. А увольняться ей приходилось часто. Она постоянно меняла места работы.
Поэтому она поступала проще. Она просто не выходила на работу, брала такой самовольный отпуск на пару недель. Телефонные звонки она отклоняла. А потом она просто заходила в отдел кадров, забирала трудовую книжку с записью об увольнении за прогулы и шла устраиваться на новое место. Так как она работала в одиночку, без команды, то она никого не подводила. Ну, кроме своего начальника, но отношения с ним при увольнении, как показывал её опыт, всё равно портились.
Вот и в этот раз она решила “увольняться” старым испытанным методом – просто не вышла на работу. Её начальник, Иван Иваныч, звонил много раз, так что ей даже пришлось добавить его в “чёрный список”. Звонили и из отдела кадров пару раз, но она не брала трубку. Чего тут разговаривать? И так всё понятно.
Но когда она через обычные две недели пришла за своей трудовой, в отделе кадров ей сказали, что она не уволена. “Иваны Иваныч, приказ на тебя не подавал”, – ответили они. А тут и сам Иван Иванович прибежал: “Машенька, ну наконец-то ты вернулась! Что случилось? Я знал, что что-то случилось. Ты так неожиданно пропала, и телефон твой перестал отвечать. На меня начальство давит, чтоб я нашёл тебе замену, но я-то тебя знаю. Я знал, что ты вернёшься и все наладишь. И вот ты вернулась! Ты когда сможешь полностью на работу вернуться?”
В этот раз Машеньке всё-таки пришлось пройти через все эти разговоры, вздохи, взгляды и отработки, которые она так не любила. И в этот раз всё было в разы тяжелее для неё, чем обычно.
Признание ошибок
Ошибки в области разработки ПО – это не какие-то экстренные ситуации, это норма. Иногда разработку сравнивают со строительством дома, но это сравнение очень далеко от реальности. Дома проектируются и строятся точно по плану, план меняется очень редко и крайне незначительно, дома в основном типовые или как минимум состоят из типовых частей.
Разработка скорее похожа на съёмки фильма. Да, есть сценарий, но он не включает в себя все детали и постоянно переделывается. Каждая сцена снимается и переснимается, пока не получится так, как надо. И в процессе случаются многочисленные накладки разной степени ужасности: актёры беременеют, бюджет меняется, меняются законы и т.д. В таких условиях даже сам подход “сделать сразу без ошибок” не имеет смысла. Это как сказать актёрам: “Плёнки на дополнительные дубли нету, играйте сразу нормально”.
Для людей из многих других областей неизбежность ошибок кажется ненормальной. Особенно странным им кажется то, что разработчик не несёт никакой ответственности за сделанные им баги. Для нас, работающих в IT, такое положение дел логично и понятно.
Одно время я вёл примерный учёт заведённых на меня багов. Для разработчика каждый баг можно считать официальной регистрацией сделанной им ошибки. Вести счёт я прекратил, когда багов стало больше 3000. Менеджер делает свою работу в тех же условиях неопределённости, что и разработчик, поэтому в IT проекте будут менеджерские ошибки. И их будет много.
Иногда бывает, что разработчик, которому сказали, что по его функционалу нашли 20 багов, удивляется и начинает их разбирать: “Ну, этот баг – это не я виноват, это там у нас дизайн кода такой кривоватый. А эти два бага надо в один объединить, и вообще это, скорее, в требованиях ошибка. А эти баги я уже исправил, это у вас просто код старый в тестирование ушёл. А эти баги очень мелкие, они не считаются. В общем, я реализовал всё без ошибок!”
Очень странно слушать такие речи от разработчика, но совсем недопустимо, когда подобное говорит менеджер. Вместо оправданий менеджеру нужно брать на себя ответственность. Любая ошибка, сделанная командой – это ошибка менеджера. Менеджеру полезно это не только знать, но и признавать публично.
Кажется, что этот подход только мешает, но он наоборот, очень продуктивен сразу по нескольким причинам. Во-первых, “поиск виноватого” не является необходимым для решения конкретной проблемы, а занимает он ужасно много времени. К тому же часто проблема является следствием цепи ошибок разных людей: заказчик дал не совсем корректные требования, аналитик не обратил внимания на краевые ситуации, разработчик реализовал, не вникая, тестировщик не продумал полноту сценариев тестирования и т.д.
Во-вторых, проблема не может быть решена на том уровне, на котором она возникла (© Альберт Эйнштейн). Если некоторый Вася обрушил продакшн, неправильно реализовав какой-то кусок кода, то очень хочется в виде решения поругать Васю и сказать ему, чтобы он так не делал. Но обычно такие ситуации означают, что процесс построен неверно, и надо менять его, а не Васю. Юнит-тесты, код-ревью, автоматизация, Continuous Integration и прочие плотно вошедшие в индустрию практики как раз позволяют избегать тех ситуаций, в возникновении которых пару десятков лет назад обвиняли “нерадивых разработчиков”.
А в-третьих (и это самое главное), когда менеджер публично признаёт свою ошибку и берёт вину на себя, это волшебным образом меняет отношение команды к проблеме. Естественная реакция, когда что-то случилось, это заявить о своей невиновности и, для верности, найти виноватого. Это может родить шквал взаимных обвинений, заканчивающийся обидой всех на всех. Виноватым назначают заказчика, так как он, обычно, на обсуждении не присутствует, и все гордо расходятся работать в точности так же, как раньше.
Если же менеджер берёт вину на себя, то команда расслабляется и может начать думать над решением. К тому же, пока менеджер рассказывает, где и что он мог бы сделать лучше, каждый из команды понимает, что он тоже мог бы многое сделать для решения проблемы, и в следующий раз ведёт себя более проактивно. Если удастся своим примером привить команде готовность признавать свои ошибки, то уже в ближайшем будущем это принесёт очень хорошие плоды.
Только менеджер должен быть очень конкретен в признании своих ошибок. Недостаточно заявить: “Вот, у заказчика сервер упал и не поднимается. Это моя ошибка, так как только по ошибке я мог нанять таких косячников, как вы. А теперь давайте вместе подумаем, как всё исправить”.
Нужно быть очень аккуратным в выборе слов, чтобы подать пример. Менеджер должен сказать то, что он хотел бы услышать от каждого из своей команды. Например: “Как вы уже знаете, продуктовый сервер заказчика на новой версии не работает, старая версия не восстанавливается, и заказчик несёт большие убытки. Причина может быть в том, что я запланировал недостаточно тестирования на этот релиз. Или в целом процесс релиза я не сделал надёжным. Или, может, мне надо было сильнее вовлечь заказчика в процесс проверки релиза. Точная причина неизвестна и не важна. Над предотвращением таких проблем в будущем мы подумаем позднее, когда пожар потушим. А пока, кто что может предложить для того, чтобы починить сервер сегодня, чтобы, когда клиенты заказчика проснулись, они могли бы работать?”
Такой подход хорош ещё тем, что команда часто видит или думает, что видит, ошибки менеджера. И то, что менеджер свои ошибки готов признать, доверие выводит на другой уровень. Возможно, когда вы будете делать следующую ошибку, кто-нибудь вам об этом скажет раньше, чем ошибка станет непоправимой.
Добренький менеджер
Люди – животные социальные. Мы все хотим симпатий окружающих нас людей и стараемся избегать действий, которые вызовут неодобрение. Особенно, если мы говорим о людях, которых мы уважаем. Менеджеры уважают свою команду, и им бывает тяжело делать что-то такое, из-за чего их могут посчитать “плохими”. Неопытные менеджеры стараются быть “добренькими”, не делать ничего, что могло бы негативно отразиться на других.
С такими позывами каждый менеджер должен бороться изо всех сил. Решения должны приниматься потому, что они нужны, а не потому, что они кому-то нравятся. Менеджер постоянно должен принимать непопулярные решения и эти решения часто вызывают негативную реакцию. Но это необходимая часть работы менеджера. Нельзя пытаться быть “добреньким”.
Пытаться никого не обидеть – это естественная реакция неподготовленного человека, назначенного менеджером. Как ни странно, у такого менеджера в команде обычно процветают конфликты, ссоры, ругань и слёзы. Как так получается, что менеджер, старающийся быть хорошим, становится источником нервотрёпки для своей команды?
Механизм хорошо иллюстрирует одна история. В небольшой компании работал менеджер, под управлением которого было 15 разработчиков. Команда была дружная, работали все хорошо. Менеджеру работать со всеми было легко. Но тут наступил очередной экономический кризис и больно ударил по компании. Менеджеру сказали сократить его команду на треть. 5 из 15 человек должно быть уволено.
Менеджер сильно задумался. Никто у него увольняться в кризис не хотел. Все его люди были хорошими работниками, и объективно он не мог выделить каких-то аутсайдеров. То есть отбор людей для увольнения должен быть случайным, а соответственно эти уволенные люди будут считать решение несправедливым, а самого менеджера нехорошим. Менеджер так делать не хотел.
И менеджер придумал “замечательный” выход. Пусть команда сама примет решение, а он будет ни при чём. Он сказал следующую мотивирующую речь: “Друзья, в нашей компании тяжёлые времена. Мы вынуждены расстаться с пятерыми из вас, но вы все очень хорошие работники, и я не могу никого из вас уволить. Вы лучше меня знаете свои обстоятельства, поэтому обсудите между собой всё и решите, по кому увольнение ударит слабее. Вот вам листок, я жду на нём пять фамилий к концу дня”. И менеджер ушёл из кабинета, полностью устранившись от принятия такого неприятного решения.
Через пять минут после ухода менеджера команда разругалась вдрызг. Потому что один из разработчиков, Петя, заявил, что он старейший член команды и должен остаться. Ему недавно принятая разработчица, Оленька, язвительно ответила, что увольнение – это не пенсия, и выслуга лет здесь не работает. Он в ответ с шовинистической уверенностью в собственной правоте заявил, что Оленька-то в декрет выскочит и будет сидеть на шее мужа, а ему семью кормить. Оленька, обиженная до глубины души, выбежала из кабинета, и Пётр записал её первой в список. Оставшиеся в кабинете испытали некоторое облегчение от того, что их шансы повысились, и сразу устыдились этого чувства. Другой из недавно принятых разработчиков, Олег, поняв, куда идёт дело, закричал: “А чего это ты, Пётр, список составляешь?”. И начал вырывать лист. Завязалась потасовка, в ходе которой Олегу разбили нос, и он вышел в туалет. Его имя записали в изрядно помятый листочек. Снова все испытали облегчение и сразу устыдились его.
В общем, день у команды прошёл нескучно. Листок рвали и переписывали. Возникали стычки и склоки. Каждый припомнил всё, про каждого из коллег. Кто-то не выдерживал и уходил. Кто-то из ранее ушедших возвращался. В общем, менеджеру листочек с пятью фамилиями пришёл только в конце дня. Он очень удивился, так как ещё утром к нему пришла Оленька с готовым списком. Оснований не доверять тому списку у менеджера не было, так как фамилия Оленьки там была первой. Он уже составил приказ и утвердил его у руководства. Пётр тоже был в том списке.
Команда больше никогда не работала, как единое целое. Вскоре все участники этих событий нашли себе другое место работы. Проект не выдержал таких ударов судьбы и был закрыт.
Желая остаться “добреньким” менеджер разрушил свою команду, и причинил много вреда ни в чём не повинным людям. Он перекинул принятие решений на свою команду, которая не имела ни навыков, ни полномочий такие решения принимать. Поэтому вся ситуация и вылилась в такой небольшой филиал ада.
Как было правильно менеджеру провести сокращение команды? Да как угодно! Он мог выбрать пятерых по алфавиту, по времени приёма на работу или полностью случайно. Да, ему пришлось бы объяснить, что его выбор несправедлив, но это просто потому, что никакой справедливости в этой ситуации нет. Да, был бы негатив, направленный против него, но это неотъемлемая часть работы! Менеджер и нужен, чтобы нести ответственность за свои решения.
Менеджер не может действовать, исходя из одобрения других людей. Даже попытка подобного поведения пагубно отражается на других. Он должен делать то, что считает нужным.
История про жажду критики
Я работал в одной компании, где было принято очень мягко работать с сотрудниками. Там было не принято выражать критику, не важно, насколько осторожной она была. Там менеджеры очень хорошо прокачивались в сглаживании острых углов и избегании конфликтов. А работа была тяжёлая. Не все выдерживали. Многие уходили в нервный срыв, а кто-то просто брал на себя слишком много и не справлялся, подводя команду и заказчика.
Но даже, когда кто-то из команды начинал вести себя непрофессионально, его не одёргивали. Его очень мягко направляли, советовали, уговаривали. Часто подключали специалистов HR, которые так же мягко пытались привести человека в норму. Даже когда становилось очевидно, что сотрудник не может выполнять свои обязанности на нормальном уровне, его переводили на более спокойный проект, давали лёгкие задания, оставляя формально ту же должность. Людей не расстраивали.
Увольняли людей, только когда они полностью съезжали с рельсов. Например, один из разработчиков, добавленных на мой проект, просто не появился на работе, а в ответ на мои запросы пришёл, устроил истерику и ушёл домой. Таких просили уволиться, но не сразу, а через несколько месяцев мучений всех окружающих.
Кстати, именно работая в той компании, я понял, что критика как инструмент управления, в общем-то, менеджеру не нужна. Она важна для развития человека, и то только если человек готов её воспринять. Но даже у таких готовых к критике людей первая реакция на критику негативная. А для менеджера это лишние сложности. Даже если человек плохо выполнил свою работу, можно просто уточнить, как вы хотите, чтобы она была выполнена. Без всякого негатива. Можно даже извиниться, что изначально “некорректно” поставил задачу. Признать ошибку, похвалить человека и пойти дальше, унося критику с собой. Я и сам научился так делать, и много раз видел, как так делали с другими.
Когда я увидел в деталях несколько таких ситуаций, то я задумался. Это что же получается, если я не потяну свою работу, то я об этом даже и не узнаю? Меня утешат, успокоят и переведут на какой-то полу-фиктивный проект, где я даже нормальной работой заниматься не смогу? Я не буду даже понимать, что со мной что-то не так, потому что от внешних раздражителей меня отгородят, а правды о моей работе я и не услышу.
В результате вместо благодарности к компании за заботу, я начал постепенно не доверять своему руководству и компании в целом. Я пытался прямо и косвенно получать обратную связь о своей работе, но мне очень не хватало уверенности в том, что со мной будут говорить открыто. Я не верил, что мне скажут правду, если эта правда будет мне неприятна.
В результате это недоверие стало одной из причин, по которой я компанию сменил. Зато я на своём примере понял, насколько прямота нужна людям. А прямота иногда включает и критику.
