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

2022-06-10 16:58:44 Привет!
Итак, как мы сражались с остальными всадниками.

Отстраненность. Чаще всего этим “недугом” страдаю команды, у которых разработка идет более 2-х лет. Эйфория от “запуска” уже давно прошла, задачи стали рутинными, а баги на вентилятор продолжают падать.

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

Выиграть здесь возможно только через создание новой системы мотивации, в которой продукт должен не только существовать, но и быть лучшим на рынке, самым стабильным и востребованным. Но здесь без продакта не обойтись)

Здесь важно посчитать урон он тех багов, которые должны быть действительно исправлены и договориться об итерациях определения “уровня сервиса” для ваших команд. Условно, это выглядит как ступеньки, по которым команда проводит продукт, например от большего к меньшему:
Продукт работает, мы можем упасть, но быстро поднимемся
Пользователи сталкиваются с проблемами, но мы не можем упасть
Люди пользуются с удовольствием, редко сталкиваются с проблемами и получают быстро решение
На рынке нет более крутого продукта

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

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

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

Во-вторых, начинайте всегда с изменений, которые обойдутся команде малой кровью и при этом дадут максимальный результат (принцип Парето, да-да).

Ну и очевидное, проведите ретроспективу, на которой вы покажите результат проведенных изменений.

К каким же результатам мы пришли в Skyeng:
количество багов в беклоге снизилось с 5000 до 1300 по всем продуктам и проектам. Это до сих пор непозволительно много, но динамика положительная :)
Появились SLA (срок жизни бага в днях/часах), в которых участвуют команды разработки на фикс багов, мы можем прогнозировать и сообщать пользователям примерные сроки решения проблем.
Про наш инцидент-менеджмент можно почитать здесь, он тоже помогает в решении пропущенных багов и их скорейшего исправления
В некоторых платформенных проектах подкрадываемся к Zero Bug Policy. Пока больно, но мы обязательно к этому придем.

Безусловно, эта история про то, что мы смогли пропустить, но мы работаем над тем, чтобы ничего не пропускать Открыть/Комментировать

2022-06-09 18:02:43 Привет!

Мы продолжаем рубрику “СТО на каникулах” и сегодня я, Сергей Никифоров, Head of QA, расскажу, как мы в Skyeng боремся с багами и каких результатов удалось достичь

Если у вас рабочий zero bug policy или lead time от создания до закрытия всех багов меньше недели – перематывайте, вы и так все знаете!

3 года назад для Skyeng нормальным явлением было 5000 багов в бэклоге, и этот тренд уверенно рос. Это нормально для всех стартапов и компаний, где нет иной ценности кроме скорости.

Чаще всего пренебрежение бэклогом сознательное и на то есть несколько причин, давайте назовем их всадниками багоапокалипсиса:
Лень: чем меньше делаешь, тем лучше.
Гордость: баги не мои и вообще такой ерундой разработчик заниматься не хочет.
Отстраненность: ощущение непричастности к продукту и что исправление 1 бага не изменит положение вещей.
Недальновидность: обязательно исправим, но потом.

Давайте разбираться, что и как можно сделать с каждым всадником.

Лень. Самый коварный противник, но мы его победили. И вот почему: значительную часть багов в core сервисах мы не решали как баги. QA “вспоминали” про их существование при планировании фичи, аргументируя это тем “слушай, ты же все равно полезешь в N, там вот еще это не работало, тебе быстро будет поменять”. И действительно, формулировка “раз ты всё равно полез, поправь попутно” работает лучше, чем отдельно стоящий bug в трекере, который отображается на доске.

Такое поведение создает привычку отдавать готовый продукт и меньше использовать костыли, плюс усиливает code review (ребята сами начинают подсвечивать проблемные зоны без QA друг-другу).

Гордость. Для большинства крутых разработчиков исправление багов не является интересной задачей. Им хочется запускать ракеты в космос, спасать принцесс, что-то делать с драконами, вот это вот всё.

Этот “всадник” отлично побеждается соревновательным элементом. Введите обязательные политики по жизни багов, SLA по их выполнению и сравните команды между собой, чтобы сильные дяди могли помериться своей силой)

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

Завтра поговорим про отстраненность и недальновидность, а также я расскажу, чего мы достигли, выиграв бой у всех “всадников”. Пока делитесь в комментариях своими всадниками багоапакалиписиса Открыть/Комментировать

2022-06-02 17:59:45 Привет!

Итак, возвращаемся к теме «Качество vs скорость». Каким же должен быть ответ на этот вопрос?!

