Pull to refresh

Менеджерам пора проснуться

Reading time 4 min
Views 34K
Original author: Marcus Blankenship

«Разве у тебя нет цикла, который можно написать?»

Самая популярная моя статья называется «Почему ваш программист просто хочет кодировать». К настоящему моменту её прочитали более 62 000 раз.

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

К сожалению, я не получил почти никакого отклика от менеджеров или руководителей по поводу этой истории.


Похоже, кто-то не понял суть, так что я скажу прямо.

Технические менеджеры, такие ситуации — это ваша вина


Вы несёте ответственность за немотивированных программистов, которые «просто хотят кодировать» и которых, похоже, волнуют только модные новые технологии.

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


Вместо этого создаётся впечатление, что многих программистов рассматривают как слабоумных всезнаек — вундеркиндов, способных только программировать.

Прекратите это. Серьёзно.

Огромный резонанс той статьи должен напугать вас до чёртиков. Рынок разогрет, что даёт им власть отправить вас в отставку и заменить лучшим руководителем.

Я чувствую, что они сердиты как черти — и больше не собираются это терпеть.

Не верите? Читайте дальше…

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

Вместо этого я получил тысячи ответов («аплодисменты» на Medium, комментарии и сообщения) от программистов, которые хотят понимания со стороны менеджеров. Хотят, чтобы их культуру принимали, чтобы их идеи обсуждали и оспаривали.

Вот некоторые комментарии, которые выделяются среди всех…

«О господи! Этот феномен принятия в штыки новых идей — главный убийца на всей земле, он вредит каждому отделу (это не только проблема программистов)».

«Когда я пришёл на работу, то был готов изменить мир. Теперь я каждый день изо всех сил стараюсь подавить свои истинные мысли — и просто мириться с тем, как обстоят дела… Я ДЕЙСТВИТЕЛЬНО надеюсь, что руководство скоро начнёт понимать проблему».

«Мне пришлось пройти через нечто подобное, я даже перестал работать над домашними проектами, потому что программирование на работе стало противным и требовательным — я рад, что просто уволился через пять месяцев!»

«Грустно, что культура программирования в моём нынешнем окружении требует от программистов просто завершать задачи, а не думать и делиться идеями».

Комментатор по имени Hasen имеет немного другое мнение.

«Нам не нужно “принятия” идей. Мы должны видеть, что наши идеи обсуждаются и оспариваются, а решение основано на ценности идеи, а не на должности её автора.

Если я подам идею, её обсудят, а затем отвергнут, это нормально.

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

Когда это произойдет, я по сути буду искать другую работу».

Этот последний комментарий подводит итог. Создайте окружение, в котором программисты могут полноценно вносить свой вклад, иначе лучшие из них уйдут.

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


Приступим к изменениям


Начните слушать и прекратите говорить


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

Начните это в следующем разговоре один на один. (Не проводите разговоры один на один? Обратитесь к моему руководству для начала).

Шаг 1: будьте скромным


Начните заново разговор с каждым сотрудником и честно спросите, не были ли вы глухи к его идеям, не рассматривали ли его как «ресурс» и не разочаровывали ли его.

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

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

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

Шаг 2: больше слушайте, меньше говорите


Во всех взаимоотношениях с командой говорите вдвое меньше. А потом ещё вдвое меньше.

Вероятно, это застигнет их врасплох, особенно если вы всегда «наступали с передовых позиций» и раздавали распоряжения.

Вместо этого слушайте, как они разговаривают друг с другом. Как они говорят о клиентах, руководителях или других командах. Кто контролирует поток? Кто до сих пор пытается выдвигать идеи? А кого полностью заткнули?

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

Шаг 3: чаще спрашивайте, чем говорите


Большинство менеджеров по разработке привыкли говорить инженерам, как нужно выполнять работу. Вероятно, потому что они сами раньше были инженерами и они «ясно видят решение».

Тем не менее, такие распоряжения не укрепляют команду, а затыкают коллег.

Так что начинайте задавать больше вопросов. Много вопросов «ПОЧЕМУ?» Конечно, придётся подключить любопытство и внимательно слушать ответы.

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

Книга Эда Шейна «Скромный вопрос» — прекрасный ресурс, чтобы научиться задавать лучшие вопросы.

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


(Все ещё не убеждены? Почитайте сотни комментариев от разочарованных разработчиков, которые требуют лучших менеджеров, а затем спросите себя: «Не такая ли ситуация у меня?»).

Продолжение: «Выученная беспомощность в разработке ПО»
Tags:
Hubs:
+57
Comments 119
Comments Comments 119

Articles