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

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

Как способствовать хорошим решениям

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

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

Создавайте культуру ориентации на конкретные данные

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

Сами обдумывайте вопросы выпуска продукта

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

Смотрите в будущее

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

Следите за результатами решений и исполняемых проектов

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

Регулярно следите за процессами в ретроспективе и сравнивайте данные с сегодняшним днем

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

Хороший менеджер, плохой менеджер: уклониться от конфликтов и погасить их

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

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

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