Аналитик мне не нужен, я сам знаю, какой продукт хочу!

Hola, Amigos!

Всем привет! Меня зовут Ася, я системный аналитик в IT-компании Amiga. Нередко приходится объяснять клиентам, зачем аналитик на проекте. Поэтому я решила раз и навсегда поставить точку в этом вопросе.

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

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

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

Как результат: перегруженный менеджер, плавающие сроки у проекта.

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

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

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

Как результат: увеличивается время на коммуникацию заказчика с исполнителем, повышается стоимость проекта при T&M.

По данным отчета The Standish Group, порядка 84% проектов заканчиваются неудачно из-за невнятных требований заказчика.

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

Первый вариант

Проект оценивается исходя из фичей и их описания, которые хочет заказчик.

Фича — совокупность функций, например, регистрация.

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

Второй пример

Либо с помощью требований. Они делятся на типы и виды по-разному, опять же в зависимости от школы, которой придерживается аналитик. Самое распространенное деление — на функциональные и нефункциональные требования.

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

Например, в первую часть документа поместить функциональные требования:

Во вторую часть документа поместить нефункциональные требования:

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

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

Пример из практики

Иногда аналитик участвует в проекте, когда его еще не существует. Как-то раз к нам пришел старый клиент с запросом «хочу корпоративный чат». Звучит легко, на деле возникает масса вопросов. В этом чате:

И еще миллион вопросов.

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

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

Аналитик не нужен, если:

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

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

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