К основному контенту

8 Параметров социальной жизни команды: как измерить неизмеримое

Автор: Наталья Тренина

Около полугода назад мне в руки попала книга Чарли Пелерина How NASA builds teams. В книге описывались социальные проблемы крупных технологических проектов, которые обошлись в миллионы долларов космической промышленности США. И, что более ценно - выводы, сделанные Чарли, в форме системы оценки социального контекста проектов NASA 4-D. По ссылке вы можете открыть весьма олдскульный сайт с анкетой, рекомендациями по заполнению и довольно обширными выдержками из книги. Однако, после нескольких экспериментов со знакомыми аджайл-командами, я пришла к выводу, что в мире современного user experience и живого общения, любую мудрую систему можно сделать чуть проще и человечнее :)
Итак, спустя несколько месяцев в моей практике появился такой вот
ВОРКШОП ПО “СОЦИАЛЬНЫМ ТЕРМОМЕТРАМ”
Как его провести? Небольшой мануал ниже.

Подготовка

  1. Любую командную активность лучше начинать с прелюдии. История полна примерами провалов отнюдь не в силу технологической не реализуемости проекта, а в силу тех или иных “человеческих” факторов. Используйте историю космической обсерватории Hubble из книги Чарли, или нагуглите софтверные эпические фейлы. Любая история, которая демонстрирует важность социального здоровья проекта будет хорошей затравкой, но хорошая история потребует подготовки.
  2. Подготовьте набор из 8-ми карточек с описанием шкалы. Ниже я опишу каждую из шкал в свободной форме, а сами карточки в формате PDF размером A6 вы можете выкачать по этой ссылке.
  3. Подготовьте наборы карт с цифрами от 2-х до 5-ти для каждого участника. Мы будем использовать эти карточки для непредвзятой оценки, по подобию той, которую даем всей командой в Planning Poker. 
  4. Подготовьте по листу бумаги для флипчарта A1. Его мы делим на 4 части и в каждой из частей рисуем по 2 шкалы. Вот что должно получиться (картинка).
  5. Еще нам потребуется явно видимый таймер, что бы у участников было здоровое ощущение границы времени. Дискуссия может поднять на поверхность немало вопросов, которые не обсуждались ранее. Обсуждение всех шкал может занять 30-60 минут, в зависимости от количества членов команды и открытости к обсуждению. Сам формат воркшопа построен таким образом, что бы помочь высказаться всем.
  6. Ну и наконец, не забудьте пригласить участников и предупредить клиентов о том, что вам потребуется этот час-полтора времени. Совет: “продайте” это как тематическую ретроспективу. Это так и есть. В результате у вас получится сырье для плана улучшений.

Проведение
  1. Расскажите свою историю и предложите воспользоваться системой NASA 4D в “Обертке” от SCRUMguides ;)
  2. Договоритесь о том, кто будет командным “летописцем” на время воркшопа. В ходе обсуждения шкал, вы можете услышать интересные вещи, о которых раньше не вспоминали открыто. Важно сохранить эту информацию, и использовать для улучшения процесса, взаимоотношений внутри команды или на уровне всей организации.
  3. Пройдитесь по шкалам, и убедитесь в том, что каждая из них понятна команде. По каждой шкале полезно договориться о “максимуме”. Что это значит - что у нас с этим фактором все замечательно? Примеры таких максимальных значений приведены в описании ниже. Команда может их корректировать по своему усмотрению. Главное, что бы у всех было ощущение “эталона”, с которым можно сверить текущую ситуацию.
  4. Самое интересное: как мы будем мерить? Процесс такой: 
    • Ведущий зачитывает объяснение шкалы
    • Команда договаривается о максимальном ее значении
    • Каждый участник выбирает карту с цифрой, которая, по его мнению характеризует текущее положение дел по этой шкале и кладет карту значением на стол
    • Когда все участники положили свои карты, карты одновременно вскрываются
    • Каждый участник по очереди отвечает - почему он выбрал именно эту карту? Чего, по его мнению, не хватает в команде/процессе, что бы добиться 5-ки? Какая история, ситуация символизирует его оценку?
    • Летописец записывает важные идеи, истории, предложения на стикерах и помещает рядом со шкалой, что бы вернуться к ним во второй части встречи
    • Как вы видите, в этом процессе все члены команды должны включиться в дискуссию, к этому “обязывает” использование карт. В такой ситуации снижается порог “смелости”, необходимой для высказывания мнения, ведь его выражают все. Важно обратить внимание команды - что “играют” (выбрасывают карты) все, и объясняют свой выбор так же все. 
    • Каждый участник ставит точку на той отметке, которую он выбросил. Или это делает за всех ведущий/фасилитатор/скрам-мастер. Как и в случае с покером планирования, значения не суммируются, точки ставятся “как есть”. Это можно сделать до или после объяснения выбора участниками.
  5. Итак, в результате первой части, у нас есть плакат с отметками на 8-ми шкалах и стикеры с “сырьем” для улучшений. Похоже, тут есть что подебрифить ;)
    • Какая самая “здоровая” наша шкала?
    • Какая шкала требует серьезных улучшений?
    • По какой шкале у нас самые совпадающие оценки?
    • По какой шкале наши мнения различаются более всего?
    • Изменения в какой шкале приведут к максимальным изменениям в остальных?
    • На какую шкалу мы сами можем повлиять более всего?
    • Над какой шкалой мы хотели бы поработать в следующей итерации?
  6. Как вы видите, мы плавно подошли ко второй части - брейнстормингу шагов/улучшений.

