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

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

Первая встреча

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

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

• О чем проект?
• Какие есть конкуренты на рынке?
• Если есть конкуренты, то что чем отличается ваш проект?
• Как он собирается зарабатывать на этом проекте?
• Почему он решил разрабатывать на Ruby?
• Есть ли у него другие разработчики или дизайнеры с кем мы могли или должны были бы работать совместно?

Если клиент хочет разрабатывать стартап с нуля:

• Будет ли идти разработка фултайм?
• Есть ли другие основатели?
• Как он собирается финансировать проект?
• Есть ли у него опыт запуска проектов-стартапов?

Если клиент это организация со своей командой разработчиков:

• Какая команда разработки у них есть?
• Какой стек технологий они используют?
• Как они управляют проектами? Используют ли они Scrum?
• Пишут ли они тесты?
• Почему они решили прибегнуть к внешней помощи?

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

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

Внутреннее обсуждение

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

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

Пишем таски и делаем их оценку

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

Потом мы проводим оценку используя Estimation Party. Обычно мы просим кого-нибудь из нашей команды присоединиться к этому процессу, чтобы иметь наиболее четкую оценку.

Мы оцениваем сложность каждого юзер-стори по шкале 0, 1, 2 или 3 поинтов. Очень грубо: 1 поинт это пол-дня работы, 2 поинта полный день и 3 поинта займет 2 дня работы. Если мы видим, что какой-то юзер-стори выглядит больше чем на 3 поинта мы разбиваем его больше чем на один юзер-стори.

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

Определяем вилку цен

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

Всего поинтов: 120
Наше велосити за неделю: 12 поинтов
120 / 12 = 10 недель

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

Оценка времени: от 10 до 14 недель

Потом мы умножаем получившееся время на среднее количество оплачиваемых часов разработчика в день, что составляет около 7 часов (мы работаем 8 часов, но выписываем счет только за продуктивное время работы), и наконец умножаем количество часов на наш часовой рейт:

10 недель * 5 дней * 7 часов * $100 = $35.000
14 недель * 5 дней * 7 часов * $100 = $49.000
Оценка стоимости: от $35.000 до $49.000

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

Отправляем оценку

И в конце-концов мы отправляем клиенту либо простой PDF документ (несколько страниц) или email со всеми юзер-стори (и их оценкой), оценкой времени и стоимости. Мы стараемся не тратить много времени на составление модных документов, мы не видим в этом смысла.

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

Проверяем оценку перед каждым спринтом

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

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

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

Заключение

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

Автор: selivandex

Источник