Аналитик Евгений Васюков | Бизнес-анализ, системный анализ, требования

🧠 Техника «5 почему»: как докопаться до сути требования

Привет! Часто заказчик приходит с готовым решением: «Нужно добавить кнопку», «Сделайте отчёт», «Хотим интеграцию». Мы, аналитики, берём это в работу, а потом выясняется, что проблема была совсем в другом.
Есть простой инструмент, который помогает не строить не то, что нужно, — техника «5 почему». Суть: задавая последовательно вопрос «Почему?», мы спускаемся от поверхностного запроса к корневой причине.

Как это работает на примере:
Запрос: «Хотим новый отчёт по продажам».
1. Почему нужен этот отчёт?
— Чтобы видеть, какие товары продаются хуже.
2. Почему вы хотите это видеть?
— Чтобы решить, что закупать в следующем месяце.
3. Почему сейчас этого не видно?
— Потому что данные о продажах разбросаны по разным системам и их никто не сводит.
4. Почему их не сводят?
— Потому что нет единого справочника товаров, и данные не стыкуются.
5. Почему нет единого справочника?
— Потому что исторически закупки ведёт один отдел, а продажи — другой, и они не договорились о правилах.
🎓 Итог: истинная проблема — не отсутствие отчёта, а отсутствие единого справочника и договорённостей между отделами. Если бы аналитик сделал отчёт, проблема бы осталась. А так — можно предложить решение: сначала согласовать справочник, а потом уже строить отчётность.

Как использовать технику в работе:
▫️Не спрашивайте «почему?» механически.
Это не допрос. Важно понять логику, а не просто задать пять вопросов подряд.
▫️Останавливайтесь, когда дойдёте до корня.
Если ответ «так исторически сложилось» — это не корень, а отговорка. Копайте дальше.
▫️Фиксируйте цепочку.
Запишите все «почему» и ответы. Это поможет и вам, и заказчику увидеть картину целиком.
▫️Проверьте гипотезу. Убедитесь, что корневая причина действительно решает проблему. Иногда после трёх «почему» выясняется, что нужно просто объяснить пользователям, как работает текущая система.

🎓 Главный принцип: аналитик — не тот, кто записывает «хотелки». Это тот, кто помогает бизнесу понять, чего он на самом деле хочет.
Вопрос к вам: А вы используете «5 почему» в работе? Или есть свой способ докопаться до сути? 👇

#BA

🧑‍🏫 Зачем аналитику быть наставником

Привет! В аналитике часто говорят о развитии: как прокачать навыки, как вырасти до сеньора, как перейти в архитектуру. Но есть один аспект карьеры, который редко обсуждают, — наставничество. И зря.

Быть ментором — это не только альтруизм. Это один из самых мощных инструментов собственного роста.


❗Почему наставничество полезно именно вам:

▫️ Вы начинаете глубже понимать то, что объясняете
Пока вы объясняете джуну, как собирать требования, вы сами структурируете свои знания. Часто именно в момент объяснения вы находите пробелы в собственном понимании. Это как «резиновая уточка» для программиста — проговаривание вслух выявляет дыры в логике.

▫️ Вы учитесь задавать вопросы, а не давать ответы
Хороший ментор не даёт готовых решений. Он задаёт вопросы, которые помогают mentee самому найти ответ. Этот навык напрямую переносится на работу с заказчиками: вместо «вот решение» — «а как вы думаете, что будет, если…».

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

▫️ Вы укрепляете репутацию эксперта
Наставничество — это признак зрелости. Когда вы помогаете другим расти, коллеги и руководители видят в вас лидера, а не просто исполнителя.

▫️ Вы получаете энергию и мотивацию
Видеть, как человек растёт благодаря вашей помощи, — это мощный источник вдохновения. Особенно в моменты, когда собственная работа кажется рутиной.


🛠️ Как начать, если никогда не был ментором:

▫️Начните с малого
Не нужно сразу брать трёх джунов. Помогите одному коллеге разобраться в сложной теме.

▫️Спрашивайте, а не поучайте
«А как ты думаешь, почему так?», «А что будет, если…», «А какие варианты ты видишь?».

▫️Давайте обратную связь по фактам
Не «ты молодец», а «вот здесь ты хорошо проработал сценарии, а вот тут можно было уточнить критерии приёмки».

▫️Не бойтесь признавать, что чего-то не знаете
Это только укрепит доверие. «Я не сталкивался с этим, давай разберёмся вместе».


🎓 Важно: наставничество — это не про то, чтобы быть идеальным. Это про то, чтобы быть полезным. И это точно стоит попробовать.

Вопрос к вам: А у вас был опыт наставничества? Что вам это дало? Или, может, вы сами сейчас ищете ментора? 👇

#BA #SA #DA

🎬 Демо, которое не провалится: 5 правил подготовки

Привет! Демо — это момент истины. Вы месяцами собирали требования, писали ТЗ, согласовывали правки. И вот заказчик смотрит на результат. Если демо прошло плохо — неважно, сколько сил вы вложили. Осадок останется.

Вот 5 правил, которые помогают провести демонстрацию так, чтобы её приняли.

▫️ Показывайте не функции, а историю
Не «вот кнопка, вот форма, вот отчёт». А «представьте, менеджер заходит утром, видит новые заявки, нажимает сюда — и заказ уходит в обработку». Заказчику легче оценить сценарий, чем набор экранов.

▫️ Репетируйте заранее
Даже если вы уверены в системе, репетиция обязательна. Пройдите весь сценарий, проверьте, что все данные на месте, что переходы работают. В идеале — за день до демо, на том же стенде, на котором будете показывать.

▫️ Подготовьте ответы на неудобные вопросы
«А почему так долго?», «А если пользователь сделает вот так?», «А это можно поменять?». Заранее продумайте ответы. Не «мы не успели», а «это вынесено во второй этап, потому что…». Не «нельзя», а «можно, если…».

▫️Не показывайте сырое
Если что-то не готово — не показывайте вообще. Лучше сказать «это в работе, покажу на следующем демо», чем демонстрировать сломанный функционал. Одна ошибка на экране может перечеркнуть доверие ко всему остальному.

▫️Фиксируйте обратную связь сразу
Во время демо записывайте все замечания и вопросы. В конце проговорите: «Итак, что мы берём в работу, что откладываем, что уточняем». Это покажет, что вы слышите заказчика и управляете процессом.

🎓 Главное: демо — это не экзамен, а совместная работа. Ваша задача — не «защитить» решение, а показать, что оно решает проблему. Если заказчик видит, что вы на его стороне, он простит мелкие шероховатости.

Вопрос к вам: А какой приём помогает вам проводить демо без стресса? 👇

#BA #SA

🧾 Аналитический долг: невидимая цена быстрых решений

Привет! Мы все знаем про технический долг: когда код пишется быстро, с костылями, и потом его приходится переписывать. Но есть и аналитический долг — накопление некачественных, размытых или противоречивых требований, которые тормозят проект не меньше, чем плохой код.
О нём говорят реже, а зря.

Как выглядит аналитический долг:
▫️Требование написано «на скорую руку», потому что «надо было срочно».
▫️Допущение не зафиксировано: «Мы предполагаем, что данные придут в таком формате».
▫️Противоречие между двумя пунктами осталось незамеченным.
▫️Часть логики описана словами «ну, вы поняли».

Сначала это кажется мелочью. Но потом каждый такой «должок» превращается в часы уточнений, переделок и споров.

Почему он возникает:
▫️Давление сроков. «Некогда думать, надо делать».
▫️Иллюзия «потом доработаем». Потом не наступает никогда.
▫️Отсутствие ревизии. Требования накапливаются, но никто их не пересматривает.
▫️Страх признать, что чего-то не знаешь. Вместо уточнения — пишем общими словами.

Чем опасен аналитический долг:
▫️Растёт стоимость изменений. То, что можно было исправить за час на старте, через месяц требует недели.
▫️Команда теряет доверие к документации. «Там всё равно всё не так».
▫️Аналитик выгорает, потому что бесконечно тушит пожары, которые сам же и заложил.

Как уменьшать аналитический долг:
▫️Фиксируйте допущения явно. Если вы что-то предполагаете — напишите это. Даже если кажется очевидным.
▫️Проводите ревизию требований. Раз в спринт или перед крупным релизом пересматривайте: что устарело, что противоречит, что нужно уточнить.
▫️Не бойтесь возвращаться. Если требование оказалось неполным — вернитесь к нему, а не «замазывайте» на ходу.
▫️Введите «час на рефакторинг». Как в коде, только для документации. Обновите схемы, приведите в порядок формулировки.

🎓Главное: аналитический долг — это не приговор. Это просто сигнал, что пора немного замедлиться и навести порядок. Как и с техдолгом, его нельзя устранить навсегда, но можно держать под контролем.

Вопрос к вам: А вы замечали за собой или командой накопление аналитического долга? Как с ним боретесь? 👇

#BA #SA

🚩 5 красных флагов в вакансиях аналитика (на что смотреть до собеседования)

Привет! Поиск работы — это не только про вас, но и про компанию. Иногда уже на этапе чтения вакансии можно понять, что там что-то не так.

