За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer и Garage48. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.
Скажу сразу, работать с командами клиентов и собирать свою команду — не одно и тоже. Есть свои преимущества и недостатки, но так же, есть общие практики, которые будут полезны как аджайл-коучам, так и технологическим предпринимателям.
Хочу поделиться парой инструментов, которые помогут быстро понять кто есть кто в команде и сэкономить время некоторых командо-образующих процессов.
Итак, предположим, что у нас есть группа людей (5-7 человек), которой предстоит работать вместе над проектом. С чего начать сборку? Начнем со знакомства…
SELL / BUY
Зачем?
Сколько времени займет?
Что потребуется?
Шаг 1. Подготовка
Предлагаем членам команды взять по индекс-карте и разделить ее на две части: левую назовем Sell, правую — Buy. На флипчарте записываем 2 вопроса и даем участникам 2-3 минуты на ответы и заполнение своей индекс-карты.
Шаг 2. Представление
Предлагаем каждому члену команды (по кругу) представиться, если они еще не знакомы, озвучить свои сильные стороны и свои интересы в профессиональном росте. Это может занять по 1-3 минуты на человека, в целом на команду — до получаса.
Шаг 3. Дебриф
Каждое командное упражнение полезно усиливать дебрифом. Здесь можно будет просто задать вопрос: “Что вы заметили?”. На моем опыте, наблюдения были следующими:
* На мой взгляд, вопрос “Что вы заметили?” — самый простой и быстрый способ дебрифа, какой бы командной активностью вы ни занимались. Он усиливает внутреннюю рефлексию (осознание) и вытягивает на поверхность, как очевидные, так и неявные выводы. Очень советую задавать его, или его модификации почаще.
Следующей командной активностью я бы предложила сделать формирование матрицы навыков. Его целью так же будет исследование навыков и знаний, но не для общего знакомства, а уже для анализа состава и уровня кросс-функциональности команды. Небольшое отступление на тему кросс-функциональности.
Командная кросс-функциональность
Часто она понимается неверно, как будто предлагается использовать фронт-энд девелопера для проектирования архитектуры базы данных, а дизайнера для написания тест-кейсов.
На самом деле речь идет о командной кросс-функциональности, а не об индивидуальной. То есть, под кросс-функциональностью мы понимаем способность целой команды выполнить все функции, необходимые для реализации проекта.
Олдскульный командный коуч во мне всегда предлагает максимально сконцентрировать навыки и знания команды в одной точке, буквально — в одной комнате. В мире распределенных проектов, это все менее возможно, но если бы я строила сейчас свою команду, я бы пренебрегла экономией офисных и зарплатных расходов в пользу высокой продуктивности, которую могут развить люди, работающие вместе, в общей временной зоне, стране, культуре и физическом пространстве.
Индивидуальная кросс-функциональность
Другой важный аспект высокой продуктивности — наличие, или даже подавляющее большинство Т-людей в команде. Здесь речь идет уже об индивидуальной кросс-функциональности, и вот что я под ней понимаю.
Специалист Т-формы получил такое название потому, что имеет глубокое (как основание буквы T) понимание одной дисциплины/домена и широкие (как шапка буквы T) интересы в других смежных областях.
Такой человек приносит 3 типа пользы проекту:
Нельзя недооценивать важность последнего пункта, особенно в динамичных технологических проектах, в которых девелоперы развивают широкое знание доменных и функциональных областей, и генерируют value куда выше, чем только строки качественного кода.
Нам нужна команда-звезда, а не команда звезд, поэтому, полезно растить Т-людей и соблюдать баланс командной и индивидуальной кросс-функциональности.
Первым шагом на этом пути может стать воркшоп по созданию матрицы навыков.
SKILLS MATRIX
Зачем?
Сколько времени займет?
Что потребуется?
Кого пригласить?
Шаг 1. Vision
Попросите вашего Владельца Продукта (может быть, это вы и есть) о коротком питче идеи продукта:
Конечно, если вы пишете интерфейсы интеграции двух корпоративных EPR-систем, содержание питча будет отличаться, однако цель его остается прежней: получить быстрое понимание что же мы будем писать, какие навыки нам понадобятся, какие технологии мы свободны выбирать, а какие уже являются предопределенным ограничением.
Шаг 2. Навыки
Руководствуясь питчем и спецификацией, выпишите навыки и технологии, которыми должна обладать команда. Вы можете их писать вначале на стикерах, или сразу — на флипчарте, в зависимости от того, насколько вы свободны в обсуждении и выборе технологий.
Флипчартный лист мы расчерчиваем матрицей, в колонках которой будут технологии и навыки, а в строках — имена людей.
Пример колонок:
Шаг 3. Люди
Коллеги из олдскульного проджект менеджмента, предлагаю сразу перестать называть людей ресурсами. Люди это люди. В строках у нас будут имена, фамилии либо никнеймы — как пожелает сама команда.
Постарайтесь, пожалуйста, не забыть никого “в шкафу”, как это часто в моей практике происходило с дизайнерами: после недели тренингов и коучинга с запуском проекта, на этапе заполнения матрицы, руководство «вспоминало», что забыли пригласить UX-а.
Итак, в строках у нас получился список членов команды. Шаблон матрицы готов, начинаем заполнять. Лучше если кто-то один нарисует заготовки кружков для всей матрицы, на пересечении строк и столбцов. Ниже — пример того, что должно получиться.
Шаг 4. Солнышки
Каждый член команды заполняет матрицу одним из 4-х типов “солнышка”. Под солнышком понимается кружок, разделенный на 4 сегмента.
Правила заполнения:
Обратите внимание, что если член команды принципиально не хочет выполнять какую-либо задачу, даже если он умеет это делать, мы не просим его заполнить кружок. Здесь, скорее необходимо поработать над мотивацией, пониманием важности командной работы и поддержки, но не стоит заставлять людей делать то, что не принесет им радости. Скорее всего, и проекту это пользы не принесет.
Шаг 5: Анализ
Теперь давайте посмотрим, что же все это значит для нас.
Паттерн: пустые колонки — первое, на что мы можем обратить внимание. Это значит, что команда еще не укомплектована, нужно открывать вакансию или искать кого-то из “family, fools, friends” в случае стартапа.
Если навык редкий и редко-используемый, существует соблазн найти кого-то part-time или воспользоваться подрядными услугами. Очень не советую: зависимость команды от внешних людей может привести к ожиданиям, разделению на “мы” и “они” и мячу на чьей-то стороне.
Если вы действительно ограничены в ресурсах или никак не можете найти постоянного члена команды, то, как минимум, придерживайтесь правила: внешний специалист никогда не должен работать один. Попробуйте найти Т-человека в вашей команде, который захочет освоить эту область, хотя бы на уровне “полу-солнышко”, и предложите ему работать в паре с привлеченным специалистом.
Готова ответить возражениями по поводу двойной стоимости парной работы, но чуть позже, поскольку ниже еще буду говорить о проектных рисках.
Паттерн: одинокие “солнышки”, заполненные больше, чем наполовину. Они создают обманчивую уверенность наличия настоящей “звезды” у нас в команде. Поэтому, полезно проверять таких людей на “автобусный фактор”.
Одинокие солнце-звезды (как и внешние специалисты, о которых я писала выше) — потенциальные “клиенты” автобусного фактора. Несмотря на всю их квалификацию, достаточно умелого хедхантинга, отпуска или рождения ребенка, что бы проект оказался в опасности.
Что делать? Определить, кто хотел бы освоить этот навык или сферу проекта, предложить работу в паре или переключение между задачами, растить Т-людей.
Паттерн: Ни одного закрашенного солнышка рядом с закрашенными наполовину. Вывод очевиден: у нас есть средние специалисты, возможно, с желанием учиться, но отсутствием внутренних менторов. Чем чревато? Сомнительным качеством или недостаточной скоростью работы. Решение: обучение внутри компании, внешний или корпоративный тренинг, найм более крутого “солнышка” — на выбор.
Как еще можно использовать матрицу навыков:
Может быть, у вас есть другие идеи по применению?
Любым бумажным артефактам полезно повисеть какое-то время на стене в комнате команды — они, вместе с дискуссиями в ходе упражнений, создают групповую социальную память, которая очень важна в процессе командообразования.
О последнем, планирую собрать идеи и инструменты для следующей публикации. Разумеется, речь не о совместных вылазках на природу и корпоративных вечеринках. У меня есть сильное убеждение, что командообразование, созданное на пикниках и вечеринках, к сожалению, там же и заканчивается.
Спасибо за внимание, буду рада ответить на вопросы и комментарии ниже.
Скажу сразу, работать с командами клиентов и собирать свою команду — не одно и тоже. Есть свои преимущества и недостатки, но так же, есть общие практики, которые будут полезны как аджайл-коучам, так и технологическим предпринимателям.
Хочу поделиться парой инструментов, которые помогут быстро понять кто есть кто в команде и сэкономить время некоторых командо-образующих процессов.
Итак, предположим, что у нас есть группа людей (5-7 человек), которой предстоит работать вместе над проектом. С чего начать сборку? Начнем со знакомства…
SELL / BUY
Зачем?
- познакомиться, узнать о сильных сторонах и интересах коллег
- почувствовать гордость за себя и ресурсное состояние команды
Сколько времени займет?
- 30-40 минут
Что потребуется?
- индекс-карты или стикеры
- фломастеры
- флипчарт
- маркеры
Шаг 1. Подготовка
Предлагаем членам команды взять по индекс-карте и разделить ее на две части: левую назовем Sell, правую — Buy. На флипчарте записываем 2 вопроса и даем участникам 2-3 минуты на ответы и заполнение своей индекс-карты.
- SELL: Какие навыки и качества у меня развиты в избытке, могу их легко “продать”?
- BUY: Какие навыки и качества я бы хотел “купить”, т.е. развить в себе еще больше?
Шаг 2. Представление
Предлагаем каждому члену команды (по кругу) представиться, если они еще не знакомы, озвучить свои сильные стороны и свои интересы в профессиональном росте. Это может занять по 1-3 минуты на человека, в целом на команду — до получаса.
Шаг 3. Дебриф
Каждое командное упражнение полезно усиливать дебрифом. Здесь можно будет просто задать вопрос: “Что вы заметили?”. На моем опыте, наблюдения были следующими:
- в комнате довольно много толковых людей, с которыми интересно будет поработать
- есть люди, готовые учиться и люди, готовые поделиться знаниями
- у нас есть практически все, что бы сделать классный продукт
* На мой взгляд, вопрос “Что вы заметили?” — самый простой и быстрый способ дебрифа, какой бы командной активностью вы ни занимались. Он усиливает внутреннюю рефлексию (осознание) и вытягивает на поверхность, как очевидные, так и неявные выводы. Очень советую задавать его, или его модификации почаще.
Следующей командной активностью я бы предложила сделать формирование матрицы навыков. Его целью так же будет исследование навыков и знаний, но не для общего знакомства, а уже для анализа состава и уровня кросс-функциональности команды. Небольшое отступление на тему кросс-функциональности.
Командная кросс-функциональность
Часто она понимается неверно, как будто предлагается использовать фронт-энд девелопера для проектирования архитектуры базы данных, а дизайнера для написания тест-кейсов.
На самом деле речь идет о командной кросс-функциональности, а не об индивидуальной. То есть, под кросс-функциональностью мы понимаем способность целой команды выполнить все функции, необходимые для реализации проекта.
Олдскульный командный коуч во мне всегда предлагает максимально сконцентрировать навыки и знания команды в одной точке, буквально — в одной комнате. В мире распределенных проектов, это все менее возможно, но если бы я строила сейчас свою команду, я бы пренебрегла экономией офисных и зарплатных расходов в пользу высокой продуктивности, которую могут развить люди, работающие вместе, в общей временной зоне, стране, культуре и физическом пространстве.
Индивидуальная кросс-функциональность
Другой важный аспект высокой продуктивности — наличие, или даже подавляющее большинство Т-людей в команде. Здесь речь идет уже об индивидуальной кросс-функциональности, и вот что я под ней понимаю.
Специалист Т-формы получил такое название потому, что имеет глубокое (как основание буквы T) понимание одной дисциплины/домена и широкие (как шапка буквы T) интересы в других смежных областях.
Такой человек приносит 3 типа пользы проекту:
- может качественно реализовать свое основное предназначение
- может заменить или поработать в паре в зонах, требующих ресурсной поддержки
- может выслушать и понять, поделиться мнением, и генерировать свежие идеи по многим проектным вопросам
Нельзя недооценивать важность последнего пункта, особенно в динамичных технологических проектах, в которых девелоперы развивают широкое знание доменных и функциональных областей, и генерируют value куда выше, чем только строки качественного кода.
Нам нужна команда-звезда, а не команда звезд, поэтому, полезно растить Т-людей и соблюдать баланс командной и индивидуальной кросс-функциональности.
Первым шагом на этом пути может стать воркшоп по созданию матрицы навыков.
SKILLS MATRIX
Зачем?
- составить карту навыков, необходимых для реализации продукта
- узнать о всех людях, доступных на проекте (желательно присутствие всех, даже part-time и подрядных участников, если такие есть)
- проанализировать насколько достаточны знания и навыки команды
- понять “узкие места” и потенциальные ресурсные риски
- спланировать действия по передаче знаний и развитию кросс-функциональности в команде
Сколько времени займет?
- 60-180 минут
Что потребуется?
- флипчарт
- маркеры
- стикеры
- фломастеры
- Беклог Продукта (по скрам), спецификацию, или требования (как бы вы их ни называли)
Кого пригласить?
- всю команду
- Владельца Продукта (по скрам), заказчика, или того, кто имеет максимально ясное представление о том, что мы будем разрабатывать (как бы вы его ни называли)
Шаг 1. Vision
Попросите вашего Владельца Продукта (может быть, это вы и есть) о коротком питче идеи продукта:
- какую проблему он будет решать
- кто ключевые пользователи
- как он планирует зарабатывать деньги
- какие конкуренты есть на рынке
- чем мы хотим отличаться
- какие технологии планируется использовать
- какие существуют ограничения
Конечно, если вы пишете интерфейсы интеграции двух корпоративных EPR-систем, содержание питча будет отличаться, однако цель его остается прежней: получить быстрое понимание что же мы будем писать, какие навыки нам понадобятся, какие технологии мы свободны выбирать, а какие уже являются предопределенным ограничением.
Шаг 2. Навыки
Руководствуясь питчем и спецификацией, выпишите навыки и технологии, которыми должна обладать команда. Вы можете их писать вначале на стикерах, или сразу — на флипчарте, в зависимости от того, насколько вы свободны в обсуждении и выборе технологий.
Флипчартный лист мы расчерчиваем матрицей, в колонках которой будут технологии и навыки, а в строках — имена людей.
Пример колонок:
- html5
- css3
- PHP
- JS
- DB
- UX
Шаг 3. Люди
Коллеги из олдскульного проджект менеджмента, предлагаю сразу перестать называть людей ресурсами. Люди это люди. В строках у нас будут имена, фамилии либо никнеймы — как пожелает сама команда.
Постарайтесь, пожалуйста, не забыть никого “в шкафу”, как это часто в моей практике происходило с дизайнерами: после недели тренингов и коучинга с запуском проекта, на этапе заполнения матрицы, руководство «вспоминало», что забыли пригласить UX-а.
Итак, в строках у нас получился список членов команды. Шаблон матрицы готов, начинаем заполнять. Лучше если кто-то один нарисует заготовки кружков для всей матрицы, на пересечении строк и столбцов. Ниже — пример того, что должно получиться.
Шаг 4. Солнышки
Каждый член команды заполняет матрицу одним из 4-х типов “солнышка”. Под солнышком понимается кружок, разделенный на 4 сегмента.
Правила заполнения:
- Пустое: Не могу или не хочу выполнять эту задачу совсем
- Первая верхняя четверть закрашена: Знаком с элементами задачи
- Вертикальная половинка закрашена: Могу выполнить с чьей-то помощью
- Три четверти закрашено: Могу выполнить задачу самостоятельно
- Все закрашено: Могу выполнить сам и научить другого
Обратите внимание, что если член команды принципиально не хочет выполнять какую-либо задачу, даже если он умеет это делать, мы не просим его заполнить кружок. Здесь, скорее необходимо поработать над мотивацией, пониманием важности командной работы и поддержки, но не стоит заставлять людей делать то, что не принесет им радости. Скорее всего, и проекту это пользы не принесет.
Шаг 5: Анализ
Теперь давайте посмотрим, что же все это значит для нас.
Паттерн: пустые колонки — первое, на что мы можем обратить внимание. Это значит, что команда еще не укомплектована, нужно открывать вакансию или искать кого-то из “family, fools, friends” в случае стартапа.
Если навык редкий и редко-используемый, существует соблазн найти кого-то part-time или воспользоваться подрядными услугами. Очень не советую: зависимость команды от внешних людей может привести к ожиданиям, разделению на “мы” и “они” и мячу на чьей-то стороне.
Если вы действительно ограничены в ресурсах или никак не можете найти постоянного члена команды, то, как минимум, придерживайтесь правила: внешний специалист никогда не должен работать один. Попробуйте найти Т-человека в вашей команде, который захочет освоить эту область, хотя бы на уровне “полу-солнышко”, и предложите ему работать в паре с привлеченным специалистом.
Готова ответить возражениями по поводу двойной стоимости парной работы, но чуть позже, поскольку ниже еще буду говорить о проектных рисках.
Паттерн: одинокие “солнышки”, заполненные больше, чем наполовину. Они создают обманчивую уверенность наличия настоящей “звезды” у нас в команде. Поэтому, полезно проверять таких людей на “автобусный фактор”.
Автобусный фактор (Bus Factor) это забавная проектная «метрика», которая показывает, как много специалистов в вашем проекте может сбить автобус, и проект все еще останется жив.
Одинокие солнце-звезды (как и внешние специалисты, о которых я писала выше) — потенциальные “клиенты” автобусного фактора. Несмотря на всю их квалификацию, достаточно умелого хедхантинга, отпуска или рождения ребенка, что бы проект оказался в опасности.
Что делать? Определить, кто хотел бы освоить этот навык или сферу проекта, предложить работу в паре или переключение между задачами, растить Т-людей.
Паттерн: Ни одного закрашенного солнышка рядом с закрашенными наполовину. Вывод очевиден: у нас есть средние специалисты, возможно, с желанием учиться, но отсутствием внутренних менторов. Чем чревато? Сомнительным качеством или недостаточной скоростью работы. Решение: обучение внутри компании, внешний или корпоративный тренинг, найм более крутого “солнышка” — на выбор.
Как еще можно использовать матрицу навыков:
- при вводе нового члена команды в курс дел
- при росте проекта: может иметь смысл разделить команду и добавить в каждую из подкоманд новых людей
- при поворотах (pivots) идеи и подключению новых технологий
Может быть, у вас есть другие идеи по применению?
Любым бумажным артефактам полезно повисеть какое-то время на стене в комнате команды — они, вместе с дискуссиями в ходе упражнений, создают групповую социальную память, которая очень важна в процессе командообразования.
О последнем, планирую собрать идеи и инструменты для следующей публикации. Разумеется, речь не о совместных вылазках на природу и корпоративных вечеринках. У меня есть сильное убеждение, что командообразование, созданное на пикниках и вечеринках, к сожалению, там же и заканчивается.
Спасибо за внимание, буду рада ответить на вопросы и комментарии ниже.
