Advent, Episode 8: Работа над проектами, подготовка и оценка

Роман Лапин — Dec 09, 2014    advent2014

Previously on Evercode Lab Advent

Действительно большинство наших заказчиков компетентны…

…не беремся за проекты, в которые сами не верим.

…не просто пишем код, мы решаем проблемы или задачи конкретных людей

Условия

Допустим, все прекрасно.

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

Первое, что всегда беспокоит всех клиентов — это сроки и деньги. Неизбежно и логично. Поэтому цель первого подготовительного этапа — предоставить клиенту такие оценки, сориентировать.

Независимо от того, по какой схеме вы работаете, продаете ли часы по факту, работаете ли по фиксированному ТЗ за фиксированные деньги, практикуете ли fixed time, fixed price, flexible scope, клиент все равно не оставит попыток получить заветный ориентир по срокам и деньгам на всю работу целиком или хотя бы большой ее кусок. Ему надо планировать расходы или бюджет, согласовывать с начальством, инвестором, партнерами. Числа нужны всем.

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

Шаг первый

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

Интересуют нас следующие вещи:

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

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

Шаг второй

Допустим, все до сих пор зашибись.

Мы выяснили общие вопросы. Процессом все довольны. Пришло время углубляться.

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

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

По итогам встречи все материалы мы стараемся оцифровать, положить в Google Drive, а что-то уже в basecamp. В нем же можно при взаимном соглашении организовать уточнение вопросов, если оно понадобится.

Шаг в сторону

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

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

Шаг третий

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

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

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

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

Шаг навстречу

Допустим, все просто шикарно. Наши оценки приемлемы для клиента, наш подход его устраивает. Тогда мы ударяем по рукам, согласуем даты старта, подписываем договор и составляем Задание на первую итерацию работы (1-2 недели). По внесению аванса стартует работа.

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

О том, что и как происходит дальше, поговорим завтра.

Эта статья является частью Evercode Lab Advent 2014 — цикла из 24 статей о том, как появилась, устроена и работает компания Evercode Lab. Полный список статей можно посмотреть в анонсе Evercode Lab Advent.

Evercode Lab

Close