🤓 Почему душнила - ваш лучший босс
Руководитель в ИТ - это не бывший разработчик, который вдруг решил стоять у всех над душой. За каждым душным требованием вроде метрик, бюджетов или проверок безопасности стоит конкретная логика: создать среду, где код превращается в бизнес-ценность, а не просто "работает где-то там".
Главный конфликт между командой и руководством возникает из-за разных языков. Разработчик говорит на языке Гита и контейнеров, руководитель - на языке рисков и приоритетов. И мост между ними - это не эмоции, а факты. Например, фреймворк STAR учит формулировать мысль не как "Улучшили процесс", а как "Сократили время деплоя с двух дней до 15 минут, и теперь релизы выходят 20 раз в неделю".
Безопасность и DevSecOps - это не попытка затормозить релиз, а встроенный фильтр. Когда проверки автоматизированы и идут параллельно с разработкой, найти уязвимость на этапе коммита в сто раз дешевле, чем чинить прод посреди ночи. То же касается Cloud Native и Kubernetes: это не хайп, а способ за минуты масштабироваться под нагрузку и не платить за простаивающие серверы.
Для бизнеса не важно, что вы подняли кластер. Ему важно, что вы "Сократили затраты на 15% и увеличили конверсию на 5%". Задача руководителя - переводить технические решения на язык выручки и рисков. А для оценки эффективности команды существуют DORA-метрики: частота релизов, время от коммита до прода, процент неудачных изменений и скорость восстановления. Они показывают не занятость, а настоящую ценность.
В итоге роль ИТ-руководителя - не копаться в коде, а отвечать за три вещи: влияние на бизнес, здоровье команды и управление техдолгом как финансовой моделью. Если это понимать, то его влезание в разработку перестают быть помехой - они становятся попыткой сделать разработку предсказуемой, безопасной и быстрой.
LinkedIn: Сергей Павлов, Head of Development - Ростелеком
· 15.05
Ну после этого поста я подписался)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён