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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ сбоев

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