Тимлид Леонид

2019-11-07 12:55:42 Привет! Сегодня в канале Карим @KarimAminov — руководитель QA в Eqvanta, и его история про то

Как транслировать ценности команде: пример из моей практики

Тестировщики — люди щепетильные, и была б их воля, проект не выходил бы в прод, пока не будет исправлен последний минор

Похвально, но это:

• бьёт по кошельку бизнеса, ведь мы увеличиваем time to market,

• влияет на отношения с разработкой: найти как можно больше ошибок, отдать их обратно и ждать c — не лучшая практика,

• а если бизнес не реагирует, сотрудники перестанут ощущать пользу от работы и могут начать "забивать" на неё.

Что делать? Я созвонился с одним из бизнес-заказчиков. Мы под запись обсудили, почему нам важно быстро выводить задачи в продуктив, что мы теряем и что получаем, если задача выполнена с минимально приемлемым качеством. Затем я обсудил это с QA-командой.

В итоге:

• каждый тестировщик начал осознавать, что значит простой по задаче и в чём важность его работы,

• ребята перестали ждать у моря погоды и самостоятельно инициировали решение важных для проекта вопросов: стало не зазорно сходить к разработчику и помочь ему с решением волнующего бага, или дойти до системного администратора, чтобы поскорее получить доступы,

• мы сохранили качество тестирования на проекте.

Да, сама идея кажется элементарной — транслировать команде результаты проделанной работы и дать каждому почувствовать себя частью общего успеха. Но так мало кто это делает. Не стесняйся рассказывать про успехи и провалы своим людям.

p.s. Хочешь задать вопрос или тоже написать пост в канал? Обращайся к @yeskelaveenrok

p.p.s. Карим и дальше хочет делиться фишками работы с командой. Что думаешь? Открыть/Комментировать

2019-11-05 13:10:28 Привет, сегодня у нас в гостях Аля @EmptyKitty — тимлид команды “Деньги” в ivi, и её рассказ про

Парное программирование как способ подружить разработку и тестирование

Цена ошибки в биллинге высока, поэтому мы уделяем особое внимание автоматизации тестирования. Интеграционные тесты (aka автотесты) выходят вместе с фичей, их пишут и поддерживают тестировщики, а для ревью мы привлекаем одного тестировщика и одного разработчика.

В теории всё прекрасно, но на практике бывает так:

• тестеры только учатся писать код

• разработчики не погружены в проект автотестов, не могут оперативно и глубоко их ревьювить

• проект и автотесты написаны на одном языке, но у них разный CI, код-стайл, набор линтеров и подход к организации кода

Тут мы и решили попробовать парное программирование, чтобы наладить обмен опытом для написания интеграционных тестов. Никого не принуждали, поэтому сначала желание выразили только один разработчик и один тестировщик. Сессию совместной работы ребята организовали так: около часа один сидел за компьютером, второй сидел рядом, после чего шёл перерыв и обмен ролями.

В результате если обычно выпуск автотестов к большой сложной задаче занимал около двух недель, то при парном программировании мы сократили все до пары дней. И тогда уже все ребята из команды были готовы попробовать новый формат. А после первых сессий они начали активнее обмениваться практиками программирования, придумали улучшения для обоих проектов.

О чём стоит позаботиться при организации парных сессий?

Дай бойцам работать, с кем они хотят. Осознание, что “кто-то будет сидеть у моего компа и смотреть, как я туплю” — это страшно. Поэтому парное программирование — это ещё и история о поиске комфортного напарника: по темпераменту, по опыту, по скорости восприятия.

Синхронизируй их время. Если в спринте планируется такая сессия парного программирования — заранее забронируйте его в календаре у обоих, чтобы не навалились другие встречи, задачи, дела.

Не планируй такие активности часто. Раз в пару спринтов — достаточно) По отзывам ребят, такой формат работ отнимает много сил, так как требует очень большой концентрации. А силы надо успевать восстанавливать.

p.s. Хочешь задать вопрос или тоже написать пост в канал? Обращайся к @yeskelaveenrok

Парное программирование Открыть/Комментировать

2019-11-01 12:55:10 Привет, сегодня у нас вопрос из зала!

Те, кто уже успел послушать вчерашний подкаст, спрашивают: что за синдром самозванца такой, и можно ли больше пруфов и деталей. Мы попросили героиню эпизода — Катю @crazycatwoman Митусову из Wrike рассказать побольше об этом деле. Передаём слово:

Этот психологический феномен был выявлен более 40 лет назад и не так уж и редок: по данным одного из исследований, свыше 50% сотрудников крупнейших ИТ-компаний хоть раз испытывали синдром самозванца. Его обладатели не могут принять свои успехи, обесценивают достижения и думают, что их “некомпетентность” вот-вот разоблачат.

