Scrum без ошибок Голдштейн Илан

«Ах, так это Дилберт наоборот![1]» – воскликнул мой друг-психиатр, когда я вкратце рассказал ему про Scrum. (Нет, я не посещал его, чтобы справиться со стрессом от написания моей первой книги, в то время как мой первый ребенок не давал мне спать!) Я рассмеялся: мой друг так просто и изящно передал суть Scrum. Кроме того, я только что нашел эпиграф для книги!

Scrum и его agile-собратья составляют следующую эволюцию профессиональной деятельности и корпоративной культуры. Безусловно, не я один пришел к выводу, что это, возможно, величайший сдвиг со времен появления теории управления и рациональной организации труда, также известной как тейлоризм. (Кстати, знаете ли вы, что Генри Гантт[2], известный своей полосатой диаграммой, был учеником Тейлора?)

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

Это невероятно волнующе. Приятно идти в авангарде этих перемен вместе с пионерами Scrum, которые возглавляют наступление. Без сомнения, в будущем нынешнее время будет признано периодом эпохальных перемен в организации труда.

Почему я написал эту книгу?

Я вспоминаю разговор с Мартином Кернсом – другим австралийским scrum-тренером. Он обратил мое внимание на то, что нравится мне это или нет, но люди прочитают мою книгу (со множеством тактических приемов, инструментов и советов) и воспримут ее как официальное руководство пользователя – то, чему они должны неукоснительно следовать. Это лишь усилило мое беспокойство: могу ли я давать конкретные советы, которые «прорезают» теорию и переходят сразу к сути, избежав при этом директивности? Я нашел для себя ответ: рассказывая о лайфхаках в этой книге, я делюсь с вами одним из подходов, а не директивно излагаю жесткий регламент внедрения Scrum. «Разве может быть больше одного подхода к Scrum?» – можете удивиться вы.

Этот момент прекрасно объясняет Кеннет Рубин[3] в своей книге Essential Scrum[4]:

Scrum основан на небольшом наборе ценностей, принципов и практик (в совокупности это фреймворк Scrum[5]). Организации, внедряющие Scrum, должны принять его во всей полноте, однако это не означает, что во всех компаниях Scrum будет реализован одинаково. Скорее у каждой фирмы будет своя уникальная реализация фреймворка Scrum, основанная на тех подходах, которые она выберет для реализации scrum-практик… Подход – это и есть конкретная реализация scrum-практик.

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

Я написал эту книгу, потому что набил много шишек, спотыкаясь о камни преткновения и разбивая голову о кирпичные стены. Честно говоря, внедрять Scrum действительно непросто! Все кажется понятным в теории, но, черт возьми, попробуйте эффективно его внедрить и использовать. Это будет чем угодно, только не тривиальным занятием. Спустя годы и после работы с несколькими командами я наконец начал видеть отдачу. Я создал легко адаптируемую (и эмерджентную) книгу рецептов Scrum, которая работала в самых разных командах и организациях. Я понял, что мои с трудом добытые знания могут выручить других, работающих в схожих условиях.

Беседуя с Мартином, я получил полезный совет. Заметив, что я недавно впервые стал отцом, он спросил меня, считаю ли я, что должен ограждать маленькую Эми от любой ситуации, в которой она могла бы упасть и пораниться. Мое сердце говорило: «Да, именно так! Я не позволю причинить вред моей малютке». Однако мой мозг осознал, что даже тем, о ком вы заботитесь, нужно позволить споткнуться (иногда), чтобы они на собственном опыте узнали, что работает, а что нет. При этом вы всегда хотите быть рядом с ними, чтобы успокоить их и дать несколько полезных советов на будущее. Итак, эта книга просто доброе напутствие перед ваши scrum-путешествием, чтобы впредь у вас возникало поменьше порезов и ушибов. Полагаю, вы уже дали Scrum шанс и, вероятно, имеете старые раны. И если хоть немного повезет, эта книга защитит вас от следующего раунда ударов.

Если вы новичок в Scrum и ненавидите порезы и ссадины, приступайте к чтению без колебаний. Возможно, некоторые советы помогут вам избегать травм какое-то время. Однако имейте в виду: каждый проект уникален, каждая команда тоже, как и каждая компания. И если вы ожидаете успеха от каждого совета, я хотел бы скорректировать ваши ожидания прямо сейчас – до того, как вы разочаруетесь. Честно говоря, нет волшебного подхода, который бы срабатывал везде и всегда.

Я надеюсь, что те из вас, кто чувствует, что разобрался со всеми тонкостями Scrum и держит все под контролем, найдут новые интересные инструменты и добавят их в свой scrum-арсенал.

Большинство уроков этой книги я извлек, работая scrum-мастером в нескольких компаниях, поэтому основной аудиторией книги являются именно они, scrum-мастера. Тем не менее эта книга, безусловно, будет полезна и для других, включая владельцев продуктов, разработчиков и стейкхолдеров. Даже моя жена-адвокат, нисколько не интересующаяся программным обеспечением, сочла ее полезной и любопытной, – вот видите!

Скорее всего, вы не новичок в Scrum и прочитали несколько книг. Возможно, даже посетили курсы и некоторое время пытались работать по Scrum. Если это про вас, моя книга поможет вам перейти на новый уровень эффективности и зрелости в Scrum за счет расширения и развития набора scrum-инструментов.

Если вы новичок в Scrum, ничего не бойтесь! Эта книга содержит много глав (или лайфхаков), которые вы легко одолеете. Тем не менее я рекомендую вам прочитать еще несколько кратких обзоров Scrum:

• Core Scrum[6] от Scrum Alliance;

• The Scrum guide[7];

• The Scrum Primer[8].

Для более глубокого знакомства со Scrum я настоятельно рекомендую приобрести книгу Кеннета Рубина Essential Scrum[9].

Как пользоваться этой книгой

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

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

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

Мои цели

Эта книга призвана не только помочь Scrum работать на вас, благодаря ей вы сумеете поднять scrum-команды на новый уровень эффективности и зрелости. Большую часть того, что я написал, вы не найдете ни в одном scrum-руководстве (даже в вашем учебном пособии scrum-мастера). Зато я описал реальную scrum-практику, протестированную в боевых условиях.

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

Сделать первый шаг к чему-то новому всегда непросто. Вопросы «с чего начать?», «как начать?» и самый важный «почему нужно начинать?» часто служат своего рода тормозами, отрицательно влияющими на решение компании внедрить такой фреймворк, как Scrum.

Ответить на эти непростые вопросы и отважиться сделать первый шаг помогут три следующих лайфхака.

Лайфхак 1 «Scrum на поле» – это руководство, которое поможет «продать» Scrum тем, кто в вашей организации связан с его внедрением.

Лайфхак 2 «Хрупкий Agile» выделяет типичные ошибки при переходе компании на Scrum и ловушки, на которые следует обратить внимание в первые дни вашего scrum-путешествия.

Наконец, лайфхак 3 «Творческий комфорт» предлагает ряд мер для создания рабочей среды и корпоративной культуры, способствующих появлению здоровой scrum-команды.

Лайфхак 1. Scrum на поле

Scrum действительно легко «продавать», и, должен признать, получить добро на внедрение Scrum проще простого. Ну, может, это и не пара пустяков, но вряд ли кто-то станет оспаривать тезис Кена Швабера, одного из создателей этого подхода: «Scrum, похоже, преодолел пропасть и теперь скорее мейнстрим, чем оригинальная новинка»[10]. Этот прогресс, безусловно, сделал жизнь нового поколения scrum-евангелистов проще по сравнению с пионерами этого движения. По крайней мере, нам больше не приходится сталкиваться с изумлением аудитории, рассказывая о подходе к разработке программного обеспечения с помощью терминов, заимствованных из регби!

Давайте рассмотрим, что же подразумевается под Scrum. Многие (даже так называемые scrum-мастера) думают, будто это аббревиатура, но на самом деле так называется схватка вокруг мяча в регби (и там все буквы строчные).

Для тех, кто не знаком с этим спортивным приемом, поясним: ватага здоровенных мужиков из противоборствующих команд вцепляются друг в друга руками, как элементы пазла, и изо всех сил стараются отбросить соперников к их воротам (к зоне подсчета очков). Именно эта концепция сплоченной самоорганизующейся совместной работы команды и дала новое agile-наполнение спортивному термину. Впервые, в 1986 году, термин Scrum описали Хиротака Такеучи и Икуджиро Нонака, которые считаются отцами-основателями Scrum[11].

Поскольку я родился в стране, где регби очень популярно, то не раз наблюдал за такими соревнованиями. Схватка напоминает атаку древней спартанской фаланги, где каждый воин укрывался под щитом соседа (см. рис. 1.1). Ее не победить, если поддерживается дисциплина, а товарищи по команде действуют сообща.

Рис. 1.1. Если scrum-команда действует дисциплинированно, как спартанская фаланга, она непобедима

Убеждать стейкхолдеров в эффективности Scrum – мое любимое занятие! Почему? Когда я говорю о прозрачности, быстрой поставке бизнес-ценности, сокращении потерь и снижении рисков, у них загораются глаза. А после того, как я выдвигаю радикальный тезис – изменения должны рассматриваться не как препятствия, а как возможности, – по аудитории проносится вздох облегчения.

Однако следует признать, что мы, scrum-энтузиасты, не охотники за оборотнями с обоймой серебряных пуль. Реальность такова, что, хотя концепция Scrum проста и интуитивно понятна, ее успешная реализация нелегкое дело.

Так что же делает Scrum самым популярным фреймворком Agile? Ответ на этот вопрос зависит от того, к кому вы обращаетесь – к scrum-команде (включая scrum-мастера, владельца продукта и разработчиков) или главным стейкхолдерам (назовем их спонсорами проекта). В оставшейся части этого лайфхака мы сфокусируемся на критических точках, имеющих ключевое значение для двух этих групп.

Майк Кон, один из основателей некоммерческих организаций Scrum Alliance и Agile Alliance, говорит о возможностях Scrum следующее:

Scrum – это гибкий фреймворк, который позволяет сосредоточиться на поставке максимальной бизнес-ценности в кратчайшие сроки[12].

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

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

Меньше переключения контекста

Общепринятое похлопывание по плечу с очередной просьбой поработать над чем-то «более срочным» отныне исключается. Scrum предоставляет концепцию защищенного спринта (которую я люблю называть фиксированной гибкостью). Защищенный спринт позволяет разработчикам полностью сосредоточиться на том, что они обязались выполнить на встрече по планированию спринта (см. лайфхак 8), а также предоставляет владельцу продукта возможность более широко модифицировать бэклог продукта на протяжении всего проекта.

Устойчивый темп

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

Кеннет Рубин прекрасно это объясняет:

Один из основополагающих принципов Scrum гласит: «Все участники команды должны работать в устойчивом ритме!» (Больше никаких маршей смерти!) При этом они обеспечивают создание продуктов мирового уровня и поддерживают здоровую и приносящую радость атмосферу на работе[13].

Больше никакого диктата

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

Нет больше разделения на «мы» и «они»

Хотя Scrum уважает и ценит уникальность любого человека, личные рекорды отступают перед достижениями команды. Уходит в прошлое специфический мониторинг производительности сотрудников (каждого по отдельности), не говоря уже об установках на разделение «мы» и «они» на различных этапах разработки. Благодаря Scrum каждый в команде максимально концентрируется на одной цели – реализовать то, что они обязались выполнить.

Специально выделенный «щит и бульдозер»

Для сфокусированного разработчика нет ничего хуже, чем необходимость иметь дело с интригами, отвлекаться на перерывы и преодолевать препятствия. Благодаря роли лидера-слуги – scrum-мастера (см. лайфхак 4) – команда разработчиков может сосредоточиться на том, что она делает лучше всего, – разработке отличного программного обеспечения. Scrum-мастер защищает команду от разрушительных внешних воздействий и решает проблемы, которые могут препятствовать прогрессу.

