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

Hola, Amigos!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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