«Ты видел их оценки для этой работы?» — спрашивает меня один из коллег.

Это риторический вопрос. Я видел оценки, и коллега это знает. Он упоминает об этом, потому что оценки, предоставленные командой, явно... завышены.

Я пытаюсь быть дипломатичным. «Похоже, что эти оценки были намеренно увеличены из-за страха перед неизвестным», — объясняю я, но знаю, что это не особо поможет. Мое объяснение того, ПОЧЕМУ команда хочет так много времени для выполнения такой небольшой работы, не делает их оценку меньше, и я это понимаю.

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

Для начала: Что такое оценка?

В гибкой разработке ПО командам показывают объем работы, разбитый на пользовательские истории или другие варианты декомпозиции — то есть, работу, которую нужно выполнить для удовлетворения какого-то нового требования пользователя. Каждый блок представляет собой часть работы, которую специалисты должны сделать для модификации существующей функции или создания новой.

Данный вид оценок применим и для проектов по водопадной модели, но с нюансами.

Обычно это выглядит так:

1. Кто-то (обычно владелец продукта или продакт-менеджер или просто менеджер) представляет команде пользовательскую функцию, которую нужно разработать.
2. Команда и менеджер добавляют и корректируют пользовательские истории в бэклоге работ так, чтобы все необходимые задачи были представлены. Некоторые из них явно являются задачами разработки (написать тот или иной код), в то время как другие могут быть для кого-то смежного с командой (написать пользовательскую документацию, протестировать код разработчика и так далее).
3. Менеджер просит команду «оценить», сколько времени, по их мнению, займет выполнение работы и, следовательно, общее время, необходимое для вывода новой функции на рынок. Оценки могут быть в разных единицах измерения: от часов до «сторипойнтов» (это выдуманные числа в скраме, которые никто не понимает, но все притворяются, что понимают).
4. Теперь команда должна дать оценки того, сколько времени займет каждая задача, двигаясь сверху вниз, пока у нас не будет оценки для всей необходимой работы.

Почему это не работает

Как бы просто это ни звучало и каким бы разумным ни казалось, часто мы обнаруживаем, что оценки, даваемые командой, либо сильно завышены, либо, что еще хуже, неправдоподобно малы. Давайте рассмотрим некоторые причины, почему это происходит, и как мы можем сделать лучше.

Причина №1: Страх

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

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

И наоборот, если кого-то просят оценить что-то, о чем он ничего или мало знает, первое, что он сделает, — это подстрахуется. Оценка будет больше, чем фактический объем работы, который может потребоваться, просто потому, что человек, которого спрашивают, не уверен, что потребуется для выполнения работы. Когда речь идет о сложных системах, таких как программное обеспечение, этот человек определенно будет перестраховываться из-за страха, что когда он начнет разбираться в системе, чтобы понять, что нужно добавить или изменить, это потребует гораздо больше усилий, чем ожидалось.

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

Как мы можем это исправить?

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

Причина №2: Нечеткие требования

Бизнес или продакт-менеджер должны заполнить пользовательские истории тем, какую работу необходимо выполнить, чтобы считать эту историю завершенной.

Эти истории часто имеют плохо определенные или наполовину завершенные требования. «Добавьте кнопку, которая сохраняет данные в формате PDF». Хм, какие данные? Как должен выглядеть PDF? Должен ли пользователь иметь возможность скачать этот PDF? Нужно ли нам сохранять копию PDF? Вопросы продолжаются и продолжаются, и все они связаны с плохими требованиями.

Это очевидно. Действительно трудно оценить, сколько времени что-то займет, если мы точно не знаем, что нам нужно сделать, чтобы это было завершено.

Как мы можем это исправить?

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

Причина №3: Конформизм

Когда работаешь в команде, в ней могут быть оптимисты и пессимисты (они называют себя «реалистами»). Мой опыт показывает, что когда группу людей просят прийти к коллективному ответу, в целом эта группа будет склоняться к наиболее пессимистичному ответу.

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

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

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

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

В-третьих, позвольте людям спорить. Вообще-то, нет. ЗАСТАВЬТЕ людей спорить. Большинство программистов в командах обычно сидят тихо на таких сессиях, так что один или два человека в итоге доминируют в разговоре и оценках. Это нехорошо. Подталкивайте других членов команды к тому, чтобы они высказывались, аргументировали свои причины для более высокой или низкой оценки.

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

Причина №4: Мы все сделаем вчера! Или нет?

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

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

Как мы можем это исправить?

Нужно чтобы вся команда высказывалась, указывая, где оценки одного человека могут быть СЛИШКОМ амбициозными. Речь идет о том, чтобы отдельные члены команды высказывали свое мнение, объясняя вещи, которые один человек мог не учесть, поддерживая более стабильный баланс в оценке, обеспечивая учет всех точек зрения и возможностей.

Заключение

Работая с командами людей, важно, чтобы любая работа, с которой они сталкиваются, выполнялась максимально методично. Хотя «проскочить» оценку может показаться хорошей идеей, я рекомендую уделять время оценке. Как и во всей работе, тщательное изучение и понимание того, что вы собираетесь делать, а затем составление реалистичных оценок обеспечивает более реалистичный и сбалансированный подход к предстоящей работе