Год назад в нашей компании произошли революционные изменения, у нас изменилась методология разработки, мы стали работать по Scrum.
Agile стал требовать от команды самостоятельного принятия решения, непрерывного улучшения. Тут мы и столкнулись с проблемой развития членов команд. В результате у нас постепенно появилось 14 способов развития, про 6 из которых расскажу в этой статье. Часть из этих способов инициировала компания, но большую часть мы придумали сами или подсмотрели и адаптировали под себя.
В компании 7 продуктовых команд, я являюсь тех. лидом (scrum master + архитектор) одной из команд.
Итак, начнем.
1. Книжный клуб
Как сделать чтобы коллеги стали больше читать? Самая очевидная идея — организовать книжный клуб. Не стали ничего выдумывать, на одном из дейли анонсировали первую встречу клуба.
Цели клуба:
- стимулировать коллег читать;
- расширять кругозор за счет друг друга. Т.е. послушать ревью профессиональных книг из первых уст и решить для себя стоит ли ее читать, либо ограничится общими моментами из книги;
- обсудить, какие идеи из книги можно применить в работе (а иногда и вне работы)
Формат:
В клубе мы делимся кто что прочитал, кратко рассказываем ключевые идеи. Клуб обычно посещают 4-8 человек и мы успеваем обсудить 2 книги. Сначала клуб проходил еженедельно, но со временем мы поняли, что за неделю не успеваем много прочитать и решили собираться в 2 недели.
В клубе обсуждаются книги по корпоративной культуре, личному развитию, тайм менеджменту. Меньше по разработке, но от книжного клуба отпочковался exersise клуб, о котом ниже.
В итоге книжный клуб инициировал создание библиотеки, в которую компания ежемесячно покупает по 5-6 книг;
2. Солнышки и тучки
Agile требует отличные от Waterfall принципы от разработчиков. Чтобы процесс адаптации проходил проще, мы придумали некую систему координат, систему ценностей, где обозначено что такое хорошо, а что такое плохо.
Обернули мы такую систему в гейминг мотивацию «Солнышки и тучки». Команда может поощрить одного из коллег солнышками, от 1 до 8 и поругать, вручим ему соответствующее кол-во тучек. Размер солнышек и тучек регламентирован, к примеру 1 солнышко — это «спасибо», 3 солнышка — выручил команду, 8 солнышеками поощряется человек сделавший техническое улучшение, отмеченное командой. 1 тучку выдаем за опоздание на встречу, 8 тучек — подвел команду и т.д.
Когда команда закрывает спринт, человек, набравшим наибольшее кол-во баллов (1 солнышко +1 балл, 1 тучка минус 1 балл), получает книгу и переходящий кубок. По итогам квартала лучший получает толстовку с названием команды. Это уникальная толстовка, толстовку с такой надписью никак иначе не получить.
Такой вид мотивации достаточно неоднозначен, кто-то считает это просто баловством. По опыту могу сказать, что мы не опаздываем на встречи и умеем отмечать заслуги и «антизаслуги» друг друга, что позволяет нам двигаться вместе в одном направлении и быть командой.
Спустя почти год понимаю, что этот способ выполнил свои цели, мы перестроили свое согласно Agile методологии. Теперь солнышки служат в качестве поощрения друг друга, иногда сложно при всех поблагодарить человека за помощь, солнышки позволяют преодолеть этот барьер.
Особенно рекомендую такой способ на этапе, когда только завозится гибкая методология.
3. Треки развития
Для развития каждого члена тех. отдела руководитель разработки ввел треки развития.
Трек развития — это индивидуальный план, в котором отражены цели и средства их достижения.
У нас в команде трек создается на 3 периода по 3 месяца. Текущий период четко описан, следующий менее детально, третий период просто идеи.
Трек каждый сам себе составляет. Задача тех. лида способствовать достижению целей и росту сотрудника.
За время работы с треками сделал вывод, что помещать в трек технологии неэффективно, т.к. непонятно что считать изучением технологии, языка программирования, той или иной базы данных. Это всего лишь инструменты.
На текущий момент для себя определил следующий формат трека: направление, средства развития, литература, метрики. В процессе движения по треку уже подбираются необходимые инструменты. Например:
направление: Общие технические знания;
средства развития: микросервисы и их готовка
литература: «Программирование на shell (UNIX). Чистый код. Паттерны проектирования. Release it! Теоретический минимум по Computer Science. Предметно-ориентированное проектирование (DDD)
метрики: Соответствие решения нефункциональным требованиям
Проблема треков заключается в том, что они работают только в том случае, если сам разработчик понимает его цели и не относится к этому формально. Отношение к треку является определяющим. Те кто следят за прогрессом, переодически смотрят, освежают трек в памяти, двигаются, те и добиваются хорошего прогресса. Треки помогают сфокусировано развиваться, достигать хороших личных результатов, а не ограничиваться решением рутинных задач.
4. Утренние „катки“
Утром, перед дейли или уже вечером перед уходом, мы соревнуемся в решении алгоритмических задач. Для этого используем сервис codingame. Участнику предлагается решить несложную алгоритмическую задачу либо на скорость, либо на количество символов кода. Катки отлично помогают набить руку в написании алгоритмов, да и вообще это фановая штука. Сервис предоставляет большой набор языков программирования, C#, C++, Javascript, Bash, PHP, Swift и еще около 20 других.
Подобные алгоритмические тренировки увеличивают скорость написания кода.
5. Perfomance Review
Во время работы очень сложно получить объективный фидбек от коллег из твоей команды. На Team Lead Conf Егор Толстой поделился опытом Perfomance Review в Avito. Мы его переняли. Отличная штука! Лично я получил очень ценный фидбек о своей работе. По полученному фидбеку смог скорректировать некоторые свои рабочие моменты. Коллеги также отзываются очень положительно о таком формате ревью, кто-то добавил куски полученного фидбека в свои треки. Через некоторое время планируем повторить.
Егор подробно описал в своей статье.
6. Exersise club
С весны у нас шла активная подготовка в выпуску нашего нового продукта. Мы понимали что недопустимо когда решение будет нестабильным или вообще упадет. Поэтому мы решили вместе углубиться в тему оперирования приложения, создав exersise club.
Exersise club — несколько иной формат книжного клуба. Здесь мы все вместе читаем одну книгу, а в клубе подробно разбираем. Это сугубо технические книги.
Предварительно договариваемся какие главы мы прочитаем к встрече. На встрече разбираем прочитанное. Смотрим какие на текущий момент есть проблемы и каким образом их устранить.
Встречи клуба проходят еженедельно и длятся 1 час.
Готовясь к большому релизу разобрали книгу Release It. На одной из встреч мы составили таблицу сервисов, которые использует наше приложение, выяснили где нет таймаутов в запросах к ним. Имея на руках эту таблицу мы со временем расставили таймауты и теперь знаем, что если упадет стороннее API или БД, то приложение будет работать. Аналогично разобрались с логами.
Теперь читая „DDD“ Эрика Эванса проектируем крупный кусок архитектуры нового модуля.
Данный формат подходит для одновременного изучения теории и одновременного применения изученного на практике.
Если задачу нужно решить в сжатые сроки, то exersise клуб будет неэффективным.
Заключение
Не надо думать что у нас все хорошо и каждый член команды неистово качается и использует все возможности для роста. Конечно это не так. Но тут важно, что такие возможности есть и они дают неплохие результаты как для каждого лично, так и для команды и для компании в целом.
В статье написал про 6 из 14 способов повышения профессиональных навыков. Если информация окажется интересной, напишу вторую часть и обобщу опыт.
Описанные в статье способы являются несложными в реализации и являются плодом наших собственных идей, опыта других продуктовых команд и компаний.
P.S. А при чем тут Scrum? Все эти способы появились именно после перехода на Scrum и инициированы командой. Очень здорово, что начинания команд находят поддержку в лице руководства компании.
Автор: kesh1987
