Уставший техдир

Уставший техдир

Разрабы должны чувствовать последствия своих решений Кент Бек, в своем подкасте сказал очень хорошую мысль: "Задача Ops-команды дать разработчиком прочувствовать боль своих ошибок". Немного злобная, но очень честная мысль. Девопс, как функция, должны помогать…

Как привести разработчиков к владению и ответственности за свои сервисы и продукты

Лозунг "you build it – you run it" звучит красиво, но это лишь принцип и сам по себе без изменений в инженерной культуре не работает

По просьбам трудящихся, как это сделать:
- Дежурства. Нужно столкнуться с проблемами самому и прочувствовать боль команды сопровождение и клиентов. Дежурство превращает её в личный опыт
- Прозрачные общие метрики. Time to Recovery, аптайм, количество исключений и ошибок, число инцидентов. При этом они должны быть командными, никаких "личных KPI"
- Совместные разборы инцидентов. Post-mortem без поиска виноватых, где разработчики видят, к чему привело их "пофиксим потом"
- Право выбирать решения. Если команда отвечает за эксплуатацию, она должна иметь полномочия выбирать инструменты мониторинга, процессы деплоя и архитектурные решения (главное не превратить их в право отморозиться)
- Поддержка и фокус со стороны менеджмента. Сверху должно быть понимание ценности владения, иначе никакой девопс-культуры не будет

Ответственность нельзя "навесить". Её можно только создать через систему, где разработчики реально живут последствиями своих решений и имеют полномочия что-то менять

Бонус: "А что делать с теми, кто говорит, я не хочу думать и за что-то отвечать, ставьте задачи"

Их место — в проектной деятельности. В продуктовых командах с культурой владения эта позиция токсична: один человек без ответственности обнуляет усилия всех остальных.

💯22❤9🔥4🤡4❤‍🔥3👍3🥱1

www.group-telegram.com/jp/tired_glebmikheev.com/2159

5.27K viewsSep 23 at 11:24

Как привести разработчиков к владению и ответственности за свои сервисы и продукты

Лозунг "you build it – you run it" звучит красиво, но это лишь принцип и сам по себе без изменений в инженерной культуре не работает

По просьбам трудящихся, как это сделать:
- Дежурства. Нужно столкнуться с проблемами самому и прочувствовать боль команды сопровождение и клиентов. Дежурство превращает её в личный опыт
- Прозрачные общие метрики. Time to Recovery, аптайм, количество исключений и ошибок, число инцидентов. При этом они должны быть командными, никаких "личных KPI"
- Совместные разборы инцидентов. Post-mortem без поиска виноватых, где разработчики видят, к чему привело их "пофиксим потом"
- Право выбирать решения. Если команда отвечает за эксплуатацию, она должна иметь полномочия выбирать инструменты мониторинга, процессы деплоя и архитектурные решения (главное не превратить их в право отморозиться)
- Поддержка и фокус со стороны менеджмента. Сверху должно быть понимание ценности владения, иначе никакой девопс-культуры не будет

Ответственность нельзя "навесить". Её можно только создать через систему, где разработчики реально живут последствиями своих решений и имеют полномочия что-то менять

Бонус: "А что делать с теми, кто говорит, я не хочу думать и за что-то отвечать, ставьте задачи"

Их место — в проектной деятельности. В продуктовых командах с культурой владения эта позиция токсична: один человек без ответственности обнуляет усилия всех остальных.

BY Уставший техдир