​​T-shape или как не взаимодействовать с клиентом.

Команда начинает задумываться про матрицу компетенций, когда сталкивается с bus-фактором. Редко - это происходит само, чаще - после какого-то факапа (участник ушёл в отпуск, и только он знал, как "настроить интеграцию" в итоге провалена цель спринта). И после важного обсуждения кому необходимо подтянуть компетенции через месяц, квартал, полугодие - рвение заканчивается. А T-shape - это непрерывный процесс, а не разовый результат.

1 января зашёл в ресторан. Полная посадка. Работает 1 официант и 1 администратор. Приём и раздача заказов происходит архимедленно. Выяснилось 2 факта:
▫️второй официант заболела
▫️не ожидали такого наплыва 1 числа.

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

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

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

О лидерстве

Существует 3 категории командных лидеров:

✌️ Первые - видят возможности развития команды, которые видны другим участникам команды и после успешного релиза такие лидеры получают удовлетворение от работы
✌️ Вторые - помогают увидеть команде точки своего развития, которые участники команды и сами бы увидели, если чуть больше постарались. Но всё же команда приходит к решениям самостоятельно (в среднем таким могут похвастаться команды, которые работают по Скрам от 1 года и более вместе). Такие лидеры после успешного релиза испытывают душевное спокойствие и наполняются энтузиазмом
✌️ А есть третья категория - лидеры, которые находят точки роста там, где их по идее быть не может!

Встречали третью категорию? Какой у вас опыт взаимодействия с такими людьми?

В продолжение предыдущего поста история одного лидера из 3-ей категории - Роберто Орос ди Бартини. Спасибо Ивану и его каналу🙏👏

Кого проще найти скрам-мастера или руководителя проектов? (с п о й л е р: обоих сложно)

Поделюсь опытом подбора СМ и РП. Возможно, это поможет тем, кто находится в поисках себя на эти позиции.

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

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

В целом было 3 потока людей:

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

📌 Безскилловые - полгода посидели с командой и хочу заоблачную ЗП, при этом скрам-гайд не открывали, а зачем?

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

Ну, подумал я, руководителя проекта-то я точно быстро смогу найти😏👍. И тут меня ждало ещё бОльшее разочарование. COVID не только подкосил здоровье на планете, но и здравое сознание неокрепших умов, когда у тебя год опыта в управлении проектами, а зарплату ты хочешь овер 200к! Рыночек, конечно, порешает, но надо же здраво оценивать свой уровень и понимать, что управлять проектом на 5 человек на складе в Абрау-Дюрсо не одно и то же с управлением проектом по внедрению высоконагруженных информационных систем на тысячи пользователей в bloody-enterprise.

Поначалу искал людей со знаниями PMBoK/PRINCE2, затем - хотя бы с желанием узнать, что это такое🙏
По итогу воронка РП оказалась ещё глубже, чем в поиске скрам-мастеров.

Чтобы найти нужных ребят с мышлением нашей компании, потребовался целый год🤯.

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

Чтобы быть хорошим скрам-мастером нужны в первую очередь мозги, эмпатия, эмоциональный интеллект, желание развиваться, а не зубрёжка скрам-гайда (хотя прочесть надо!). А хорошим менеджером проекта - это уметь добиваться цели проекта во что бы ни стало, организовывать, коммуницировать, планировать, управлять рисками, управлять проектным треугольником и, в 2022-м, смотреть в сторону Agile, хотя бы в сфере ИТ, не забывая о том, что всё вышеперечисленное направлено на привнесение ценности для клиента.

​​scrum of skills VS scrum of chance

Команда генерирует ценность для бизнеса. А что делать с техдолгом?

Встречал подходы:
👉 брать техдолг в спринт по "0" стоимости. То есть команда считала, что - это их недоработка и должны править код в независимости от capacity: в рабочее или нерабочее время.
👉 не брать техдолг вовсе - legacy растёт, ну а что делать? Нужно доставлять ценность!

