Ребята, привет!
Сегодня запускаем рубрику: цитаты великих руководителей разработки
Возможно, вы знаете, что в начале сентября мы делали митап лидов и техдиректоров. Но трансляция с него не удалась. Потому мы собрали записи в плохом качестве по крупицам — и расшифровали их. Сегодня с вами Андрей Шелёхин, руководитель собственной разработки в Tinkoff, и его принципы работы с изменениями
Есть два базовых принципа, которых я придерживаюсь. Первый — любая команда в каждый момент времени может работать эффективнее, чем она делает это сейчас. И второй — самый важный — это запуск культуры непрерывных улучшений. Начинать нужно с этого.
Откуда берутся изменения? Нужно стремиться к тому, чтобы большинство инициатив по изменениям исходило от команд, а не спускалось сверху. Но этот процесс не так просто запустить, на старте все равно придется добавлять некую инициативу со стороны тимлидов. Пусть они приходят, предлагают даже базовые вещи, указывают на ошибки, проблемы и пр. Но за несколько итераций нужно прийти к тому, чтобы вовлечь команду.
Очень важно, чтобы в основе любых изменений лежала боль или проблема, которую вы подтвердили. Есть такое заблуждение у начинающих лидов, что они обязаны производить изменения: сегодня у нас будут дейлики, завтра мы будем вот так делать и пр. Команда не очень поймет, зачем оно надо, если это не фундаментальная проблема — и все не подтвердят её наличие.
Как мониторить изменения? На первых этапах, когда команда молодая, никаких особых практик в принципе не надо. Все проблемы лежат на поверхности, сильно свербят — и если становится лучше, это видно и без всяких метрик. А вот когда команда становится более зрелой, метрики позволят выявлять проблемы: например, что очень долго задача висит в ревью, — и тогда что-то с этим пробуем делать, смотрим в динамике.
Еще одна прикольная тема, которая помогает выявлять инсайты — это ретроспектива по задачам. Например, мы смотрим, где оценка задачи существенно расходится с оценкой затраченного времени: это значит, что команда изначально что-то совсем не знала или не учла. И это дает нам шанс много нового узнать о системе и процессе".
Сегодня запускаем рубрику: цитаты великих руководителей разработки
Возможно, вы знаете, что в начале сентября мы делали митап лидов и техдиректоров. Но трансляция с него не удалась. Потому мы собрали записи в плохом качестве по крупицам — и расшифровали их. Сегодня с вами Андрей Шелёхин, руководитель собственной разработки в Tinkoff, и его принципы работы с изменениями
Есть два базовых принципа, которых я придерживаюсь. Первый — любая команда в каждый момент времени может работать эффективнее, чем она делает это сейчас. И второй — самый важный — это запуск культуры непрерывных улучшений. Начинать нужно с этого.
Откуда берутся изменения? Нужно стремиться к тому, чтобы большинство инициатив по изменениям исходило от команд, а не спускалось сверху. Но этот процесс не так просто запустить, на старте все равно придется добавлять некую инициативу со стороны тимлидов. Пусть они приходят, предлагают даже базовые вещи, указывают на ошибки, проблемы и пр. Но за несколько итераций нужно прийти к тому, чтобы вовлечь команду.
Очень важно, чтобы в основе любых изменений лежала боль или проблема, которую вы подтвердили. Есть такое заблуждение у начинающих лидов, что они обязаны производить изменения: сегодня у нас будут дейлики, завтра мы будем вот так делать и пр. Команда не очень поймет, зачем оно надо, если это не фундаментальная проблема — и все не подтвердят её наличие.
Как мониторить изменения? На первых этапах, когда команда молодая, никаких особых практик в принципе не надо. Все проблемы лежат на поверхности, сильно свербят — и если становится лучше, это видно и без всяких метрик. А вот когда команда становится более зрелой, метрики позволят выявлять проблемы: например, что очень долго задача висит в ревью, — и тогда что-то с этим пробуем делать, смотрим в динамике.
Еще одна прикольная тема, которая помогает выявлять инсайты — это ретроспектива по задачам. Например, мы смотрим, где оценка задачи существенно расходится с оценкой затраченного времени: это значит, что команда изначально что-то совсем не знала или не учла. И это дает нам шанс много нового узнать о системе и процессе".