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

Hola, Amigos! 

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

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

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

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

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

Заказчик: 

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

Аналитик: 

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

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

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

• Работу аналитика берет на себя менеджер проекта. Для него это дополнительная нагрузка, поэтому страдает качество проекта: многое не протоколируется, техническая документация ведется несвоевременно, актуализацией существующей документации заниматься некогда.
  Как результат: перегруженный менеджер, плавающие сроки у проекта.
• Нет четкого понимания архитектуры сервиса и согласованной документации. Клиент не видит общую картину проекта, какая функция будет разрабатываться на каком этапе. Баз фиксированных требований любое изменение вносит хаос в проект, так как изменением нельзя управлять.
  Как результат: недовольный заказчик, непопадание в изначальную оценку по срокам и стоимости, демотивированная команда — никому не хочется несколько раз переписывать код или перерисовывать макеты. Плюсом, никто не знает, что реализовано в системе, только разработчик, который непосредственно это делал.
•  Нет понятно описанных сценариев, которые учитываются при дизайне и разработке и описания проекта в целом. Поэтому возникают дополнительные вопросы и баги.
  Как результат: увеличивается время на коммуникацию заказчика с исполнителем, повышается стоимость проекта при T&M.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Всё, что связано с дизайном. Дизайн-макеты должны быть разработаны для разрешения 1280px. 
• Всё, что связано с безопасностью. Использование сложных паролей (заглавные, прописные символы, цифры). 
• Всё, что связано с кроссбраузерностью. Сайт должен корректно работать в следующих версиях популярных браузеров: Google Chrome 85+, Safari 13+, Mozilla Firefox 82+, Opera 70+, YandexBrowser 20+. 

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

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

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

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

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

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

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

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

Итог

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

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

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

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