Историями о профессиональных сообществах сейчас вряд ли кого-то удивишь. Гильдии образуют по разным причинам: кто-то из интереса, кто-то чтобы быть в тренде, а кто-то из-за недостатка общения на профессиональные темы. Это история о том, как бизнес-направление компании ЦФТ, Денежные Переводы Online, желая производить больше и быстрее, в очень короткий срок утроило штат инженеров, которых не успели нормально заонбордить, и в итоге чуть не уронили качество продукта и не сожгли ключевых членов команды.

Доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, представила на конференции TeamLead Conf 2020 Head of Android QA одного из флагман-продуктов компании ЦФТ Надежда Потаенко.

Продукт ЦФТ Золотая Корона в 2016 году прочно стояла на позиции самой крупной системы денежных переводов без открытия счета на территории России и СНГ. В момент, о котором пойдет повествование, у пользователей появилась возможность начать отправлять переводы не только офлайн, но и через веб и мобильные фронты.

И команду разработки начало потихонечку взрывать, потому что в эти мобильные фронты резко устремились несколько миллионов активных клиентов.

Стало понятно, что продукт взлетел, и его надо срочно развивать. Именно высокая востребованность продукта заставила ЦФТ очень быстро вырасти. За три года команда разработки продукта Денежные Переводы Online увеличилась с 7 до 200+ человек. В какой-то момент старые производственные процессы просто перестали работать. Сотрудники вынуждены были отправиться на поиски новых конфигураций.

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

Для кого готовим?

Гильдия, о которой мы поговорим это 25 QA Android инженеров. Если вы не имеете отношения к качеству, это не страшно. Рекомендации, которые вы увидите здесь, легко портируются как на команду разработки, так и на команду аналитики. Информация может быть полезна даже agile-гуру и вообще всем людям, которые ищут точку опоры для создания профессионального сообщества, но пока что ее не нашли.

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

Что было в холодильнике?

Шел 2016 год, и в компании стал развиваться продукт, который начал активно зарабатывать деньги. Ранее этот продукт разрабатывала сравнительно небольшая команда из 20 человек (4 компонентные команды: Backend, Web, iOS, Android), все сидели в славном городе Томске и были экспертами в продукте. Казалось, все идет просто идеально!

Но как это часто бывает, заказчик с этим согласен не был. В 2017 году он начал задавать вопросы о том, почему продукт так долго релизят?

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

Настал 2018, и боги провозгласили год найма и новых рук. Компания начала расти, причем не только в Томске, но параллельно в Новосибирске и в Питере. На графике видно, что в конце 2018 появилось 130 инженеров в 3 локациях, а в 2019 их стало больше 200. Это около 30 команд, которые сейчас совместно пилят один и тот же продукт: Денежные Переводы Online.

От такого роста ожидали увеличение скорости разработки и сокращение TTM, но получили совершенно иную картину.

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

Почему так получилось? Команда разработки росла быстрее, чем в ней адаптировались процессы.

• Не успевали качественно онбордить

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

• Разный уровень hard skills в разных локациях

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

Например, в Томске инженеры предпочитали вести тестовую документацию в виде чек-листов и подробно там ничего не расписывать. В Питере считали, что это хаос и вред, и каждое ответвление flow должно быть покрыто стопочкой тест-кейсов.

Другой пример: в Новосибирске инженеры считали, что побегать за аналитиком и дожать из него недостающую информацию это ОК. В Питере ребята сказали: Ну нет! Должен быть четкий Definition of Ready. Мы ни за кем бегать не будем!

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

• Релизила по-прежнему одна команда

Главная боль всего 2018 и части 2019 года заключалась в том, что несмотря на увеличение количества команд, которые в изоляции друг от друга производили вполне годные фичи, стабилизацией, сборкой, багфиксингом, поставкой в прод занималась по-прежнему одна и та же релиз-команда. Конечно, она не могла качественно пропустить через себя такой объем производства.

Выпуская релизы раз в 2-3 недели, члены команды горели на работе, потому что жили там до 2 часов ночи. Они почти ненавидели новых людей, которых зачем-то кто-то нанял.

В какой-то момент Надежда поняла, что надо спасать коллег по цеху.

Шаг 1: Перемешать и поставить на плиту

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

• Повысить степень причастности и ответственности;

• Выровнять уровень понимания бизнес-логики продукта.

Но эта попытка сразу же въехала в стройку. Стало понятно, что совместный регресс не решает ни одну из проблем. Более того, он их только обострил.

Шаг 2: Довести до кипения

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

Например, что-то тестили, попали на незнакомый flow, испугались, завели баг, кинули его в чат Android: кто-нибудь потом разберется. А на самом деле просто заехала новая фича, поменялся flow, а тест-кейсы еще не актуализировали.

