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

Далее информация будет по блокам: Цель-Действия-Результат.

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

❗Главный принцип: не читайте документацию подряд. Документация - это ответы на вопросы, которых у вас пока нет. Сначала наберите вопросы, потом идите за ответами.

👩‍💻День 1. Пройти продукт руками Цель: Изучить систему руками.

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

🏅Результат: 20-40 незнакомых терминов и черновая схема экранов.

📝День 2. Собрать карту сущностей Цель: Понять, чем продукт оперирует, а не что он показывает.

Действия: Выпишите все существительные из интерфейса и из заголовков задач (заказ, клиент, договор, платеж). Это и есть сущности системы. По каждой ответьте на три вопроса: 1) Откуда она появляется? 2) Какие у нее бывают состояния? 3) Кто и когда эти состояния меняет?

Если есть доступ, посмотрите названия таблиц и полей в базе данных проекта, если нет - ответы API в DevTools вашего браузера. Структура данных честнее документации.

🏅Результат: Схема из 7-12 сущностей со связями.

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

Действия: Посмотрите, куда система ходит, используйте DevTools, логи, конфиги, swagger. По каждой внешней системе ответьте на четыре вопроса: 1) Что мы отдаем. 2) Что получаем. 3) Синхронно или асинхронно. 4) Что происходит, когда она недоступна. Теперь можно открывать Confluence: вы уже знаете, что ищете.

🏅Результат: Контекстная диаграмма на страницу и список интеграций.

📚День 4. Разобрать три закрытые задачи Цель: Понять не продукт, а то, как здесь принято его менять. Этого нет в документации.

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

🏅Результат: Неписаные правила команды и список вопросов к ней.

🙋‍♂️💁‍♂️День 5. Проверить себя вслух

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

Действия: Соберите все на одну страницу и покажите двум людям: техническому специалисту и кому-то со стороны бизнеса. Именно двум, потому что они видят систему по-разному.

Прием, который меняет результат. Говорите утверждениями, а не вопросами. На вопрос "заказ уходит в обработку после оплаты?" вам ответят "да, примерно". На утверждение "заказ уходит в обработку только после оплаты" возразят: "нет, есть еще постоплата". Возражение полезнее подтверждения.

🏅Результат. Исправленная карта и 5-10 мест, где вы ошибались. На выходе у вас одна страница: сущности, состояния, интеграции, неписаные правила. Полноценный артефакт, который удобно отдать следующему новичку.

Если нет времени на выполнение всего плана, делайте дни 1, 2 и 5.

Через неделю вы не эксперт, но вы знаете границы своего незнания (а это уже очень ценно!). Для аналитика это и есть рабочее состояние, а уверенность в том, что все понял, обычно означает обратное.

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

Открыта к предложениям, если вашей команде нужен аналитик. #системныйаналитик #бизнесаналитик #онбординг #требования