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

В основе плана внедрения лежит ментальная модель Flying Jet Fixing. Обычно, если руководство хочет внедрить изменения, то оно предпочитает отрывать людей от их задач и проводить тренинги, на которых рассматриваются оторванные от реальных задач упражнения. Такой подход плох по двум причинам: 1) на тренинге люди отвлекаются, потому что рабочие задачи все равно важнее; 2) людям самим надо понять, как связано то, чему их обучили с их реальной работой. Как правило, после тренинга они этого не делают и все предоставленные им фреймворки быстро забываются.

Поэтому изменение подходов к работе мы рекомендуем делать во время самой работы и на материале самой работы: ремонтировать летящий самолет.

Предложенный план состоит из 8 спринтов, каждый из которых заканчивается командной встречей. После реализации плана такие встречи начинают проходить регулярно и по определенным правилам, чем обеспечат Continuous Improvements, Focus, Transparency, Value Delivery и – самое важное достижение Phase I – Demanding Environment.

Еще раз уточним, что этот план не является прескрептивным. Если вы можете и хотите выполнить все, что здесь написано именно так, как здесь написано – вы это можете сделать. Но, скорее всего, понадобится некоторая адаптация. Какие-то шаги окажутся вырожденными – к примеру, у вас уже есть ось эпиков и создавать ее повторно нет нужды.

Вы стартуете с командой, состоящей из одного человека – вас самих. При этом, формально, у вас могут быть сотрудники и, формально, они могут быть в команде.

'M Team Leader: в любой команде должен быть лидер – человек, который заинтересован в том, чтобы проект успешно закрыть и который готов делать намного больше, чем самый минимум.

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

В "зеленых" культурах принято исходить из того, что лидер либо не нужен вообще (как в Scrum), либо лидер должен помогать команде, обеспечивая их снеками и газировкой. Если вы смогли построить такую команду, для работы которой вы можете только не мешать, – примите наши поздравления.

'M Team Leader: в любой команде должен быть лидер – человек, который заинтересован в том, чтобы проект успешно закрыть и который готов делать намного больше, чем самый минимум.

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

В "зеленых" культурах принято исходить из того, что лидер либо не нужен вообще (как в Scrum), либо лидер должен помогать команде, обеспечивая их снеками и газировкой. Если вы смогли построить такую команду, для работы которой вы можете только не мешать, – примите наши поздравления.

'M Distributed Leadership: люди могут быть лидерами в тех областях, в которых они лучше всего разбираются. Это хорошая модель, но для того, чтобы люди также начали вести себя по-лидерски, необходимо два условия: они должны этого хотеть и они должны это уметь делать.

'M Psychological Contract: в реальности же, для того чтобы человек оказался в команде, с ним необходимо заключить Психологический Контракт: человек соглашается делать больше, чем подразумевает его роль, а в обмен он получает право принимать решения, касающиеся работы команды и продукта.

Если люди на такое не согласны – не берите их в команду. Используйте их компетенции по C&C. Поэтому до того, как команда начала работать, пообщайтесь со всеми потенциальными кандидатами в команду и пригласите тех, кто готов вкладываться в проект.

'M Deliverables: что будет в результате? Модель состоит в том, что в результате любой активности остается что-то: написанный код, договоренность как действовать, понимание новой предметной области.

На первой встрече не делайте ничего для обеспечения психологической безопасности и не разрабатывайте никаких правил общения. Просто уважительно пообщайтесь. И начните с того, что людям интереснее всего: чем они сейчас занимаются.

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

На самой встрече сформулируйте эпики, которые получаются исходя из того, что люди делают прямо сейчас.

Что такое Эпик?
Эпик – это маленький проект. Это, в частности, значит, что эпик должен быть завершаемым. Если у команды есть продолжающаяся активность, то это процесс, а не эпик.

Эпик строится по форме 'We want X to Y', то есть указывается не только то, чего хочет достичь команда, но и зачем это необходимо.

Удобнее работать с эпиками, у которых есть внятные выделенные жирным заглавия.

Что Делать?

1. На встрече просто пообщайтесь о тех крупных задачах, которые есть в команде.
2. Записывайте названия этих задач на доску. В какой-то момент вы заметите, что люди начинают повторяться и говорить о том, о чем уже шла речь. Это хорошо. Просто просите команду дать комментарии: это одно и то же или все-таки речь идет о разных задачах.
3. В ходе такого обсуждения начнут вырисовываться важные задачи – именно с них и начинайте формулировку эпиков.
4. Держите в голове, что весь объем работ можно разделить на эпики многими способами и что все равно останутся какие-то задачи, не имеющие отношения к конкретным эпикам.
5. Расскажите команде, что такое эпик и как он строится. Начиная с этого момента такие большие задачи начинайте называть эпиками.
6. Сформулируйте первый эпик совместно с командой.

Если вам удастся сформулировать все эпики за эту встречу – хорошо; если это не получится – еще лучше. Договоритесь с командой, как вы закончите эту работу за следующий спринт. Будет ли это отдельная встреча или каждый напишет свои эпики отдельно? В любом случае, это будет первое командное решение, поэтому не выполненная до конца работа лучше выполненной.

Deliverables:

• Максимально: Ось Эпиков; минимально: один хорошо прописанный Эпик.
• Возможно: договоренность о том, как завершить создание оси эпиков.

Если у вас еще нет Оси Эпиков, то эту встречу стоит посвятить именно ей. Так как люди уже понимают, что такое Эпик, и обсудили значительную часть работы, то одной встречи должно хватить для того, чтобы завершить Ось Эпиков. Если у вас останется время, лучше завершите встречу и не обсуждайте новых тем.

Если у вас уже есть Ось Эпиков, то вторая встреча будет посвящена ответственности.

В Agile ответственности нет. Как говорит Владимир Тарасов: "Двух солдат отправляют за хворостом, одного назначают ответственным". Класcический PM говорит, что ответственного необходимо назначить для выполнения даже маленькой задачи и внести его в матрицу ответственности. Agile не использует слово "ответственность" нигде, кроме как в "вся команда ответственна за все". Что эквивалентно тому, что никто ни за что не отвечает.

Отказ от ответственности мы считаем ошибкой в Agile, несбалансированным "зеленым" решением. В свой работе мы помещаем ответственность в Эпик. Epic Owner – это человек, ответственный за закрытие эпика. Раздавать и фиксировать ответственность за истории слишком мелко, делать людей ответственными за выполнение целей слишком крупно: цели для команды. Эпик – это, с нашей позиции, лучший элемент, за который люди могут нести ответственность.

Структура Задачи. В TDF мы будем несколько раз апеллировать к классическому определению структуры задачи, на нем же будет построен Responsibility Grades Framework.

Спросите у своей команды: "Чайник стоит 1000 рублей. Его цену подняли на 10%, потом снизили на 10%. Сколько теперь стоит чайник?" Если вы уже поняли основные правила работы с командой, то можете догадаться о том, что условия необходимо записать на доску.

Единственный правильный ответ – это 990 рублей. Но вместо него люди могут давать такие ответы: "на 1% меньше", "на 10 рублей меньше" или, самое ужасное: "не знаю". Ответ "990 рублей" показывает, что перед вами человек, который заботится об удобстве своих коллег и приносит готовый, а не промежуточный результат.

Структура Задачи:

• R – Resources. Ресурсы – это то, что у команды есть. В задаче ресурсы – это три утверждения: 1) "чайник стоит 1000 рублей", 2) "цену чайника сначала снизили на 10%", 3) "потом цену чайника повысили на 10%".
• P – Purpose. Цель – это то, чего необходимо добиться. В данном случае ответить, сколько теперь стоит чайник. Возможно, это необходимо для того, чтобы сотрудник магазине мог поменять ценник.
• T – Tools. Инструменты, которые помогают человеку перевести R в P. Здесь это умение работать с процентами и арифметика.

Responsibility Grades:

Specialist. Это человек, которому можно дать ресурсы, объяснить что нужно сделать и как это сделать, а человек сделает все аккуратно и, если столкнется с трудностями, вернется к вам и спросит. Такие люди очень ценны. Большинство людей находятся ниже этого уровня.

Были ли у вас такие ситуации, что вы в понедельник дали человеку все ресурсы, объяснили что нужно сделать, показали примеры, дали инструкции, призвали писать вам, если что-то будет неясно, рассказали, что дедлайн в пятницу в 16.00. А в пятницу в 16.00 вам приносят работу, которая выглядит так, будто ее в последние 15 минут сделали на коленке? А вам потом нужно это все переделывать в субботу дома?

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

Если у вас в команде есть человек на уровне Specialist, то приглашать его в ядро команды стоит только в том случае, если человек активен и амбициозен. В противном случае стоит управлять им через C&C.We are a leading firm in providing quality and value to our customers. Each member of our team has at least 5 years of legal experience. We love what we do.

Teammate
Это человек, который, получив ресурсы и цель, сможет сам понять, как добиться цели: ему не нужна инструкция и микроменеджмент. При должном стремлении, такой человек может развиться и стать Epic Owner.

Epic Owner
Это человек, который несет ответственность за эпик, который сам же и сформулировал. Epic Owner – это специалист, который при знании цели проекта может сам сформулировать маленький проект, необходимый для закрытия основного проекта. Epic Owner получает ресурсы, ставит сам цель и определяет путь ее достижения.

Team Lead
Человек, который несет ультимативную ответственность за успех проекта, в том числе и за привлечение необходимых ресурсов для его закрытия. Это вы. Если в вашей команде есть другие люди, находящиеся на таком уровне ответственности, то вам повезло. Цените их.


Что Делать?

1. Проведите эксперимент с ценой чайника.
2. Презентуйте коллегам фреймворк.
3. Задайте ожидания: Epic Owner – это человек, который находится на уровне Epic Owner. Они даже специально называются одинаково.
4. Этот фреймворк команде именно дается, его не стоит обсуждать за исключением тех случаев, когда команда видит его очевидную неприменимость к вашему случаю. В таком случае обсуждайте и меняйте, но всегда держите в фокусе, что это фреймворк об ответственности, а не о должности или профессионализме.

Мы в Kite работали в основном с управленческими командами, в которые входили лидеры соответствующих команд. Такие люди находились минимум на уровне Epic Owner, что приводило к тому, что все эпики в команде покрывались кем-то из участников.

Противоположный случай – это команда стажеров. В этом случае вы несете ответственность за все эпики.

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

Если и можно дать рекомендацию по распределению ответственности, то она такая: дайте людям возможность взять на себя ответственность и, если они не будут способны ее нести, забирайте ее. Фреймворк о том, как забирать ответственность и не потерять участника команды, будет презентован на Phase II.

Deliverables: У каждого Эпика есть ответственный.

Планировать люди не любят, Agile-мемы про непредсказуемость мира люди склонны воспринимать как разрешение не думать наперед и делать то, что делается. Поэтому на этой встрече нужно взять один и только один эпик и разбить его на Истории длиной в спринт. Когда будут обнаруживаться dependencies, их стоит прописывать и помещать в соответствующий Эпик, но всегда держать в фокусе тот Эпик, который вы планируете.

История строится по той же формуле, что и Эпик: "We want X to Y", но, в зависимости от типа истории, у нее может быть различная первая часть. Будете ли вы использовать User Stories, Job Stories, какие-то другие типы историй или вообще будете разбивать Эпики на задачи – решать вам вместе с командой.

Эпик стоит планировать top-down. Часто люди стремятся планировать bottom-up: берут историю, которую им необходимо закрыть, и думают, к какому эпику она имеет отношение. Top-down подход состоит в том, чтобы взять эпик и понять, из каких историй он состоит, – то есть что нужно сделать для того, чтобы Эпик закрыть.

После того, как вы распланируете один Эпик, вы сможете обсудить, как оценивать Истории. Оценка Историй – это хорошо прописанная тема. Мы лишь скажем, что оценивать Историю должны те люди, которые будут вовлечены в ее закрытие.

Оценка Истории – это функция от времени и энергии. Чем дольше выполнять историю, тем она сложнее; чем более изматывающей является история, тем она сложнее. Для того, чтобы лучше понять энергию, представьте, что вам нужно 4 часа заниматься любимым делом или 4 часа сдавать экзамен. В первом случае вы скорее всего не почувствуете усталости, в то время как во втором будете выжаты и ничего продуктивного в этот день уже сделать не сможете.

Для того, чтобы спланировать остальные Истории, обычно проводят специальную встречу: Story Writing Workshop. В любом случае, в конце встречи стоит принять решение, как команда завершит планирование.

Важно отметить, что под планированием понимается не порядок выполнения Историй, а только нарезка Эпиков на Истории.

Вы обнаружите, что какие-то Истории необходимо выполнить, но ни к каким Эпикам они не имеют отношения. Так и должно быть. Создайте для них столбик Miscellaneous. Индикатором неверного планирования будет наличие в этом столбике большого числа Историй, или если каждый Спринт команда будет брать в работу Истории в основном из этого столбика. Это будет значить, что команда не работает над закрытием проекта, а застряла в операционной деятельности.

Брать на следующий Спринт что-то из этого в работу или нет – решите вместе с командой.

Deliverables:

• Распланированный Эпик;
• Договоренность о способе оценки Историй;
• Договоренность о том, как вы будете планировать оставшиеся Эпики;
• Решение о том брать ли какие-то из Историй в работу.

Изначально Ретроспектива была редким событием – в конце проекта [NC]. Считалось, что люди вынесут из закрытого проекта уроки и в следующем проекте уже будут более опытными. Тем не менее, идея о том, что Ретроспективы стоит проводить чаще и в ходе проекта тоже была [JH]. Scrum популяризовал Ретроспективу каждый спринт – и мы полагаем, что это слишком часто.

Ретроспектива нужна по двум причинам: вынести уроки из прошлых успехов и неудач и закрыть гештальт, то есть отвязаться от негативных переживаний связанных с другими людьми. Выносить быстрые уроки можно и каждый спринт, но для того, чтобы вынести глубокие, фундаментальные уроки и действительно закрыть прошлые обиды необходимо погружение. Поэтому эти две активности мы разделяем.

Kite практикует проводить глубокую Ретроспективу раз в пол года: в январе, после того как люди отдохнут, и в августе – также после того как люди отдохнут.

Быстрая Ретроспектива, которую можно проводить и сразу же после события и на командной встрече называется After Action Review (AAR). У AAR есть преимущества:

• Ретроспективу люди не любят. Первое, на чем начинают экономить время, – это на Ретроспективе. Выполнение работы, анализ метрик, планирование – все эти активности воспринимаются людьми, как имеющие отношение к работе, в то время как Ретроспектива – это что-то нерабочее. Поэтому глубокую Ретроспективу стоит проводить, когда у людей еще нет рабочей суеты – после отдыха. AAR проводится более технично, поэтому воспринимается как более рабочая активность.
• Название. После того, как проведение Ретроспектив стало популярным, за этим названием люди начали понимать совершенно разные вещи. Использование AAR позволяет сделать активность по извлечению уроков более ясной.
• Эмоции. Одни люди на Ретроспективе могут расплакаться, другие выйти, хлопнув дверью [ED]. Так действительно может быть при глубоком погружении, когда Ретроспективе уделяется как минимум целый день. Но когда у вас есть один час, то даже опытному фасилитатору не удастся поработать с глубокими эмоциями. Более того, мы можем утверждать, что многие люди не любят Ретроспективу именно потому, что им предлагается раскрыться эмоционально. Одни люди не хотят этого делать – и вы не их психотерапевт, чтобы настаивать на этом; другие люди используют эмоции для того, чтобы привлечь внимание – и остальные могут не хотеть терпеть этого. Поэтому если эмоциональная сотрудница расплачется, то нордический сотрудник вполне может хлопнуть дверью.

В итоге, мы рекомендуем проводить глубокую Ретроспективу раз в полгода или чаще если для этого есть достаточно важное событие на целый день; для оперативной работы мы рекомендуем использовать AAR.

К этому моменту у вас должно быть достаточно много потенциальных проблем, если нет – отложите AAR и проведите его после Key Results, но до Интеграции.

Проведение AAR, которую использует Kite, состоит из трех шагов: 1) обсудите правила, 2) обсудите проблему, 3) разработайте решение. Если вы хотите выработать свой подход, то можно ознакомиться с источниками [AR].

На AAR мы не оцениваем настроение людей по 10-балльной шкале, не используем игры и не меняем схему проведения.

В самом начале встречи проведите Check-In – краткий рассказ человека о прошедшем спринте. Такой краткий рассказ, несмотря на то, что там присутствуют личные вещи, в действительности настраивает на работу. Следуйте правилам:

• Можно говорить только о себе.
• Нельзя перебивать человека, но после того, как человек закончил, можно задать уточняющий вопрос или высказать свою поддержку.
• Не давайте советов.
• Нельзя начинать дискуссии. Только уточняющие вопросы и поддержка.

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

Все должны обязательно высказаться. Если у человека случилось в жизни что-то очень плохое – настолько плохое, что он не может участвовать в рабочем процессе, – то такому человеку стоит взять паузу и не приходить ни на рабочие встречи, ни на работу.

После Check-In обсудите Правила AAR. Самое важное правило – это Prime Directive Норма Керта: "Вне зависимости от того, что мы обнаружим, мы будем полагаться на то, что каждый человек сделал лучшее что мог в той ситуации, с теми ресурсами, с теми знаниями…"

Мы бы сказали так: если вы поймете Prime Directive, то больше никаких правил и не нужно. Но это правило стоит не навязать, а обсудить.

• Напишите текст правила на доске: крупно и читаемо.

• Попросите высказаться людей о том, что они по этому поводу думают. Не заставляйте людей говорить, если они не хотят. Ключевые моменты записывайте на доску: позитивные зеленым, негативные красным, нейтральные синим. Спустя некоторое время у людей возникнет общее понимание: с какими-то моментами люди будут все больше и больше соглашаться, какие-то останутся без внимания.

• Самые главные тейки из Prime Directive: мы не обвиняем людей в том, что они сделали; если бы у нас был тот опыт, который есть сейчас, то мы сделали бы по-другому, но тогда у нас этого опыта не было; с теми ресурсами можно было бы сделать больше, чем мы сделали, но мы не знали как; вообще, в стрессовой ситуации трудно создавать идеальные решения. Если люди существенно упускают один из главных тейков: расскажите ваше мнение с тейком и спросите, что команда об этом думает.

• Лидер высказывается последним. Если у вас адекватная команда, то говорить вам будет не сложно: все уже сказали за вас.

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

• Поблагодарите команду.

[?] Что делать, если люди уверены, что Prime Directive – это чушь и что люди должны были сделать лучше? В таком случае у команды нет основополагающей ментальной модели ни для AAR, ни для Ретроспектив. В таком случае лидеру не стоит проводить AAR и сфокусировать на другом: а почему люди в команде так настроены? С этим вопросом стоит обратиться к профессиональному специалисту.

Обсудите Проблему. Лучше всего, если у вас есть заглавие и столбики. В заглавии должна быть записана проблема – тут важно, что именно она записана. Проблема не должна иметь в себе решения. Столбики помогают провести анализ. Вы можете выбрать из приведенных столбиков или добавить свои.

• Почему это проблема. "Пользователи нашей системы не могли пользоваться ей три часа в прошлую пятницу потому что мы вынуждены были отключить ее из-за проблем с интеграцией". Да, но почему это проблема? Давайте людям проговаривать банальные ответы – и записывайте их: "Пользователи были возмущены", "Некоторые клиенты ушли от нас", "Наша репутация ухудшилась", "Мы потеряли деньги", "Наши конкуренты обсмеяли нас в Твиттере – и нам неприятно".
• Следующие две колонки обсуждаются вместе: что получилось хорошо и что получилось плохо. Когда обсуждаете хорошую сторону, записывайте даже самые банальные ответы. Когда обсуждаете плохую сторону, напомните команде про Prime Directive. В идеале при обсуждении плохой стороны люди будут говорить только про себя. Но если идеально не получается, то попросите людей говорить про ситуацию, а не про участников. "Мне не удалось вовремя получить дамп", вместо "Итан обещал предоставить мне дамп заранее, но принес в последний момент". Если обвинять людей, они будут защищаться и, в свою очередь, обвинять других.
• Кого поблагодарить. Поблагодарить коллег помогает закрыть гештальт и не ввязываться в эту ситуацию эмоционально. Всего лишь помогает, но не работает абсолютно. Выслушайте благодарность первого человека, передайте ему маркер и попросите записать на доске кого он благодарит; заберите маркер у человека и дайте его следующему человеку, который хочет высказаться до того, как он начал что-то говорить. Позвольте человеку самому решить: сначала высказаться, а потом записать на доске или наоборот.

Что Мы Будем Делать Иначе? Если после AAR получаются action items – сформулируйте их и поместите в backlog. Если по результатам AAR можно сформулировать правило – сформулируйте его и поместите в список правил и, в дальнейшем, отслеживайте его исполнение.

Правила AAR для Тимлида от Kite:Project:

1. Не поощряйте "зеленую культуру": если кто-то хочет поплакать или покричать, то он или она могут сделать это в уединенном месте. Не стоит отрицать чувства других людей, и хорошо проплакаться – это уже само по себе хорошая психотерапия: слезы выводят кортизол. Но не стоит это делать за счет других людей.
2. Худшее, что может произойти как на AAR, так и на Ретроспективе – это не ругань и взаимные обвинения. Худшее, что может произойти – это молчание или уверение, что все хорошо. Поэтому если люди ведут себя деструктивно – это уже хорошо: с деструктивным поведением можно работать.
3. Вы можете попросить людей высказаться, если считаете, что человеку есть что сказать. Так бывает, что человек именно ждет, пока его спросят. Но не стоит заставлять человека говорить, если он или она не знают, что добавить. Именно такое давление и приводит к нежеланию проводить Ретроспективы и AAR.

Deliverables: Зафиксированные Action Items или Командные Правила.

Большую часть того, что нужно знать про Цели, сказали Эдвин Локк и Джон Дорр [OB]. Перед тем как начать создание целей, обсудите с командой критерии, по которым вы будете эти цели ставить. Как правило, люди знают про SMART-цели – и для 70% случаев этого будет достаточно. Мы опишем эти и некоторые другие критерии, которые вы можете использовать за исключением измеримости: этому будет посвящена следующая встреча.

Specific
Как понять, что ваши цели написаны ясно? После того, как цель написана, дайте каждому сотруднику стикер и три минуты на то, чтобы описать на стикере то, как он или она поняли цель. Ясной цель будет тогда, когда каждый выйдет к доске, прочитает свое описание – и не последует возражений или значимых корректировок. Если вам не удается сделать цель ясной и компактной одновременно, сделайте более подробное описание в отдельном общедоступном документе.

Committed or Aspirational
Это термины из OKR: каждая цель должна быть либо Committed – люди понимают как закрыть ее на 100% и будут фокусироваться именно на том, чтобы закрыть ее на 100%. Aspirational цели рискованны, но интересны и ведут к развитию компании. Они могут быть не закрыты полностью.

Relevant
Цель должна отвечать на вопрос: а какую ценность мы хотим получить? Ответ на этот вопрос поможет приоритизировать цели и выбрать только самые высокоприоритетные. Не ограничивайтесь ответом "Да, это важная цель", а именно прописывайте ценность, которая достигается.

Time-Bound
В нашей идеальной вселенной люди работают циклами по полгода, каждый такой цикл начинается с Ретроспективы за полгода и Стратегической Сессии, а заканчивается отдыхом: новогодним и летним. Поэтому базовые цели мы ставим на полгода. Можно ставить более высокоуровневые цели: на год, на два года или до дедлайна.

Written Down
Цели не поставлены, пока они не записаны и не сохранены в том месте, в котором каждый участник команды имеет к ним доступ в любое рабочее время.

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

• Компромисс. На компромиссы идти надо, сколько бы Томас и Килманн нас не убеждали в обратном. Идеальное решение, которое устраивает всех может попросту не существовать или его поиск может занять слишком много времени.
• Адекватность. "Это чушь, я никогда не соглашусь с такой целью", – реальная фраза, которая была сказана на стратегической сессии одним из участников. Для того, чтобы такие фразы не звучали или их можно было попросту отметать, существует фреймворк, созданный внутри Социократии: Qualification as Objections [SA]. Не каждое возражение квалифицируется как возражение, а для того, чтобы возражение было валидным, оно должно удовлетворять определенным критериям. Выработайте критерии сразу после выбора критериев для целей.

Количество Целей. Есть общее правило: человек может держать в фокусе внимания от 5 до 9 объектов.

• Если у вас получается больше 9 целей, то это значит, что вы пытаетесь сфокусироваться слишком на многом – и в результате не будете сфокусированы ни на чем.
  
• Если у вас получается 8 или 9 целей, то вы можете попробовать их реализовать, но морально подготовьтесь к тому, что через полгода на Ретроспективе вы будете обсуждать проблему расфокуса.
  
• 7 целей – это тот предел, на котором может сфокусироваться эффективная команда.
  
• 5 целей – это хороший показатель, с которым можно эффективно работать.
  
• Если у команды меньше пяти целей, то это может быть либо маркером того, что команда действительно крайне сфокусирована на самой важной цели или двух, либо что люди сами не знают, что им делать. Вы почувствуете разницу.
  

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