Приправим все это классическими проблемами распределенных команд: в Питере сотрудники проснулись и пришли в офис, а в Томске и Новосибирске уже ушли. И команда заводила три одинаковых бага, потому что согласованности в работе не было.

Кроме того, существовала токсичность локаций в адрес друг друга. Например, эксперты в Томске были в ярости от того, что их коллеги заводят ненормированное количество багов, которые за ними надо перепроверять и закрывать. А новички злились на то, что какие-то распальцованные ребята в Томске закрывают их задачи без объяснения причин.

Как тушить все это, было непонятно.

Шаг 3: Остудить, еще раз перемешать

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

• Выработать единый подход к регрессу;

• Найти способы ускорить регресс;

• Восстановить качество релизов;

• Делиться друг с другом экспертизой в продукте.

Все QA в команде Денежных Переводов Online находятся в своих фича-командах. В каждом спринте у них есть собственные sprint goal. Но понимания, зачем QA-инженеры из этих обособленных фиче-команд раз в две недели собираются все вместе в трех локациях, чтобы кому-то помогать, ни у кого не было. Надежда решила начать сначала, и собрать всех очно в одной локации.

Это предпринималось для того, чтобы за аватарками в сети все увидели реальные лица, поняли, что все одинаково болеют за продукт, но из-за отсутствия настроенных процессов тянут в разные стороны, как лебедь, рак и щука.

А еще ей хотелось сформулировать цель совместной работы.

Летом 2019 года все собрались и познакомились, после чего родилась цель: выпускать качественный продукт быстро, чтобы заказчик и пользователи были довольны.

Качественно и быстро это отсылки к желаемому сокращению ТТМ и к восстановлению уровня качества.

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

Мозговой штурм был построен на базе книги 5 пороков команды Патрика Ленсиони. И на него было потрачено около 8 часов.

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

Когда участники встречи разъезжались, заряд community был такой мощный, что все говорили: Эге-гей! Да мы следующий регресс вообще за день бахнем!.

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

Шаг 4: Выпекать до готовности

В команде Денежных Переводов Online договорились проводить регулярные встречи гильдии раз в 2 недели.

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

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

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

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

Канал коммуникации очень простой: QA-инженеры раз в две недели встречаются онлайн в Microsoft Teams.

За счет таких встреч им удалось выработать единый подход к регрессу и найти способы ускорить его.

Осторожно! Горячо!

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

Если вы захотите строить свое профессиональное сообщество на базе животрепещущего процесса, вы должны быть готовыми к тому, что после различных форс-мажоров в этом процессе участники встречи вряд ли будут доброжелательными.

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

Шаг 5: Сбрызнуть соком лимона

Сообщество - это не всегда только про решение проблем. Это неизбежно история про обучение и QA-сообщество ДП Online не исключение. Например, кто-то хочет научиться пользоваться снифферами, а кто-то мечтает, чтобы ему объяснили, как безболезненно протестировать пуши на интеграции. Такие запросы есть всегда. Самое главное, что по востребованным темам есть эксперты, и нужно лишь решить вопрос формата подачи информации.

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

В команде появился такой wishlist:

В Confluence сотрудники компании сами вписывают темы, которые они хотят послушать, или о которых готовы рассказать. Коллеги лайкают, и если тема популярна, она попадает в анонс. Казалось бы, что может быть проще и работоспособнее?

Но проблемы начались с самого первого митапа.

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

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

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

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

Шаг 6: Дать отдохнуть

В ДП Online решили отправлять сотрудников в командировки для того, чтобы они начали встречаться не только онлайн, но и лично. Когда появилась страничка графика поездок, очередь туда выстроилась до конца 2020 года. И все, естественно, хотели в Питер, ведь две другие локации находились в Сибири.

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

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

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

Профиты командировок:

• Для продукта: быстрый шаринг экспертизы;

• Для инженеров: сменить обстановку, пообщаться с иногородними коллегами.

За счет командировок сотрудникам QA-сообщества ДП Online удалось выработать единый подход к регрессу и найти способы ускорить его, восстановить качество релизов и делиться друг с другом экспертизой в продукте.

Что дальше?

В 2020 году в ЦФТ появились новые цели саморазвития гильдии.

• Коммуникация с QA-гильдиями других платформ продукта;

Если в 2019 году сотрудники команды притирались и учились друг с другом общаться, то сейчас внутри Android community очень теплая и уютная атмосфера. Но там готовы раздвинуть границы и подсмотреть, что происходит у других сообществ. Уже запланированы встречи кросс-платформенного community.

• Ежемесячные публикации блога с обзором новостей платформы и сообщества.

Обо всех нововведениях и текущих изменениях хочется рассказывать, поэтому в QA-сообществе начали выпускать блог с обзором новостей.