Делюсь своими «красными флагами», которые заставляют меня насторожиться.

▫️ «Аналитик-универсал» с огромным списком обязанностей
В вакансии перечислено всё: сбор требований, написание ТЗ, тестирование, поддержка пользователей, написание SQL-запросов, иногда даже разработка. Это признак того, что в компании нет чёткого разделения ролей, а аналитик — «человек-оркестр». Скорее всего, вы будете тонуть в задачах, которые не относятся к вашей зоне ответственности.

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

▫️ Отсутствие конкретики
«Участие в разработке требований», «взаимодействие с командами», «анализ данных» — общие фразы без деталей. Если не указано, какие задачи, с кем работа, какие инструменты, — есть риск, что и внутри всё так же размыто.

▫️ «Сможете ли вы работать в условиях неопределённости?»
Этот вопрос на собеседовании часто означает: «У нас нет процессов, документации и понимания, что делать. Выживешь — молодец». Неопределённость — часть нашей работы, но когда она возведена в культ, это выгорание.

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

🎓 Что делать?
Не бойтесь задавать уточняющие вопросы на собеседовании: «Как выглядит типичный рабочий день?», «Какие процессы уже выстроены, а какие в планах?», «Кто будет моим основным стейкхолдером?». Ответы многое скажут.

Вопрос к вам: А какие «красные флаги» в вакансиях вы замечали? Делитесь в комментариях — соберём чек-лист для тех, кто в поиске! 👇

#BA #SA #DA

🛠️ Карта переходов состояний (FSM) против BPMN: что выбрать для описания логики?

Когда ко мне приходит бизнес с задачей описать сложный процесс, первый порыв — открыть Miro/Camunda и нарисовать красивую BPMN-схему. Но всегда ли это эффективно для разработки?

Мой личный гайд по выбору инструмента:

▫️BPMN
Идеально, когда нужно показать процесс сквозным образом между отделами, системами и людьми. Понятно заказчику, подсвечивает узкие места.

▫️FSM / Таблица переходов
Незаменима, когда мы опускаемся на уровень бэкенда и базы данных. Если у вас есть объект (например, «Заказ») с 15 статусами и кучей валидаций, таблица [Текущий статус] -> [Триггер] -> [Проверки] -> [Новый статус] сэкономит разработчикам тонну времени.

🎓 Главное: Бизнесу — картинки (BPMN), разработке и QA — строгую логику переходов состояний (FSM).

Вопрос к вам: Каким инструментом чаще пользуетесь для визуализации логики статусов вы?

#BA #SA #DA

🧩 Как работать с несколькими проектами

Привет! Работа аналитика часто похожа на жонглирование: один проект на этапе сбора требований, второй — на согласовании, третий — уже в разработке и требует уточнений. И всё это одновременно.
В какой-то момент кажется, что ты везде опаздываешь, ничего не успеваешь, а голова превращается в хаос. Знакомо?

Вот несколько принципов, которые помогают мне удерживать несколько проектов и не сойти с ума.

▫️.Разделяйте контексты, а не задачи
Мозгу сложно переключаться между проектами каждые 15 минут. Вместо того чтобы метаться, выделите блоки: утро — проект А, после обеда — проект Б, вечер — проект В. Даже если это не всегда возможно, старайтесь минимизировать переключения в течение дня.

▫️. Ведите единый список задач по всем проектам
Не держите в голове, что нужно сделать по каждому проекту. Записывайте всё в одно место, но помечайте тегами: #проект_А, #проект_Б, #срочно, #потом. Так вы видите общую картину и не забываете важное.

▫️.Учитесь говорить «нет» или «позже»
Когда вас просят срочно подключиться к новой задаче, а у вас уже три проекта, — это не повод героически взять всё. Спросите: «Что из текущего я могу отложить, чтобы взяться за это?». Пусть решение о приоритетах принимает тот, кто ставит задачу.

▫️.Используйте «правило одного касания»
Если задача занимает меньше 2 минут — делайте сразу. Если больше — записывайте и возвращайтесь к ней в специально выделенное время. Это спасает от постоянного «ой, я забыл».

▫️. Защищайте время для глубокой работы
Даже при нескольких проектах нужно время, чтобы сосредоточиться на сложной задаче без отвлечений. Поставьте в календаре «неприкасаемый» час и скажите команде, что в это время вы недоступны. Это не эгоизм, это условие качественной работы.

▫️. Раз в неделю проводите «разбор полётов»
В конце недели уделите 15 минут, чтобы просмотреть статус по всем проектам: что сделано, что горит, что можно делегировать или отложить. Это помогает не накапливать хаос.

🎓Главное: многозадачность — это не про то, чтобы делать всё сразу, а про то, чтобы управлять вниманием и приоритетами. Не пытайтесь быть везде и сразу. Лучше сделать меньше, но качественно.

Вопрос к вам: А сколько проектов вы ведёте одновременно? И какой приём помогает вам не сойти с ума? 👇

#BA #SA #DA

🌱 Право на ошибку: почему культура экспериментов важнее безупречности

Привет! В аналитике часто царит культ «правильности». Мы боимся ошибиться, потому что ошибка = проблемы, переделки, потеря доверия. Но есть одна вещь, которую мы упускаем: если мы никогда не ошибаемся, значит, мы никогда не пробуем новое.

Как создать среду, где ошибки — не катастрофа, а часть процесса?
▫️. Ошибки — это источник данных
Каждая ошибка содержит информацию: что пошло не так, почему, как это исправить. Если вы скрываете ошибки или боитесь их признать — вы теряете ценные данные. В хорошей команде разбор ошибок — это рутина, а не трибунал.
▫️Ошибки на ранних этапах дешевле
Если вы ошиблись в требованиях — это можно поправить за часы. Если ошибка ушла в разработку — за дни. В тестирование — за недели. В продакшен — за месяцы. Чем раньше вы допустили ошибку и признали её, тем дешевле её исправить.
▫️ Ошибки показывают границы
Вы не знаете, где проходят границы системы, пока не наткнётесь на них. Вы не знаете, насколько гибко решение, пока не попробуете его сломать. Иногда ошибка — это единственный способ понять, где ваше решение перестаёт работать.
▫️Ошибки — это топливо для обучения
Знаете, что лучше всего запоминается? Ошибки, на которых вы учились. Если вы никогда не ошибались — вы просто не выходили из зоны комфорта.

Как внедрить культуру экспериментов в свою работу:
▫️Фиксируйте не только успехи, но и провалы.
Ведите журнал ошибок — что пошло не так, почему, что сделали, чтобы исправить. Это не для отчёта, а для себя и команды.
▫️Обсуждайте ошибки на ретроспективах.
Не «кто виноват», а «что мы поняли из этого опыта».
▫️Предлагайте гипотезы вместо «готовых решений».
Вместо «мы сделаем так» говорите «мы попробуем такой вариант. Если не сработает — скорректируем». Гипотезу легче отменить, чем решение.

🎓Важно: право на ошибку не означает безответственность. Это означает ответственность за извлечение уроков и недопущение повторения той же ошибки дважды.

Вопрос к вам: А как у вас в команде относятся к ошибкам? Есть культура экспериментов или страх ошибиться? 👇

#BA #SA #DA

🚩 5 признаков, что проект токсичный (и что с этим делать)

Привет! Не все проекты одинаково полезны для карьеры и психики. Бывают проекты, где всё идёт не так с самого начала, но вы продолжаете тянуть, потому что «ну надо», «обещал», «неудобно уйти».

Вот 5 признаков, что проект уже токсичный — и пора что-то менять.

▫️Требования меняются быстрее, чем вы их записываете
Это не «гибкость», это хаос. Если заказчик не может определиться, а вы переписываете одно и то же в третий раз без видимого прогресса — проект в зоне риска.
Что делать: Договориться о «заморозке» требований на спринт. Все изменения — в следующий спринт.

▫️ Вас постоянно дёргают по мелочам
Каждые 15 минут — вопрос в чат, срочное уточнение, «а можно глянуть?». Вы не можете сосредоточиться на глубокой работе.
Что делать: Ввести правило «вопросы — один раз в день, в определённое время». Объяснить команде, что это нужно для качества работы.

▫️ Вы чувствуете себя виноватым даже тогда, когда всё идёт нормально
Постоянное ощущение, что вы что-то не доделали, что-то упустили, что вы недостаточно хороши. Это не профдеформация, это признак нездоровой атмосферы.
Что делать: Записывать свои успехи и достижения. Если ощущение вины не проходит — поговорить с руководителем.

▫️Вы не видите результата своей работы
Проходят недели, месяцы — а проект всё на стадии «почти готово». Нет релизов, нет обратной связи, нет ощущения завершённости.
Что делать: Договориться о промежуточных релизах. Любой результат лучше никакого.

▫️Заказчик (или команда) постоянно обесценивает вашу работу
«Мы это сами могли сделать», «Ну, это же просто», «Почему так долго?» — звучит знакомо? Если уважения нет, то и результата не будет.
Что делать: Честно поговорить. Если не помогает — обсуждать дальнейшее участие в проекте.

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

Вопрос к вам: А по каким признакам вы определяете, что проект «не ваш»? 👇

#BA #SA #DA

🔄 Когда требования нужно менять (и это нормально)

Привет! Многие считают, что изменения требований — это всегда проблема. Что идеальный аналитик должен всё предвидеть и зафиксировать с первого раза. Но реальность другая: иногда изменения — не ошибка, а признак того, что проект живёт и развивается.
Вопрос не в том, изменяются ли требования, а в том, как вы с этим работаете.

Вот 3 сценария, когда изменение требований — это правильно.

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

▫️Изменился бизнес-контекст
Законодательство поменялось. Рынок сдвинулся. Появился новый конкурент. Если бизнес адаптируется — требования тоже должны адаптироваться. Игнорирование внешних изменений — путь к устаревшему продукту.

▫️Появилось лучшее техническое решение
Разработчик предлагает более эффективный способ реализации, который меняет часть требований. Это не «нарушение договорённостей», а улучшение продукта. Если вы настаиваете на старом решении только потому, что «так записано» — вы вредите проекту.

Но! Есть разница между осознанными изменениями и хаосом. Чтобы изменения не превращались в проблему:
▫️Фиксируйте причину изменения. Не просто «передумали», а «изменились условия на рынке».
▫️Оценивайте влияние. На сроки, бюджет, другие требования.
▫️Согласовывайте с командой. Не в одиночку, а вместе с разработчиками и заказчиком.

🎓 Главное: требования — это не памятник. Это рабочий инструмент. Если инструмент перестал подходить — его можно и нужно менять.

Вопрос к вам: А как вы отличаете «полезные» изменения от «вредных»? 👇

#SA

🕳️ 5 ошибок, которые убивают проект на старте (и как их не совершить)

Привет! Часто проекты разваливаются не в середине или в конце, а в самом начале — когда закладываются основы. Ошибки на этапе инициации или первичного анализа могут стоить недель (или месяцев) переделок.
Вот 5 самых распространённых из них — и как их избежать.

▫️ Начинать решение, не поняв проблему
Заказчик говорит: «Нам нужен отчёт по продажам». Команда начинает делать отчёт. А проблема была в том, что менеджеры не видели динамику и не могли планировать. Отчёт — это решение. Проблема — отсутствие видимости. Если начать с решения, можно сделать не то, что нужно.
Как избежать: До того как предлагать решение, задайте 3 вопроса: «Что именно вас не устраивает?», «Как вы сейчас решаете эту задачу?», «Что вы хотите увидеть/получить в итоге?».

▫️ Игнорировать молчаливых стейкхолдеров
Обсудили требования с директором, подписали ТЗ. А когда начали разрабатывать, выяснилось, что у операторов своё видение. Или у смежного отдела. Документ подписан, но работать по нему невозможно.
Как избежать: Составьте список всех, кто будет касаться системы. Не только «руководители», но и «пользователи», «поддержка», «смежные отделы». Поговорите с ними до того, как утвердите требования.

▫️ Не фиксировать допущения
«Мы исходим из того, что данные будут приходить раз в день», «Мы предполагаем, что максимальная нагрузка — 100 пользователей». Если эти допущения не записаны — они превращаются в «а мы это не обсуждали» в самый неподходящий момент.
Как избежать: Заведите в спецификации раздел «Допущения и ограничения» и записывайте туда всё, что вы принимаете как данность без проверки.

▫️Обещать сроки, не разобравшись в задаче
Менеджер спрашивает «когда будет анализ?», а вы ещё не видели систему. Называете «3 дня». А оказывается, что доступ к данным дадут через неделю, а ключевой эксперт ушёл в отпуск.
Как избежать: Говорите не «сделаю за 3 дня», а «я смогу оценить сроки после того, как получу доступ к базе. Предварительно — от 3 до 7 дней». И всегда добавляйте буфер на неожиданности.

▫️Делать всё в одиночку
Аналитик погружается в задачу, собирает требования, пишет ТЗ, никого не вовлекая. А потом выясняется, что разработчики видят решение иначе, а заказчик имел в виду другое.
Как избежать: Показывайте промежуточные результаты: схему, набросок требований, список вопросов. Вовлекайте команду и заказчика на ранних этапах. Это не замедляет, а ускоряет — потому что снимает вопросы до того, как они превратятся в проблемы.

Суть: 80% проблем проекта закладываются в первые 20% времени. Чем тщательнее вы пройдёте старт, тем меньше будет переделок потом.

Вопрос к вам: А какая ошибка из этого списка вам знакома? Или, может, у вас есть своя «фирменная» грабля, на которую наступали не раз? 👇

#BA #SA