Важно, чтобы QA/QL сказал, что «скорости не бывает без качества» и сможет это аргументировать, например, так:
Хорошие процессы приводят к хорошим решениям, которые легко разрабатывать (тестирование требований, груминг, исследования)
Качество — это и поставка нового крутого функционала в сжатые сроки. Клиент должен быть доволен сроками появления фич или исправлением неудачных решений.
Можно сделать быстро и некачественно, но исправление ошибок тоже жрет время, а следовательно итоговое решение придет все равно позже
Я должен влиять на сроки, ускоряя производство через качественные процессы, а полученное время команда может использовать для новых задач, рефакторинга и т.д.

Этот простой вопрос не раз помогал мне определиться с кандидатами, он работает как лакмусовая бумажка — можно знать много теории и практики, но если с такой фундаментальной частью проблемы, то ты обязательно столкнешься со сложностями при интеграции такого человека в команду. Открыть/Комментировать

2022-06-01 17:59:05 Привет! Меня зовут Сергей Никифоров, я руководитель гильдии QA внутри компании Skyeng.

За свою историю в QA я провел сотни собеседований, как на QA/QAA разных уровней, так и на QA Lead (далее – QL). Помимо этого, мы помогали прокачивать курсы по QA в Skypro (наши курсы про #войтивайти), создали собственную платформу стажировок, систему грейдирования и программу обучения по автоматизации.

Не поверите, но понять уровень профессионализма специалиста вам поможет ответ на один простой вопрос: Скорость или качество?

Почему именно этот вопрос? Давай копать

Этот вопрос одновременно отражает знание процессов управления разработкой продукта, показывает опыт человека в решении конфликтов и отстаивании своей точки зрения. Почти всегда – 20 из 24 QL – выбирали один из вариантов, большинство голосовало за «качество».

При попытке объяснить выбор, на меня часто смотрели как на дурака и выдавали аргументы про:
Ну, я QL, я про качество.
Кроме меня никто на качество смотреть не будет, а качество важно, я должен его контролировать
Наш клиент должен получать качественный функционал, это самое важное.

Бесспорно, бывали и варианты про приоритет скорости:
Мы должны следить за качеством, но не мешать своей работой разработке и бизнесу
Качество важно, но мы не влияем на сроки, сказали быстро — делаем быстро
Если у нас спринты, то мы должны успевать, а баги править будем позже

И в том, и в другом случае проблема одна — QL/QA не видит своё влияние на весь процесс. Для него работа в команде это постоянное противостояние между командой «скорости» (чаще всего — разрабы и их тимлид) и «качества» (QA и QL), которые на протяжении 457 серий делают продукт. Это приводит к тому, что человек чаще всего работает с процессами в рамках только этапа тестирования и не думает о счастье пользователя.

Так, а какой ответ верный, спросите вы? А об этом мы поговорим завтра, друзья, не переключайтесь

PS. Делитесь в комментах своими подходами Открыть/Комментировать

2022-05-27 22:44:01 Ребят, и оффтопом немного про ближайший викенд)

Эти выходные у многих пройдут под лейтмотивом конференции CodeFest в Новосибе) Skyeng тоже в ней участвует, заходите послушать доклады и познакомиться!

Завтра (28 мая) в 11.00 я – Виталий Леонов – буду открывать секцию Management, расскажу о том, как построить приборную панель тимлида, все оцифровать и спать спокойно. Приходите поддержать и буду рад со всеми пообщаться в перерывах между треками.

29 мая в 11.00 Head of Mobile Platform Слава Слуцкер расскажет про SwiftUI + Combine и как же все же начать писать простой и тестируемый код. Открыть/Комментировать

2022-05-27 16:57:32 Всем привет!

На прошлой неделе прошла конференция TeamLead Conf, где было много крутых докладов про управление командами, мотивацию и развитие сотрудников, оптимизацию процессов и многое другое

Мое выступление было о том, как построить people management на данных и сократить текучку в IT. Делюсь ключевыми поинтами)))

Прежде чем бросаться в решение какой-то проблемы, нужно ее провалидировать: описать и оценить ее значимость для бизнеса. И только после этого инвестировать ресурсы в решение.

В случае с текучкой, мы собрали данные об уходе сотрудников в IT-команде за год – в январе 2021 показатель составил 38% – и измерили его в деньгах. При этом перенаем одного инженера на тот момент стоил компании ~1.3млн руб. Таким образом, высокая текучка айтишников обходилась бизнесу в сотни миллионов рублей в год. Проблема провалидирована, надо решать.

Дальше важно провести анализ, чтобы понять первопричины проблемы. В рамках борьбы с текучкой мы взяли данные из опроса вовлеченности, показатель eNPS и разбили их по командам. Так мы увидели ключевые факторы, влияющие на показатель – недостаток обратной связи от руководителей и непрозрачные карьерные возможности для сотрудников.

