Продуктовая VS Инженерная культура. Какая культура эффективнее? (Пост 1)Вчера на митапе от South Hub про роли CPO и CTO, их зонах ответственности в современных реалиях, подняли тематику «Продуктовой» и «Инженерной» культуры, и мол, какая лучше. Но для начала давайте определим, что есть что :)Начну с Продуктовой культуры. Основной вопрос, на который ищется ответ в ней - «Что мы строим и зачем?». Тут весь фокус на пользователе и ценности, которую мы ему наносим. Вроде бы очевидно, но дьявол в деталях:- Важен не объём работы, а результат. Не то, сколько фич мы запилили, а то, изменилось ли что-то для пользователей и как поменялись наши метрики. Выросла ли конверсия? Стали ли люди чаще возвращаться? Вот это важно.- Эмпатия к пользователю значит реально погружаться в их проблемы, делать исследования, слушать обратную связь. Решения принимаются не потому, что «стейкхолдеру так показалось», а потому что есть данные и исследования.- Эксперименты являются важной частью продуктовой культуры. Мы признаём, что не знаем многого. Делаем MVP, тестируем гипотезы, смотрим на цифры. Ошибка — это не провал, а обучение, познание того, а как оно на самом деле. - Лучше выкатить что-то рабочее сегодня и получить фидбек, чем полировать до идеала год, пока рынок не ушёл.- Видение продуктовое важно, но оно должно подтверждаться метриками и калиброваться об реальность.- Роль членов команды, в частности инженеров - ты не просто кодер, получающий ТЗ. Ты соавтор решения. Ты понимаешь бизнес-контекст и можешь предложить более простое техническое решение для достижения цели.Инженерная культура. Основной вопрос - «Как мы это строим?»Здесь в центре — технологическое совершенство, надёжность и качество процессов:- Качество кода имеет доминирующее значение. Чистая архитектура, минимум технического долга, принцип «оставь код чище, чем нашёл». Звучит идеалистично, но это про долгосрочную эффективность и стабильность.- Рутина убивает продуктивность, потому фокус на автоматизация всего (CI/CD, автотесты и пр.). Если что-то делается руками больше двух раз — автоматизируй. - Важен постоянный обмен знаниями для развития всей системы и каждого разработчика - Code review как способ обучения, внутренние митапы, документация. В хороших командах знания не монополизируются, а усиливают друг друга.- Когда что-то сломалось, мы ищем не виноватого, а причину в системе. Post-mortem анализ, чтобы не повторить ошибку. Люди должны чувствовать себя безопасно.- Право выбирать инструменты и технологии, если это обосновано является ядром автономности инженеров.- Продукт для инженеров это нагрузка на систему. Их задача сделать так, чтобы эта нагрузка систему не уронила, чтобы всё было безопасно и поддерживалось годами.Эти две культуры часто конфликтуют, и это нормально, если конфликт конструктивный:Продакты говорят: «Нужно вчера, давайте быстрее, рынок не ждёт!»Инженеры отвечают: «Нужно сделать правильно, спешка породит баги и техдолг».Продакты смотрят на код как на инструмент. Его можно выбросить, если не зашло.Инженеры видят код как актив. Плохой код замедлит нас в будущем.Продакты боятся сделать никому не нужный продукт.Инженеры боятся, что система упадёт или станет неподдерживаемой.Для продактов качество — это когда пользователь доволен и метрики растут.Для инженеров качество — это когда система стабильна, код покрыт тестами, архитектура масштабируется.Когда доминирует продукт, команда скатывается в Feature Factory. Бесконечная гонка за фичами, а техдолг игнорируется. Через год-два разработка встаёт колом, любое изменение всё ломает, лучшие люди увольняются от работы с говнокодом.Когда доминирует инженерия, выстраивается Ivory Tower. Бесконечный рефакторинг ради рефакторинга, модные технологии, которые не нужны бизнесу. В результате идеальный код продукта, который никому не нужен, или выход на рынок, когда конкуренты уже всё заняли.Если одна культура полностью давит другую — компания и продукт и пользователь страдают. Все страдают.Продолжение будет в следующем посте.
