Классно, когда в компании уже есть механизм оценки требований или оценку ведут архитекторы / PM-ы / PO и прочие люди, которые никак не являются аналитиками. Но у нас в компании не было сложившейся модели оценки, и каждая команда тратила большое количество времени, оценивая запросы клиентов. Тогда нам пришлось разработать собственную схему оценки требований, потратив на это много времени - сначала набирая опыт и проверяя его, затем внедряя и объясняя сотрудникам методику.

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

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

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

Определяемся с типами запросов

Все пресейлы (тут и далее имеется ввиду контакт с новым клиентом) или запросы о реализации функционала (доп. требования от текущего клиента), которые присылали в Компанию на оценку, мы разделили на три типа в зависимости от цели, которую преследует компания, отправляющая запрос:

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

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

3 тип: Оценка в часах по требованиям. Понятно из названия.

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

Рекомендуемые трудозатраты на оценку пресейлов

Так как оценка трудозатрат не является оплачиваемой работой (контракта-то еще нет), волевым решением определили, что на оценку требований будем тратить не более 2-х часов. Исключения составили только те пресейлы, которые считались наиболее вероятными к заключению контракта. Для этого перед оценкой руководитель пресейла экспертным путем оценивал его вероятность, либо аналитик бегло просматривал требования и мог заключить, наш/не наш это заказчик. Такое случалось достаточно часто, так как наше решение не было явно узкоспециализированным и область его применения можно было трактовать по-разному.

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

Тип пресейла: 1. Первоначальная оценка возможностей системы

Такой тип пресейлов характерен для самого первого запроса от заказчика, когда он ищет на рынке подходящие ему системы/продукты/платформы.

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

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

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

Тип пресейла: 2. Оценка реализуемости

Заказчик задает вам вопрос-вброс: "А можете это нам сделать?".

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

Тип пресейла: 3. Оценки в часах

Самый конкретный запрос - заказчик хочет понять, сколько ему будет это стоить.

----

Общие правила оценки

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

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

Оценка в часах для нового заказчика

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

Какие могли быть риски у нового заказчика:

• много заинтересованных сторон для принятия решений (долгий сбор требований и долгая приемка),

• собственные требования к документации,

• возможные личные визиты на сдачу/выяснение требований, присутствие на местах сотрудников на время опытной эксплуатации,

• требования к безопасности, итд.

На все это закладывался определенный процент рисков (от 20% до 40%), с учетом того, что после первоначальной оценки пойдет обсуждение и снятие части рисков.

Оценка по требованиям (в часах) для текущего заказчика

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

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

Оценку на обработку инцидентов считали как = общее количество потраченных часов по всем инцидентам (от заказчика) / количество заявок (от заказчика). Получится среднее количество часов на инцидент.  Далее оценивали примерное количество заявок от заказчика на предыдущих проектах с ним же.

Таким образом, в оценку по текущему заказчику мы включали также и все его особенности.

Оценки по ролям

Заказчик хочет понять «Почему так много?» (и это не первая итерация проработки оценок).

Ответ делился на две части:

• Конкретное описание, что будет сделано - достаточно детальное и понятное по бизнесу.

• Разбивка по ролям, кто сколько потратит на задачу.

Когда видно, какая роль будет делать какую часть от общего "пирога", иногда заказчик лояльнее принимает оценки по задаче.

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

Оценки тут я не привожу, у каждой компании, бизнеса и системы они будут свои.

Оценка по длительности

Если было совсем все непонятно, можно было оттолкнуться от занятости команды на год. В большом проекте с непонятными требованиями, частыми релизами или с работой по Time&Material команда мы считали, например, так:

РП - 0,3 чел

Аналитик - 1 чел

Разработчик - 2,5 чел

Архитектор - 0,7 чел

Тестировщик - 0,8 чел

Всего = 5,3 чел.

(Не целые значения - это частичное привлечение сотрудника, где-то он будет на 100% работать, а где-то на 0%).

Например, в среднем проект планируется длительностью 1 год, обычно включающий (очень грубо):

• 1,5 мес – проработка требований

• 8,5 мес – разработка

• 2 мес – опытная эксплуатация, внедрение

Т.е. по самым грубым подсчетам может получиться:

= 5,3чел*12мес*8ч*23дня = 11 702 часа.

Более точные оценки могли получиться, если бы учитывали этапность разработки проекта:

• 1,5 мес – проработка требований, участвует обычно РП (0,4 чел), аналитик (1 чел), архитектор (0,2 чел) = 1,6 чел*1,5мес*23*8 = 441 час;

• 8,5 мес – разработка (вся команда, но РП там 0,2 чел) = 5,2 чел*8,5мес*23дня*8ч = 8132 часа;

• 2 мес – опытная эксплуатация, внедрение (РП обычно задействован больше (0,5 чел); 1 аналитик, указанный тестер и часть команды разработки для исправлений ошибок (например, 1 чел), архитектор (0,5 чел)) = 3,8 чел*2*23*8ч = 1398 часов.

Итого в таком случае: 9 971 часов.

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

Вариация оценок min и max

Иногда заказчик просил оценить верхнюю и нижнюю границы в вариантах реализации. Т.е., например, можно разработать сервис загрузки данных из одной системы в другую (max), а можно оценить трудоемкость выгрузки в эксель из другой системы и полуручной перебивки данных в нашу (min).

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

Работа с неясным требованием

Иногда мы оказывались перед неприятной реальностью, что требование непонятное, а спросить, что имелось ввиду - не у кого. Тогда мы вывели для себя правило - предлагать два варианта реализации: удобный нам, простой сценарий и сложный сценарий. Далее мы оценивали оба сценария и выводили оценку по следующей формуле: (3* оценка простого сценария + 2*оценка сложного сценария)/5.

Что нужно было учитывать дополнительно

1. Требования к документированию. Иногда работы было на месяц разработки, а документы мы писали все три. Это сразу было видно либо в ТЗ, которое нам высылали для оценки, либо уже при обсуждении требований.

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

3. Активность заказчика и размер внедрения. Одно дело – когда в системе работают 10 человек. Другое – если система внедряется в 10 дочерних обществах с 100+ пользователями в каждой. Это разный уровень сопровождения, в том числе на опытной эксплуатации.

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

Итерационный подход после оценки требований

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

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

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

--

Но как же именно мы оценивали требования?

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

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