Одна из нынешних команд пришла к тому, что надо брать техдолг в работу наравне с пользовательскими историями, но как понять: "а сколько можем осилить"? Это наложилось на непростой период: завершён 1,5 месячный проект, баги, техдолг. Что делать? Да как обычно - любое решение можно принять, основываясь на реально собранных данных🤩

В итоге:
✌️считаем доступность команды
✌️capacity в спринтах
✌️снижаем количество сторипойнтов на "NN" процентов
✌️мониторим тренд роста/решения техдолга
✌️а самое главное - прозрачность!

Берём задачи по техдолгу в спринт бэклог, а не делаем где-то там "на коленке" в обход дэйли и прочих скрам-активностей. Таким образом команда сможет быстрее увидеть границы правильного баланса, чем в случае изменений "наугад"🧙‍♂️

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

Замечали в своих командах, что начинают страдать постулаты прозрачность/инспекция/адаптация (делать что-то в обход бэклога/ отменять ретро/ не действовать по шагам, которые вынесли для улучшений)?
Поработать с одним из них для команды - уже большая победа!💪

"Вы будете знать, сколько "достаточно", пока не узнаете сколько это - "больше, чем достаточно" (с). Уильям Блейк.

​​CTQ Tree

Пользователь обратился к нам с проблемой, но как понять то ли мы достигли, что на самом деле хотел пользователь. Можно воспользоваться подходом из Lean Six Sigma - CTQ (Critical To Quality) Tree.

3 компонента, которые включает в себя CTQ:

💡 Потребность – критические потребности ваших клиентов.
Вопрос для самопроверки: "Какая потребность у человека, чтобы полностью быть удовлетворённым вашим продуктом или сервисом?"

💡 Драйверы – драйверы качества, которые необходимы для удовлетворения этих потребностей.
Вопрос для самопроверки: "Какие элементы или характеристики клиенты будут предпочтительней оценивать, когда будут судить о качестве вашего продукта или сервиса?"

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

Например, если потребитель хочет пить кофе, чтобы чувствовать себе бодрым и уверенным - на самом деле можно выразить следующими CTQ:

📌 Выходные характеристики (горячий кофе)
📌 Метрика - которую необходимо улучшить (температура кофе в градусах по Цельсию)
📌 Целевое значение (75 градусов по цельсию)
📌 Спецификация или лимиты (между 70 и 80 градусами по Цельсию)

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

#непропроекты Время для ответа.

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

Ни всегда оперативность возможна. А какой разумный срок для ответа?⏱

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

📲 Мессенджер - до 2-х часов. Многие уже 2 года на удалёнке. Работа асинхронная, обед - тоже. Считаю, что направленный вопрос может попасть на время встречи человека (~1час) и обед (~1час). Итого до 2-х часов - это адекватное время для получения ответа.

📩 Почта — формализм. Когда получаю электронное письмо - ощущение близко к тому, что получил письмо обычной почтой с описью, уведомлением о вручении и меня уже ждут в прокуратуре🤪 Если вопрос не оперативный и не требует ответа "здесь и сейчас" (а если требует, то почему не написали в мессенджер?), то разумное время на ответ - до 1 рабочего дня. Обычно почта используется для того, чтобы зафиксировать договорённости ("минутки", протокол встречи, дальнейшие шаги или итоги проекта и т.д.)

☎️ Телефонный звонок - вам точно это нужно? Если да, то нужно запомнить несколько правил:
📞 Звонок - вторжение в личное пространство. Договорись заранее - удобно ли собеседнику.
📞 Звонок - трата времени. Текст прочесть быстрее, чем "Аааа, эээ, что я хотел сказать…"
📞 Звонок - риск потери времени. Половину собеседник может не запомнить и всё равно придётся дублировать часть инфы письменно.
📞 Звонок - риск несоблюдения договорённостей. О чём-то договорился, собеседник потом забИл/забЫл и ничего не докажешь. А переписка - сохранится.
📞 Звонок - риск потери инфы. Качество связи может быть "ниже плинтуса", если звонок из метро, к примеру. А текст - есть текст.

