Почему программисты хотят просто писать код: Серия 2

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

[sendpulse-form id=”278″]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начните это в следующем разговоре один на один.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В заключение

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