Выработка решений. Пожалуй, главная рекомендация на этом этапе – направлять свой ресурс именно в те причины, которые оказывают наибольшее влияние на проблему и не распыляться на остальные. Для борьбы с текучкой мы реализовали несколько инициатив: запустили курсы по обратной связи для руководителей, внедрили прозрачные карьерные треки для инженеров, провели интенсивы по составлению PDP (персональный план развития) среди тимлидов, провели грейдинг команды и составили для каждого планы по развитию.

Этап, про который очень часто забывают. Перепроверьте, что ваши усилия были не напрасны и проблема решилась.

Какие результаты мы получили:
вовлеченность выросла на 4%, в частности пункт про карьеру увеличился на 11%,
eNPS вырос на 7,5%,
ну и самое главное, годовая текучка упала на 30%.

Profit Открыть/Комментировать

2022-05-20 12:37:24 Привет!

А мы снова с митапами
На этот раз мы участвуем в Avito Analytics meetup #6 вместе со спикерами из Яндекс Маркета и Авито. Евгения Дубровина из Skyeng поделится нашим опытом работы со сплит-тестами на разветвлённой клиентской базе с многоэтапной воронкой.

А еще в программе огненные доклады про оценку медиамаркетинговых кампаний и оптимизацию юнит-экономики экспресс-доставки.

Регистрируйтесь по ссылке и подключайтесь 24 мая в 18:00. Открыть/Комментировать

2022-05-17 16:37:16 Привет!

19 мая Skyeng примет участие в митапе по мобильной разработке Ozon Tech Mobile Meetup.
Артем Новичков из Skyeng расскажет, как работает новая модель многопоточности, и на примерах разберет, что нового появилось в Swift и как это подружить со своим кодом.

А также Александр Свиридов из Ozon расскажет, какие метрики собираются и как ребята борются за перформанс приложения и Владимир Шедько презентует, как в Ozon делали плавный скролл для нагруженного UI.

Регистрируйтесь по ссылке и подключайтесь 19 мая в 18:00. Открыть/Комментировать

2022-05-13 17:48:34 Привет!

Команда разработки Slack выложила отличный разбор своего инцидента, произошедшего 22 февраля.

Если кратко, то суть в следующем: обновление Consul привело к сбросу кэша, что стало причиной беспрецедентно высокой нагрузки на БД неоптимальными запросами. Настоящий эффект бабочки — обновление версии софта вызвало взрывной рост нагрузки.

Интересен раздел Learnings. С одной стороны, причины очевидны: узкое горлышко в БД, каскадный отказ, зависимость от горячего кэша и минорные изменения как триггер сбоя. С другой стороны, это стало ясно лишь в ретроспективе. В сложных системах, коими является любая более-менее крупная IT-инфраструктура, предсказать такие сбои практически невозможно.

Какие выводы я сделал из этого разбора:
1. Невозможно предусмотреть и закрыть все возможные отказы в таком крупном проекте как Skyeng. Инцидент может случиться где угодно, когда угодно и почему угодно.
2. Нужно больше уделять внимания инструментам, которые позволят быстрее узнавать об инцидентах и их митигировать: чувствительные мониторинги, детальные логи, подробные Disaster Recovery Plan и команда дежурных, готовых отработать инцидент 24/7. Открыть/Комментировать

2022-05-06 17:00:41 Привет!

В Skyeng мы стремимся принимать решения на основе данных. Если в управлении продуктами этот подход широко распространен – проведение А/В тестов, сбор продуктовых метрик, исследование клиентов и т.д., то в разработке дела обстоят иначе)

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

Однако, любое упоминание о метриках в среде разработчиков вызывает у коллег тревожность. Дескать, если начали собирать метрики, то они попадут в личные KPI, а стало быть придется ломать голову над достижением “красивых” цифр в отчете.

Например, недавно мы собрали метрику Lead Time – время от создания до решения задачи. Главное возражение коллег было в том, что им невыгодно закрывать старые задачи, т.к. метрика будет портиться. Но ведь метрики не тождественны KPI, они помогают оцифровывать любой процесс с разных сторон – управляемости, предсказуемости, динамики и т.д.

Ключевое слово здесь оценивать, т.к. любая метрика никогда не будет точной на 100%. То, что при закрытии старых задач у какой-то команды вырастет Lead Time не говорит о том, плохо это или хорошо. Она лишь объективно показывает ситуацию в команде, а уже тимлид будет решать, стоит ли что-то менять в процессах или нет.

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

Лично мне поменять майндсет в этом направлении помогли эти книги:
1. Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе
2. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта

Надеюсь, и вам пригодится Открыть/Комментировать