Заметки Аналитика | IT

Документация или код: как перестать враждовать и начать жить в условиях договора

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

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

Давайте разберемся, как сделать ее союзником, а не врагом."

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

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

Продолжаем цикл о методах сбора требований. Сегодня - про анкетирование.

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

Анкетирование - это сбор информации через заранее подготовленные письменные вопросы (анкету), на которые отвечает респондент (пользователь, стейкхолдер). Цель - получить структурированные данные от большой аудитории для анализа.

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

▪️︎ Масштаб: можно опросить сотни или тысячи людей географически распределенной аудитории.
▪️︎ Скорость и экономичность: сбор данных происходит быстро, особенно с онлайн-инструментами (напр. Google Forms).
▪️︎ Анонимность: часто повышает искренность ответов
▪️︎ Объективность и простота анализа: данные уже структурированы. Легко получить процентные соотношения, построить графики, выявить тренды.
▪️︎ Свобода респондента: можно ответить в удобное время.

➖ Минусы и риски:

▪️︎ Низкая глубина: нельзя уточнить, понять контекст или эмоции за ответом.
▪️︎ Риск неверной интерпретации: респондент может неправильно понять вопрос, а вы не сможете это вовремя заметить.
▪️︎ Самый большой риск - низкий ROI: если анкету составит неспециалист, вопросы будут наводящими, варианты ответов некорректными, а выводы - бесполезными.
▪️︎Сложность с открытыми вопросами: их анализ (текстовые ответы) трудоемок.

🎯 Когда использовать?

Идеально подходит, когда нужно:
● Провести аудит (например, выяснить, какие функции старой системы используют чаще всего).
● Оценить удовлетворенность.
● Собрать демографические данные или данные об использовании (сколько раз в день, с какой целью).
● Приоритизировать гипотезы или функции, предложив аудитории выбрать из списка.
● Получить обратную связь от широкого круга стейкхолдеров на ранних этапах проекта.

🔨 Этапы подготовки и проведения

1. Определите четкую цель: Что я хочу узнать?, а не "просто собрать мнение".
Пример цели: "Выявить 3 наиболее проблемных этапа в процессе оформления заказа на сайте с точки зрения пользователей".
2. Определите целевую аудиторию: Кто будет отвечать? Пользователи какой роли? Как их найти и привлечь?
3. Продумайте логику анкеты:
- От простого к сложному. Сначала - легкие демографические вопросы.
- От общего к частному.
- Самые важные вопросы - в середине (в начале респондент еще "входит", в конце - уже устал).
- Логические ветвления: "Если ответили А, переходите к вопросу 5".
4. Сформулируйте вопросы грамотно:
- Избегайте двойных вопросов ("Вам нравится интерфейс и функционал?").
- Избегайте наводящих вопросов ("Вам же не нравится этот медленный процесс?").
- Используйте шкалы для оценки. (например, шкала Ликерта: от "полностью согласен" до "полностью не согласен")
- Всегда добавляйте вариант "Затрудняюсь ответить" или "Другое (уточните)".
5. Протестируйте анкету (пилотный опрос): дайте заполнить анкету 2-3 коллегам или доверенным пользователям. Убедитесь, что вопросы понятны, логика ясна, нет технических ошибок.
6. Запустите опрос и соберите данные.
7. Проанализируйте результаты: не просто посчитайте проценты. Ищите корреляции, сегментируйте ответы (например, как отвечали менеджеры vs. как отвечали клиенты). Важен именно анализ, а не сырые данные.

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

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

​​📑 Исследуем UX-долг: как мы превращали список проблем в продуктовые решения

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

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

​​📑 От процессов к системам: разработка для корпоративного университета

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

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

​​📑 ArchiMate для архитектурного проектирования на примере корпоративного университета

Автор Анна Вичугова:
"Практика применения ArchiMate для стратегического моделирования: от мотивационных факторов до информационных сервисов. Смотрим на примере корпоративного университета."

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

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

Интервью – это не просто «разговор», а структурированный метод, позволяющий глубоко понять контекст, мотивацию и неочевидные проблемы стейкхолдера.
Суть метода в том, что у вас есть план и ключевые темы, но нет жёсткого сценария. Вы ведёте беседу, адаптируя вопросы по ходу дела, чтобы исследовать интересные детали.

Практический пример:

Ситуация: Вы разрабатываете новый внутренний сервис для подачи заявок на отпуск.
Ваш стейкхолдер: Мария, руководитель отдела маркетинга.
Её запрос-решение: «Хочу, чтобы заявку можно было подавать из нашего мессенджера. Так будет быстрее».

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

1. Вопрос на понимание контекста: «Мария, расскажите, как сейчас выглядит процесс согласования отпуска в вашем отделе? Опишите, пожалуйста, шаг за шагом».
2. Вопрос на выявление проблемы: «С какими сложностями вы или ваши сотрудники сталкиваетесь чаще всего? Что больше всего раздражает или отнимает время?»
3. Уточняющий вопрос на «решение»: «Вы упомянули мессенджер - что именно в текущем процессе заставляет думать, что мессенджер ускорит дело?»
4. Вопрос на выявление цели: «Представьте идеальный сценарий. Что должно происходить, когда сотрудник хочет в отпуск?»

Вероятный результат такого интервью:
Окажется,что главная боль - не в способе подачи, а в том, что заявки «теряются» в длинных email-переписках, непонятен их статус, и Марии приходится постоянно напоминать HR о согласовании. Её истинная потребность - прозрачность и контроль над процессом, а не скорость отправки.

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

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

А на картинках к этому посту вы найдете еще несколько рекомендаций по подготовке и проведению интервью ⬆️

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

​​📑 Архитектура через призму сложности

Автор - Сергей Баранов:
"Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?

Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга. Игнорируя хотя бы один из них, получим легаси с техдолгом вселенских масштабов уже через полгода (при современных условиях может и быстрее).​"

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

​​📑 Бережливое производство и имитационное моделирование для анализа и оптимизации бизнес-процессов

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

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

​​📑 Цикл статей: Kafka для начинающих

Автор - Никита Дымко
Java Backend Developer

1. Откуда такой спрос и зачем нужна эта технология

2. Работа с брокером сообщений на практике

3. Гарантии доставки на практике и настройка идемпотентности

4. Работа с оффсетами на практике

5. Работа с Kafka транзакциями на практике — когда они нужны, а когда только вредят?

​​📑 Хранилища данных. Обзор технологий и подходов к проектированию

Автор - Марина Зенкова
"В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных."

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

​​📑 BPMN для аналитиков и тимлидов (часть 2)

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

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

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

​​Как продакт и аналитик работают в одной задаче: три кейса из практики

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

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

​​Фильтруй. Переиспользуй. Собирай. Почему DITA — идеальный формат для разработки сложной технической документации

Автор - Александр Клименков, техлид, технический писатель, программист:
"DITA расшифровывается как Darwin Information Typing Architecture. Фактически это формат, основанный на XML, со своей стандартизированной схемой DTD. Формат DITA предназначен для разметки исходного текста документов с помощью специальных тегов. Набор тегов в этом формате специально разработан для того, чтобы было удобно форматировать текст пользовательской или технической документации.

В этом формате предусмотрено несколько удобных механизмов, которые позволяют здорово упростить жизнь автору текста. Например, в DITA есть очень удобные средства для фильтрации и повторного использования контента. Из исходных файлов в формате DITA с помощью свободно распространяемого набора скриптов DITA-OT (Open Toolkit) можно собрать документы в различных форматах: HTML, PDF, EPUB, CHM и других.

Давайте познакомимся с этим форматом поближе."

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

​​📑 Кому выгоден перманентный пожар: экономика тушения в ИТ

Автор - Светлана Пурик:
"Борьба с последствиями плохого ТЗ иногда ценится выше, чем работа по его предотвращению.

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

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

​​Как написать AI-ТЗ из одной фразы заказчика: пошаговая инструкция по методике SARD от идеи до спецификации требований

"Эта статья — демонстрационный пример, иллюстрирующий пошаговую методику преобразования одной вымышленной бизнес-фразы заказчика в полноценное техническое задание (ТЗ) с помощью инструментов искусственного интеллекта (ИИ). В качестве исходной фразы для демонстрации выбрана бизнес-идея, приписываемая гипотетическому Сэму Альтману: «Помогите мне сделать GPT настолько незаметным, что люди перестанут бояться сингулярности»."

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

От стейкхолдеров к требованиям: с чего начать?

Привет, коллеги!
В прошлый раз мы с вами разобрали, кто такие стейкхолдеры и как с ними взаимодействовать.
Вы уже составили свой список ключевых лиц, наметили стратегию коммуникации... И теперь возникает самый важный и сложный вопрос: «Что же делать дальше?» 🤔

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

Главный секрет на этом этапе - научиться отделять истинную Потребность от предложенного Решения.

▪️Решение - это то, ЧТО человек просит сделать. Часто это уже готовое, иногда неоптимальное, техническое предложение.
▪️Потребность - это то, ПОЧЕМУ он это просит. Это коренная проблема, боль, цель или желаемый результат, который стоит за запросом.

Классический пример:
- Что говорит стейкхолдер (Решение): «Мне нужна еще одна кнопка «Экспорт в PDF» в правом верхнем углу отчета».
- Что может быть на самом деле (Потребность): «Мне еженедельно приходится тратить 2 часа, чтобы вручную сводить данные из этого отчета в презентацию для руководства. Мне нужно быстро получать данные в удобном для презентации формате».

Видите разницу? Если мы слепо реализуем «кнопку», мы можем упустить возможность создать автоматический еженедельный отчет-презентацию, который сэкономит не 10 минут на клик, а 2 часа работы в неделю.

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

Вопросы-помощники для выявления потребностей:
- «Расскажите, как вы сейчас выполняете эту задачу? Опишите ваш обычный день» (понимание текущего процесса).
- «С какими сложностями или рутиной вы сталкиваетесь? Что отнимает больше всего времени?» (выявление боли).
- «Какой идеальный результат для вас? Что изменится, когда проблема будет решена?» (понимание цели).
- Уточняющие вопросы на любое предложенное решение: «Почему это важно? Как это решит вашу задачу?»

Ваша цель первой встречи - не записать список функций, а понять контекст, бизнес-процесс и настоящие цели.

Итог: Переход от стейкхолдеров к требованиям начинается со смены фокуса. Фокус на ЛИЦА (кому важно) меняется на фокус на ПРОБЛЕМЫ (что важно и почему).

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

@notes_analyst