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

Hola, Amigos!

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

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

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

1. Классифицирует желания клиента в различные требования к системе. Помогает заказчику понять, какие требования приоритетны, а какие можно отложить в стол до следующих релизов.
2. Следит, чтобы заказчик и разработчики понимали, какой продукт должен получиться. Например, какая бизнес-логика прослеживается в системе.
   
3. Не дает заказчику делать всё, что заблагорассудится. Особенно, когда бизнес-заказчик и владелец продукта — два разных человека. Эту функцию можно проиллюстрировать вот таким диалогом из практики:

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

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

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

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

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

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

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

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

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

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

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

• Vision или документ о границах системы описывает в общих чертах систему: зачем она нужна, что будет делать и какие проблемы решать.
• Техническое задание — документ, который будет передан разработчикам, описан в рамках российских ГОСТов, используется в основном с государственными заказчиками, т.к. слишком бюрократизирован.
• Спецификация — аналог технического задания, но без привязки к ГОСТам, может писаться в специальных сервисах вроде Википедии, но на уровне компании. Содержит требования к системе, подробное описание функций, модель данных и прочее.

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

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

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

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

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

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

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

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

1. На сайте пользователь может воспользоваться калькулятором ипотеки.

2. На сервисе пользователь может воспользоваться поиском, система будет искать введенные данные на сайте и на архивированных страницах.
3. На сайте будут размещены вакансии с hh.ru. При нажатии «Откликнуться» пользователь переходит на сайт с размещенной вакансией.
4. На сайте можно изменять страницы с товаром, можно добавлять, редактировать и удалять новости и достижения.

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

1. Всё, что связано с дизайном. Дизайн-макеты должны быть разработаны для разрешения 1280px.

2. Всё, что связано с безопасностью. Использование сложных паролей (заглавные, прописные символы, цифры).
   

3. Всё, что связано с кроссбраузерностью. Сайт должен корректно работать в следующих версиях популярных браузеров: Google Chrome 85+, Safari 13+, Mozilla Firefox 82+, Opera 70+, YandexBrowser 20+.

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

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

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

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

• Будут общие группы или только личные сообщения?
• Как будут добавляться новые пользователи? Через администратора компании или сами?
• Будут боты?
• Можно отправлять файлы в чат? А какую защиту для них хотите предусмотреть?
• Видеозаписи будете отправлять?

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

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

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

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

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

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

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