Искусство Эстимации

Искусство Эстимации

Практически все заказчики, которые приходят в компании разного уровня со своими проектами, хотят сразу знать, во сколько им обойдётся конечный продукт. Естественно, у них есть записки на бумаге, возможно даже презентация будущего проекта в Power Point, или даже варианты мокапов, набросанные далеко не специалистами. И вываливая всё это дело вам на стол, они ждут чётких цифр по срокам и финансам.

Сделаю оговорку — ситуация актуальна вне зависимости от исповедуемой заказчиком или исполнителем модели оценки работы, будь то fixed price, fixed all, time&material или dedicated team.

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

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

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

Что такое эстимация? Поскольку дальше я буду использовать этот термин наряду с «оценкой», то давайте определимся с ним. Итак, под эстимацией в сфере веб-разработки обычно понимается математически вычисленная приблизительная оценка затрат на выполнение проекта, при которой входная информация о будущем проекте может быть неполной или неточной.

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

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

  • Вы даёте оценку функционалу (features), а не пользовательским историям (user stories);
  • Ваша цель — помочь клиенту определиться с его проблемами, а не спланировать его финансовые расходы;
  • Точность оценки — средняя или низкая, но никак не высокая;
  • Ранняя эстимация должна делаться одним экспертом, а не командой разработчиков.

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

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

А теперь самое интересное.

Что необходимо для ранней эстимации

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

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

№  Задача Сложность реализации Возможные реальные решения Комментарии
1 Сделать форум Средняя Встроенный форум, Advanced forum module Клиент хочет, чтобы было красиво

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

Что нужно сделать

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

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

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

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

Фичи извлекаются из любой доступной нам информации, полученной от заказчика.

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

Поскольку от Drupal я никуда не денусь, в этом примере извлекаем друпал функции: тип контента «Статья», настройки по умолчанию «не опубликовано», сверху модули Rules и Mailhandler для назначения определённых событий и реакций на них. Всё это должно быть в нашей таблице, пока что не структурировано. Но на этот раз давайте сделаем таблицу немного более функциональной.

№ 

Уникальный номер

Задача или feature Часы Экспириенс (от 1 до 5) Возможные реальные решения Описание задачи. Комментарии
1 F001 Сделать форум 15 1 Встроенный форум, Advanced forum module Клиент хочет, чтобы было красиво
2 D007 Подготовить тестовый сайт 3 4   Используем drush

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

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

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

Как оценивать часы

Лучшим и наиболее проверенным способом оценивать часы на разработку является использование шкалы. Шкала — это определённый набор цифр, из которых вы выбираете часы. Наиболее популярной шкалой является 1, 2, 4, 8, 16. То есть на определённую задачу мы можем написать количество часов, соответствующее одной из цифр. Вы также можете комбинировать часы и использовать доли часов, например разработка модуля может занять 16+16 часов, а включение какой-нибудь встроенной функции — 0.2 часа. Самое главное, что вы мыслите в пределах определённого фиксированного набора цифр, это позволяет мозгу не пытаться брать случайные числа с потолка и хоть как-то переваривать задачу, прежде чем оценить её. При этом дробить цифры шкалы не рекомендуется при отсутствии надлежащего опыта.

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

Если задача занимает более, чем 50 часов — разбивайте её на более мелкие.

То, в чём мы не уверены, или то, что проэстимировать невозможно в принципе, откладываем в отдельный раздел таблицы для обсуждения с заказчиком. Не пытаемся брать данные с потолка!

Управляем неопределённостью и рисками

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

Очень сильно уровень неопределённости на ранних этапах оценки позволяют снизить вайрфрэймы (wireframes) — информации по их использованию и созданию лучше поискать самим.

Как я уже говорил выше, от ошибок никто не застрахован, но их количество можно сильно уменьшить.

Основные факторы, влияющие на риски, это:

  • Низкий уровень команды
  • Неправильно истолкованные требования к проекту или недостаточное внимание к ним
  • Полное отсутствие или недоработка стандартов и практик совместной разработки
  • Ошибки в планировании
  • Отсутствие системы контроля версий (Git, Svn, Mercurial, Bazaar и т. д.)

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

  • Производительность (сайт должен работать быстро)
  • Стабильность (он не должен падать)
  • Безопасность (его должно быть тяжело взломать)
  • Юзабельность (он должен быть простым в использовании для всех групп пользователей)

Общение с заказчиком

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

Я не уверен, что вы имели в виду под «интегрированная система оценки комментариев», поэтому в своих оценках я предположил, что (подставить нужное), и именно это я использовал в эстимэйтах. Если я не прав, то что конкретно вы имели в виду?

Заказчик будет вам благодарен.

Избегайте решений, в которых не уверены

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

Оцениваем риски правильно

Самый простой и лёгкий способ оценить риски в эстимэйтах, а значит — правильно выставить часы, это заполнить колонку «Экспириенс» в табличке. Если вы уже делали это решение и точно знаете, сколько времени на него уйдёт, ставим пятёрку. Если в приниципе знаем как это сделать, но сами ни разу не пробовали, то тройка подойдёт. Если вообще не знаете, как делать-то единица. Чем ниже цифра, тем выше риски, и тем больше часов надо закладывать на них, ведь вы будете проводить время в гугле, википедии, специализированных сайтах и форумах, общаясь по IRC.

И вот здесь начинается магия!

Мы вводим понятие «коэффициент риска». Фактически, это просто некий множитель, который применяется к эстимированным ранее часам. Обычно этот коэффициент рассчитывается так. Цифра перед двоеточием (от 1 до 5) это уровень экспириенса по задаче. После двоеточия — минимальное и максимальное значение множителя для данного уровня экспириенса.

5: 0.8x — 1.25x

4: 0.67x — 1.5x

3: 0.5x — 2x

2: 0.25x- 4x

1: 2x>

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

Минимальное количество часов = предварительное количество часов * минимальный коэффициент риска.

Максимальное количество часов = предварительное количество часов * максимальный коэффициент риска.

Например, первоначально мы прикинули, что сделать форум у нас займёт 10 часов, и наш уровень экспириенса равен пяти. Значит минимальная оценка на данную задачу (10*0.8) = 8 часов, а максимальная оценка (10*1.25) = 12.5 часов. Идеальное же значение (8+12.5)/2 = 10.2. Как правило, идеальное или усреднённое значение должно совпадать с предварительной оценкой.

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

Окончательный вариант таблицы оценки. Все числа «научно» просчитаны.

№  абс. №  Задача Часы Опыт Часы мин. Часы макс. Решение Комментарии (описание) Связи
1 D001 Профили пользователей 16 3 8 32 Модуль Profile2 Нужна консультация с экспертом по юзабилити D002
2 D002 Интеграция с форумом 8 5 6 10 Модуль phpBB Модуль требует тестирования
                   
    ИТОГО 24   14 42      

Плюс, не забываем заложить в эстимэйты такие вещи, как:

  • Затраты на управление проектом (даже если у вас есть стейкхолдер, держащий руку на пульсе): 1.25x
  • Тестирование: 1.15x

А у меня есть вопрос!

И тут же ответы на самые очевидные вопросы.

Что нужно знать, чтобы правильно эстимировать часы?

Всё, что вам нужно, это насобирать как можно больше логов выполнения задач, которые уже сделаны. Собирайте их сами с себя, со своих коллег, друзей — где угодно, пока на название типовой задачи у вас в мозгу не будет выскакивать число часов. Ну и конечно — нужно хорошо знать систему, с которой вы работаете, желательно как можно больше её аспектов. Используйте системы управления временем, благо их десятки. Я использую Toggl, например.

Может ли коэффициент риска привести к уменьшению эстимэйта?

Возможно, вы заметили, что коэффициент риска может быть меньше единицы, это значит, что если предварительно заэстимировали 5 часов на задачу, после применения коэффициента получили 2.5 часа как минимум, и 10 часов как максимум. Таким образом, риск повлиял на уменьшение количества часов. Здесь нет ошибки — ведь говоря «риск», мы подразумеваем, что есть некие непредвиденные факторы, способные повлиять на грубые цифры, а они могут работать не только в сторону увеличения. Простейший пример — после начала работы над проектом оказалось, что один из разработчиков потиху занимался «домашним» проектом, в котором он применил решение, которое мы первоначально оценили как очень рискованное. Мы об этом могли и не знать на этапе эстимации, и поэтому потратили на решение задачи минимальное время.

Что делать дальше?

Дальше всё зависит от ваших задач. Умножьте часы на ставку, например 2 доллара в час, и получите стоимость проекта. Уберите лишние колонки, которые заказчику лучше не показывать, и поразите его детализацией документа. Если время позволяет, обсудите документ с командой. Если вы работаете по модным нынче технологиям — у вас уже готовый бэклог!

Disclamer

Спасибо ребятам из NodeOne на друпалконе за вправление мозгов по поводу правильного эстимирования проектов. В результате появилась возможность переосмыслить процесс и сообразить те пару абзацев текста, представленного вам на размышление.

Для тех, кто хочет копнуть глубже, чем просто таблички с формулами, отсылаю к:

  • Замечательная книга Agile Estimating and Planning by Mike Cohn
  • Все возможные презентации на друпалконах и технических ивентах на эту тему, так как единого подхода здесь не существует и быть не может в принципе

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

 

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

Критика жесточайше приветствуется.