Как применять аналитические техники в реальных проектах

Привет, Хабр! С вами Диана, системный аналитик в АШАН ТЕХ. В прошлых постах я писала о том, как училась системному анализу, готовилась к собеседованиям и не выгорела в процессе.
Но после выхода на реальную работу возникает другой вопрос: как применять все эти знания не в учебном кейсе, а в живом проекте?
Короткий ответ — не так аккуратно, как в обучении.
Чем работа отличается от обучения
В обучении почти всегда есть понятное задание и ожидаемый результат.
В реальной работе даже при наличии бизнес-требований (БТ) всё может быть иначе: документ устарел, написан под старую логику или не отражает реальные пользовательские сценарии.
Поэтому аналитик чаще работает не «по документу», а с проблемой, которую ещё нужно правильно сформулировать.
С чего на самом деле начинается задача аналитика
Задача редко приходит в идеальном виде.
Обычно есть БТ, которое:
требует актуализации;
противоречит текущей логике системы;
не учитывает ограничения или реальные сценарии.
Иногда аналитик сначала формулирует требования буквально для себя, чтобы разобраться, в чём вообще задача.
Дальше начинается обсуждение с бизнесом: целей, ожиданий, допущений. Иногда — сразу с несколькими стейкхолдерами.
Как я структурирую хаос
Когда информации много, а ясности мало, я делаю довольно простые вещи:
фиксирую всё, что уже известно;
выписываю вопросы и противоречия;
уточняю цель и ограничения;
формулирую рабочую версию требований.
Это не финал, а отправная точка для обсуждений и проверки гипотез.
Правила, которые мне сильно помогли на онбординге
Когда я только пришла в компанию и проходила онбординг, наставник поделился простыми, но очень практичными правилами. Со временем я поняла, что они применимы почти к любой задаче.
Обратная совместимость всегда важна. Бэк — раньше фронта. Любые изменения стоит рассматривать с точки зрения того, что уже работает в проде и кем это используется.
Ко всему нужно относиться критично. Даже если требование звучит логично, полезно задать вопрос: а зачем это? какую проблему решаем? что будет, если ничего не менять?
Всегда думать про альтернативные сценарии. Что пойдёт не так? А если пользователь сделает иначе? А если данные придут не в том виде? Эти вопросы часто экономят команде время на доработках.
Формирование ТЗ: «бизнес сказал» и «разработчик знает» — плохая основа
Сделать хорошее техническое задание (ТЗ), общаясь только с заказчиком, сложно.
Но и ожидать «того самого разработчика, который всё знает», — плохая стратегия.
Такой подход:
увеличивает время на задачу;,
создаёт бутылочное горлышко;
концентрирует знания в одной голове.
Гораздо эффективнее вовлекать разработчиков ещё на этапе формирования ТЗ.
Итог
Аналитика — это не шаблоны и диаграммы.
Это умение уточнять и структурировать, работать с бизнесом и командой, видеть риски и альтернативные сценарии, аргументировано защищать решения.
P.S.
На этом можно было бы закончить, но реальная работа аналитика подкидывает столько нюансов, что в один пост всё явно не уместить.


