Кросс-функциональность, Т-люди и Автобусный фактор

в 4:59, , рубрики: agile, запуск проекта, командообразование, разработка, стартап, управление людьми, управление проектами, метки: , , , ,

За последние полгода мне удалось побывать на двух стартап-конкурсах — 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

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js