12 советов по эстимации проектов по разработке от практикующих пресейл-специалистов

36 комментариев
12 советов по эстимации проектов по разработке от практикующих пресейл-специалистов

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

О том, как давать адекватую и реалистичную оценку, а не прикидку на глаз, не раздувать её сверх меры, но и не поскромничать, мы поговорили с Сергеем Сметюхом, директором по бизнес-развитию в компании 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 не несёт ответственности за достоверность информации в корпоративных блогах компаний.

По теме
Все материалы по теме

Хотите сообщить важную новость?

Пишите в наш Телеграм

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая

Конкурс EY Entrepreneur Of The Year 2020

EMERGE 2020
1 июня — 3 июня

EMERGE 2020

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
4 июня

Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

Читайте также

Notion снял ограничения в бесплатном тарифе
Notion снял ограничения в бесплатном тарифе

Notion снял ограничения в бесплатном тарифе

2 комментария
Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)
Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)

Белорусы сделали «поисковик» по блогерам (уже продукт недели на PH)

Решение белорусов хотят использовать для удалённого контроля за больными COVID-19
Решение белорусов хотят использовать для удалённого контроля за больными COVID-19

Решение белорусов хотят использовать для удалённого контроля за больными COVID-19

2 комментария
А1 и чешский техностартап с офисом в Минске запустили систему умного дома
А1 и чешский техностартап с офисом в Минске запустили систему умного дома

А1 и чешский техностартап с офисом в Минске запустили систему умного дома

1 комментарий

Обсуждение

2

Можно несколько вопросов?

1. Из вашего опыта сделанных оценок и выигранных проектов, какое среднее значение недо/переоценности получилось?
2. Выполненная оценка включается в контракт по модели fixed price? Или является "ориентиром"?
3. Каким образом вы оцениваете R&D, в случаях, когда на начальном этапе известно только то, что надо получить в итоге, но неизвестно, каким путем пойдет команда разработчиков?

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Смотрите ответ ниже, по ошибке запостил его отдельным комментом)

1

Спасибо, полезная статья. А как у вас развиваются события после определения этой 90%-й величины? Как фиксируется договоренность с заказчиком и как она корректируется по ходу дела?

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
2

Вариант фиксирования договоренности зависит от выбранной модели контракта.
1. Если это Fixed Price - мы фиксируем объем работ. Детальная разбивка объема работ вместе с оценкой на каждую подзадачу обычно помещается в контракт. Если по ходу выполнения работ мы видим, что по своей ошибке недооценили задачу - делаем ее за свой счет. Мы не практикуем "неоплачиваемые овертаймы", которые сжигают команду. Оплачиваемые овертаймы делаем только, если этого хочет клиент и команда согласна. Если команда не успевает сделать оговоренный объем в оговоренный срок - добавляем людей. Чтобы люди могли оперативно подключаться на проекты, мы разрабатываем стандарты кодирования и общую библиотеку, но это тема отдельного обсуждения. Важно уметь отличать недооценку задачи от расширения объема работ, здесь важна постоянная коммуникация с клиентом и нацеленность на как можно лучшее понимание целей клиента. С этим нам, к слову, помогли тренинги PMBA от Марии и Сергея Бондаренко.
2. Если это T&M контракт - мы обычно оговариваем примерные бюджеты с клиентом и держимся в их рамках. Если мы видим, что объем работ растет и потенциально может выйти за рамки бюджета, то сигнализируем об этом клиенту и вместе решаем что делать. В рамках T&M мы часто фиксируем объем работ на итерацию, чтобы и для нас и для клиента разработка была более предсказуемой.
3. Если это Dedicated Team - как правило, менеджеры со стороны заказчика сами управляют командой. Если привлекается менеджер с нашей стороны - мы управляем объемом работ и оценками как в T&M.

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
1

Здравствуйте, Сергей.
Ответы:
1. Статистика немного отличается в разных департаментах. Могу рассказать, как у нас в игровом. Когда мы начинали налаживать процесс оценки, проекты в среднем недооценивались на 30%, но это лишь средняя цифра, от проекта к проекту ситуация могла сильно отличаться. Мы ставили себе целью не просто выйти на точную оценку с среднем, а делать точную оценку на каждом проекте. С помощью описанного в статье мы пришли к точным оценкам, недо/переоцененность колеблется в пределах 95-105%.
2. Для fixed price контрактов оценка чаще всего включается в контракт. Мы не стесняемся показывать детальные разбивки оценки клиентам - это помогает синхронизировать понимание скоупа работ. Для T&M оценка служит ориентиром.
3. Зависит от объема трудозатрат, необходимых для построения родмапа. Если объем небольшой, мы делаем исследование и построение родмапа за свой счет на стадии пресейла. Если объем большой - выделяем отдельную фазу анализа (иногда несколько фаз), которую можем делать по fixed price. В результате фазы анализа формируется оценка и родмап.
Для игровых проектов все еще сложнее - клиент зачастую не знает, что надо получить в итоге. Здесь мы почти всегда выделяем одну или две фазы анализа.

1

Спасибо за ответы, Артём. Интересно было бы услышать еще информацию от неигрового отдела :-)

В статье упоминается, что исполнитель, выполняющий эстимацию, выбирается "полуслучайно" (т.е. условно берется незанятый человек с бенча). Тут еще пару вопросиков напрашивается, а именно:

1. Какие требования у вас внутри предъявляются к человеку, который будет выполнять эстимацию?
2. В чем отличие между RFC Coordinator и человеком, готовящим оценку? А в чем между ним же и sales manager?

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Здравствуйте, Сергей.
Еще ответы:
1. Мы проводим тренинги по эстимации, которые улучшают общее понимание процесса сотрудниками, а также позволяют оценить навык оценки у каждого из сотрудников. Зная уровень этого навыка для каждого сотрудника и понимая сложность проекта мы выбираем наиболее подходящего специалиста из находящихся на бенче. RFX примерно равномерно распределяются между текущими людьми на бенче, более сложные - более опытным. Недостаток опыта у эстиматоров мы компенсируем большим вниманием со стороны супервайзера. Важный для понимания момент - мы не профилируем пару человек на выполнение оценки, а учим каждого человека.
2. RFX Coordinator - человек, который управляет процессом оценки. Чаще всего это человек со стороны продакшена - тех. лид или менеджер. Это человек опытный в эстимации, анализе требований и коммуникации с заказчиком. Сам он не делает оценку, но может ее проверить и синхронизировать между разными эстиматорами.
Sales Manager не вникает в детали выполнения оценки, RFX Coordinator в свою очередь не занимается составлением коммерческих предложений и контрактов.

1

Спасибо Артём, ваш процесс мне стал понятен

Anonymous
Anonymous Business Development Director в Softeq Development
1

Сергей, здравствуйте,

Хочу добавить в ответ моего коллеги Артема порцию информации, которая будет отвечать на ваши вопросы от имени наших других департаментов (mobile, enterprise web, embedded systems).

1. Из вашего опыта сделанных оценок и выигранных проектов, какое среднее значение недо/переоценности получилось?
[SOFTEQ]. Артем правильно отметил, что среднее значение надо/переоценки после внедрения основных описанных принципов, налаживания процессов и постоянного обучения оценкам экспертов существенно разнится от того, что было в самом начале налаживания процесса оценки проектов.
На момент начала налаживания процесса оценки проектов среднее значение надооцененности проектов по компании было порядка 25-30%. "Лидировали" в этом показателе наши enterprise web департамент и отдела встроенного ПО. Получше дела обстояли у игрового направления и лучше всех показывал результат мобильное подразделение.
После стабилизации процесса оценки проектов показатели департаментов выровнялись и приблизились к одному уровню. Сейчас у нас в компании в целом уровень надо/переоценки проектов колеблется в пределах 5%.

2. Выполненная оценка включается в контракт по модели fixed price? Или является "ориентиром"?
[SOFTEQ] Мы действительно не стесняемся показывать наши оценки по fixed price клиентам, когда они хотят увидеть оценки. Зачастую им не надо сами детальные оценки, а на первый план выходят бюджет и сроки сдачи проекта.
Мы не можем себе позволить поставку оцененного фиксированного объема работ с опозданием по срокам по нашей причине. Даже задержки сроков со стороны клиенты мы учимся предсказывать в процессе обработки запросов и подготовки предложений клиентам. Этими задержками со стороны клиента мы управляем по ходу выполнения проекта и разными способами пытаемся придерживаться изначального графика.

3. Каким образом вы оцениваете R&D, в случаях, когда на начальном этапе известно только то, что надо получить в итоге, но неизвестно, каким путем пойдет команда разработчиков?
[SOFTEQ] Артем очень хорошо изложил в своем ответе саму концепцию работы в подобных случаях. Мы действительно находим ту точку на проекте, где можно будет принять принципиальное решение и выбрать самый подходящий путь дальнейшего движения. Если мы можем аргументировать, что попадание в точку даст возможность клиенту максимально оптимизировать инвестиции в проект и получить максимально подходящее решение по его ожиданиям, то тогда мы продаем это фазу/часть проекта.
Часто эту фазу можно продать на проектах игрового отдела, реже на проектах других департаментов. Но снова же, все зависит от проекта и его специфики.

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

-6

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

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
1

Спасибо за отзыв)
Поделитесь опытом, если используете что-то, о чем мы не написали.

-3

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

-4

"Эстимации"... Рунглиш такой рунглиш.
Писали бы уже сразу: "дюжина адвайсов по эстимации прожектов по девелопингу от пресейл практишенеров".

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
2

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

-1

это 5, так и надо

-2

"Дюжина"? Какое же издевательство над русским языком! Это вообще законно!?

0

Нет конечно, наказывается тремя годами расстрела!

3

PERT (оптимистичная + 4*реальная + пессимистичная)/6)
либо «закладывание отдельного буфера» для корректировки оценки относительно рисков

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

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Правильно ли я понимаю идею, что к 4м цифрам PERT добавляется еще одна цифра - вес, итого 5 цифр на каждую задачу, из которых 4 должен внести эстиматор?
Сам я евангелист подхода с оценкой через 2 цифры - оценка задачи и оценка риска. На мой взгляд этот подход лучше подходит опытным эстиматорам, т.к. дает больше контроля над оценкой и делает ее более прозрачной. Для тех, кто не работал с таким подходом, распишу его чуть подробнее. Оценка на задачу вычисляется по формуле:
TE = M * (1 + R)
TE – ожидаемое время
M – наиболее вероятное время
R – риск
Эстиматор вводит 2 числа - M и R, число TE считается автоматом. Каждое из этих чисел нужно для своих целей:
TE - оценка, попадающая в контракт
M - время, на которое должен ориентироваться разработчик, при выполнении задачи.
R - степень неопределенности в задаче, которая позволяет RFX-координатору оценить понимание командой объема работ и, что важно, конкретные области неопределенности.

1

имел ввиду что:
Веса 1o 4р 1п в формуле

Могут быть 1 2 3, например, то бишь наиболее вероятная оценка задачи сдвинется в сторону пессимистик в данном случае, правильно?

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

Евангелист для меня страшное слово ) И я давненько уже ничего не оценивал - так, вспомнилось. Так что прошу не пинать )

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
1

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

-2

тоже вот стал интересен вопрос веса. почему именно 4 не подскажете?

1

если меня спрашиваете то pert его знает ) бинарные распределения и все такое....не математик

2

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

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

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

0

C вами очень очень поспорят ) ребята из компаний интеграторов своих готовых решений (банковские, телекоммуникации, страхование и т.д.) - проекты на много человеко лет продаются по fix price с доработкой и интеграцией с довольно точной (после анализа месяца 3-4) оценкой на кастомизацию(1-2 года) и внедрение (от полу года). Скрамами там и не пахнет....

0

Хотя нет сам себе отвечу - все скажут - у нас адаптированный аджвйл.... и все такое )

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
1

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

Anonymous
Anonymous Marketing & PR Director в Softeq Development
1

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

Anonymous
Anonymous ведущий разработчик в Credo-Dialogue
0

1. Скажите пожалуйста, откуда Вы брали графики (например "Оптимальный размер команды для оценки проекта")?

2. Как вы определяете, что точность Ваших оцененок составляет 5%? Как при этом учитывается участие сотрудников в непроектных работах, больничные, работа на нескольких проектах одновременно и тому подобное?

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Здравствуйте, Сергей.
Ответы:
1. Графики мы брали из своего опыта.
2. Точность оценки мы определяем, сравнивая изначальную оценку и фактически потраченные часы. Для этого по каждому проекту рассчитывается специальный KPI. Скажем, если оценка была 1,000h, а потратили 1,030, то неточность рассчитывается так:

(1,030 - 1,000) / 1,000 = 3%

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

Anonymous
Anonymous ведущий разработчик в Credo-Dialogue
0

А каки образом устроен учет времени?

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Разработчики вносят время в Jira Tempo. Менеджеры проектов мониторят потраченное время и подсчитывают еще один KPI, показывающий текущий уровень "успевания" проекта.

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Поступил вопрос в скайпе, к каким по бюджету проектам применимы наши советы?
В целом советы применимы к разным бюджетам, от 100 до 20k часов. Совет о привлечении к оценке большей команды стоит проецировать на бюджет проекта: чем больше проект, тем больше команда оценки.

-2

>> Примечательно, что в нашем игровом подразделении zGames эмпирически было выявлено, что риски лучше оценивать одной цифрой.
Решил пойти дальше и оценивать риски одной буквой.

Артем Воробьев
Артем Воробьев Technical Process Architect в Softeq Development
0

Мы с этой буквы начинали)

0

ребята, а про метод параметрических оценок в вашем процессе можно чуть детальнее?

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже