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

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

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 24 25 26 27 28 29 30 31 32 ... 78
Перейти на страницу:

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

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

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

Как становятся менеджерами, управляющими людьми

Я начинала как неформальный руководитель группы (тим-лид) в компании, не признававшей менеджеров в традиционном понимании. После того как я в течение некоторого времени поруководила группой неформально, подошло время, когда меня официально назначили менеджером. Такая позиция в нашей организации была непривычной, и весь коллектив встретил мое назначение с определенной настороженностью. Когда между менеджерами разделялось инженерное направление, мы долго взвешивали, кто мог бы справиться с ним. Не все менеджеры хотели работать с бывшими коллегами, но мне повезло. Большинство тех, кем я руководила, долго проработали со мной и спокойно восприняли меня как менеджера. Их поддержка мне очень помогла. Не все обстояло гладко, но она дала очень важный для меня толчок.

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

Один из этих инженеров продолжил помогать мне советами и рекомендациями. Я очень старалась понять, что было важно для этого человека и как я могу обоим инженерам помочь в работе. Второй инженер не сразу приспособился ко мне как к менеджеру. Сначала он перешел в другую команду. Через несколько месяцев, несколько смущенный, вернулся в нашу команду и согласился работать со мной. Таким образом, получается, что быть хорошим менеджером — не значит обладать самым высоким уровнем технических знаний. Для успеха менеджмента гораздо важнее оказалась работа по оказанию поддержки.

Бетани Блаунт

Оставайтесь инженером

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

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

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

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

Зачем беспокоиться об участии в написании кода, если вы все равно будете успевать писать только какие-то куски или блоки? Ответ в том, что вы должны участвовать в работе, чтобы видеть узкие места и проблемы при создании. Вы можете увидеть это и наблюдая за метриками кода (их много), но значительно легче почувствовать проблемы, если вы сами активно участвуете в написании кода. Если дело происходит медленно, а разворачивание кода занимает слишком много времени, и если обратная связь с пользователями превращается в кошмар, вы как опытный инженер сразу почувствуете это в решении простых программных задач. А представьте, как расстраивается вся ваша команда! Решать технические проблемы и определять приоритеты в решении гораздо проще, когда вы сами имеете дело с кодом.

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

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

1 ... 24 25 26 27 28 29 30 31 32 ... 78
Перейти на страницу:

Комментарии
Минимальная длина комментария - 20 знаков. В коментария нецензурная лексика и оскорбления ЗАПРЕЩЕНЫ! Уважайте себя и других!
Комментариев еще нет. Хотите быть первым?