Метрики – это основной инструмент Demanding Environment. Метрики объективно показывают, где мы хотели быть и где мы находимся сейчас.

На этой встрече обсудите Ментальную Модель Не все Измеримое Ценно, не все Ценное Измеримо.

Не все Ценное Измеримо. Вопреки убеждению, что каждая цель должна быть измерима, мы все же не можем с этим согласится. Команда работает над макетом. Цель: выиграть в конкурсе и продать проект заказчику. Тут команда либо продала, либо нет.

Даже если продать можно не по фиксированной цене и команда имеет цель по сумме контракта, то это все равно неизмеримо: в ходе всей подготовки у команды нет данных о том, насколько она приближается к своей цели: измерять можно только косвенные показатели.

Не все Измеримое Ценно. Закон Гудхарта говорит, что метрика сама становится целью, если человека наказывают за то, что метрика не совпадает с целевым показателем. Люди начинают мыслить локально: мы сейчас продадим и получим премию, а то, что это не смогут доставить вовремя и клиент будет недоволен, – это не наша проблема.

Поэтому KPI работают при централизованном иерархическом управлении, когда от сотрудников ожидается, что они будут заниматься только своим делом, а управлением займется менеджмент. Впрочем, KPI при централизованном иерархическом управлении работает плохо: поэтому в корпорациях пытаются повесить ответственность за всю систему на самих сотрудников.

Команда должна отвечать за всю систему – пусть и небольшую. Если команда сама влияет на систему, тогда метрики показывают, что у команды получается и что не получается, и могут служить источником для внедрения улучшений. Но для этого люди должны хотеть успеха всей системы, а не отдельных ее частей. Что будет невозможно, если их будут награждать за достижение целевых показателей.

Хорошим примером таких метрик являются воронки: когда команда измеряет не один показатель, а их совокупность и когда видно, как повышение кликов на кнопку в результате конвертируется в годовые подписки.

Инициативность. На проблему можно отреагировать инициативно: попробовать решить ее самому или с помощью команды, или неинициативно: сделать вид, что проблемы нет или попробовать переместить ее на другого человека. Если вы замечаете в вашей команде не инициативных людей, то помните про теорию Bad Apples: одно гнилое яблоко портит всю бочку [BA].

Sprint Quality. Команда сама разрабатывает метрики к своим целям. Но одну метрику мы предлагаем использовать всегда – это Sprint Quality.

• Каждый Action Item, над которым команда работала на Спринте, должен быть оценен.
• Action Item имеет статус Done, если команда согласна, что ценность была доставлена, иначе это Not Done.
• Action Item имеет статус Drop, если его выполнение потеряло актуальность.
• Action Item имеет статус Add, если команда его не планировала, но была вынуждены сделать, потому что этот Action Item оказался блокирующими или срочными. Если в вашей команде работает правило, что каждая задача, квалифицируемая как Add, приводит к прерыванию спринта, то у вас этой колонки не будет.
• Action Item имеет статус Extra, если команда не планировала его делать, но у нее было свободное время.

Sprint Quality = (Done + Add + Extra) / (Done + Not Done + Add + Extra) * 100%

На что обращать внимание:

• Хороший спринт закрывается на 90% или более. Если команда регулярно закрывает спринт менее чем на 90% – это индикатор проблем.
• Если команда регулярно не закрывает спринт хотя бы на 70% – это индикатор больших проблем.
• Если спринт закрыт не на 100%, но у команды есть Extra – это индикатор того, что команда делала то, что интересно, а не то, что было нужно.
• Если у команды регулярно случается Drop – это индикатор проблем.
• Наличие Add может и не быть индикатором проблем при условии, что он не большой.

Поработайте с этими проблемами на AAR.

Deliverables:

• Команда начала измерять Sprint Quality;
• Команда разработала метрики к своим целям;
• В работу взята история разработать среду для ведения этих метрик так, чтобы на следующей встрече команда могла уже зафиксировать первое измерение.

Последнюю встречу посвятите тому, чтобы убедиться, что все элементы TDF согласованы. К этому моменту у вас должно быть:

• Привычка встречаться регулярно в конце каждого спринта для того, чтобы посмотреть на результаты прошедшего спринта, сделать выводы и распланировать новый спринт.
• Управляющие переменные, показывающие куда идет команда: цели, метрики и эпики.
• Work Breakdown Structure: распланированные эпики, нарезанные на спринты.