Зачем разработчику внедрять стандарты в разработке?

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

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

Кажется, что… В разработке нет стандартных задач.

На самом деле: Решение задачи часто не является стандартным. Но процесс разработки — от появления задачи до релиза — проходит по примерно одному алгоритму.

‍

Кажется, что… Стандарты убивают творчество.

На самом деле: Стандарты освобождают энергию для творчества. Когда процессы управления и разработки не стандартизованы, вы тратите энергию на «как» даже для типовых задач. Рутинные задачи решаются медленнее, а значит времени на интересные задачи и творчество меньше.

‍

Кажется, что… Стандарты ограничивают в выборе практик.

На самом деле: В какой-то степени это справедливо: стандарты «выбирают» из бесконечного множества только лучшие практики. Если эта практика не лучшая, её можно обсудить и при достаточности аргументации — изменить. Это рождает постоянное совершенствование мысли о том, как нужно делать, а не постоянное возвращение к одному и тому же.

‍

Кажется, что… Стандарты мешают внедрять инновации в процесс разработки.

На самом деле: Какие-то практики разработки и подобие стандарта есть в каждой группе, явно или неявно. Инновация — это изменение явного или неявного правила.

Явно описанное правило (стандарт) менять проще, чем существующее в головах, но сам описанный стандарт делает дискуссию по его изменению и практики применения более конкретным. Изменение стандарта — это здоровый конфликт, где все могут подискутировать и договориться.

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

‍

Кажется, что… Стандарты мешают развиваться.

На самом деле: Развиваться — это пробовать что-то новое, думать о чём-то новом. Если в управлении и разработке нет стандартов, то проект замкнут на команде, которая с ним работает, его передача другим командам затруднена. Разработчик прикован к своему проекту, потому что перевести его на другое направление — слишком дорого для компании.

Когда стандарт работы и описания проекта выстроен, то передать проект другой команде гораздо проще. Соответственно, проще освободиться от привычной задачи и стека и начать думать про новое — развиваться.

‍

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