От разработчика до руководителя

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

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

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

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

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

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

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

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

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

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

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

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