Как оценить проект и не попасть впросак? Ч. 2

berlin-airport

Запуск Berlin Brandenburg Airport изначально запланированный на 2012 снова перенесен. Теперь на 2020. Где ошибся менеджер?

Для себя собрал маленький estimate фреймворк. Совсем просто, но идея эстимейта состоит в том, чтобы пройти следующую цепочку шагов:

Собрать требования > Разбить на задачи > Оценить задачи

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

1. RFP

Как работать с требованиями уже разбирались, хотя тема бездонная. На Входе нужно получить RFP (request for proposal) от клиента или саммари от сейлзов по брифу.

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

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

Клиент прислал запрос создать сайт для публикации отчета о работе за год. Единоразовый сайт для презентации инвесторам и понтов. Через месяц-другой жизни он совершенно потеряет актуальность. Компания-подрядчик предложила создать все на CMS с возможностью управлять каждым ньюансом отображением и управления содержимым.
Клиент отказался. Его “боль” – не управление контентом. Его боль – быстрее выкатить в мир “витрину”. Не поняли боли, не взяли проект.

2. Брифование

Если есть возможность, то проведите встречу(и) с клиентом по требованиям и ещё глубже детализируйте бриф. С upwork-клиентами это нереально, знаю, по крайней мере, с большинством из них. Но с другими клиентами это вполне возможно.

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

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

Нет смысла браться за эстимейты, если нет навыков в анализе

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

По итогу, в конце первой группы процессов ПМ должен детализировать RFP и обновить бриф.

Estimate scoring

Для скоринга эстимейтов пользуюсь подходом Probability/Impact, чтобы понять, насколько сильно нужно углубляться в оценку. Если клиент пришел из ниоткуда, требования туманны, клиент выходить на связь не хочет и при этом есть маленький бюджет, то это Low Probability и Low Impact. Для такого запроса сделайте high-level оценку и предложить созвониться для выяснения требований. Не представляю себе вселенную, где можно выжимать из таких запросов толк и потому много тратить сил не стоит.

Если у клиента есть кредабилити, как минимум успешная история на UpWork или подтвержденный background check, и это тендер с ограниченным кол-вом участников, то оценивается в Probability High / Impact High. И за такие запросы беритесь закатав рукава.

Не беритесь за каждый запрос

Фокусируйтесь на самом главном и выстраивайте ожидания сейлзов и клиентов. Из 500 знаков написанных на салфетке тяжело сделать оценку с точностью выше 50%. Тем самым вы начнете уделять больше внимания правильным клиентам и меньше внимания трешу.

Сейлз или руководитель просит браться за каждый запрос и уделять каждому запросу одинаковое время (сомнительно, но все же)? Соберите историю оценок и посмотрите, какие из них зашли за последний квартал. Головой ручаюсь, что заходили только High / High.

3. Техническое решение

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

Вводная 1: Клиент хочет просто выйти в онлайн и дать знать миру о своей компании. Хочет рассказать про себя, команду и услуги. Не хочет ничего продавать (пока что).

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

Да, можно поддаться веянию моды и предложить сделать SPA на React или Angular. Но смысл забивать гвозди микроскопом?

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

Анализ: вот тут надо разобраться с основными пользовательскими сценариями и ролями. Конкретное решение может быть сделано как на реакте, так и на cms, но формализация требований должна идти на первом месте. Если у клиента нет списка сценариев, их нужно продумать вместе с ним.

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

4. Декомпозиция

Есть формализованные требования в любом удобном для команды виде. Может быть формат SRS, может быть плоский список пользовательских историй. Теперь на их основе делаем Work breakdown structure.

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

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

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

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

Знайте для кого делаете оценку и подстраивайтесь

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

5. Оценка

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

Оценка по 2-м точкам: не так хороша, как оценка по 3-м точкам, но для начала подойдет. Если осилите, углубитесь в красоту среднего распределения, почитайте о PERT и добавьте пару колонок в эксель. Но даже 2 точки (min-max) обеспечат минимальную “вилку” при оценках. Исходя из концепции “конуса неопределенности”, на этапе присейла есть высокий шанс неадекватно оценить проект. И потому лучше страховаться и всегда давать рейндж, а не 1 цифру.

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

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

Человек принимает решения на основе эмоций. Человек мыслит категориями и образами. И разработчик тоже человек, а значит несовершенен и подвержен ошибкам. Более того, у разработчика может быть мало опыта. Так зачем ломать ему и себе голову и пытаться оценивать в часах, если не выходит делать хорошо? Попробуйте оценивать в отностительных величинах.

Это большая задача или маленькая? Задачи можно сравнивать между собой, а можно с эталоном. Нормализуйте размеры и договоритесь с командой оценки об эталонах. Соберите для себя размеры где будут:

  • S(mall) – маленькие задачи, не требует описания выполнения. Для одних команд может быть добавить кнопку, для других – создать десяток api endpoints.
  • M(edium) – средние задачи, требует описания выполнения.
  • L(arge) – большие задачи, требует дальнейшей декомпозиции.

6. Финализация

Вычитываем и форматируем. Помните, документы – лицо менеджера. Если документ минимально не отформатирован, есть ошибки в формулах и опечатки, то какая гарантия, что менеджер точно так же и проект не сделает?

Помните что:

  • Libre Office Calc умеет проверять орфографию в таблицах;
  • Google Sheets имеет отличный плагин Spelling;
  • Дайте вычитать коллеге.
Не отправляйте документы с “гуляющими” шрифтами и глупыми опечатками в первой строчке

Выходы оценки

На выходе нужно получить минимальный набор артефактов состоящий из:

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

С этими документами сейлз уже сможет сделать хорошее предложение клиенту и понимать, что мы делаем, сайт визитку или маленькую ERP систему.

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


На правах рекламы. 17-18 февраля буду проводить 2-х дневный курс-интенсив по управлению проектами в P&M Hub. Рассмотрим вопрос работы с требованиями, оценок, управления сроками и бюджетом. Специально для читателей блога есть промо-код OUTSOURCED – даст 20% скидки. Узнать про мероприятие.

estimate-workshop