Инженерная культура Большинство IT проектов улетают в мусорку | )

Инженерная культура

Большинство IT проектов улетают в мусорку. Говорят что 9 из 10 стартапов умирают не запустившись.

Происходит это по разным причинам. Самые популярные: отсутствие PMF (Product/Market Fit), нехватка денег, плохой маркетинг, слабые продажи или низкое качество программного продукта.
 
Обидно, когда перспективный продукт с хорошей идеей не взлетает из-за слабой реализации, множества багов или неспособности быстро реагировать на запросы клиентов. 
 
Почему продукты обладают низким качеством? Я думаю ключевыми являются два фактора: слабая команда и/или инженерная культура. 
 
Вопрос построения сильной, сплоченной команды крайне интересный, но в этот раз я хочу поговорить о формировании культуры внутри команды разработки.
 
Давайте для начала обсудим, что вообще такое инженерная культура? 
 
Для меня это набор принципов, правил, привычек и договоренностей, которым команда следует в процессе работы. Даже если никто об этом не задумывается, культура присутствует в любой команде. 
 
Однако развитая инженерная культура не появляется из ниоткуда - это заслуга всех участников команды, которые сознательно прилагают к этому усилия.
 
Формирование инженерной культуры нацелено на повышение скорости разработки и качества программного продукта. Это позволяет сократить Time To Market, снизить количество багов, быстрее проверять бизнесовые гипотезы и выкатывать новые фичи на прод.
 
Как этого достичь?
 
Стоит выделить несколько основных моментов, которые определяют качество и скорость разработки: автоматизация рутинных задач, настроенный CI/CD и линтеры, высокое покрытие модульными, интеграционными и авто тестами, стандартизация написания кода, исчерпывающая и актуальная документация, а также обязательный код ревью. 
 
Когда на проекте развертывание происходит вручную, разработчики не придерживаются единого стиля написания кода, никто не ведет документацию, тестирование и код ревью игнорируются - разработка стоит дорого, длится долго, а в результате получается говно.
 
Со временем подобные проекты обрастают костылями и техническим долгом, разработчикам часто приходиться овертаймить, поскольку работа, которую можно сделать за 4 часа выполняется 3 дня. Бизнес теряет гибкость и способность быстро тестировать новые гипотезы.
 
Хорошие разработчики и управленцы выделят время на формирование правильных процессов и заложат прочный фундамент на начале проекта. Слабые специалисты же побегут сразу писать код, а со временем увязнут в куче проблем и неэффективном рабочем процессе.