Есть и продуктовые цели.

Если раньше в ДП Online существовал басфактор в виде единой выпускающей команды, то теперь он исчез. Тем не менее, процесс релиза непрозрачный, очень тяжело онбордить в него людей. Поэтому стоит цель однозначно работать над его упрощением и над снижением порога входа в проект автотестирования. А еще могут потребоваться новые hard skills, ведь продукт компании динамичный.

Выводы в цифрах и фактах

На картинках активности, которые пробовали применять в QA-сообществе ДП Online.

Рост качества, произошедший на почве работы сообщества, напрямую отразился на количестве hot fixов на число выпущенных версий.

И немного статистики релизов продукта за 2018-2019 годы. Внизу красным подсвечены hot fixы. В 2018 году в ДП Online было нормой раз в 3-4 релиза выпустить hot fix. С 2019 года, когда начала собираться гильдия экспертов, hot fixов почти нет. За весь 2019 год выпустили всего 4. Причем речь не о клиентских, а о технических hotfixах, например, когда какое-то событие было потеряно в Google Analytics.

Кроме того, активности, которые были направлены на решение продуктовых проблем, принесли несколько положительных сайд-эффектов:

• Тюнинг soft skills;

• Единое информационное поле;

• Здоровая конкуренция;

• Новые лиды.

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

Программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

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

Присоединяйтесь!

Это продолжение перевода статьи о парном программировании. С первой частью можно ознакомиться здесь.

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

Итак, как же работа в паре поможет достичь этих целей?

Обмен знаниями

Давайте начнем с самого очевидного и наименее спорного преимущества - обмена знаниями. Общая работа двух людей над одним куском кода позволяет команде делиться опытом в программировании и избегать застоя знаний. Кроме того, две головы увеличивают шанс найти достойное решение. Разные опыт и взгляды ведут к рассмотрению большего количества вариантов.

Практические советы

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

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

Размышления

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

Практические советы

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

Сосредоточение

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

Практические советы

Составьте план вместе. Обсудите задачу и обдумайте шаги для достижения цели. Запишите каждый шаг на стикерах (или в таск-менеджере, если вы работаете удаленно), держите их на виду и делайте один за другим. Попробуйте объединить эту технику с техникой Помодоро и попробуйте завершать один шаг за одну помидорку. Никогда не забывайте, что коммуникации - самое важное. Обсуждайте вашу работу и требуйте пояснений друг от друга.

Ревью кода на ходу

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

Рефакторинг - важная часть написания кода, следовательно, и парного программирования. Проще улучшить код, когда кто-то стоит за плечом, потому что вы можете, например, сразу обсудить подход или какие-либо названия элементов в коде.

Но совместное ревью кода имеет также и свои минусы. К ним мы вернемся позже.

Практические советы

Задавайте вопросы друг другу! Вопросы - самый мощный инструмент для понимания того, что вы делаете, и выбора наилучшего решения. Если одному из вас сложно прочитать код, попробуйте сделать по-другому, чтобы стало понятнее.

Совмещение двух моделей мышления

Как мы упоминали ранее (в первой части), рассматривая классическую модель Ведущий/Штурман, совместная работа позволяет получить разные взгляды на код. Мозг Ведущего обычно работает в режиме тактики, размышляет о деталях и текущих строчках кода. В то время как мозг Штурмана думает более стратегически и охватывает бОльшую картину, отмечает следующие шаги и идеи на клеющихся стикерах. Может ли один человек сочетать в себе оба режима одновременно? Конечно, нет! Поэтому такой "удвоенный" взгляд улучшает качество кода, так как включает рассмотрение и деталей, и общей картины.

Практические советы

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

Как "Штурман", избегайте тактического мышления, разбора деталей кода - того, что делает "Ведущий". Ваша работа - отойти на пару шагов и дополнить вашу пару в части тактики и среднесрочным планированием.

Коллективное владение кодом

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

Мартин Фаулер

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

Практические советы

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

Установка WIP-лимитов для команды

Ограничение числа незавершенных задач, как один из базовых принципов Канбан, увеличивает продуктивность сотрудников. Следование технике WIP-лимитов (аббревиатура от Work In Progress) помогает сосредотачиваться на ключевых задачах. Многозадачность неэффективна даже для одного человека, что говорить о целой команде. Парное программирование позволяет ограничить число задач, прорабатываемых параллельно, и тем самым увеличить общую сосредоточенность. Это гарантирует непрерывность рабочего процесса без подводных камней.

Практические советы

Ограничьте список задач в работе для нескольких разработчиков и обнародуйте в рабочем пространстве вашей команды (или в таск-менеджере). Сверяйтесь со списком перед постановкой новых задач. Это дисциплинирует и поможет закрепить привычку работать по парам.

