Estimations Wars

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

Скрытая оценка

Наша земля белорусская взрастила уже не одну тысячу аутсорсеров и фрилансеров. Все они занимаются, в общем, тем, что продают своё время “богатому дяде из США”, у которого есть гениальная идея для стартапа, но он бережёт свои деньги и поэтому нанимает более дешёвую рабочую силу “где-то на востоке”. То есть, если упростить всё до уровня четвероклассника, то получается такая задача:

У богатого американца Дональда Бранта есть заказ на разработку проекта P. Программист Петя оценивает работу в X часов. Нам известно, что стоимость одного часа работы программиста Пети стоит Y долларов США. Вопрос: сколько денег потратит Дональд Брант, если он хочет, чтобы программист Петя разработал для него этот проект?

Ответ: X * Y * 2. Комментарий: программист Петя не учел все риски при оценке и поэтому потратит в два раза больше времени

Аутсорсинг наносит ответный удар

Петя очень амбициозный разработчик. Ему не нравилось то, что его оценки так сильно расходятся с реальностью. И он решил, что следующим шагом в его карьере должна стать большая аутсорсинговая компания. Там-то ребята наверняка знают как делать всё правильно. Он успешно прошёл интервью в компании “Horns&Hooves-Soft”. Там он узнал много нового о том как можно улучшить оценку проекта. В бытность фрилансером, Петя просто говорил, что сделает проект за X часов. Здесь же ему рассказали про декомпозицию проекта (разбиение целого проекта на подзадачи, выделение доменов). После декомпозиции для каждой задачи делалась двух(трёх)точечная оценка — оптимистичная, реалистичная и пессимистичная. “Вот это круто! Оказывается вот как всё просто!” — подумал Петя. После чего все эти подзадачи вместе с оценками фиксировались в JIRA.

Про JIRA, на самом деле, стоит упомянуть отдельно. В компании “Horns&Hooves-Soft” (как в принципе и в любой другой крупной аутсорсинг компании) она была чем-то сродни божества, в которое должны верить и которому обязаны поклонятся все работники компании, иначе за тобой придёт инквизиция.

Никто не ждёт испанскую инквизицию!

Абсолютно все процессы работы компании были построены через JIRA — контроль задач при разработке проектов, найм и увольнение сотрудников, контроль отпусков… Вполне вероятно, что Кафка вдохновился бы этим всем на написание второй части “Процесса”!

Новый проект

И вот однажды с со своей новой идеей стартапа в Horns&Hooves-Soft пришёл Дональд Брант. В этот раз он решил сотрудничать с большой компанией с поставленными процессами, потому что уже однажды обжёгся, когда подрядил какого-то фрилансера на свой предыдущий стартап. “Мир, оказывается, очень тесен” — подумал Петя. Брант ничего не подумал, потому что он даже не подозревал, что Петя снова приложит руку к его новой идее, потому что личность Пети была скрыта за несколькими слоями менеджеров, с которыми вёл непосредственное общение Брант. Это был крупный проект, на который планировали собрать большую команду — Backend, Frontend, Mobile разработчики и т. д.

Первым делом для проекта начали делать оценку. Был проведён очень глубокий анализ, проект был гранулирован на подзадачи максимально насколько это возможно. Для каждой подзадачи была сделана трёхточечная оценка, которая должна была учитывать все возможные риски. На эту оценку ушло несколько недель работы, но в итоге Брант остался доволен, когда увидел документ с итоговой оценкой. Он, конечно, ничего не понимал в том, что было написано в этой таблице и, по сути, он в первую очередь посмотрел в колонку “Итого”. Но его очень впечатлила внимательность компании к деталям. Поэтому он, долго не раздумывая, подписал контракт с Horns&Hooves.

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

Возникшие проблемы с оценками

Неточные оценки и варианты решения

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

  • Глубоко вдохнуть и завести митинговый маховик с повесткой “Нам нужно поменять оценку”. В худшем случае это затронет всю команду, весь управленческий состав проекта, а также заказчика, которому нужно будет объяснить причины почему так получилось. И проект в данный момент будет развиваться медленнее.
  • Начинать хитрые манипуляции с оценками, вроде: “Фёдор Михалыч, смотри, я тут ошибся с оценкой задачи X и мне не хватает часов 8, чтобы закончить её. Но я вижу, что на задачу Y стоит слишком большая оценка. Я думаю, ничего страшного не будет, если я заберу часов 8 оттуда".

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

Психологический аспект

У неточной оценки есть также психологический аспект. Разработчику в большой аутсорсинг компании в общем случае всё равно закончится ли проект в срок или нет. Ему платят за 8 часов в JIRA и не важно насколько быстро он сделал свою задачу. За сроки пусть волнуются менеджеры! И это приводит к такой ситуации, что если задача была оценена в X часов, а разработчик понимает, что вполне реально сделать эту задачу за X/2 часов, то далеко не факт, что он её сделает в два раза быстрее, чем ожидалось. В данном случае оценка будет работать как якорь - если эту задачу оценили в X часов, то, значит на её нужно потратить X часов. Для этого нужно работать примерно по такому плану - почитать интернет, начать делать, почитать интернет, сказать на митинге, что начал делать и всё идёт по плану, немножко поработать ещё, так, в интернете определённо появилось что-то новое и интересное, ..., "Б#$%Ь! Уже почти не осталось времени на эту задачу, надо по-быстрому ща запилить!". Заниженная оценка также работает в качестве якоря. Разработчик или сразу же начинает работать в режиме "Б#$%Ь! Уже почти не осталось времени...". В обоих случаях страдает качество продукта (не говоря уже про психологическое состояние разработчика). И все страдают из-за того, что опираются в работе на точные временные оценки, сделанные в начале разработки, когда степень неопределённости того, что нужно делать, была очень высокой. Также большой проблемой здесь является то, что программист в работе над задачей слишком сильно фокусируется на том как быстро ему нужно её сделать, а не как хорошо ему надо её сделать.

Непостоянство команды

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

  • Изменяющуюся команду
  • Больше всё таки постоянную, нежели переменную оценку.

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

Что делать?

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

  • Если над задачей будет работать неопытный разработчик, то умножь оценку на 2;
  • “Слушай, а что если у каждого разработчика будет свой коэффициент производительности, который будет пересчитываться раз в полгода на основе того как сильно его реальный результат разошёлся с оценкой?”;
  • Давайте перед тем как начинать работу над задачей, разработчик меняет, если необходимо начальную оценку

Всё это приводит к тому, что управлять этой оценкой становится очень тяжело, а с какого-то момента и вовсе невозможно для человека:

Зависимость сложности управления оценкой от количества правил

Но практика показывает, что с увеличением времени потраченного на оценку, её точность существенно не изменяется:

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

Новая надежда

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

простейшая формула вычисления скорости разработки

В числителе сумма в стори-поинтах задач, которые команда успела выполнить за спринт. В знаменателе — общее время потраченное командой (T - число часов в спринте, N - размер команды). Из этой формулы также видно, что данный принцип чувствителен к размеру команды. То есть для максимальной объективности необходимо, чтобы на протяжении всего проекта ядро команды оставалось неизменным, иначе значение скорости V будет постоянно меняться. Причина в том, что любое линейное изменение команды (добавление, удаление, замена члена команды) влечёт не линейное изменение суммы выполненных стори-поинтов. В основном это из-за того, что команде нужно "притереться" к новому члену команды или же наоборот отвыкнуть от того, что раньше с ними был топ-программист, благодаря которому команда могла закрывать в два раза больше поинтов.

Заключение

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

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

А что с Петей стало? Пока ничего. Будем ждать пробуждения силы…

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.