Как оценка этапа аналитики влияет на сроки реализации всего проекта

Сколько времени займет реализация проекта и какой бюджет потребуется? Эти два фундаментальных вопроса остро встают перед владельцами бизнеса на этапе принятия решения о разработке или доработке системы. За ответами заказчик идет к команде, которая озвучивает ему некую величину человеко-часов, и на ее основе рассчитывается стоимость проекта. Откуда берется эта цифра? Учитывает ли она текущее положение проекта, его задачи и цели, бизнес-процессы заказчика, границы системы и сценарии ее использования, внешние факторы и риски, которые могут возникнуть? 

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

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

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

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

Точно не имеет смысла проводить полноценную аналитику сразу, если:

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

Если хоть один из этих пунктов про вас, подойдет другой путь. О нем и пойдет речь ниже. Но и на нем вас встретит аналитик.

Всегда сначала аналитика

Разработка любой системы начинается с аналитики. Если лет 10 назад аналитик был скорее диковинкой на проекте, а разработчики реализовали систему «со слов» заказчика, то с ростом сложности и размеров проектов аналитик — это уже обязательная роль в команде. При этом до сих пор встречаются команды, где роль аналитика берет на себя ПМ, разработчик или специалист со стороны заказчика, ответственный за автоматизируемый бизнес-процесс. В других командах аналитик — не просто отдельный человек, а целая группа специалистов, каждый из которых ответственен за свой участок: бизнес-аналитик, системный аналитик, аналитик по интеграциям и т.д.

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

Как разработке предшествует аналитика, так и оценке разработки предшествует оценка этапа аналитики. Этот этап позволяет:

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

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

Основная сложность оценки заключается в том, что специалисту приходится иметь дело с системой, с которой он знаком со слов заказчика или на основании некоторой документации. В любом случае 1-3 дня, отведенные на оценку, — не тот срок, за который человек может погрузиться в проект, узнать все его подводные камни и «провести аналитику», не проводя ее.

4 критерия успешной оценки

Как аналитику оценить проект, о котором он мало знает, а главное — как заказчику доверять такой оценке? Для этого должны быть выполнены как минимум четыре условия:

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

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

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

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

Если к вам на проект подключится опытный аналитик, который проведет фазу аналитики за 75% от оценочного времени — отлично, сможете быстрее начать разработку. Менее опытному специалисту придется приложить больше усилий, чтобы вписаться в указанную оценку с учетом резерва на риски, но для него это станет челленджем и точкой роста. Этого не стоит бояться, поскольку вполне вероятно, что для решения ваших задач не нужен дорогостоящий senior. 

3. Оценка не должна содержать лишнего. Артефакты проекта должны иметь баланс. Их должно быть ровно столько, сколько достаточно для разработки и согласования. Конечно, можно описать «каждую запятую» на проекте вдоль и поперек, но это может существенно замедлить выход продукта на рынок (time to market). Соответственно, состав фазы аналитики может меняться от проекта к проекту. 

Фаза аналитики — отдельная группа работ, включающая в себя задачи, объединенные одной тематикой. Например, «Сбор требований», «Техническая документация» и т.п. 

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

Парадоксально, но бывают случаи, когда владелец продукта пытается занизить оценку. Например, заявляя, что на внутреннюю систему, с которой нужно интегрироваться системе, есть API-документация. Специалист оценивает эту задачу как легкую и ставит, например, 6 часов. В процессе реализации этапа аналитики выясняется, что документация отсутствует. В результате аналитику придется потратить время еще и на то, чтобы разобраться с интегрируемой системой. Скорее всего, это потребует и участия разработчика. Таким образом, время на этапы аналитики и разработки вырастет. В результате страдает time to market.

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

Как ИТ-компании обеспечивают соблюдение этих условий

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

1. Люди: кто и как проводит оценку

Рассказываем, как мы организовали работу группы оценки. Это был долгий процесс, в котором учитывали многолетний опыт оценки продуктовых проектов. Мы попытались создать максимально универсальную, стандартизированную, но достаточно гибкую систему. Сейчас группа оценщиков объединяет 25 практикующих аналитиков уровня middle+ и выше. В этой команде я всегда могу найти эксперта с любой специализацией (системный анализ, бизнес-анализ) и экспертизой в разных предметных областях (финтех, фудтех и т.д.), с опытом аналитики разных систем (CRM, ERP, интернет-магазины, мобильные приложения) и работы с различными инструментами.

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

Действующих оценщиков всегда стараюсь держать «в тонусе»:

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

2. Наличие инструментов и стандартов

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

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

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

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

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

3. Опыт проведения предпроектных исследований

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

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

Выводы

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

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

Главное — помнить, что оценка проекта предполагает сотрудничество между бизнесом и оценщиком. И заказчик, и исполнитель заинтересованы в том, чтобы система удовлетворяла требованиям бизнеса, его целям, time to market и бюджету. Без этого проект просто не состоится. Чтобы реальность соответствовала этим ожиданиям, оценка должна быть качественно проведена. Фундамент для оценки проекта — оценка этапа аналитики. Чтобы преодолеть неопределенность и довести проект до нужного результата, обе стороны должны приложить максимум усилий.