👦🏻👩‍🦰Личная встреча (опционально видеозвонок "one-to-one" в 2022🧑‍💻) - идеальный вариант для связи с клиентом, если накопилось несколько вопросов, которые требуют уяснение однозначного понимания обеих сторон и могут вызывать двусмысленность в переписке. Кроме того, клиентская лояльность повышается🎉, если общение - личное.

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

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

​​Продуктовый инструмент

"Эврика! У меня потрясающая идея! Надо срочно создавать продукт.

А люди действительно ждут твою идею?🤔 Ответив на этот вопрос, можно узнать есть ли реальная потребность у рынка. "Но мне ведь нужна полноценная команда по исследованию пользователей, чтобы сделать это правильно?"💁‍♂️ - необязательно. В большинстве стран мира Google поработает на вас. Answerthepublic — отличный инструмент для первичного анализа. Благодаря ему можно проанализировать не только потребность, но и оценить: рассчитывать на глобальный рынок или только на локальный?

Например, мы хотим узнать потребность людей разных стран в доставке еды. Ок, гугл…https://answerthepublic.com/

Итак, в 🇬🇧Британии людей больше всего интересует:
🔸 Какие компании доставки платят больше?
🔸 Принимают ли какие-то доставки cash?
🔸 Где роботы по доставке еды?
🔸 Кто доставляет в локдаун при Ковиде?

А в 🇷🇺России спрашивают:
🔸 Доставка еды для похудения/без глютена/без сахара/без лактозы/без мяса
🔸 Доставка еды в область
🔸 Города запрашиваемые для доставки (Москва, Спб, Зеленоград, Королёв, Екатеринбург, Набережные Челны)
🔸 Или доставка еды "с бесплатной доставкой" (наш менталитет😉)

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

​​Инструмент для дорожных карт

Время от времени в чатах мелькает вопрос: "поделитесь опытом, как можно вести roadmap продукта"?

В своём выступлении на Agile Days '21 Павел Алфёров отметил, что сейчас сложно встретить применение чистых Agile-подходов в связке с бизнесом. Скорее модель выглядит так: бизнес работает с предиктивным типом проектов, в которые встраиваются ИТ со своими скрамами, канбан-методами и т.д.

Это как раз наш случай. Бизнес работал с долгоиграющими проектами во Wrike, а ИТ - команда использовала в работе продукты Atlassian (Service Management, Software, Bitbucket, Confluence). Всё управляемо пока продуктов было немного, но бизнес и количество проектов & продуктов значительно выросли. И если на стыке ИТ по-прежнему хорошо работала связка ITIL & Scrum, то с бизнесом появились постоянные "провисания" задач, непрозрачность и т.д.

Мы долго подбирали инструментарий, чтобы подружить Atlassian с Wrike, начиная с попыток интеграции этих 2 продуктов до взглядов на платные add-ons к Jira.

В итоге остановились на продукте Advanced Roadmaps или "Jira Plans" от Atlassian, который интегрирован в Jira Software.

"➕":
🎉 полная интеграция в Jira Software
🎉 управление "классическими" предиктивными проектами, проектами по Agile и продуктами "под одной крышей"
🎉 возможность назначать несколько команд для работы над одним продуктом и видеть capacity каждой команды по спринтам на общем roadmap
🎉 возможность строить карты зависимости задач друг от друга на общей доске
🎉 попробовав пару раз поработать в Jira Plans про MS Project хочется забыть, т.к. первый, сохранив возможности проджекта, даёт бОльшую гибкость в работе с ИТ-продуктами

"➖":
🥶цена. Продукт доступен только в подписке Premium, которая увеличивает в 2 раза стоимость использования. Поэтому логично использовать для большого числа команд (от 100 пользователей), взаимодействующих с бизнесом, который работает по предиктивной модели

Уже 2-й месяц живём с этим продуктом. ИТ-команды и бизнес получили эффективный инструмент повышения прозрачности взаимодействия.

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

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

