Как хорошему разработчику не стать плохим менеджером - Константин Борисов Страница 8

Тема доверия является ключевой в работе с людьми. И если посмотреть “в среднем” (а средняя картина всегда довольно печальная), то менеджеры не доверяют своим командам, а команды не доверяют менеджерам. Это абсолютно безумная ситуация, так как менеджер работает с людьми, они его инструмент. Не доверять своей команде – это то же самое, как если бы программист не доверял своему компилятору.  Дело бесполезное и опасное.

Давайте сперва определим термин “доверие”, так как здесь есть разночтения. Доверие – это вера в то, человек подойдёт к своим обязанностям честно, постарается выполнить свою часть работы, вместе с вами будет идти к результату, будет вести себя порядочно. Это вера в человека, ограниченная рабочими рамками.

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

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

Гораздо проще сразу поверить Алексею. Сомневаться в его словах во-первых, неприлично, во-вторых, контрпродуктивно. Считайте, что действительно у него случилась какая-то критическая ситуация. Лучше даже не выслушивать оправдания, так как у человека могут быть очень личные или даже не совсем приличные проблемы, о которых он вам сообщать и не должен. Не спрашивайте об оправданиях. Зачем вам они? Считайте, что человек старался по максимуму, но у него не получилось.

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

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

Обратите внимание, что недоверие к Алексею вы не выражаете. Вы просто говорите, что он не соответствует занимаемой должности. Жёстко, не правда ли? И прикрыться оправданиями Алексей не может. Потому что в таком разрезе понятно, что вам нужна работа, а не отговорки. Но вы не выказываете и тени сомнения в том, что Алексей правда пытается прийти вовремя. Конечно, вы в это верите, просто вам нужен результат.

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

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

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

Опять же, обратите внимание, в такой постановке вопроса нет никакой “мягкости”. Я тут прямо угрожаю разработчику: “Заказчик придумает своё решение и нам придётся его реализовывать”. Это страшная угроза и она реальна. Но говорить разработчику, что я ему не верю, очень неправильно. Я ему верю, решения задачи нет. Просто нам теперь нужно решить другую задачу: предложить что-то другое заказчику.

На самом деле, нет ни одного вменяемого примера, когда имеет смысл сказать человеку, что вы ему не верите. Человек врёт вам, вы ему об этом скажите, и он резко перестанет так делать? Это сумасшедшее предположение, так общение с людьми не работает. А если вы не можете сказать никому, что вы ему не доверяете, то зачем не доверять?

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

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

И ещё иногда менеджеры смешивают доверие и технический уровень: “Задача сложная, Вася никогда не работал над такими, он может не справиться”. Это не имеет никакого отношения к доверию. Доверие – это про то, что Вася будет стараться изо всех сил (может и невеликих), а не про гарантию, что Вася справится с задачей. Работа с рисками, по-прежнему, на менеджере. Даже, если вы доверяете Васе, вы можете и должны помогать ему, контролировать его, организовывать ревью его работы более опытными разработчиками и т.д. Потому что никто (и вы в том числе) не застрахован от ошибок. И наличие ошибок не должно влиять на доверие.