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

Hola, Amigos!

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

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

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

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

Что делает аналитик?

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

Заказчик:

— Давайте в первом релизе сделаем чат, в котором можно 1) проводить конференции, 2) публиковать истории, 3) создавать ленту, 4) с темной и розовой темой.

Аналитик:

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

Оригинал картинки: vk.com/lepragram 
Оригинал картинки: vk.com/lepragram 

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

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

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

Оригинал картинки: texterra.ru/blog
Оригинал картинки: texterra.ru/blog

Что происходит на проектах без системного аналитика?

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

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

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

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

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

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

Немного статистики

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

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

Анастасия Бойкова, PM Amiga

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

Аналитик редко нужен на поддержке, но тот же одностраничный сайт может перерасти в огромную систему, поэтому лучше подключить специалиста сразу

Виталий Гришин, PM Amiga

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

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

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

Как оформить свои пожелания, чтобы получить максимально точную стоимость проекта?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

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

Ася Васильева
Системный аналитик
2929
14 комментариев

За такой вот диалог с заказчиком в стиле "Заткнись и не мешай нам работать, мы лучше тебя всё знаем", я бы аналитика уволил с проекта.

5

Добрый день!
Спасибо за комментарии, поясняю более подробно.

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

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

Если Вы считаете иначе, я была бы рада услышать Вашу точку зрения.

5

Думаю, что ключевой посыл - то, что аналитик может сказать "нет", и подготовить к такому исходу любого заказчика. Ну проиллюстрировано это кратко-лаконично-неформально, но смысл все уловили :)

2

Ну проиллюстрировано это кратко-лаконично-неформально, но смысл все уловилиЗа высказывания в духе "ну всем и так всё понятно, что тут усложнять" аналитика нужно еще раз уволить

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

Последовательность базовых артефактов в сис./бизнес анализе:
BRD - Scope^Vision - FSD - SRS

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

И шаблон BRD, который отдаётся заказчику и позже с ним валидируется - это must have. Иначе продолжите собирать требования в чатиках.

2

Аналитик - важный человек в команде. Порой очень много интересного и неожиданного раскапывает

2

Комментарий недоступен

1