Быстрая адаптация новых сотрудников

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

Практические советы

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

Составьте план по адаптации со списком тем. Для некоторых тем запланируйте специальные (тематические) сессии, для изучения которых новичок может скооперироваться для работы в паре. Если что-то изучено во время совместной работы - вычеркивайте из списка. Таким образом прогресс в адаптации будет виден каждому участнику команды.

Это были цели и преимущества парного программирования. Следующая часть статьи будет посвящена подводным камням парного программирования - с какими затруднениями можно столкнуться при работе в паре.

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

С точки зрения каждого члена команды, мы полагаем, что "каждый сам себе CEO", тем самым, это зона ответственности каждого индивида. С точки зрения продукта - у нас есть менеджмент, который собирает метрики, делится своим видением будущего и планирует дорожные карты. Но с точки зрения команды - у нас есть мы сами, продукт и нам со всем этим нужно что-то делать.

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

Опросы

Да, это очередные опросы, но в нашем случае они приносят пользу и каждую ретроспективу поднимаем вопрос, нужны ли нам они или уже нет. У нас спринты длятся 2 недели, поэтому у нас есть еженедельный опрос и опрос в конце спринта.

Еженедельный опрос

В конце каждой недели мы получаем опросник на 30 секунд с вопросами: как часто у вас не было сил выполнять работу? Получал ли удовольствие от задачи? Сколько часов переработал? На выходе мы строим график для всей команды в динамике за последние 6 недель и обсуждаем на ретроспективе.

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

Опрос в конце спринта

Тут всё просто, мы за пару часов до ретроспективы всей командой отвечаем на простой вопрос "Как вам спринт"? Тут мы уже преследуем цель разговорить команду. До введения этого опроса, ретроспектива начиналась с молчания и попыток скрам-мастера разговорить людей, что, как правило, заканчивалось "да обычный спринт, ничего такого". Сейчас же команда стала более разговорчивой, больше обсуждают проблем и кидают больше идей.

Опросы раздражают

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

Мотивация

Наша команда разрабатывает B2B продукт, известный только в узких кругах компаний, и новые члены команды столкнулись с тем, что им никто не объяснил кто и для чего используют наш продукт. В итоге это выглядело так: вот вы, вот продукт с кучей легаси кода, вот Jira - поехали.

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

Как минимум, воодушевление пришло когда люди узнали кастомеров, например, "О, это мой банк", "У этих 3-х компаний больше миллиона сотрудников", "У меня машина этой компании" или "Я читаю финансовые новости от них". Думаю, в компаниях, названия которых встречаются хотя бы раз в месяц дела обстоят лучше.

Боли (от выполнения ручной/неудобной работы)

Когда мы взяли новых членов команды, то от них услышали, что некоторые процессы сложные/долгие/непонятные. Возможно, ранее так казалось и другим, но со времени все привыкли/забили/смирились. Т.к. у нас появилась возможность выявить слабые стороны, мы решили ею воспользоваться. Для этого мы начали:

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

• Сравнивать затреканое время в Jira между нашей командой и другими командами, чтобы понять, кто делает что-то лучше нас и почему мы не делаем также.

• Опять же посмотреть в Jira и рассмотреть что мы можем делать лишнего, или что уже не актуально и можно упразднить. Например, мы рассматривали релиз-тикеты и пытались понять какие моменты мы можем делать быстрее. Так мы обнаружили, что security scan кода занимал по 20-30 минут, мы подумали, что можно делать всё проще и в итоге сейчас это занимает около 5-10 минут.

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

В результате у нас всё задокументировано в Jira в эпиках (с чем мы уже можем прийти к PO для обсуждения включения этих улучшений в дорожную карту на следующий квартал), у нас уже есть правило, что 10% времени в спринте каждый тратит на развитие своих навыков, и у нас уже был план кто и что будет изучать. В нашей компании у всех есть доступ к обучающим курсам на разных площадках, поэтому вопрос самообучения был решён автоматически, но мы договорились о следующем:

• Изучение будет происходить в паре/тройке. Так и интересней, и если кто-то уйдёт в отпуск - работа не встанет.

• Пары/тройки будут меняться в будущем. Чтобы команда не дробилась на небольшие "кружки по интересам" и оставалась одной командой.

• Внутри пары/тройки нет ограничений на источник обучения. Кому-то могут нравиться курсы с LinkedIn, кому-то с Udemy, а кто-то вообще нашёл крутой разбор темы на YouTube на своём родном языке.

Больше болтовни

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

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

Также мы заметили, что когда люди включают web-камеру - они более искренне и более разговорчивы. Если вся команда не разговорчива, мы просто используем Wheel Of Names и там уже рандомом выбираем кто будет говорить.