Надеюсь, теперь у вас есть команда, которую вам удалось убедить в преимуществах Scrum и которая готова его использовать.

А теперь давайте раскроем ключевые преимущества, которые получают наши главные спонсоры проекта.

Снижение рисков

У традиционного проекта по разработке программного обеспечения риск составляет 100 %, а поставленная ценность – 0 %, и так будет, пока не настанет день успешного релиза. Длительные 18-месячные циклы выпуска продукта по водопадной модели[14] не могут дать осмысленной целостной картины или понимания ценности вплоть до самого релиза (см. рис. 1.2).

Рис. 1.2. Проекты, разрабатываемые по водопадной модели, сопряжены со 100-процентным риском вплоть до самого конца

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

Прозрачность, открытость и меньше неожиданностей

Прозрачность особенно актуальна для компаний, у которых спонсоры не имеют опыта разработки программного обеспечения. Для них ваша работа – черный ящик. Scrum основан на эмпирическом, наглядном управлении процессами, что делает прозрачность его основополагающим принципом. Это достигается за счет простых для понимания информационных источников (таких как доска задач – (см. лайфхак 21)), а также регулярных обзоров спринта, на которые приглашают всех желающих.

Непрерывное улучшение

Наряду с прозрачностью двумя другими столпами эмпирического управления процессом являются инспекция и адаптация. Эти важные элементы применяются как к продукту, так и к процессу его разработки, чтобы обеспечить его непрерывное улучшение по всем направлениям. «Инспекция и адаптация» – основная мантра Scrum.

Изменения – это возможности

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

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

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

Лайфхак 2. Хрупкий Agile

Пожалуй, один из самых неприятных комментариев, которые я слышу от молодых scrum-команд: «Мы используем Scrum: работаем в спринтах, проводим ежедневные стендапы, у нас даже есть бэклог продукта». Может быть, вместо этого сказать честно: «Мы не ведем никакой документации, выпускаем релизы как бог на душу положит, планируем все на лету и не задумываемся об ошибках, потому что просто исправим их в следующей итерации»?

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

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

Чтобы правильно внедрить Scrum, важно следовать четким правилам и работать в рамках практик фреймворка. Только так вы окажетесь на верном пути. Кен Швабер в своем блоге пишет: «Scrum – это как шахматы. Вы либо играете по правилам, либо не играете совсем»[15]. Расширяя эту аналогию, можно сказать, что частичная реализация Scrum похожа на игру с 20 шахматными фигурами вместо стандартных 32. Есть небольшой шанс, что игра так или иначе пойдет, но это будет не стандартная и выверенная игра в шахматы, это будет другая игра с непредсказуемыми последствиями (см. рис. 1.3).

Рис. 1.3. Так же как нельзя менять правила игры в шахматы, не следует менять и правила Scrum

Scrum не содержит лишних правил или практик. Чтобы он работал как задумано, его нужно реализовывать целостно. Частичное применение Scrum равнозначно отказу от него.

Сертификация scrum-мастеров, безусловно, полезна, но и здесь присутствует человеческий фактор, снижающий ее значимость. Много лет назад, когда я проходил первый курс обучения на scrum-мастера, в нашей группе был участник, менеджер проекта из банка, который, казалось, видел себя сержантом на курсах молодого бойца. Я тогда подумал:

даже если он несколько лет потратит на обучение, все равно ему не стать scrum-мастером, ведь качества гораздо важнее подтвержденной сертификации (см. лайфхак 4).

Те, кто склонен искажать Scrum, обычно цитируют Agile-манифест, чтобы оправдать отсутствие документации и дефицит планирования.

Манифест agile-разработки программного обеспечения

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

• люди и их взаимодействие важнее процессов и инструментов;

• работающее программное обеспечение важнее исчерпывающей документации;

• сотрудничество с заказчиком важнее согласования условий контракта;

• готовность к изменениям важнее следования плану.

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Те, кто злоупотребляет Agile-манифестом, либо (а) не прочитали последнюю строку, либо (б) забыли последнюю строку, либо (с) проигнорировали последнюю строку.

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

