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

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

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

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

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

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

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

Что мне делать? Я опасаюсь переходить от ситуации полного отсутствия процессов к задействованию сразу нескольких. Но что-то надо менять!

Подумайте о процессах в контексте управления рисками.

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

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

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

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

Практический совет: старайтесь не персонифицировать принятие решений

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

Проверка кода

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

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

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

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

Анализ сбоев

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