За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer ^[1] и Garage48 ^[2]. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.

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

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

Итак, предположим, что у нас есть группа людей (5-7 человек), которой предстоит работать вместе над проектом. С чего начать сборку? Начнем со знакомства…

SELL / BUE

Зачем?

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

Сколько времени займет?

• 30-40 минут

Что потребуется?

• индекс-карты или стикеры
• фломастеры
• флипчарт
• маркеры

Шаг 1. Подготовка

Предлагаем членам команды взять по индекс-карте и разделить ее на две части: левую назовем Sell, правую — Bue. На флипчарте записываем 2 вопроса и даем участникам 2-3 минуты на ответы и заполнение своей индекс-карты.

• SELL: Какие навыки и качества у меня развиты в избытке, могу их легко “продать”?
• BUE: Какие навыки и качества я бы хотел “купить”, т.е. развить в себе еще больше?

Даем участникам 3-4 минуты на заполнение индекс-карт.

Шаг 2. Представление

Предлагаем каждому члену команды (по кругу) представиться, если они еще не знакомы, озвучить свои сильные стороны и свои интересы в профессиональном росте. Это может занять по 1-3 минуты на человека, в целом на команду — до получаса.

Шаг 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 ^[4]) это забавная проектная «метрика», которая показывает, как много специалистов в вашем проекте может сбить автобус, и проект все еще останется жив.

Одинокие солнце-звезды (как и внешние специалисты, о которых я писала выше) — потенциальные “клиенты” автобусного фактора. Несмотря на всю их квалификацию, достаточно умелого хедхантинга, отпуска или рождения ребенка, что бы проект оказался в опасности.

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

Паттерн: Ни одного закрашенного солнышка рядом с закрашенными наполовину. Вывод очевиден: у нас есть средние специалисты, возможно, с желанием учиться, но отсутствием внутренних менторов. Чем чревато? Сомнительным качеством или недостаточной скоростью работы. Решение: обучение внутри компании, внешний или корпоративный тренинг, найм более крутого “солнышка” — на выбор.

Как еще можно использовать матрицу навыков:

• при вводе нового члена команды в курс дел
• при росте проекта: может иметь смысл разделить команду и добавить в каждую из подкоманд новых людей
• при поворотах (pivots) идеи и подключению новых технологий

Может быть, у вас есть другие идеи по применению?

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

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

Спасибо за внимание, буду рада ответить на вопросы и комментарии ниже.

Автор: Natatara