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

О том, как давать адекватую и реалистичную оценку, а не прикидку на глаз, не раздувать её сверх меры, но и не поскромничать, мы поговорили с Сергеем Сметюхом, директором по бизнес-развитию в компании Softeq Development, и Артёмом Воробьёвым, техническим руководителем её игрового подразделения zGames.

Читать далее

1. Не начинайте подготовку оценки без понимания того, что вам нужно оценить

It’s easy to estimate what you know

It’s hard to estimate what you don’t know

It’s very hard to estimate what you don’t know you don’t know

Точность оценки напрямую зависит от степени детализации предоставленной на входе информации от клиента. Чем больше у вас информации, тем более точную оценку можно предоставить. Если есть пробелы в представлении, то не стоит сразу переходить к допущениям, а лучше задать имеющиеся вопросы клиенту. При этом следует помнить о четырёх общих правилах эстимаций:

1. Учитывать один элемент функциональности только один раз.
2. Включать в оценку всю функциональность, которую хочет заказчик.
3. Не включать в оценку ту функциональность, которую заказчик не хочет.
4. Оценивать функциональность правильно.

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

Как это работает у нас

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

2. Привлекайте для оценки проекта команду, которая будет выполнять этот проект

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

Конечно, при большом потоке запросов от клиентов соблюдать это правило становится сложнее. Если 1 человек оценивает 4 проекта, то вероятность, что он в итоге будет реализовывать проект, который сам и оценивал, всего 25%. Иными словами, 75% проектов выполняются по «чужим» оценкам. И именно в этом корень зла, ведь люди склонны к субъективности и меряют в основном по себе. Что у старшего разработчика с доменным опытом займёт 100 часов, у специалиста со средним опытом — на 30% больше. Масштабируйте это на общие цифры оценки, и проблема приобретёт угрожающий масштаб.

Как это работает у нас

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

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

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

3. Привлекайте к формированию оценки более одного человека

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

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

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

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

Как это работает у нас

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

4. Назначайте ответственного за формирование финальной оценки данному клиенту

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

Как это работает у нас

Мы всегда придерживаемся этого правила, так как у нас на постоянной основе идут проекты, в которых участвуют сразу несколько департаментов. Например, разработка наручного браслета для контроля физиологических параметров профессиональных атлетов, проходящих реабилитацию после травмы, которая включает в себя: hardware — проектирование платы и корпуса самого устройства и его физических компонентов, firmware — разработка прошивки для корректной работы самого устройства, mobile — создание пользовательских приложений, чтобы вся информация могла через канал связи передаваться с устройства в мобильное приложение, где следить за статистикой намного проще, web — для хранения всех данных в cloud, а не на мобильных девайсах и управления всей системой администраторами.

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

Отдельно стоит отметить, что ответственное лицо всегда должно ставить эстиматорам чёткие сроки, когда нужна оценка. В нашем случае это делает чаще всего Sales Manager или RFX Coordinator — координатор обработки поступившего запроса (RFX — request for X, где X может быть Information, Quote, Proposal).

5. Согласуйте между участниками все тонкости формирования оценки и придите к общему пониманию объёма оцениваемых задач

У всех участников должно быть одинаковое представление как по основным функциональным компонентам/юнитам, так и по нефункциональной части проекта. Главная идея заключается в том, чтобы после формирования оценки каждым участником можно было сравнивать «яблоки» с «яблоками».

Как это работает у нас

• Мы всегда вникаем в то, чего именно хочет клиент, какая его бизнес-цель. Все участники пресейла должны это понимать, чтобы принимать наиболее эффективные решения и делать наиболее полезные предложения.
• Перед началом процесса эстимации мы проговариваем со всеми участниками объём не только функциональной части проекта, но и задачи по составлению документации, созданию unit-тестов, проведению code review и необходимых видов тестирования, организации обучения для клиента при необходимости и т. д.
• Каждый участник руководствуется одними и теми же предположениями (assumptions) и формирует оценку на основание того, что проект будет выполнять специалист предварительно оговоренного уровня.
• Синхронизация происходит не только перед началом оценки, но и в процессе.

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

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

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

Как это работает у нас

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

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

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

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

Как это работает у нас

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

На большинстве проектов в Softeq мы используем модель оценки PERT (Program Evaluation and Review Technique, её ещё называют «оценка на трем точкам») либо «закладывание отдельного буфера» для корректировки оценки относительно рисков. Эти две техники существенно отличаются по способу предоставления клиенту оценки рисков. В случае использования PERT модели мы закладываем риски в каждую задачу (итоговая оценка считается как (оптимистичная + 4*реальная + пессимистичная)/6). Задачи в оригинальной оценке идут без заложенных рисков, если на риски выделяется отдельный бюджет (или буфер). Использование той либо иной техники зависит от клиента и его пожеланий. Независимо от выбранной техники представления рисков клиенту, наш рисковый бюджет остается неизменным на проекте.

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