Фидбеки

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

Мы постоянно общаемся с менеджментом и PO и слышим от них статистику, на что стоит обратить внимание сейчас. Как правило, это запаздывающие метрики и в итоге часто мы тушим пожары, но редко уделяем много времени причине их возникновения, т.к. сразу переключаемся на другой пожар. Это не значит, что мы не проводим анализы причины, просто "предотвращать" пожары может стоить дороже, чем их многочисленное тушение.

Поэтому, мы стали искать те причины пожаров, решение которых займёт не много времени. Например, мы заметили, что наша L2 поддержка перегружена. Мы попросили фидбек от L2 команды и выяснили что у них много однотипных проблем от кастомеров, например, вот две из них:

• Кастомеры задавали вопросы на одни и те же сообщения в логе. Суть в том, что в логе мы печатали что-то вроде "Module: service XXX call, RC = Y, RSN = ZZ". Т.к. это вообще не понятно никому, L2 выстраивали у себя сводную таблицу таких сообщений, чтобы отвечать кастомерам. Если какая-то новая комбинация - то это шло дальше в L3 (к разработчикам). Решением было простым: мы просто написали функцию которая по кодам печатает user-friendly сообщения с полным описанием причины проблемы.

• Кастомеры находили уже пофикшенные баги. С каждым релизом мы не так много внимания уделяли описанию проблем. В итоге, когда пользователь встречал баг, он открывал описания выпущенных релизов и искал там свою проблему - разумеется он там ничего не находил и писал в саппорт. Ребятам из L2 приходилось лезть в нашу Jira и они пытались найти баги, похожие на кастомерские. Решение банально - мы стали лучше описывать баги с их симптомами в релизах. Кастомеры стали меньше писать в саппорт, т.к. находили свои баги в описаниях релизов, а если уж и открывалось, L2 на них почти всегда могли ответить самостоятельно и быстро.

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

Ежедневный отчёт

У нас каждый день скрам-мастер, в конце рабочего дня, в канале команды в слаке публикует суточный отчёт, который описывает текущие горящие темы, блоки команд, проблемы в команде/продукте и т.п. Этот отчёт полезен как для команды, так и для менеджмента. Во-первых, если кто-то из команды имеет проблемы и видит, что его проблема там не описана - он идёт к скрам-мастеру и отчёт обновляется. Во-вторых, все видят что происходит сейчас в команде, у менеджмента есть актуальный, обобщённый отчёт, и им не нужно дёргать людей, чтобы получать ответы на свои вопросы. С помощью этого отчёта мы пытаемся добиться прозрачности и выявлять блоки как можно раньше, чтобы избегать случаев "У нас уже месяц всё хорошо, но 4 недели назад случилась проблема и мы не успеваем".

Я хочу ещё раз подчеркнуть, что этот "отчёт" - был создан внутри команды для нас самих же и не занимает больше 5 минут в день для его поддержания.

Свои метрики

Внутри команды у нас есть свои метрики. Некоторые пересекаются с менеджерскими, некоторые уникальны.

Например, кастомерские проблемы идут в приоритет и нам, как команде, очень важно, чтобы оно в L3 находилось как можно меньше времени. Поэтому мы стараемся отвечать на проблему, либо находить реальную причину (например, баг) как можно быстрее. Менеджмент всего лишь следит, чтобы ответ был не дольше чем за 2/7 дней (в зависимости от важности проблемы - у них свои метрики).

Частота "незапланированных" задач. Каждый спринт у нас случаются не запланированные таски, возникающие после старта спринта, которые откладывать на 1-2 недели нет возможности. Мы пытаемся отслеживать такие вещи, смотреть сколько в среднем мы тратим на них время и каждый спринт откусывать кусок пирога для этой активности. Тем самым, нам проще выполнять наши собственные коммитменты и тогда команда становится более предсказуемой.

Мы используем и другие метрики, включая самые очевидные: процент покрытия кода юнит-тестами, покрытие QA тестами функционала продукта, время жизни пулл-ревквеста или velocity команды.

Больше правил

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

Можно долго спорить и ругаться, например, что лучше: табы или пробелы, можно назначать митинги для их обсуждения, создавать новые чаты, ругаться в пулл-реквестах, а можно просто написать правило "только пробелы" и просто следовать ему. Кто-то будет недоволен, но теперь это правило, и его не обсуждают, ему просто следуют. Поэтому, рекомендую задокументировать всё, что связано с правилами написания кода. А ещё лучше, посоветовать команде почитать какой-нибудь Code Complete, чтобы разработчики (особенно начинающие) имели представление откуда эти правила берутся.

Правила помогают разделять белое и чёрное, избегать конфликтов и иногда упрощать жизнь. А иногда, наоборот, усложняют жизнь. Ввод любого нового правила означает снижение доверия к индивидуумам, снижение доверия означает рост неэффективности, рост неэффективности приводит к увеличению времени разработки.

Также, правила должны подвергаться пересмотру. Например, в какой-то момент времени у нас случилось несколько кастомерских проблем из-за релиза, баги в котором могли быть замечены аж на трёх этапах: Разработка (code review), Просмотр билда разработчиками, и уже QA. На всех трёх этапах можно было предотвратить ошибку. Разумеется, после этого инцидента все этапы были ужесточены. В итоге то, что раньше могло занимать до 5 дней, стало занимать до 10 дней. Со временем все ужесточения были пересмотрены. Некоторые до сих пор остались, просто был изменён процесс чтобы действие занимало меньше времени, что-то было упразднено, а что-то наоборот добавилось.

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

Ответственность на всех

В нашей команде мы стараемся играть в "трёх мушкетёров", т.е. ответственность за всё лежит на ВСЕЙ команде, никто не будет осуждать члена команды вне команды. Если кто-то один облажался и это привело к каким-то последствиям, то всё равно виноваты все, потому что:

• Плохие вещи случаются. Нельзя запланировать и предвидеть всё.

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

• Очень просто спихнуть всю ответственность на кого-то одного и осудить его. Если такое происходит часто, то все понимают, что рано или поздно это случится с ними и уходит доверие, что приводит к росту издержек, снижению эффективности ... ну вы поняли.

• Обвинения не решают проблем. Вообще никаких.

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

• Женщину, которая в полной темноте переходила дорогу в неположенном месте?

• Водителя автомобиля с автопилотом, который вряд ли сам среагировал бы?

• Компанию, которая разрабатывает автопилот?

• Разработчиков, кто писал код для автопилота?

• QA кто выпустил этот код в прод?

Субъективно, тут виноваты все, либо никто. Но, очевидно, что виновные есть, т.к. в итоге женщина скончалась. Значит виноваты все.

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

Team Building

Я не хочу заострять внимание на тимбилдинге, все мы понимаем зачем он нужен и каждый в этом участвовал. Тимбилдинг, так или иначе, нужен, особенно когда в команде появляются новые люди. Хочу отметить, что сейчас онлайн тимбилдингов уже существует много и есть где разгуляться. Основной посыл здесь, что не стоит ждать пока менеджмент соберёт всех вместе где-нибудь на очередной ежегодной вылазке. Нужно самоорганизовываться самим и организацию таких мероприятий (онлайн или оффлайн) брать на себя скрам-мастеру, тимлиду или самовыдвиженцам из команды.

Заключение

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

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

Если коротко, то дать сотрудникам возможность отвлечься и поиграть. Мы как команда это то, что мы делаем. Поэтому нужно делать что-то интересное вместе. Удаленка не приговор и не помеха.

Эта статья от том, как я организовал Хакатон для IT компании в Малайзии в самые первые месяцы пандемии. Игра была целиком посвещена Linux администрированию, траблшутингу и хакингу. При этом она позволяла поучаствовать всем сотрудникам, от junior инженера технической поддержки до senior архитектора.

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

Дано:

• Компания системный интегратор в Куала Лумпуре;

• Интернациональная команда IT-специалистов;

• 99.99% персонала внезапно ушло на удаленку.

Задачи:

• Позволить сотрудникам отвлечься от работы и снизить уровень стресса;

• Развить навыки, используя геймификацию;

• Развить внутренний бренд для будущих IT игр.

В чем заключалась сложность?

• Неравномерный уровень подготовки и квалификации.

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

• Сменный график работы сотрудников.

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

• Локальный менталитет.

К особенностям местного населения необходимо привыкнуть. Работают в компании в основном малайцы, индийцы и китайцы. Преимущественно они не задают вопросов, опасаются участвовать в чем-то новом и непонятном. Раз в неделю 80% сотрудников покидает офис на 2,5 часа по религиозным соображениям. На корпоратив добрая половина придет только если пообещать им лотерею и призы (очень популярная практика у местных компаний). Заинтересовать таких людей участием в игре было нелегко.

Мне удалось =)

А где Гарри? Шалит с новым хакатоном.

• Неразбериха из-за пандемии.

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

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

• Демотивированный персонал.

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

Еще как может! Риск не собрать аудиторию не оправдался.

Типичный сотрудник в самом начале пандемии.

План подготовки и проведения хакатона

В моем случае выполнение всех этих действий позволило мне успешно провести мероприятие.

• Разработка концепта игры.

Я решил, что темой хакатона будет Linux администрирование. Соответственно, задания должны были строиться вокруг базовых административных задач: проверялось умение использовать command line, браузерные тулзы, знание SQL, DNS, самые основы шифрования.