Когда я только стала тимлидом, эти симптомы проявились во всей красе. Стала его исследовать вопрос и нашла целую классификацию.

Существует пять типов самозванцев, у каждого есть определённая модель поведения и страхи.

• Эксперт. Главный страх — знать не на 100%, дать неправильный ответ и иметь недостаточно опыта.

• Перфекционист. Главный страх — сделать хоть что-то неидеально. Часто ставит перед собой недостижимые цели, ему тяжело отпустить контроль.

• Superman/Wonder woman. Говорит “да” любой задаче, работает 24/7, но очень часто это нездоровая нагрузка.

• Гений от природы. Главный страх — если не понял или не сделал что-то быстро, то провалился.

• Ярый индивидуалист. Главный страх — просить помощи и делегировать.

Подробнее о каждом можно почитать в этой статье на Хабре.

p.s. Тоже хочешь писать в канал или задать вопрос его авторам? Обращайся к @yeskelaveenrok

Время анонимных пятничных откровений - а какой самозванец ты? Открыть/Комментировать

2019-10-31 13:10:07 31 октября, а значит, время страшных историй

“Аааа, ничего не получается”,
“Я делаю всё не так”,
“Моя команда наверняка считает меня полным дном, пора собирать вещи и валить”

Доводилось ли вам испытывать такие чувства А на регулярной основе?

Если да, то вы либо реально не справляетесь (сочувствуем), либо вы просто натренировали свою внутреннюю нейросеть видеть только ложку дёгтя среди сотни бочек мёда. Если второе — это синдром самозванца

Как с этим бороться? Мы откровенно поговорили с человеком, которая провела с такой “профессиональной шизофренией” первые полгода тимлидства — а потом выдохнула и поборола эту дрянь с помощью:

• безумной бабки из сериала “Симпсоны”
• простого списка “трёх побед в день”
• и еще парочки практик, о которых рассказала в подкасте “Тимлид Позвонит”

Материал доступен в текстовой выжимке и полной аудиоверсии. Изучайте, если нужно (мы никому не скажем), и делитесь опытом в комментариях по ссылке. Поможем молодым тимлидам сохранить голову на плечах!

p.s. Хотите поучаствовать в записи следующего выпуска — пишите @yeskelaveenrok, и тимлид позвонит. Открыть/Комментировать

2019-10-28 13:01:30 Ребята, привет!

Сегодня запускаем рубрику: цитаты великих руководителей разработки

Возможно, вы знаете, что в начале сентября мы делали митап лидов и техдиректоров. Но трансляция с него не удалась. Потому мы собрали записи в плохом качестве по крупицам — и расшифровали их. Сегодня с вами Андрей Шелёхин, руководитель собственной разработки в Tinkoff, и его принципы работы с изменениями

Есть два базовых принципа, которых я придерживаюсь. Первый — любая команда в каждый момент времени может работать эффективнее, чем она делает это сейчас. И второй — самый важный — это запуск культуры непрерывных улучшений. Начинать нужно с этого.

Откуда берутся изменения? Нужно стремиться к тому, чтобы большинство инициатив по изменениям исходило от команд, а не спускалось сверху. Но этот процесс не так просто запустить, на старте все равно придется добавлять некую инициативу со стороны тимлидов. Пусть они приходят, предлагают даже базовые вещи, указывают на ошибки, проблемы и пр. Но за несколько итераций нужно прийти к тому, чтобы вовлечь команду.

Очень важно, чтобы в основе любых изменений лежала боль или проблема, которую вы подтвердили. Есть такое заблуждение у начинающих лидов, что они обязаны производить изменения: сегодня у нас будут дейлики, завтра мы будем вот так делать и пр. Команда не очень поймет, зачем оно надо, если это не фундаментальная проблема — и все не подтвердят её наличие.

Как мониторить изменения? На первых этапах, когда команда молодая, никаких особых практик в принципе не надо. Все проблемы лежат на поверхности, сильно свербят — и если становится лучше, это видно и без всяких метрик. А вот когда команда становится более зрелой, метрики позволят выявлять проблемы: например, что очень долго задача висит в ревью, — и тогда что-то с этим пробуем делать, смотрим в динамике.

Еще одна прикольная тема, которая помогает выявлять инсайты — это ретроспектива по задачам. Например, мы смотрим, где оценка задачи существенно расходится с оценкой затраченного времени: это значит, что команда изначально что-то совсем не знала или не учла. И это дает нам шанс много нового узнать о системе и процессе". Открыть/Комментировать