Про стандартизацию
Введение стандартов – это упрощение. Систематезируя процессы и инструменты ты экономишь «мыслетопливо» (Максим Дорофеев – Джедайские техники) и можешь при старте нового продукта фокусироваться на его бизнес ценности, а не на том, какой фреймворк, базу данных или линтер использовать.
У нас ± одинаковый стек из проекта в проект, но этот стек постоянно совершенствуется и улучшается. Это позволяет за день развернуть production-ready проект с кучей интеграций, проверок и понятным release-флоу, а своё время тратить на решение проблем бизнеса. Все в команде знают, как писать js или ruby, всем понятно что писать в пулл-реквестах, все могут просто копипастить конфиг для CI, который уже претерпел пару десятков итераций и решает сотни проблем. А деплой будет работать как для одного сервера, так и для кластера из 10 – и думать об этом на старте не нужно.
О чем нужно помнить, стандартизируя процессы?
– Система ≠ бюрократия. «Где задачку брали – туда и за апрувом идите. И вообще не видите, у нас обед?»
– Система должна ускорять и упрощать, а не наоборот
– Отвечайте на вопрос почему. «Окей, мы используем 2 пробела, а не 4. А где я могу почитать внутренний срачик на эту тему и его итоги?»
– Нужна возможность для обхода системы. «Проверка на гитхабе загорелась красным, но мне некогда править опечатки – на проде пожар! Как мне зарелизиться?»
– Нужен прозрачный формат улучшения. «Ребята, есть идея для обсуждения – а может уже попробуем react вместо jquery?»
– Нужно место и время для экспериментов. Время для анархии, чтобы люди понимали пользу стандартов (например, хакатоны). Небольшие проекты, чтобы пробовать что-то новое и улучшать стандарты.
– Нужно ставить стандарты под сомнение. Каждый раз, применяя тот или иной стандарт нужно задумываться, а не стал ли он карго-культом?
>>Click here to continue<<