Хакатон должен был длиться несколько дней. Поэтому я придумал систему уровней и кодов. Каждый уровень представлял собой одну виртуальную машину, в которую участникам нужно было зайти по SHH и найти спрятанный код. На каждой из машин был запущен Apache c простым сайтом, где размещались подсказки. Ну или нет =)

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

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

На этом же этапе была продумана система поощрений.

1. Top-3 самые ценные индивидуальные призы;

2. Top-10 дополнительный специальный пак призов;

3. Первые 50 участников гарантированные призы из дешевого ценового диапазона.

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

• Технический дизайн.

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

В качестве хостинг площадки был выбран AWS. Игровые серверы и хост с веб формой были подняты на t2.medium EC2 инстансах. К каждому инстансу был привязан 1 бесплатный домен. В качестве базы данных использовалась Amazon DynamoDB. Форма была написана на Python и фреймворке Flask. Бэкенд формы был выполнен на основе FaaS (Function as a Service) подхода с помощью связки API Gateway + Lambda + DynamoDB.

Выбор такой технологической базы был обусловлен субъективными пожеланиеми организаторов, наличием необходимой корпоративной облачной подписки, и знаменитым правилом start where you are. Последний принцип подсказал, что можно взять подходящую web форму, используемую в продакшене, и переписать ее под нужды игры. Пользуясь случаем, Алекс и Саша, огромное спасибо за помощь с AWS деплойментом и девелопментом формы. Без вас мне бы было значительно сложнее.

• Презентация концепта руководству и получение бюджета.

К моменту запуска игры руководство догадывалось, что ежегодный корпоратив и некоторые другие привычные активности в этом году не произойдут. Поэтому бюджет на необычный способ тимбилдинга и незнакомый формат были одобрены довольно быстро. Менеджмент из трех предложенных вариантов призового бюджета выбрал самый дорогой.

Как ощущаешь себя когда получаешь максимальный бюжет на проект.

• Разработка дизайна и внешнего вида.

Сначала я определился с названием бренда для внутренних игр и выбрал цвета на свой вкус. На мое счастье в компании был дизайнер, который помог подготовить несколько вариантов логотипа. Я написал и согласовал ТЗ. Итоговый логотип в белом, черном и цветном вариантах был использован для рассылок и печати на призах. Абсолютно все материалы были выдержаны в одном стиле, распространялись под одним брендом и сопровождались одним и тем же логотипом. Недавно, когда я рассылал тизеры о новом хакатоне мне уже не задавали вопросов о том, что происходит. Инженеры точно знали, чего ожидать.

• Выбор и заказ призов.

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

• Рассылка тизеров до начала игры.

До начала ивента я несколько раз отправлял сообщения-тизеры на глобальный мейл-лист азиатского отделения компании. Письма выглядели как спам со множеством спецсимволов, нарочно сломанной версткой и намеками вместо прямых объяснений или инструкций. Такая подача только подогревала интерес к игре. Коллеги довольно часто интересовались не сломан ли мой рабочий аккаунт и можно ли доверять такой корреспонденции. Виртуальный офис жужжал, а это и было именно то, чего я добивался.

• Сюжетное обрамление.

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

• Релиз.

Первое письмо было отправлено на весь офис и содержало начало истории, ссылки и правила игры. Тут же посыпались вопросы: коллеги просили подсказки, пытались уточнить правильно ли они понимают задание, а также старались выудить полезную информацию любой ценой. Не то чтобы получалось. Я был кремень.

• Элемент обучения.

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

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

• Организовать постоянный follow up.

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

• Выдать призы.

Из-за пандемии и Малазийских локдаунов мне удалось отправить призы своевременно только ТОП-3 игрокам. Остальным своих посылок пришлось ждать дольше. Несмотря на небольшую стоимость гарантированного призового пака сотрудники были воодушевлены получением заветных пакетов.

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

• Собрать обратную связь.

Действовать следовало итеративно и с фидбеком. Поэтому всем участникам был разослан опросник. 25% заполнили его. Об ответах в описании результатов.

Весь подготовительный процесс занял 2 месяца и 68 человеко-часов главного организатора. Но результат стоил того.

Результаты:

• Боевой дух команды вырос.

Игра подразумевала индивидуальное участие и решение задач. Однако, мне доподлинно известно, что люди объединялись в команды, устраивали созвоны и брейнштормы. Активным участникам точно было не скучно. Люди, которым в силу неопытности удалось прорваться только через несколько уровней, определенно научились чему-то новому. Цель отвлечь участников и снизить градус напряжения была достигнута.

• Позитивный фидбек от участников.