На этапе дебрифа ясна картина по всем шкалам и команда выбирает одну-две самые важные из них. Поэтому полезно отделять сбор “сырья” и его “переработку”, т.е. не проводить брейнсторм по каждой шкале во время ее обсуждения. Иначе воркшоп может сильно затянуться :)
Думаю, что полтора-два часа вместе с генерацией плана улучшений - адекватное время для этой активности. Из расчета на среднюю команду в 5-9 человек.
Не буду рассказывать как именно генерировать и отбирать идеи. Думаю, вы хороши в этом и без меня, благодаря регулярной “зарядке” - практике ретроспективы.
Приятного времяпровождения и полезных дискуссий вам! Кстати, насколько мне удалось заметить - этот процесс доставлял удовольствие и даже веселье участникам. Возможно, стоит немного настроить их на то, что это не “серьезный разговор”, а скорее - активность for fun. А от пользы им и так не отвертеться ;)

Описание шкал

I. CULTIVATING

1. Выражение благодарности и признания. Людям нравится чувствовать признание своих достижений и благодарность за работу со стороны окружающих. Через выражение искреннего признания создается атмосфера взаимного уважения членов команды.
Максимум шкалы: Признание и благодарность выражаются регулярно, искренне, своевременно, конкретно и соразмерно вкладу каждого участника.
2. Знание и использование общих интересов. Люди предпочитают взаимодействие в команде своим личным интересам тогда, когда понимают общие цели и выгоду от совместной работы. «Интересы» — это выражение ценностей и взглядов. Можно определить общие интересы задаваясь вопросом: «Что они хотят такого, чего я тоже для них хочу?».
Максимум шкалы: Члены команды знают интересы друг друга, их пересечения и умеют использовать их в разрешении споров и конфликтов.

II. INCLUDING

3. Правильное включение в процессы. Людям важно ощущать сопричастность к общей работе. Мы чувствуем «включенность» через обмен информацией, делегирование, выражение и учет мнений. Типичный пример недостаточного включения — принятие важного для всех решения неполным составом команды. Пример избыточного включения — скука на встречах и злоупотребление опциями СС и “Ответить всем” в почте.
Максимум шкалы: Члены команды обмениваются информацией, принимают решения, участвуют в реализации, избегая недостаточного или расточительного включения участников.
4. Соблюдение всех договоренностей. Людям нравится работать в атмосфере доверия, а доверие развивается путем соблюдения договоренностей, возможности “положиться” на принятое решение и на коллег, которые его поддержали. Кроме этого, правила обычно принимаются, что бы повысить эффективность работы. Если придерживаться договоренностей сложно, прежде чем от них отказаться или нарушить — обязательно обсуждайте причины и способы их корректировки.
Максимум шкалы: Принимаются только те правила, которые все участники договорились соблюдать и члены команды строго следуют договоренностям.

III. VISIONING

5. Выражение реалистичного оптимизма. Людям важно верить в позитивное будущее. Оптимизм усиливается через понимание конечных выгод и соотнесение с ними временных трудностей. Проблемы важно обсуждать открыто и своевременно, в атмосфере поддержки и здравого оптимизма.
Максимум шкалы: Все члены команды понимают цели и верят в их достижимость, поэтому придерживаются оптимистичного настроя даже когда сталкиваются с трудностями.
6. Приверженность конечной цели. Фокус на конечной цели повышает энергию и вовлеченность команды. Люди, нацеленные на результат, переживают изменение восприятия и начинают видеть дополнительные возможности (В английском языке есть класивая поговорка: «Where attention goes, power flows»).
Максимум шкалы: Члены команды демонстрируют 100%-ю приверженность и следование общим целям.

IV. DIRECTING

7. Отпор обвинителям и жалобщикам. Состояния драмы отнимают слишком много энергии. Лучше фокусироваться на разрешении проблем вместо поиска виновных или обстоятельств. Не вступайте в “клуб” жертв и агрессоров и культура команды станет более здоровой.
Максимум шкалы: В команде не принято обвинять других или жаловаться на обстоятельства. Члены команды избегают таких способов ухода от ответственности и “помогают” в этом другим обратной связью.
8. Ясность функций, подотчетности и полномочий. Успех определяется через соответствие ожиданиям или возможность их превзойти. Прояснение ролей, функций, подотчетности, ожидаемых результатов и “власти”, необходимой для их достижения – помогает команде работать успешно.
Максимум шкалы: Ожидания от ролей членов команды ясны и согласованы со всеми важными сторонами; зоны ответственности распределены и снабжены соответствующей автономностью и властью.
И еще раз ссылка на скачивание карточек.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.