Делаем оценку в 5 шагов для проекта с неполными требованиями

Было ли у вас такое, что приходил RFP всего в 10 строк с просьбой дать оценку? У меня такое происходит регулярно. Что делать менеджеру проекта, если нужно оценить проект, а требований не хватает или они неполны? За годы работы в аутсорсе я выработал ряд правил, как делать оценки на основе фрагментарной информации.

1. Сужайте конус неопределенности

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

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

“It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data and certified chiefly by the hunches of the managers.” Fred Brooks

2. Не проксируйте

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

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

Потратьте 20-30 минут (или больше, если есть возможность) и разберитесь в том, что нужно сделать. Сделайте предварительную разбивку на большие компоненты. Сразу задайте вопросы клиенту по недостающим деталям. И только затем уже ставьте конкретную задачу разработчикам.

3. Стройте предположения

Ок, а как же узнать про проект больше если ваш заказчик – посредник? Или на данный момент требований не хватает? Нет глубоких знаний в доменной области? Стоит ли оно вообще того?

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

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

Согласитесь, это ведь нормально прийти в магазин и попросить консультанта помочь с выбором услуги\товара. И это ненормально, когда консультант отвечает: “Ага, вы не знаете чего хотите? Ну идите домой и возвращайтесь когда будете знать!”.

Так вот, если требований нет, клиент неопределенный и Сатурн в созвездии Рака, то нужно делать следующее: работать с предположениями (assumptions).

Разберем пример вместе. Клиент хочет запустить e-commerce проект и говорит: “Должны быть оплаты на сайте”. Такое требования нельзя оценить as is. Тут нужно или разговаривать с клиентом или строить предположение, что мы сделаем оплату на сайте через PayPal/Stripe/Braintree. И даже пойти дальше и сказать, какие SDK можно использовать. А вот уже с этой информацией вы сможете оценить трудозатраты на фичу “Принимать оплату на сайте”.

4. Создавайте прототипы и low-fi wireframes

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

Лучше один раз нарисовать, чем 100 раз объяснять.

Каждый менеджер должен освоить прототипирование и уметь создать low-fi варфреймы. Есть мощный и бесплатный Mockplus, больее мощный и платный Axure и есть условно-бесплатные онлайн редакторы. Выбирайте на свой вкус и рисуйте.

5. Создайте спеку

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

И вот уже с этой спекой можно делать детальную оценку. В моей практике у меня были клиенты, которые приходили просто с фразой: “Хочу магазин, или хочу свой маленький гугл докс” и на выходе оценки получали талмуд в 200 страниц. Часть проектов даже заходила в разработку, часть – нет. Это нормально.

Ненормально разбрасываться возможностями и не развиваться в работе с требованиями.