За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer и Garage48. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.
Скажу сразу, работать с командами клиентов и собирать свою команду — не одно и тоже. Есть свои преимущества и недостатки, но так же, есть общие практики, которые будут полезны как аджайл-коучам, так и технологическим предпринимателям.
Хочу поделиться парой инструментов, которые помогут быстро понять кто есть кто в команде и сэкономить время некоторых командо-образующих процессов.
Итак, предположим, что у нас есть группа людей (5-7 человек), которой предстоит работать вместе над проектом. С чего начать сборку? Начнем со знакомства…
SELL / BUE
Зачем?
- познакомиться, узнать о сильных сторонах и интересах коллег
- почувствовать гордость за себя и ресурсное состояние команды
Сколько времени займет?
- 30-40 минут
Что потребуется?
- индекс-карты или стикеры
- фломастеры
- флипчарт
- маркеры
Шаг 1. Подготовка
Предлагаем членам команды взять по индекс-карте и разделить ее на две части: левую назовем Sell, правую — Bue. На флипчарте записываем 2 вопроса и даем участникам 2-3 минуты на ответы и заполнение своей индекс-карты.
- SELL: Какие навыки и качества у меня развиты в избытке, могу их легко “продать”?
- BUE: Какие навыки и качества я бы хотел “купить”, т.е. развить в себе еще больше?
Даем участникам 3-4 минуты на заполнение индекс-карт.
Шаг 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) идеи и подключению новых технологий
Может быть, у вас есть другие идеи по применению?
Любым бумажным артефактам полезно повисеть какое-то время на стене в комнате команды — они, вместе с дискуссиями в ходе упражнений, создают групповую социальную память, которая очень важна в процессе командообразования.
О последнем, планирую собрать идеи и инструменты для следующей публикации. Разумеется, речь не о совместных вылазках на природу и корпоративных вечеринках. У меня есть сильное убеждение, что командообразование, созданное на пикниках и вечеринках, к сожалению, там же и заканчивается.
Спасибо за внимание, буду рада ответить на вопросы и комментарии ниже.
Автор: Natatara
