Telegram
Онлайн библиотека бесплатных книг и аудиокниг » Книги » Домашняя » Как хорошему разработчику не стать плохим менеджером - Константин Борисов 📕 - Книга онлайн бесплатно

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

155
0
Читать книгу Как хорошему разработчику не стать плохим менеджером - Константин Борисов полностью.

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 10 11 12 ... 32
Перейти на страницу:


Анализ

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

1 ... 10 11 12 ... 32
Перейти на страницу:
Комментарии и отзывы (0) к книге "Как хорошему разработчику не стать плохим менеджером - Константин Борисов"