Компания
32,62
рейтинг
23 июня 2012 в 08:59

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

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

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

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

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

SELL / BUY

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

Сколько времени займет?
  • 30-40 минут

Что потребуется?
  • индекс-карты или стикеры
  • фломастеры
  • флипчарт
  • маркеры

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

Предлагаем членам команды взять по индекс-карте и разделить ее на две части: левую назовем Sell, правую — Buy. На флипчарте записываем 2 вопроса и даем участникам 2-3 минуты на ответы и заполнение своей индекс-карты.
  • SELL: Какие навыки и качества у меня развиты в избытке, могу их легко “продать”?
  • BUY: Какие навыки и качества я бы хотел “купить”, т.е. развить в себе еще больше?
Даем участникам 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
SCRUMguides
рейтинг 32,62
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (9)

  • +1
    Может BUY?
    • 0
      Спасибо, исправила.
  • +1
    Спасибо за статью.
    От себя хочу добавить: матрица навыков может стать очень хорошей базой для проработки планов саморазвития членов команды. Мы фактически визуализируем цели, которые необходимо превратить в задачи (помочь «солнышкам» правильно делиться накопленными знаниями, рассмотреть возможность парной разработки, запланировать внутренние семинары и поездки на конференции, закупить книжек, в конце-концов и т.д.). Главное, чтобы результат встречи по выработке матрицы навыков, не остался просто артефактом на стене).
    • +1
      Спасибо за дополнение, совершенно согласна. Ничего так не разрушает доверие и мотивацию, как «мы поговорили, а толку?». Поэтому, важно на выходе каждой командной встречи иметь план следующих шагов и имена людей, которые проследят, что бы шаги были пройдены.
  • 0
    Спасибо за яркие и глубокие аффирмации, вроде: «Нам нужна команда-звезда, а не команда звёзд». Метит куда-то в девизы социализма XXI века. Невероятно воодушевляет подход. Надеюсь, уже в самом ближайшем будущем всё это станет неотъемлемой частью индустрии ИТ на всём пост-советском пространстве. Поскольку, это и есть будущее.
  • 0
    На мой взгляд, в небольших компаниях матрица навыков может быть долгосрочным динамическим артефактом. Хоть бы и перерисовывать её каждый раз, когда положение дел меняется. Визуализация командных возможностей всегда востребована и всегда полезна.
  • 0
    Спасибо за отличные советы по анализу солнышек
    Vision полезно дополнить метафорой — описание системы в 5 словах. Например «Электронный кошелек для клиентов интернет-провайдера»
    Таким образом все понимают, на что должна быть похожа система и чем руководствоваться при решении вопросов с не очевидным ответом.
  • 0
    А вы не пробовали использовать SWOT анализ? Цель проста: определить сильные и слабые стороны каждого участника команды, а также возможности и угрозы которые из этого исходят. А на дебрифе свести данные и смотреть с чем команде придется мириться, а где минусы одного человека стоит компенсировать плюсами другого. Ну и конечно что развивать.
    • 0
      SWOT как инструмент люблю и, в основном, использую его для выбора одного варианта из нескольких, а так же в роли «сам себе маркетолог». В отношении людей, признаться, не пробовала, поэтому пофантазирую: я бы его свела к чуть более формальному варианту sell/buy, целью которого было бы не знакомство, а именно анализ. Есть похожий айсбрейкер, с вопросами:
      — Что я делать умею и люблю?
      — Что я могу делать, при необходимости?
      — Что я делать никогда не должен (и даже не просите)?

      У последнего может быть причина как в неумении, так и в нежелании. Такая формулировка персональна и чуть более общая, чем в Weaknesses. Думаю, для того, что бы использовать SWOT в чистом виде, в команде должна быть открытая атмосфера и доверие. А в свеже-собранной команде их еще нет, есть только сильная потенциальная возможность их построить. Вот лично я бы ею не рисковала, и использовала чуть более «мягкие» к признанию своих недостатков инструменты.

      Но мне интересен ваш опыт, я полагаю что все, как обычно, зависит от контекста. Как вы заполняете «внешние» блоки матрицы, Opportunities и Threats? По классике, они ведь включают внешние факторы (в данном случае, за пределами команды).

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка