От разработчика до руководителя. Менеджмент для IT-специалистов - Камиль Фурнье

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

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

Хороший менеджер, плохой менеджер: «царь организационного процесса»

«Царь организационного процесса» уверен, что существует один-единственный организационный процесс и при правильной эксплуатации он поможет решить все проблемы команды. Такие «цари» могут быть одержимы agile-, kanban-, scrum-процессами, «методами бережливого производства» или даже «каскадной методикой». Они точно знают, как эффективно организовать работу системы on call (получение сигналов о сбоях в работе программного обеспечения в режиме реального времени), как нужно организовывать проверку (инспекцию) кода, как и весь процесс релиза готового продукта. Обычно такие люди очень организованны и любят детали. Как правило, они хорошо знают все производственные нормы и правила и неукоснительно следуют им.

«Цари организационного процесса» обычно обнаруживаются в подразделениях по контролю и обеспечению качества, группах по менеджменту продуктов и сервисах для организации поддержки клиентов. Их много также в консультационных агентствах и других организациях, где востребовано точное измерение прогресса проекта или выполняемых работ. Некоторые могут иметь отношение к разработке софта, однако их обычно мало в классических группах разработчиков. Такие люди бывают исключительно ценны в командах по управлению проектами, потому что благодаря им ни одна задача не забывается и все идет в соответствии с установленными процедурами.

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

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

Антипод «царя» — не менеджер, полностью отставляющий в сторону все процедуры, а менеджер, понимающий: организационные процессы должны отвечать потребностям команды и ее работы. Как это ни смешно, но хотя agile-методы обычно претворяют в жизнь довольно жесткими способами, принципы Agile Manifesto — квинтэссенция здоровых моделей управления.

Интересы отдельных работников и их взаимодействия должны стоять над интересами «процессов и методик».

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

Сотрудничество с клиентом должно иметь преимущество над процедурой переговоров.

Умение реагировать на возникающие изменения должно стоять над неукоснительным следованием плану.

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

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

Как быть хорошим техническим руководителем

Хорошему техническому руководителю нужны разные качества, но вот главные.

Поймите архитектуру системы

Если вы становитесь техническим руководителем и чувствуете, что не полностью понимаете архитектуру системы, для которой работаете (то есть совокупность важнейших решений об организации программной системы), потратьте необходимое время, чтобы разобраться в ней. Изучите ее. Поймите ее смысл. Мысленно представьте себе ее образ. Разберитесь в ее элементах. Поймите, где сконцентрированы данные, как они путешествуют по системам. Разберитесь, как система связана с продуктами, поддерживаемыми ею, какова центральная логическая идея продуктов. Руководить проектами без понимания архитектуры, подлежащей изменению, почти невозможно.