Русский
Русский
English
Статистика
Реклама

Командообразование в ит

Как свод правил на GitHub помогает нам не ругаться уже год

24.07.2020 12:09:40 | Автор: admin
Год назад моя команда выросла: усложнялась бизнес-логика, по сути, мы делились на три подкоманды в каждой были как новички, так и те, кто работал в компании годами. Подкоманды сфокусировались на своих направлениях, и хотя все пилили биллинг, перестал работать принцип общей зоны ответственности. Да и практики, которые работали у старичков, не всегда подходили новому коллективу.



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

Спасибо Рэю за идею


Весной 2019-го вокруг только и было разговоров, что о книге Принципы. Жизнь и работа от Рэя Далио. Слышал о ней и Алексей Катаев он же Тимлид Леонид и наш тогдашний тимлид.

Рэй Далио? Кто это?
В 1975-м основал инвестиционную компанию Bridgewater Associates. К 2010-м из конторы с офисом в одной из комнат съемной квартиры она постепенно превратилась в пятую по значимости инвест-организацию в США. А сам Рэй вошел в список 100 самых богатых людей в мире.

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

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

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

Пафосно, конечно. Но мы решили попробовать адаптировать их под себя. Лёша набросал список из 10 принципов, а команда дополнила его, доведя общее число тезисов до 43. Завели репозиторий на гитхабе: символично, что правила работы будут хоститься там же, где и ее результат.


Да и, если честно, так проще поддерживать и развивать все это дело.

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


Мы договаривались на берегу. В этом и была задумка Лёши.

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

image
Пул-реквест должен был одобрить каждый член команды.

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


Огласите весь список, пожалуйста


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

Принципы работы


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

Еще 11 пунктов
1.2 Мы открыто говорим о проблемах и рисках
Не согласен с техническим решением или план невозможно выполнить скажи. Сломал базу или профакапил сроки скажи сразу. Тимлид пришел с дурацким предложением не молчи. Часто кажется, что проще согласиться или промолчать. Помни, что это приведёт к ещё большим проблемам позже.

1.3 Мы непредубеждены
По-максимуму избавляемся от эго. Не доказываем, кто прав. Не думаем о личной выгоде. Не боимся выглядеть глупо. Помним, что часто мы неправы. Искренне стараемся понять оппонента. Не спорим впустую. Забываем о личном отношении. Цель найти лучшее решение.

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

1.5 Лучше не стесняться и спросить, чем потом долго чинить

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

1.7 Мы не оставляем белых пятен
Мы избегаем абстрактных и не до конца понятных формулировок. Задаём вопросы, ресёрчим, высказываем сомнения. Потратим время сейчас сэкономим потом.

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

1.9 Мы доверяем друг другу и можем положиться друг на друга

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

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

1.12 Мы не меняем приоритеты спонтанно
Приоритеты не могу меняться внезапно. Требуются веские аргументы и согласования с заинтересованными сторонами.

Технические принципы


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


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

2.3 Целостность данных
При написании кода, который манипулирует с данными биллинга, особенно балансом или деньгами, мы делаем эти изменения атомарными. Если мы меняем структуру хранения или массово изменяем данные, делаем изменения обратимыми.

2.4 Простые решения лучше сложных
Качество и стабильность != сложные универсальные решения. Мы против оверинжиринга в пользу простых и понятных решений.

2.5 Мы знаем, что биллинг не пуп земли
Биллинг это проект, который используется многими подразделениями в Skyeng. Внося изменения в его работу, мы задумываемся о командах, работающих с биллингом или данными биллинга.

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

2.7 У нас есть список обязательных знаний
Каждый должен потратить время и выучить вещи, которые нам важны:
Основы работы с RabbitMQ: обменники и их типы, очереди
БД: транзакции и уровни изоляции, блокировки
Двойная запись в бухгалтерии
SOLID, DI, IoC

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

