Мы используем cookie-файлы. Оставаясь на сайте роботов, человек соглашается на использование cookie-файлов.
Подробнее — в «Условиях использования cookie-файлов».

Учесть всё: как оценить проект и не ошибиться

Роботы объясняют, какие факторы влияют на срок и стоимость разработки продукта, откуда ждать подвоха и что делать, если план расходится с реальностью.

Александра Абакумова, руководитель проектов Redmadrobot

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

Собрать информацию

Получить бизнес-требования 

Нельзя определить затраты и время выполнения работ, если клиент не знает, что хочет получить. Такое случается нередко, заказчик может предложить: «Давайте сделаем кэшбек и добавим десять партнёров в разных категориях. Сколько нужно времени и денег на внедрение?»

Данила Березин, руководитель проектов Redmadrobot

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

Привлечь экспертов

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

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

Освоить новые технологии и отрасли

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

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

Учесть зависимости 

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

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

Это тоже зависимости

  • согласование требований и дизайна с клиентом;
  • получение доменного имени, SSL-сертификата, доступов к аккаунтам и ПО;
  • договорные отношения и сроки согласования документов у клиента и подрядчиков;
  • процессы госструктур, если ваш проект зависит от решений госорганов;
  • каникулы в App Store и Google Play.

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

Железная выдержка

Опытный менеджер может назвать клиенту вилку прямо на встрече. Но чем меньше опыта у команды, тем сильнее бывает желание угодить клиенту и спешно оценить проект. «Не затягивать» с оценкой может предложить и сам заказчик. Если оценка собрана за день, она, скорее всего, подведёт. Важно объяснить клиенту, что спешка не выгодна вам обоим, и попросить время на расчёты.

Объективность

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

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

Что ещё учесть, чтобы не попасть впросак

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

Оценить

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

Диапазон или вилочная оценка 

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

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

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

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

Story Points

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

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

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

Параметрический метод относительных оценок

Разбивает функциональность продукта на модули, чем напоминает Story Points. Например, модули онлайн-магазина — это списки, коллекции, баннеры, диалоги, карточки и т.д. Каждый модуль оценивается в стори-поинтах и умножается на количество модулей своего типа. В результате получается относительная оценка суммы всех модулей, видна продолжительность проекта в стори-поинтах и скорость работы команды.

Чем хорош. Помогает быстро оценить типовые задачи.

Слабые стороны. Метод не подходит для новых, нестабильных команд, недавно работающих над продуктом.

PERT

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

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

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

Most Likely

Метод разбивает проект на части. Команда детально прорабатывает каждую задачу и возможные варианты реализации: когда всё идеально, когда срабатывают все риски и когда — часть рисков. В план закладываются наиболее вероятные. Для части задач допустима погрешность в меньшую сторону — в итоге оцененные по Most Likely задачи в совокупности компенсируют риски друг друга.

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

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

Проверить

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

  • заложена ли в задачу обработка ошибок?
  • какие учтены краевые состояния продукта?
  • как команда представляет себе UI/UX-поведение продукта?
  • где запланирована основная логику задачи: на backend-стороне или у клиента?
  • нюансы обработки данных на frontend-стороне: например, будет ли кластеризация на карте?

Как оценивают роботы

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

Десять шагов к безупречной оценке

1. Разбить проект на этапы и задачи внутри каждого этапа.

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

3. Учесть часы на проектную коммуникацию команды. Обычно она занимает 15-20% от общего срока.

4. Добавить часы на стабилизацию после завершения каждого этапа. Стабилизация — не риск, а типичная задача проекта. Это ещё 20-25% от времени, запланированного на реализацию.

5. Если проект ведётся по модели Fixed Price, сверху необходимо заложить дополнительный буфер в 20-30% на непредвиденные обстоятельства.

6. Правдоподобная оценка — та, которую трижды верифицировали: команда разработки, менеджер и руководитель.

7. Проверить финансовые показатели до начала производства.

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

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

10. Статистика план-факта поможет откалибровать оценку подобных задач в будущем. А также проанализировать проблемы и учесть возможные риски.