Коллеги, привет!
Ранее мы разобрались, что такое метод наблюдения, чем он отличается от интервью и опросов, и какие виды наблюдения существуют. Теперь переходим к самому важному: как применять этот метод на практике и не разочароваться в результатах.

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

Плюсы метода наблюдения

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

➕️ Наблюдение позволяет обнаружить так называемые скрытые требования. Пользователи часто не осознают, что их обходные пути, ручные операции или стикеры на мониторе - это не особенности их рабочего стиля, а сигналы о несовершенстве системы. Эти неформализованные практики редко всплывают в ходе интервью, но именно они дают наиболее ценные данные для улучшения продута

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

➕️ Наконец, наблюдение позволяет фиксировать непроизвольные эмоциональные реакции. Замешательство, раздражение, облегчение - эти проявления сложно имитировать или скрыть, и они служат надёжными маркерами проблемных зон.

Минусы и ограничения

➖️ При всех своих достоинствах наблюдение остаётся одним из самых ресурсоёмких методов. Один час наблюдения требует как минимум двух часов на расшифровку и анализ. Если выборка пользователей велика, бюджет времени может оказаться неприемлемым.

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

➖️ Существует и риск субъективной интерпретации. Наблюдение отвечает на вопрос «что происходит?», но не на вопрос «почему?». Пауза в работе может означать и глубокую аналитическую деятельность, и потерю ориентации в интерфейсе, и просто усталость. Без последующего уточнения трактовка остаётся гипотетической.

➖️ Кроме того, не во все процессы можно погрузиться напрямую. Работа с персональными данными, врачебная деятельность, режимные объекты - в этих сферах наблюдение либо невозможно, либо требует длительных согласований.

---

Продолжение ⬇️

Практические рекомендации: как проводить наблюдение эффективно

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

Шаг 1. Подготовка

▪︎ Сформулируйте конкретную цель наблюдения. «Понаблюдать за бухгалтерами» - плохая цель. «Выявить, на каких операциях при закрытии периода возникают задержки и чем они вызваны» - хорошая.

▪︎ Согласуйте доступ. Получите разрешение руководства и обязательно объясните участникам, что ваша задача - улучшить систему, а не оценивать их компетентность. Люди должны чувствовать себя спокойно, иначе данные будут искажены.

▪︎ Подготовьте инструменты фиксации. Блокнот и ручка остаются самым ненавязчивым вариантом. Если планируете вести аудиозапись или снимать экран, запросите отдельное согласие и объясните, как будут использоваться эти материалы.

▪︎ Разработайте структуру для записей. Это не обязательно жёсткий чек-лист, но хотя бы мысленный план: какие категории действий вы фиксируете, на что обращаете внимание, какие вопросы откладываете для уточнения.

Шаг 2. Проведение

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

▪︎ Записывайте временные метки ключевых операций. Даже приблизительный хронометраж даст позже объективную основу для приоритизации проблем.

▪︎ Обращайте внимание на невербальные реакции. Вздохи, хмурый взгляд, удивлённо поднятые брови - фиксируйте эти моменты, они укажут на зоны дискомфорта точнее любых слов.

Шаг 3. Анализ и верификация

▪︎ Сразу после наблюдения выделите время на обработку записей, пока детали свежи в памяти. Дополните сокращения, расшифруйте неразборчивые пометки, зафиксируйте возникшие гипотезы.

▪︎ Обязательно проведите уточняющее интервью с участником. Покажите свои записи и задайте вопросы: «Я заметил, что здесь вы сделали паузу. С чем это было связано?», «Вы использовали сторонний калькулятор - почему не встроенный?». Именно на этом этапе вы переходите от наблюдения к пониманию.

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

---
И в заключении:

Метод наблюдения даёт уникальную возможность увидеть реальную картину работы пользователей без фильтров и искажений. Однако его применение оправдано только в связке с другими инструментами.

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

Наблюдение не заменяет разговор с пользователем — оно делает этот разговор осмысленным и предметным. Именно в этом сочетании метод раскрывает свой полный потенциал.

Пробуйте, адаптируйте под свои проекты и обязательно фиксируйте, какие подходы работают именно в вашем контексте.

#теоретическиезаметки | @notes_analyst

​​25 железных правил проектирования баз данных в PostgreSQL

В статье приведены 25 правил, которые Автор собрал из опыта работы с высоконагруженными системами. Это не теория из учебника — это грабли, на которые уже наступили до вас. Каждое правило сопровождается примером «как надо» и «как не надо», чтобы разница была наглядной.

Читать статью

​​📑 Как определить границы бизнес-процесса: 3 совета для начинающих аналитиков

Автор - Анна Вичугова:
"Описать бизнес-процесс невозможно без определения его границ. Поэтому сегодня рассмотрим, что такое границы бизнес-процесса, зачем их определять и как это сделать максимально просто и эффективно. Рекомендации начинающим аналитикам, на что обратить внимание при описании бизнес-процесса и разработке целостной системы иерархически связанных процессных блоков, чтобы комплексно описать всю деятельность предприятия."

Читать статью

​​Декомпозируем систему и проектируем устойчивую микросервисную архитектуру

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

Читать статью

​​Сравнение LLM по навыку анализа бизнес-процессов

Автор - Андрей Бугаенко:
"Всё чаще аналитики бизнес-процессов используют LLM для поиска неэффективностей. Звучит логично: большие языковые модели умеют искать паттерны, а Process Mining как раз об этом. Но на практике результаты пляшут так, что становится понятно: не все LLM одинаково полезны для операционной аналитики. Решил разработать методологию тестирования LLM на предмет релевантности использования для задач анализа процессов."

Читать статью

📑 Как выжить в срочном проекте: тушим пожар и не сгораем сами

Автор - Дмитрий Кислов, системный аналитик в команде автоматизированной банковской системы в ПСБ:
"Рано или поздно каждый ИТ-специалист сталкивается с ситуацией, когда бизнес ставит почти невыполнимую задачу с жёстким дедлайном. Как тут не вспомнить старую шутку: «Можно ли заставить 9 женщин родить ребёнка за один месяц?». Ответ очевиден — нет, законы природы (и разработки) не обманешь.

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

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

Читать статью

​​SQL для ритейла: пример 5 задач, которые я решала как аналитик ассортимента

В статье на примере пяти реальных задач из ритейла показывается, как аналитик ассортимента использует SQL для работы. Автор делится опытом, как с нуля (без технического бэкграунда) освоила язык для решения практических вопросов: анализа товаров, категорий, продаж и поставок. Статья доказывает, что SQL — логичный и мощный инструмент для извлечения данных, а не просто абстрактный навык из требований вакансий.

Читать статью

​​📑 Архитектура и GraphQL

Автор - Татьяна Сальникова:
"В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдём к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.
Архитектура GraphQL отличается от традиционных REST API. Вместо множества эндпоинтов используется единая точка входа. Это создаёт уникальные вызовы: как организовать код, обеспечить производительность, масштабировать систему и интегрировать различные источники данных."

Читать статью

​​Применение модели C4 в работе системного аналитика

Автор - Яна, старший системный аналитик в компании «Совкомбанк Технологии»:

"Если говорить про проектирование, то многие вспомнят язык моделирования UML (Unified Modeling Language) с его разнообразием диаграмм. В этой статье расскажу еще об одном, менее популярном, но не менее удобном подходе к описанию архитектуры – модели C4. Она позволяет системно и последовательно визуализировать архитектуру на разных уровнях детализации.

Далее рассмотрим, как системный аналитик может использовать C4 в повседневной работе, какие уровни модели наиболее полезны и какую практическую ценность это приносит команде."

Читать статью

Виды моделирования данных. Полный гайд

"Спроси любого уважаемого аналитика или инженера данных о том, какие бывают способы моделирования данных, тебе ответят: звезда, 3NF и DataVault. Спроси ИИ, получишь примерно такой же ответ. Придешь на какой-нибудь проект в компанию, также скорее всего встретишь там кого-нибудь из этих друзей. В 90% материалах про методологии моделирования освещаются только эти трое. Как будто других методологий не существует.

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

Читать статью

