#вопросответ
Состоявшийся продукт со сформированной большой аудиторией, лидер в нише. Много legacy, большое количество подпродуктов с разной степенью связанности. Команда маленькая, супер-компетентная и знающая нюансы продуктов и предметной области, есть незаменимые люди. Ничего категорически нового в продукте не делаем, локально дорабатываем и развиваем. Из раза в раз повторяются ситуации, что что-то в системе отваливается, часто в критичные для бизнеса моменты и часто оказывается, что причина в изменениях месячной-полугодовой давности. Исправить это команда не может или не хочет, а бизнесу больно, что делать?Боритесь не с симптомами в виде ошибок и падений, а стройте систему и хороший процесс разработки. А сокращение ошибок и падений станет приятным побочным эффектом. Но, вероятно, вам это не нужно и вы пожалеете, если начнете. И вот почему.
Чтобы сделать процесс доставки стабильным и предсказуемым есть множество устоявшихся инженерных практик, инструментов, фреймворков и подходов.
— Вся разработка строго через Git (банально? да! Но удивительно, все еще не везде так)
— Весь процесс деплоя строго через CI/CD
— Автотесты
— Внедренды всевозможные статические анализаторы кода
— Активно эксплуатируются практики DevSecOps
— Все структурные изменения строго через миграции
— Процесс написания документации является неотъемлемой частью пайплайна разработки
— QA, тест-менеджемент и актуальная тестовая документация
— Всевозможные мониторинги, алерты
— ... еще многое
Проблема в том, что каждый пункт при его отсутствия в ДНК команды будет требовать существенных затрат на внедрение: время и нервы команды, преобретение недостающей экспертизы. С внедрением каждого пункта будут неизбежно расти издержки и трудозатраты на внедрение каждой новой фичи, будет расти время доставки фичи. Будет теряться привычная скорость и гибкость работы команды: если раньше фича могла выкатиться день-в-день сразу по готовности, то теперь вам придется ждать ближайшее релизное окно (которое может быть, например, «в следующую пятницу»). Команда станет сильно больше, в ней появится много новых ролей, «незаменимость» отдельных людей будет снижаться. И всем этим надо будет управлять и строить новую систему управления и в процессе будет казаться что все становится только хуже.
В конечном итоге все точно станет более предсказуемо и надежно. Но точно будет дороже и медленней. И самое главное — даже самый крутой и супер-избыточный процесс не застрахует на 100% от ошибок и сбоев.
Сравните текущие потери бизнеса от сбоев с затратами на перестройку. Если оно оправдано — действуйте.
Если нет, то вероятно стоит принять текущее положение дел и оставить все как есть для legacy-части ваших продуктов. А вот когда перед бизнесом будут стоять задачи по разработке чего-то принципиально нового и по запуску новых направлений — там уже с первых дней все делать «как надо».
Присылайте ваши рабочие ситуации и вопросы на man@spectr.dev или в ТГ @aleks_tsykarev — буду отвечать на самые интересные в канале