💭 БЛАГОДАРНОСТЬ за потраченное время
💭 ДЕМОНСТРИРУЕТ ПОНИМАНИЕ различия стран
💭 ЛИДЕР, который его вдохновил ("я никогда не забуду тот день")
💭 КОНФЛИКТ (влияние отца с требованием снять фото со стены) на который он не поддался - и умение ОТСТАИВАТЬ МНЕНИЕ
💭 ПРИВОДИТ ОБЪЕКТИВНЫЕ АРГУМЕНТЫ почему другая сторона конфликта имела свои основания на такое мнение (через что прошёл отец: война, пропаганда, дезинформация, потери физические и моральные)
💭 ПРИЗНАНИЕ ВЕЛИЧИЯ города Ленинграда и защищавшего его народа (несмотря на очевидный ущерб непосредственному родственнику)
💭 УМЕНИЕ ДИФФЕРЕНЦИРОВАТЬ, что лидер - это не про флаг, а - про человека
💭 ПРОЯВЛЕНИЕ ЭМПАТИИ, описывая качества Власова: чуткость, доброта, ум, щедрость
💭 ТАКТИЛЬНАЯ СВЯЗЬ: фотография, кружка (пьёт кофе каждое утро из неё😊, ну, тут толика лукавства и приукрашивания, вряд ли каждое, но субъективно не проверить наверняка, но как же это органично вплетено в сторителл
💭 ТРАНСФЕРИНГ от примера и лидера переходит к народу, про их качества и черты
💭 ПРОЯВЛЕНИЕ ЭМПАТИИ: "надеюсь, что вы позволите мне сказать вам правду" (максимально осторожное "вторжение" со своим мнением)
💭 ПРОЯВЛЕНИЕ ЭМПАТИИ сразу же сглаживает возможные возмущения, что никто не захочет слушать про критику своего правительства
💭 ДЕМОНСТРАЦИЯ РАВЕНСТВА, что он не совсем чужой в этой команде и имеет право высказать своё мнение и дать обратную связь ("но, как давний друг российского народа")
💭 ДОПОЛНИТЕЛЬНО ГАСИТ ВОЗМОЖНЫЙ ОППУРТУНИЗМ ("Позвольте напомнить, что я вам говорю это с той же искренней заботой")
💭 ПРИВОДИТ АРГУМЕНТЫ, КОТОРЫЕ СЛОЖНО ОСПОРИТЬ. Они не оспариваются и легко проверяются по обе стороны, а дальше уже каждый может сделать логичный вывод, если пошевелить мозгами
💭 ЗАВЕРШАЕТ ЛОГИЧНОЙ СВЯЗЬЮ с началом герой прошлого времени - герои нашего времени, подчеркивая в чём для него заключается величие народа, а не страны.

​​В развитие поста https://news.1rj.ru/str/projman/71 подсказали: https://mycreativetype.com (Даша, спасибо за ресурс🙏) для определения собственного типажа креативности. В дополнение было интересно узнать с кем полезно сотрудничать твоему типу, что побуждает пройти тест всей командой. В нашем случае получился удивительный тандем innovator-maker-visionary-thinker.

P.s. При прохождении теста визуальные ощущения где-то между декорациями сериала "Игра в кальмара" и музеем современного искусства!

​​Весна показала кто где… "хайп" ловил.

Сейчас часто спрашивают как устроиться скрам-мастером пройдя курсы без практического опыта?

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

Поэтому для начинающего скрам-мастера vital получить скиллы лежащие в смежной плоскости: аналитик, разработчик, тестировщик, продакт/проджект менеджера и т.д., говоря про ИТ. Если таковых нет, то как минимум будет сложным вникать в то, за что команда сражается с бэклогом?!

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

В конце концов "отцы основатели" Agile пришли к созданию манифеста с большим бэкграундом собственных подходов: XP, Crystal, FDD, DSDM, и т.д. Набив шишки в области разработки, тестирования, коммуникаций с клиентами гораздо проще стать экспертом в области гибких методологий разработки, в том числе и Скрам, но не наоборот.

​​Коучинг владельца продукта

В задачи скрам мастера входит помогать стать эффективней DevTeam, организации и PO.
А как часто вы коучите PO? Это всегда происходит в ходе рабочего процесса или есть выделенные сессии?

Нашим скрам-мастерам пришёл запрос на коучинг владельцев продуктов по написанию пользовательских историй
Основные проблемы с которыми сталкивались команды:

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

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

Интересный вопрос на котором "зарубился" с архитектором систем:

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

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

Про архитектуру продукта

Покидаю компанию и с уходом "помрёт" мой email на который регал аккаунт в популярной международной обучающей платформе, где учился PMP и Agile.

Парадокс в том, что у них email выступает id-ключом аккаунта обучающегося. Без возможности сменить. Совсем! То есть даже служба поддержки это не в состоянии изменить! Аццкая архитектура🤯 Продакты и аналитики в канале можете подсказать чем руководствуется ИТ-команда зашивая такой безальтернативный способ авторизации?

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

Даже не припомню ещё сервиса где нельзя было бы сменить свой email на альтернативный при желании.

​​Scrum! Какой ты в условиях кризиса?

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

В Грузии пир обычно приводит к тому, что называют «шемомечама» — переводится как «не хотел, не собирался, но съел». Мы тоже не хотели, не собирались, но уже пришли туда, где находимся поэтому…

...поглядываем с некоторыми командами, использующими фреймворк скрам на канбан-метод, т.к. всё чаще звучат слова Lead Time, Cycle Time, приоритетные потоки, множество статусов задач, где выполненная командой задача не означает, что она не вернётся на предыдущие статусы работы, а главное - горизонт планирования уже перестал исчисляться двух- и даже одно-недельными планами.

Новые задачи влетают через день на третий. Хаос? Матрица Стейси сейчас один из оптимальных инструментов, чтобы выбрать решение в условиях нынешней "определённости". Приходим к тому, что для части команд этим решением станет канбан-метод.

​​Путешествие в Мордор

На прошлой неделе провели 2 дня тренинга по командообразованию для клиента. Исходными данными были 9 участников, множество новых людей в коллективе и шероховатости в доверии и взаимопонимании между участниками.

Началось всё с факапа. Выяснилось, что флипчарты для тренинга, которые рисовались заранее - бесследно исчезли. На что наш скрам-мастер Даша, улыбнувшись, ответила: "Я очень плох в планировании, но неплох в импровизации"😜😂 И, то, что ранее готовилось за час, на этот раз было сделано за 15 минут пока все участники наливали себе кофе с печеньками. Подумалось, это как раз тот случай, когда 5S в офисе - враг фасилитатора🤦‍♂️

Весь тренинг был упакован в единое повествование путешествия, где участникам необходимо было пройти ряд испытаний, чтобы стать настоящей командой:
🌊 Переплыть океан на корабле (визуализировали корабль и "мечту" какой командой они хотят стать, поделились фактами о себе, чтобы лучше узнать друг друга)
🎈 Спастись на воздушном шаре (работая уже как команда, искали возможности, чтобы добиться общей цели и спастись, терпя крушение)
🧙‍♂️ Повстречать местного жителя, приземлившись на суше необитаемого острова (попутно демонстрируя свои эмоции, слабые и стыдные стороны, чтобы наладить психологическую безопасность)
⛰ Двигаться по дремучему лесу в горы (чтобы описать реальные качества своей команды, которые помогут им в реальной работе добиваться общекомандных целей)

💠 Ярким событием стало то, что маркером доверия выступило как часто в течение встречи участники говорят "спасибо" друг другу. В первый день "спасибо" между участниками прозвучало один-единственный раз, но, всё больше формируя поддержку друг друга, во второй день благодарностей были десятки.

💜Очень запомнилась фраза одной из участниц мероприятия: "Не забывать, что ты человек, а не функция!"

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

​​Включать ли камеру на встречах?

С начала ковидной истории настораживал один из принципов Agile "face-to-face conversation".

Как командам следовать принципу в новых реалиях? Включить камеру = повысить эффективность общения? А работает ли вообще принцип в 2022 году?

- Однозначных ответов нет.

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

Близкое к моему ощущению формации общения написал в своём посте Брайан Милнер. Для наиболее эффективного общения распределённой команды нужно:

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

А включать или нет камеры решать вам😉