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

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

Я не стараюсь навязывать свое суждение, но призываю всегда понимать разницу между ориентацией на продукт или бизнес и ориентацией на технологии. Руководствуйтесь каждой там, где целесообразно. Что по-настоящему важно для успеха компании или организации? Если создание продукта, сочетающего разные стороны бизнеса, то вы, видимо, заинтересованы в лидерах, бизнес-интересы понимающих. Напротив, там, где прежде всего необходимы солидные инновационные информационные технологии, больше нужны инженеры и разработчики сложных систем. Зачастую вам не нужно полностью ориентироваться на один вариант. Но вам нужно сознавать, что одно из направлений должно быть ведущим. И особенно если вы один из высших руководителей компании: вы должны уметь сосредоточить внимание на направлении, наиболее ценном для компании, и сконцентрироваться на нем.

Создание технологических процессов в разработке ПО

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

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

Спросите технического директора: что такое технологический процесс

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

В последнее время ко мне стали приходить инженеры и жаловаться, что новые сотрудники используют в системах другой код. Я тоже недавно обнаружил, что кто-то пишет код на языке программирования Scala, хотя все мы используем Ruby. Этот человек один знает в нашей команде язык Scala, и я боюсь, что нам придется столкнуться с трудностями в поддержке этого кода. Но проект продвинулся далеко вперед, поэтому просто остановить его я не могу.