Обложка статьи «Стоит прочитать: обзор книги Майкла Лоппа «Как управлять интеллектуалами. Я, нерды и гики»»

Стоит прочитать: обзор книги Майкла Лоппа «Как управлять интеллектуалами. Я, нерды и гики»

Александр Громов

Александр Громов, ведущий разработчик IT-компании NodaSoft

Я прочитал эту книгу, когда мы в NodaSoft работали на самоизоляции и это, наверное, лучшее, что я прочитал в тот период. Майкл Лопп щедро поделился богатым опытом управления айтишниками, приводя многочисленные примеры кейсов и персонажей. Многие ситуации оказались настолько близки мне, что хотелось воскликнуть, — да, вот так оно и бывает!

Кто в этом зоопарке смотритель клетки со львами

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

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

Совещания с пользой

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

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

Эффективный тет-а-тет

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

Есть несколько принципов, которые помогут сделать такие встречи продуктивными. Без предварительной подготовки толку будет мало. Одного вопроса «как дела?» недостаточно, чтобы тет-а-тет прошел эффективно и принес пользу. Хотя такой вопрос и хорош для начала диалога, автор даже приводит его в качестве вопроса-открывашки.

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

Принести пользу и расстаться друзьями

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

Каждому сотруднику индивидуальный подход

Приведена авторская классификация психотипов людей, встречающихся в командах айтишников. Как и всякая подобная классификация, содержит несколько знакомых каждому руководителю типов сотрудников и несколько новых, встречаться с которыми к счастью пока не пришлось. Этот раздел может быть полезен в том случае, если вы испытываете сложности в работе с конкретным из описанных типов людей и не можете самостоятельно решить их. В остальном подобная классификация носит субъективный характер и имеет больше развлекательный характер, нежели обучающий.

Работать вместе

Существенную часть книги занимают вопросы разрешения различных конфликтов, так часто возникающих в тесных сообществах на подобии IT-команд.

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

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

***

Могу рекомендовать книгу как начинающим тимлидам, так и опытным руководителям, под руководством которых сформировалась уже не одна айтишная команда.