Рассмотрим несколько симптомов того, что Scrum искажен, деформирован и используется неверно. Не путайте их с проблемами «прорезывания зубов», с которыми сталкиваются начинающие (но настоящие) scrum-команды. Например, ежедневный Scrum, который не всегда начинается вовремя, – это неидеально, но при правильной мотивации эту проблему можно решить, и регулярное смещение графика не всегда сигнализирует о том, что команда не принимает эту практику.

Спринты тестирования

Обеспечение качества – неотъемлемая часть процесса разработки. Требование не может считаться выполненным, если оно не удовлетворяет критериям готовности (см. лайфхак 11). Однако иногда это правило нарушается. Обычно это происходит на этапе «функциональных» спринтов, фокусирующихся исключительно на разработке нового кода (чтобы создать впечатление прогресса), дополняемых связкой «догоняющих» спринтов для выявления и исправления багов.

Типичное оправдание такого поведения – команда хочет в первую очередь показать общие функциональные возможности ПО пользователям (чтобы проверить свою работу). В такой ситуации я обычно говорю команде: «Если вы работаете в спринтах, это еще не значит, что вы ушли от водопадной модели». Помните: до тех пор пока функциональность продукта не будет полностью протестирована и готова к релизу, она не является завершенной (должна считаться невыполненной, то есть бесполезной, и очень рискованной).

Другое проявление этого антипаттерна – программисты и тестировщики работают в разных спринтах. Например, тестировщики отстают на один спринт от программистов[16]. Такое становится возможным, если практика автоматизированного тестирования все еще недостаточно зрелая и зависимость от ручного регрессионного тестирования велика. Этот ступенчатый сценарий спринта неизбежно приводит к таким же «догоняющим» спринтам, которые обсуждались выше.

Бесконечные нулевые спринты

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

Эта предварительная работа, как правило, не подразумевает временных рамок и не обладает всеми типичными структурными элементами, которые есть в реальном спринте (бэклог спринта и четко сформулированные требования).

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

Рис. 1.4. Минимальный список задач для нулевого спринта

Элементы в списке «Не включать» на рис. 1.4 могут показаться туманными, в отличие от конкретных функциональных требований, но это не значит, что их нельзя оценить, спланировать и разбить на задачи и, следовательно, включить в спринт. Ввиду неопределенного характера этой подготовительной работы необходимо окружить ее надлежащими техниками спринта, чтобы обеспечить большую прозрачность и более жесткий контроль.

Изменяющаяся продолжительность спринта

Постоянная продолжительность спринта важна по ряду причин, описанных в лайфхаке 8.

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

Полагаю, есть только две причины для изменения длины спринта:

1. Когда новая команда экспериментирует на начальном этапе работы.

2. Когда все работы завершаются ранее последнего дня финального спринта (см. рис. 1.5).

Рис. 1.5. После определения продолжительности спринта поддерживайте ее неизменной

Изолированная оценка

Подобная ситуация характерна для всех процессов вне Scrum, с которыми я сталкивался. Она возникает, когда ведущий разработчик пытается единолично оценить продолжительность всех работ. Вы можете спросить: а в чем проблема? Разве опытный сотрудник с наивысшей квалификацией не способен дать точную оценку? Тем не менее это действительно одна из проблем. Хотя ведущий разработчик может быть самым опытным, в большинстве случаев сам он не станет выполнять работу. По своим способностям он, несомненно, отличается от участников команды, которым и предстоит выполнить стоящие перед ними задачи. Следовательно, и его оценка будет отличаться от реального положения дел. Работу выполняет не один человек, а вся команда, поэтому она (как коллектив) и должна давать оценку (см. лайфхак 14). Когда это делает один человек, никакой системы сдержек и противовесов для него не существует. А если у него был выходной, он не услышал некоторые важные данные и сделал неправильные выводы? Когда в оценке задействованы все участники команды, такие промахи гораздо менее вероятны благодаря нескольким слоям и фильтрам при обработке информации.