Одним из факторов, которые говорят о безоговорочном успехе мероприятия, является факт участия тяжелых на подъем сотрудников. Хакатон имел успех и среди линейных менеджеров, которые по долгу службы не работают с Linux напрямую, и среди инженеров-ветеранов.

Три наиболее частые причины почему участники согласились играть:

1. Возможность проверить свои скиллы;

2. Любовь к играм и соревнованиям;

3. Любопытство.

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

• Карт-бланш и бюджет на проведение новых хакатонов.

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

Личное:

Что получил лично я? Опыт, море позитива и желание делать Хакатоны и дальше, в том числе и на коммерческой основе. У меня есть планы на новые игры и, определенно, есть ресурсы, чтобы их воплотить.

А еще я сформулировал и взял на вооружение...

Ключевые принципы организации хакатонов.

• Знайте свою целевую аудиторию.

Хакатоны - для всех!

Хороший хакатон сделан специально для ваших сотрудников и в соответствии с нуждами компании. И да, хакатоны могут быть не только для программистов. Они могут быть вообще для всех.

• Агитируйте правильно.

Землю - крестьянам, игры - айтишникам!

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

• Управляйте сложностью.

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

У меня есть пароль, но нет логина. Зарепортить игровой баг или поискать еще?

• Позвольте играть не так как задумано.

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

А Барсик один в игре ковыряется, посмотри на него!

• Призы хорошо, но не главное.

А как же сектор приз?

Не делайте акцент на призах. Я озвучивал их наличие, но не сообщал, что будет подарено победителям до самого последнего дня. Цель игры не в получении очередного красивого рюкзака, нового пауэрбанка или коллекционной готовальни. Цель участника - строить коммуникации, учиться новому и получать море фана от процесса.

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

Спасибо, что прочли. Увидимся в будущих публикациях!

Весной 2021 проходит шестой запуск проектно-образовательного интенсива От идеи к прототипу Университета 20.35. В нём студенты придумывают идеи для будущих технологических проектов самостоятельно, либо получают их от инновационных бизнес-компаний. С 2020 года в интенсивах существует Банк задач чуть больше чем за год в проект привлечено 30+ компаний, в 25% случаев заказчики предлагали студентам стажировку или работу по итогам интенсива, не менее половины команд решили задачи и показали прототипы на финале проектного трека.

Новый запуск принёс и новую форму самого банка no-code решение публичной витрины для прозрачного и доступного бронирования задач. Нажав на карточку, пользователь может прочесть краткое описание, а также увидеть тематические теги и название вузов, взявших задачу для своих студентов. Рассказываем, как это было.

Наташ, мы всё уронили

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

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

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

Как мы пришли к Airtable

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

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

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

• краткое описание того, что предстоит сделать,

• тематику задачи (например, агротех, дизайн, VR или чат-боты),

• требования к команде (если компания оставила пожелания),

• подробную расшифровку в pdf-файле

• бронирования от вузов кто уже взял эту задачу

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

С появлением такого no-code решения организаторы интенсивов получили возможность модерировать заявки на бронирование задач, один кейс могли взять себе три вуза. Если желающих было больше, их можно отсечь по времени заполнения формы на бронирование кто не успел, тот опоздал. К тому же в следующий раз не понадобится создавать новый документ или страницу: существующая витрина обновится с появлением свежих задач. Иными словами, файл для внутреннего пользования превратился в наглядный пример как для университетов что их студенты могут получить в качестве бизнес-кейса для проекта в интенсиве, так и для компаний что и в каком формате они могут предложить в качестве задачи.

А что сейчас?

В марте 2021 года координаторы 29 вузов выбрали 27 задач из 28 предложенных, самыми популярными по количеству запросов оказались задачи edtech, медицинско-ветеринарного профиля и агротех. Традиционно высокий спрос на решения data science и веб-разработку.

Уфимский ГАТУ вдохновился примером Банка и воспользовался готовым шаблоном на Airtable от разработчиков Университета 20.35. Так студенты этого вуза смогли асинхронно выбрать предложенные задачи с помощью витрины и наглядно записаться в интересующие их проекты.

Что даёт участие в Банке задач стартапам и компаниям:

возможность найти талантливых и заинтересованных студентов, протестировать их своей задачей и принять решение о дальнейшем найме этих студентов в качестве сотрудников;

решить не самую приоритетною задачу за счёт внешнего ресурса без лишних затрат;

предложить себя в качестве работодателя в обход конкуренции с большими и популярными корпорациями, чтобы студенты познакомились со спецификой бизнеса и корпоративной культурой стартапов;

прокачать навык менторства и получить новые идеи для решений других задач от студентов

К слову, если вы тоже хотите, чтобы студенты интенсива потрудились над задачей вашей компании, оставьте заявку: http://business.2035.university.