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