8. Старайтесь всегда использовать более одного подхода для формирования максимально точной оценки

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

Как это работает у нас

Два самых распространённых комбинированных подхода у нас в компании такие:

• формальная модель оценки «по аналогу» + экспертная оценка «снизу вверх» (или так называемая Work Breakdown Structure-based);
• формальная модель «параметрических оценок» + экспертная «групповая оценка».

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

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

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

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

9. Предоставляйте клиенту диапазоны с обоснованными и аргументированными вероятностями попадания в нижнюю/верхнюю границу

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

Как это работает у нас

Оценка в виде диапазона формируется достаточно быстро минимальными трудозатратами. Чаще всего в подобных ситуациях мы используем любую формальную модель оценки (например, «по аналогу» либо «метод параметрических оценок»).

10. Если имеете дело с Agile, делайте всё более точные оценки от спринта к спринту на основание текущей производительности команды и приобретаемых знаний по деталям проекта

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

Как это работает у нас

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

11. Храните оценку онлайн, а не в локальном файле

Локальные копии документов в процессе оценки — это на самом деле даже не проблема, а прародитель всех проблем, так как:

1. Ответственному за данный RFX сотруднику потребуется неоправданно много времени на то, чтобы разобраться и интегрировать оценки команды эстиматоров, если каждый делает оценку в своём файле. Кроме прочего при этом допускается ещё и много ошибок.
2. Если плодить документы, их версии, копии, то никакие пометки типа «final» в названии не гарантируют, что это действительно актуальная версия документа.
3. Люди болеют, уходят в отпуск и попросту забывают детали со временем. Техника ломается. Онлайн-документы позволяют минимизировать эти два риска, что уже немало.

Как это работает у нас

Мы пользуемся только онлайн-документами:

• Оценку разных фаз проекта мы делаем в разных вкладках одного документа, например, в Google Spreadsheet.
• Задачи объединяем логически в группы (фичи), чтобы облегчить внесение изменений. Иногда нужно несколько уровней вложенности тасков (у нас обычно не более четырёх: Programming->UI->Screens->Settings Screen).
• Время на некоторые таски удобно считать по формулам. Например, в оценке проектов по созданию игр таски, зависящие от количества элементов контента (время на отрисовку и программирование персонажей зависит от количества персонажей) мы рассчитываем так:

Characters modelling = Number of Characters * Time per character’s model

Characters programming = Number of Characters * Time per character’s mechanics

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

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

Не увлекайтесь оценкой и всегда контролируйте тот момент, когда оценки достаточно для предоставления максимально точного ответа клиенту с минимальными трудозатратами с вашей стороны. Ведь, по сути, когда речь идёт о формировании оценки, всё, с чем мы имеем дело, это максимальные приближения (апроксимации) и предсказания объёмов планируемых работ. В какой-то момент наступает ситуация, когда максимальное значение уточнения, которого можно добиться, измеряется в 1-10% от общего размера оценки. Но для того, чтобы добиться этого уточнения, надо потратить в 2-4 и более раз больше времени, чем потребовалось на формирование оценки с точностью 90-99%.

Как это работает у нас

Практически все запросы на оценку, которые мы обрабатываем, не занимают у нас более двух итераций. Часто получается сформировать финальную оценку с первой попытки. Для этого необходимо получить все оценки участников команды с максимально разбежкой до 20%. Если же разбежка составляет более 20%, то тогда нужно обсуждать доводы эстиматоров в обоснование предоставленных ими цифр и/или провести дополнительную сессию обсуждения с заказчиком. Это зачастую помогает прояснить детали, когда требования непонятны.

После дискуссии каждый участник повторно выполняет оценку (обновляет предыдущую версию). У нас в компании второй итерации в большинстве случаев достаточно, чтобы получить оценки в диапазоне с разбежкой между минимальной и максимальной полученной до 20%. Затем мы выбираем усреднённую оценку и представляем её клиенту.

Надеемся, наш опыт и рекомендации будут полезны проект-менеджерам, разработчикам, и другим участникам пресейл-процесса.

*Редакция dev.by не несёт ответственности за достоверность информации в корпоративных блогах компаний.

Место солидарности беларусского ИТ-комьюнити

Далучайся!