​​Как построить карьеру системного аналитика в банке: от junior-анализа до лида

Автор - Александр, работает в Центре компетенции аналитики в команде РСХБ.Цифра:
"Мы отвечаем не только за реализацию конкретных функций, но и за развитие методологий и подходов, которые помогают командам банка работать более эффективно над продуктом «Свои финансы». В этом материале поделюсь мыслями о том, как строить карьеру системного аналитика в банковской сфере, дам практические рекомендации новичкам и тем, кто только задумывается о карьере в этой области. "

Читать статью

​​Domain-Driven Design: полный гайд по моделированию домена в 2026 году

Автор - Сергей Прощаев:
"Сегодня предлагаю обсудить тему проектирования. Представьте ситуацию: у вас есть, казалось бы, простой микросервис пользователей. Через полгода в нём 30 таблиц, логика размазана по сервисам как масло по горячему тосту, а на вопрос «почему при подтверждении email падает заказ?» никто не может дать ответ, не открыв IntelliJ и не продравшись через пять часов дебага.

Знакомо? Наверное многие через это проходили. И каждый раз причина была одна: мы не договорились о том, что на самом деле делает система. Мы думали таблицами и классами, а не бизнес-процессами. Именно здесь на сцену выходит Domain-Driven Design (DDD).

Не буду грузить вас теорией Эванса и Вернона страницами. Вместо этого я покажу, как DDD реально помогает не выстрелить себе в ногу, когда проект разрастается."

Читать статью

Коллеги, привет! 👋

Мы продолжаем разбирать инструменты сбора требований. Сегодня на очереди - воркшоп (Requirements Workshop). Метод, который требует подготовки и дает мощный результат в сжатые сроки.

Воркшоп - это структурированная групповая встреча, на которой ключевые стейкхолдеры под руководством фасилитатора совместно вырабатывают и согласовывают требования.

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

Хороший воркшоп строится по четкой структуре:

1. Открытие: объявление целей, знакомство, правила работы
2. Разогрев: короткая активность для вовлечения участников
3. Анализ текущей ситуации (AS-IS): фиксация болей и проблем
4. Проектирование будущего (TO-BE): генерация идей, прототипирование, моделирование
5. Приоритизация: отбор самого важного в реализацию
6. Закрытие: подведение итогов, фиксация договоренностей

Обязательные элементы между блоками - перерывы. Кофе-брейки дают возможность неформального общения и снижают усталость от интенсивной работы.

Плюсы метода (+)

➕ Высокая скорость согласования. Разногласия между участниками снимаются в моменте. Не нужно ждать ответов на письма дни и недели.
➕ Единое понимание задачи. Все уходят с встречи с одинаковым видением результата. Исключается ситуация, когда заказчик и команда говорят об одном и том же, но подразумевают разное.
➕ Вовлеченность заказчика. Когда представители бизнеса сами рисуют процессы и правят прототипы, они чувствуют сопричастность и берут ответственность за результат.
➕ Быстрая проверка гипотез. Аналитик может сразу скорректировать свое понимание, получив обратную связь от экспертов.

Минусы метода (-)

➖ Высокая стоимость. Собрать нескольких ключевых экспертов компании на полдня - серьезная инвестиция ресурсов.
➖ Сложность организации. Найти общее время в плотных календарях занятых людей непросто.
➖ Зависимость от качества фасилитации. Без опытного ведущего встреча рискует превратиться в хаотичный флуд или, наоборот, в скучную лекцию.
➖ Риск доминирования одного мнения. Если в группе есть авторитарный лидер, он может подавить остальных, и реальные требования останутся незамеченными.

Когда использовать воркшоп?

✅ Подходящие ситуации:

▪️︎ Запуск нового проекта, нужно определить границы и ключевые требования
▪️︎ Наличие противоречий между отделами по поводу бизнес-процессов
▪️︎ Необходимость быстро согласовать прототип интерфейса с будущими пользователями
▪️︎ Формирование бэклога продукта (EPIC и User Story)

🚫 Ситуации, когда метод не сработает:

▪️︎ Нужно собрать данные у большого количества людей
▪️︎ Ключевых экспертов невозможно оторвать от операционной работы
▪️︎ У команды нет навыков фасилитации и управления группой

Пять правил, которые помогут провести воркшоп эффективно:

1. Тщательная подготовка. Разошлите участникам контекст, текущие схемы и вопросы за 2-3 дня. Люди должны прийти уже погруженными в тему. Составьте поминутную повестку и придерживайтесь её.

2. Правило «Парковки».
Заведите отдельный лист флипчарта. Как только разговор уходит в сторону, но вопрос важный - отправляйте его на «Парковку». Это поможет не потерять фокус на основной цели.

3. Визуализация всего происходящего. Рисуйте схемы, клейте стикеры, записывайте тезисы на флипчарте. Когда участники видят, как рождается общая картина, споры уходят быстрее.

4. Управление групповой динамикой. Вежливо останавливайте тех, кто уходит в детали («Это важный момент, давайте зафиксируем и вернемся позже»). Вовлекайте молчаливых участников прямыми вопросами

5. Мгновенная рассылка итогов. В течение 24 часов отправьте протокол встречи: фото флипчартов, список принятых решений и зону ответственности каждого. Пока впечатления свежи, участники должны видеть результат своей работы.

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

Статья:
🖇 Воркшопы по выявлению требований к IT-проектам: как и зачем их проводить?

Хлеб на закваске как управляемый процесс

Автор - Екатерина, старший менеджер проектов в ЮMoney:
" Однажды поймала себя на мысли: «Я пеку хлеб так же, как управляю сложными проектами — с контрольными точками и анализом результатов». В статье расскажу, как процессный подход помогает печь идеальный каравай и почему это работает не только в офисе."

Читать статью

📑 Сократили срок выхода задач в продакшен почти вдвое: что реально сработало

Автор - Василий Ферапонтов, отвечает за SaaS-направление в Аспро:
"Год назад у нас была ситуация, которая многим знакома. Команды заняты, задачи двигаются, релизы происходят… но предсказуемости нет. Сроки плавают, бэклог разрастается, внутри много устных договоренностей. Все работают, но система не работает.

За один квартал мы перестроили процессы и получили вполне измеримый результат:
- срок прохождения задачи от «готова к работе» до «выпущено» сократился с 23 до 11 дней
- производительность выросла на 17%
- релизы стали регулярными, а не «как получится»
- бэклог перестал быть черной дырой.

Расскажу, что именно мы изменили и почему это сработало."

Читать статью

Привет, коллеги!

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

Метод популярный, но вокруг него много споров. Кто-то считает его панацеей, кто-то - пустой тратой времени. Давайте разбираться, как получить от него реальную пользу.

Что это вообще такое?

Если по-простому: вы собираете группу людей, даете им задачу (например, «какие фичи нужны в личном кабинете в первую очередь?») и просите генерировать идеи. Главное условие - никакой критики!

Обычно процесс делят на несколько этапов:

1. Разогрев: ведущий ставит задачу, напоминает правила, раздает стикеры.
2. Генерация: все пишут и говорят всё, что приходит в голову. Безумные идеи приветствуются. Критика запрещена. Работаем на количество.
3. Анализ идей: тут уже включаем голову: группируем, отсеиваем невозможное, ранжируем то, что осталось, голосуем.

Плюсы метода:

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

➕ Это отличный способ сплотить команду вокруг задачи. Когда люди вместе придумывают требования, они потом меньше спорят на этапе разработки.

➕ Это быстро. За час можно накидать столько, сколько на интервью собирали бы неделю.

Но есть и обратная сторона (минусы):

➖ Много шума. Из 50 идей рабочими окажутся 5, остальное - фантазии. Их все равно придется обрабатывать.

➖ Давление авторитета. Если в комнате есть большой начальник, его мнение может задавить креатив остальных. Даже если он не прав.

➖ Нет структуры. Метод не подходит для сбора точных данных или формальных требований к безопасности. Тут нужны эксперты, а не "толпа со стикерами".

Бывает так, что мозговой штурм путают с воркшопом.

Мозговой штурм - это про идеи. Его цель - накидать как можно больше вариантов. Это свободный полет, без жесткой структуры и обязательных результатов на выходе.

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

Вот несколько рекомендаций по проведению мозгового штурма:

1. Соберите правильный состав. Не нужно 20 человек. Оптимально - 5-8 участников. Важно, чтобы это были не только руководители. Нужна разноплановая группа: люди с креативным мышлением, «голос пользователя» (тот, кто реально делает работу) и технический специалист, который потом поможет отсеять заведомо нереализуемые варианты.

2. Разошлите контекст заранее. За день скиньте в чат вводную: что хотим получить, какие ограничения есть. Люди придут уже с разогретым мозгом.

3. Следите за главным правилом. Самое сложное на сессии - удержать участников от преждевременной критики. Как только кто-то начинает говорить «это не взлетит», «это слишком дорого» или «пользователи такое не примут», креативный процесс останавливается. Задача модератора - мягко, но уверенно возвращать группу в режим генерации. Рабочая фраза: «Отлично, важное замечание, давайте запишем его и вернемся к оценке чуть позже. Сейчас продолжаем собирать идеи без ограничений».

4. Записывайте всё. Даже бред. Иногда одна сумасшедшая идея наталкивает другого участника на гениальное решение.

5. Не затягивайте с обработкой. Отсортируйте идеи в тот же вечер или на следующее утро. Если оставить на неделю, энтузиазм угаснет, а часть мыслей просто потеряется.

Как итог:
Мозговой штурм - штука полезная, если подходить к нему не как к «посиделкам со стикерами», а как к инструменту с четкими правилами.

🖇 Мозговой штурм – 10 правил генерации гениальных идей

🖇 Как провести мозговой штурм: основные правила, методы и ошибки

#теоретическиезаметки | @notes_analyst

​​AI и токсичная документация

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

Читать статью

​​📑 Эволюция подходов к работе со спецификациями: от бумажного ТЗ к Everything as Code

Автор - Анастасия Афанасьева:
"Код идеально отвечает на вопрос «как?», но в нем нет ответа на вопросы «зачем?», «для кого?», «почему?». Без знания ответов на эти вопросы, любая доработка — это гадание на кофейной гуще.

В этой статье проследим эволюцию: от Водопада к Agile, от Agile к гибридам и Everything as Code.

• Водопад: эпоха «толстых ТЗ»
• Agile: эпоха «общения»
• Гибриды: осознание
-Everything as Code: документация становится кодом
-Requirements as Code

• Заключение"

Читать статью

Как я перестал переключать раскладку ради одного символа: Прокачиваем русскую клавиатуру в Windows для Markdown и кода

Автор - Аскар Жакенов:
"Стремительное развитие ИИ в последние годы привело к невиданному росту популярности Markdown. Почти все современные LLM — от ChatGPT до Claude — по умолчанию выдают ответы в этом формате. Мы привыкли оформлять в нем заметки в Obsidian, писать промпты, вести документацию в GitHub и общаться в рабочих мессенджерах. Markdown стал «лингва-франка» современного интернета.

Но есть одна проблема. Использовать Markdown с русским языком — это боль.

Вам нужно поставить заголовок? Alt+Shift -> # -> Alt+Shift обратно. Нужно выделить код? Снова чечётка по клавишам переключения раскладки. Стандартная русская раскладка в Windows будто застряла в прошлом веке. Клавиша Shift+3 выдает нам символ №, который в 2024 году нужен крайне редко, в то время как жизненно необходимые решетки, собаки и скобки заставляют нас постоянно прыгать между языками.

Я решил эту проблему для Windows с помощью небольшого скрипта на AutoHotkey (v2)."

Читать статью

​​Когда машине нужен человек: инженерные подходы к удалённому управлению автономным транспортом

Автор - Дмитрий Ивахненко из команды Автономного транспорта Яндекса:
"В этой статье я подробно разберу, как устроены сервисы удалённого управления автономными юнитами — роботакси, роботами‑доставщиками и грузовиками.

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

В статье — архитектурные решения и инструменты, которые позволили сделать весь процесс удалённой помощи масштабируемым, надёжным и эффективным."

Читать статью