2.9 Мы пишем код так, как будто у нас нет отдела QA
Стараемся самостоятельно протестировать код. Если не знаем как его вызвать узнаем. Если тестировать тяжело или долго подробно в комментариях к задаче пишем инструкцию для QA. Это увеличит время in development, но время до production уменьшится: задача не зависнет в непонятных статусах.

2.10 Мы тестируем код
Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage.

2.11 Мы не аутсорсим разработку биллинга
Это увеличивает технический долг и небезопасно.

2.12 Мы с осторожностью удаляем данные
Просто так ничего не удаляем: ни поля, ни данные.

2.13 Делаем ограничения на уровне БД
Проставляем уникальные ключи, правильные типы данных. Лучше ошибка о нарушении уникального ключа, чем двойные выплаты.

2.14 Читаемость важнее скорости и краткости
Код гораздо чаще читают, чем пишут. Уделяем внимание форматированию, phpdoc, описанию, README.

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

Про последний пункт, кстати, Лёша делал отдельный доклад.


Ну окей, а как это работает?


  • Правила помогают быстро донести командную культуру при онбординге: новичок может понять, как все устроено, а по истории вопроса на GitHub разобраться, почему оно так, как был принят тот или иной принцип и что о нем думал конкретный коллега.
  • Принципы сделали команду более открытой мы перестали срезать острые углы. Ввели оценку 360, стали честнее давать фидбек и активнее использовать его: каждый член команды смог узнать свои сильные и слабые стороны по мнению других. Многие что-то поменяли по итогу.
  • Мы поменяли модель взаимодействия с заказчиками четко зафиксировали: никто не выполнит задачу, не разобравшись в сути. И теперь на техническом ревью (созвон, на котором обсуждаются новые задачи) начинается с того, все ли понимают, для чего мы это делаем. Если команда не понимает явной пользы, даже СТО (сейчас это тот самый Лёша) не может рассчитывать на моментальное Будет сделано!. При этом иногда по ходу обсуждения мы усложним задачу для себя, но зато будем уверены, что избежали проблем через полгода. А иногда вообще докажем заказчику, что ее не надо делать.
  • Наконец, так проще принимать решения и разрешать конфликты. Это экономит время: если обсуждение затягивается, спор идет вокруг одного и того же, мы всегда можем подсмотреть а как там в наших принципах. И принять решение, опираясь на них.



Что было дальше


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


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

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

image
Главное не бояться договариваться и обсуждать проблемы.

Интересно, как оно устроено у вас.
Подробнее..

Recovery mode Как поднять боевой дух команды на удаленке?

16.06.2021 10:13:29 | Автор: admin

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

Эта статья от том, как я организовал Хакатон для 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 галеру в классическом негативном понимании этого термина аудиторией сами знаете какого сайта.

[Спойлер]
А Барсик один в игре ковыряется, посмотри на него!А Барсик один в игре ковыряется, посмотри на него!
  • Призы хорошо, но не главное.

[Спойлер]
А как же сектор приз?А как же сектор приз?

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

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

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

Подробнее..

Перебраться через забор или история о том, как стать командой за три часа

25.11.2020 22:06:19 | Автор: admin
Существуют разные мнения о том, как команды становятся командами. Есть несколько наиболее популярных моделей, которые говорят о невозможности стать командой быстро. Это может быть долгий процесс со своей динамикой.

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

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

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


Ну, вы поняли.

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

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

Так впервые мы все увидели друг друга только на первом планировании. И поскольку это было не просто планирование, а PIP (Product Increment Planning мероприятие в SAFe, посвященное высокоуровневому планированию работы команд на следующие несколько спринтов), то нам предстояло разобраться со многими вещами за ограниченный отрезок времени.

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

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


Кстати, наш Product Increment Planning, будь он в оффлайне, мог бы выглядеть так.

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

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

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

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

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

Робкий костер разгорелся в уверенное яркое пламя.

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

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

Выступление на TED на эту тему мне попалось намного позже.

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

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

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

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

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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru