Бизнес-аналитик

Как пройти маршрут

Бизнес-аналитик помогает разобраться, что мешает работе компании и как это исправить. Здесь вы попробуете его задачи: поговорите с сотрудниками, нарисуете порядок работы, напишете требования и подготовите проверки.

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

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

Порядок занятия

1. Прочитайте пример в начале шага.
2. Откройте материалы и найдите указанные темы. Если это большой справочник, читать его целиком сейчас не нужно.
3. Выполните задания и сохраните работу.
4. Сравните результат с проверкой в конце. Разбор в раскрывающемся блоке открывайте после своей попытки.
5. Исправьте ошибки и поставьте отметку о завершении шага.

Начните с 6–10 часов в неделю и подстройте темп под себя. Время возле шагов — наша оценка, пока не проверенная на учениках. Основная часть рассчитана примерно на 211–317 часов, углубление — на 54–78. Беседы с участниками и ожидание обратной связи могут увеличить календарный срок.

Если что-то непонятно

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

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

Язык и доступ к материалам

Объяснения и задания карты написаны на русском. Многие статьи и видео по ссылкам — на английском. Для текста можно включить перевод страницы в браузере. В видео проверьте кнопку субтитров; их наличие и перевод зависят от автора и платформы.

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

По каким программам и вакансиям собрана карта →

Учебная история: прокат инструментов «МастерПрокат»

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

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

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

Условия задачи

• Один пункт проката, 300 заявок в месяц. В 12% заявок возникает конфликт бронирования. Активная работа сотрудника над заявкой занимает в среднем 20 минут.
• Владелец предлагает чат-бота, чтобы уменьшить ошибки. На первое изменение он готов потратить до 100 000 ₽. Работу сети филиалов и онлайн-оплату пока не планирует.
• Оператор считает бронь подтверждённой после отправки сообщения. Кладовщик — после записи конкретного инструмента за клиентом. Клиент хочет получить обещанный инструмент в нужное время.
• Для расчёта в шаге 10 предположим, что время работы сократится с 20 до 12 минут. Проект стоит 90 000 ₽, поддержка — 6 000 ₽ в месяц. Условная стоимость часа работы — 600 ₽.

Эти числа — исходные условия упражнения. В шаге 9 будет отдельная таблица из восьми заявок для тренировки расчётов; она не описывает весь месяц.

Шаг 1. Понять, чем занимается бизнес-аналитик

Разберём на примере

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

Бизнес-аналитик выясняет, почему возникла ошибка. Он разговаривает с оператором и кладовщиком, смотрит, как они записывают заявки. Возможно, оператор отправляет клиенту подтверждение, а склад ещё не закрепил за ним инструмент. Чат-бот сам по себе эту несогласованность не исправит.

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

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

Что прочитать и посмотреть

1. IIBA — The Business Analysis Standard — Прочитайте определение бизнес-анализа и обзор шести основных понятий. Попробуйте связать каждое с историей проката: кто участвует, что ему нужно и что предлагается изменить. Доступ: английский; обзор открыт, для загрузки может понадобиться аккаунт. Платную книгу BABOK покупать не нужно.
2. Яндекс Практикум — введение в бизнес-анализ — По желанию пройдите бесплатное введение. Если не можете зарегистрироваться, начните с примера и заданий на этой странице. Доступ: русский; введение бесплатное, нужен аккаунт. Продолжение платное и для этого шага не требуется.

Что сделать

1. Запишите три строки: что случилось с клиентом; какое решение предложил владелец; что ещё нужно узнать перед выбором решения.
2. Составьте 5 вопросов владельцу и сотрудникам. Начните с «Как вы сейчас проверяете, что дрель свободна?» и добавьте свои вопросы.
3. Придумайте по одному вопросу для бизнес-аналитика, системного аналитика и аналитика данных. Ориентируйтесь на задачи из объяснения выше.
4. Объясните знакомому за две минуты, что делает бизнес-аналитик. Используйте историю проката.

Что сохранить

Один документ: ваше объяснение профессии, три вида вопросов и вопросы сотрудникам проката.

Как проверить себя

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

Шаг 2. Подготовить папку и программы для учёбы

Разберём на примере

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

Для этого достаточно текстового редактора, электронной таблицы и редактора схем. Текст нужен для объяснений, таблица — для списков и расчётов, схема — чтобы показать порядок действий. Покупать программы для этого шага не нужно.

Сохраняйте файл, который можно изменить, и при необходимости его копию для просмотра. Например, схему в формате .drawio можно отредактировать, а её картинку удобно показать другому человеку.

Что прочитать и посмотреть

1. diagrams.net — редактор схем — Создайте пустую схему, выберите сохранение на устройство, сохраните файл .drawio и откройте его снова. Доступ: бесплатно; выбирайте сохранение на устройство, аккаунт не нужен.
2. draw.io — BPMN 2.0 — Найдите, где включается набор фигур BPMN. Значения фигур разберём в шаге 8. Доступ: английский; открытая инструкция.

Если нет офисных программ, используйте бесплатный LibreOffice: Writer для текста, Calc для таблиц. Сначала достаточно ввести небольшой список, сохранить документ и открыть его снова.

Что сделать

1. Создайте папку «Бизнес-анализ». Внутри — папки «Задача», «Интервью», «Схемы», «Требования», «Проверки» и «Решения».
2. Создайте таблицу «Учебный журнал» с колонками: дата, мой вопрос, где искал ответ, что узнал, что осталось непонятно, что сделаю дальше. Заполните первую строку по шагу 1.
3. Сохраните небольшой текст, таблицу в формате CSV и схему. CSV — текстовый файл, в котором строки таблицы записаны по одной, а ячейки разделены, например, запятыми. Закройте файлы и откройте снова.
4. Назовите схему «Бронирование-v01» и добавьте дату. Сохраните также её изображение. Проверьте, что умеете изменить исходную схему.

Что сохранить

Рабочую папку, журнал и три файла: текст, таблицу и схему.

Как проверить себя

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

Шаг 3. Описать проблему и цель проекта

Разберём на примере

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

Проблема — то, что сейчас мешает людям: одну дрель обещают нескольким клиентам на одно время. Цель — результат, которого хотим добиться: уменьшить число таких случаев. Границы проекта — какую часть работы меняем сейчас: например, бронирование и выдачу в одном пункте.

Не всё известно заранее. «Ошибки возникают из-за устаревшей таблицы» — пока предположение. Его нужно проверить. Этот ранний разбор задачи часто называют discovery: команда исследует проблему и решает, стоит ли продолжать проект.

Что прочитать и посмотреть

1. GOV.UK — discovery — Найдите части о проблеме и ограничениях проекта. Сравните вопросы статьи со своими вопросами к владельцу проката. Доступ: английский; открытый текст.

Что сделать

1. Перечитайте историю «МастерПроката» в начале карты. В 2–3 предложениях опишите, кто столкнулся с трудностью, что произошло и к чему это привело.
2. Запишите цель с числом и сроком. Число, которого нет в условиях, пометьте «учебное предположение, нужно проверить».
3. Разделите лист на «Делаем сейчас» и «Не делаем сейчас». В первую часть включите бронирование и выдачу в одном пункте. Во вторую запишите 4 исключения, включая онлайн-оплату и работу сети филиалов.
4. Запишите 5 предположений. Рядом с каждым укажите, у кого или по каким записям его можно проверить.

Что сохранить

Документ «Задача проекта»: проблема, цель, что входит в работу, ограничения и предположения.

Как проверить себя

По вашему тексту понятно, что должно измениться для клиента или сотрудника. У каждого числа указан источник: условия учебной задачи или ваше предположение. Вы можете объяснить, как проверите цель.

Шаг 4. Определить, с кем обсуждать изменения

Разберём на примере

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

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

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

Что прочитать и посмотреть

1. IIBA — The Business Analysis Standard — Найдите обзор работы с участниками: Stakeholder Engagement и Elicitation and Collaboration. Выпишите, с кем и о чём нужно поговорить в вашей задаче. Доступ: английский; обзор открыт, для загрузки может понадобиться аккаунт. Платную книгу BABOK покупать не нужно.

Что сделать

1. Сделайте таблицу с 6 строками: владелец, оператор, кладовщик, клиент, бухгалтер, разработчик.
2. Для каждой роли запишите: что ей важно, чего она опасается, о чём может рассказать, когда с ней удобно встретиться и какие решения она вправе принимать. Неизвестное пометьте вопросом.
3. Возьмите 4 решения: бюджет, правило подтверждения, порядок выдачи и вид сообщения клиенту. Для каждого укажите, кто готовит предложение, кого спрашивают и кто утверждает итог. В учебной задаче выберите одного окончательно согласующего.
4. Запланируйте 3 встречи. Для каждой напишите тему, участников и результат, который нужен к концу разговора.

Что сохранить

Таблицу участников, список ответственных за решения и план трёх встреч.

Как проверить себя

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

Шаг 5. Провести беседу о реальной работе

Разберём на примере

Вы спрашиваете оператора: «С ботом ведь станет удобнее?» Он отвечает «да», но вы так и не узнали, откуда берутся ошибки. В вопрос уже было заложено желаемое решение.

Начните иначе: «Расскажите о последнем случае, когда клиент приехал, а дрель была занята». Уточняйте по порядку: что случилось сначала, где записали заявку, кто проверил наличие, что сказали клиенту. Такая рабочая беседа называется интервью.

Просите показать записи, если это возможно. Отделяйте слова человека от своего вывода. «Оператор сказал, что таблица обновилась позже» и «причина ошибки — задержка обновления» пока не одно и то же: второй вывод ещё надо проверить.

Что прочитать и посмотреть

1. GOV.UK — глубинные интервью — Прочитайте, как готовить беседу, задавать нейтральные вопросы и обрабатывать записи после разговора. Доступ: английский; открытый текст.

Что сделать

1. Подготовьте 8 вопросов, на которые нельзя ответить только «да» или «нет». Добавьте 3 уточнения к последнему случаю двойной брони: о времени, записи и передаче информации.
2. Попросите знакомого сыграть сотрудника по карточке в начале карты. Проведите беседу на 20 минут. Если хотите записывать звук, сначала получите согласие.
3. Если собеседника пока нет, разберите карточки письменно и отметьте это как учебный разбор. Запланируйте разговор с человеком до итогового проекта.
4. Разделите заметки на три части: что сказал собеседник, что вы увидели в записях, как вы это объясняете. Отдельно выпишите вопросы без ответа.
5. Отправьте или прочитайте собеседнику краткий пересказ и дайте исправить неточности.

Что сохранить

Вопросы, заметки без личных данных и краткий пересказ разговора с исправлениями.

Как проверить себя

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

Шаг 6. Разобраться в разных значениях слов и спорных сведениях

Разберём на примере

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

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

Так же разбирайте спорные сведения. Если два человека называют разное время выдачи, уточните, от какого события они считают. Сохраните, что решили и на чём основано решение. Это поможет не начинать тот же спор через неделю.

Что прочитать и посмотреть

1. IREB — Foundation Level Handbook и Glossary — В справочнике Foundation Level Handbook найдите glossary — словарь терминов, и validation — проверку того, что записи соответствуют задаче. Если загрузка недоступна, используйте пример словаря и задания на этой странице. Доступ: английский; справочник бесплатный, для загрузки через IREB Cockpit может понадобиться аккаунт. Экзамен сдавать не нужно.
2. GOV.UK — глубинные интервью — Вернитесь к After the interview — действиям после беседы. Проверьте, как уточнить и подтвердить свой пересказ. Доступ: английский; открытый текст.

Что сделать

1. Создайте словарь из 12 слов проката. Обязательно включите заявку, резерв, выдачу, возврат, отмену и отдельный экземпляр инструмента. Для каждого дайте определение и пример.
2. Запишите 4 спорных вопроса по истории проката. Если для четырёх не хватает условий, придумайте дополнительные ситуации и пометьте их как учебные.
3. Для каждого вопроса заполните: в чём расходятся мнения, что проверить, кто поможет и к какому сроку нужен ответ.
4. Выберите один вопрос и запишите решение: какой вариант выбран, почему, кто его согласовал и когда. При самостоятельной работе отметьте согласование как предполагаемое.

Что сохранить

Общий словарь, список спорных вопросов и запись одного решения.

Как проверить себя

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

Шаг 7. Нарисовать, как бронирование работает сейчас

Разберём на примере

Клиент позвонил. Оператор проверил таблицу, написал кладовщику и ждал ответа десять минут. Если на схеме оставить только «проверить наличие», причина задержки будет незаметна.

Процесс — последовательность действий, ведущих к результату. Схему текущей работы называют AS-IS, то есть «как есть». Здесь нужно показать, как сотрудники действуют сейчас, даже если по инструкции должны иначе.

Начните с простых прямоугольников и стрелок. Внутри прямоугольника пишите действие: «Проверить свободную дрель». Отведите отдельную полосу оператору и кладовщику. Так будет видно, в какой момент работа переходит от одного к другому.

Что прочитать и посмотреть

1. GOV.UK — discovery — Вернитесь к разбору того, как человек решает задачу сейчас. Найдите ограничения, которые нужно показать на схеме проката. Доступ: английский; открытый текст.
2. diagrams.net — редактор схем — Создайте простую схему с отдельными полосами для сотрудников. Сохраните исходный файл и картинку. Доступ: бесплатно; выбирайте сохранение на устройство, аккаунт не нужен.

Что сделать

1. Нарисуйте путь от обращения клиента до выдачи инструмента или отказа. Покажите телефон, сообщения и таблицу там, где ими пользуются.
2. Рядом создайте таблицу: действие, кто выполняет, что нужно для начала, что получается в конце, сколько работают, сколько ждут, что может пойти не так.
3. Пройдите по стрелкам три истории: инструмент свободен; инструмента нет; два клиента хотят одну дрель на одно время. Добавьте недостающие ветки.
4. Отметьте места, о которых нет сведений в условиях. Подпишите вопрос сотруднику вместо выдуманного факта.

Что сохранить

Схему AS-IS и таблицу действий с ожиданиями и вопросами.

Как проверить себя

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

Шаг 8. Описать процесс с помощью BPMN

Разберём на примере

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

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

Шлюз XOR выбирает одну подходящую ветку. Параллельный шлюз AND запускает все выходящие ветки. Для выбора «свободен / занят» подходит XOR: одновременно подтвердить и отклонить бронь нельзя.

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

Что прочитать и посмотреть

1. Camunda — BPMN primer — Изучите events — события, tasks — задачи, gateways — шлюзы и sequence flows — стрелки порядка действий. Найдите каждый элемент в своей схеме. Доступ: английский; справка открыта, устанавливать Camunda не нужно.
2. draw.io — BPMN 2.0 — Повторите пример схемы в редакторе, затем нарисуйте бронирование по тем же правилам. Доступ: английский; открытая инструкция.

Что сделать

1. Откройте схему шага 7 и материалы этого шага. Создайте её версию в BPMN: компания — один пул с дорожками оператора и кладовщика, клиент — отдельный пул.
2. Поставьте проверку наличия перед выбором. Подпишите выходы «есть свободный инструмент» и «свободного инструмента нет».
3. Проведите пальцем по стрелкам для обычной заявки, отказа и отмены. На каждом разветвлении объясните, почему идёте по этой ветке. В BPMN такую проверку также описывают как движение воображаемого токена — отметки текущей точки процесса.
4. Найдите пути, которые оборвались или бесконечно возвращаются назад. Исправьте их либо подпишите, какого события они ждут.

Что сохранить

Исходный файл BPMN-схемы и три коротких описания прохода по ней.

Как проверить себя

Между пулами нет сплошной стрелки порядка действий. Для каждого выбора понятны условия. Каждый путь доходит до результата или до объяснённого ожидания.

Шаг 9. Посчитать время ответа и долю ошибок

Разберём на примере

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

Метрика — показатель, который мы считаем по понятному правилу. Например, время от регистрации заявки до окончательного ответа. Сначала договоритесь, что именно измеряете, и только потом считайте среднее.

Ниже — восемь вымышленных заявок для упражнения. Они нужны для проверки расчётов. По ним нельзя подтверждать месячные 12% ошибок из истории проката: это отдельные учебные данные.

Что прочитать и посмотреть

1. GOV.UK — метрики сервиса — Прочитайте, как выбрать показатель для цели и определить, откуда брать данные. Доступ: английский; открытый текст.

request_id,channel,elapsed_minutes,conflict
R01,phone,30,0
R02,web,50,0
R03,phone,20,0
R04,web,90,1
R05,phone,40,0
R06,web,60,0
R07,web,10,0
R08,phone,100,1

Каждая строка — одна заявка. Столбцы означают:

• request_id — номер заявки.
• channel — канал: phone означает телефон, web — сайт.
• elapsed_minutes — сколько минут прошло от регистрации до окончательного ответа.
• conflict — обнаружена ли конкурирующая бронь: 1 — да, 0 — нет.

Среднее: сложите все значения времени и разделите на число заявок.

Медиана: расположите значения по возрастанию и найдите середину. Если значений чётное количество, сложите два центральных и разделите на 2. Например, для 10, 20, 40, 90 медиана равна (20 + 40) / 2 = 30.

Доля конфликтов: посчитайте строки с единицей в conflict, разделите на число всех заявок и умножьте на 100, чтобы получить проценты.

Для первого расчёта хватит калькулятора. Затем попробуйте функции среднего и медианы в таблице. Убедитесь, что минуты распознаны как числа. Пустая ячейка означает отсутствие значения; записав туда ноль, вы измените результат.

Что сделать

1. Скопируйте CSV из блока выше в файл requests.csv и откройте электронной таблицей. При импорте выберите запятую как разделитель. Должно получиться 4 столбца и 8 строк данных.
2. Посчитайте количество заявок, среднее время, медиану и процент заявок с конфликтом. Используйте объяснение рядом с данными. Проверьте один расчёт вручную.
3. Для времени ответа и доли конфликтов запишите: формулу, единицу измерения, откуда берём данные, за какой период считаем, какие заявки включаем и кто отвечает за сведения. Такое описание иногда называют паспортом метрики.
4. Добавьте столбец «Причина отмены». Если причины неизвестны, оставьте их неизвестными. Запишите, будете ли включать отменённые заявки в расчёт и почему: нельзя незаметно убрать их из общего числа.

Что сохранить

Таблицу с расчётами и описание правил для двух показателей.

Как проверить себя

Вы получаете 8 заявок и можете объяснить расчёт без функции таблицы. Понимаете, почему время до ответа отличается от активной работы. Не подменяете месячные условия результатом маленького упражнения.

Шаг 10. Сравнить способы решения и затраты

Разберём на примере

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

Запишите для каждого варианта, какую проблему он решает, сколько стоит, когда его можно попробовать и что может пойти не так. Такой разбор называют бизнес-кейсом. Здесь слово «кейс» означает обоснование решения, а не учебную историю.

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

Что прочитать и посмотреть

1. IIBA — The Business Analysis Standard — Найдите Analyze Potential Value and Recommend Solution — оценку пользы и выбор решения. По нему проверьте, что сравнили несколько вариантов. Доступ: английский; обзор открыт, для загрузки может понадобиться аккаунт. Платную книгу BABOK покупать не нужно.
2. GOV.UK — метрики сервиса — Проверьте, можно ли измерить результат, который вы обещаете для каждого варианта. Доступ: английский; открытый текст.

Что сделать

1. Создайте таблицу для трёх вариантов: правила и общая таблица; готовая программа; своя разработка. Добавьте ожидаемую пользу, расходы, срок запуска и риск. Придуманные цены и сроки пометьте как учебные.
2. Для проекта за 90 000 ₽ посчитайте: сколько часов освобождается при 300 заявках и экономии 8 минут на каждой. Переведите минуты в часы, разделив на 60.
3. Умножьте часы на условные 600 ₽ за час. Вычтите 6 000 ₽ поддержки за месяц. Разделите 90 000 ₽ на результат — получите условный срок в месяцах.
4. Повторите расчёт для 200 заявок. Объясните, почему эти сроки не доказывают денежную окупаемость, если зарплаты прежние и дополнительных заказов нет.
5. Выберите вариант для первой проверки и объясните выбор в 3–5 предложениях.

Что сохранить

Таблицу вариантов, два расчёта и короткую рекомендацию.

Как проверить себя

В расчёте учтена ежемесячная поддержка. Вы отличаете освобождённые часы от полученных денег. Рекомендация опирается на задачу проката и явно отмеченные предположения.

Шаг 11. Нарисовать новые правила работы и пробный запуск

Разберём на примере

Вы предлагаете новое правило: сообщение «Бронь подтверждена» отправляется только после того, как за клиентом закрепили инструмент. Теперь нужно показать все действия вокруг этого правила.

Схему будущей работы называют TO-BE, то есть «как должно быть». Сравните её с AS-IS из шага 7. Например, раньше оператор сначала обещал дрель, теперь сначала проверяет и закрепляет её. Для каждой разницы объясните, какую ошибку она помогает предотвратить.

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

Что прочитать и посмотреть

1. Camunda — BPMN primer — Повторите события и шлюзы. Используйте справку, когда будете добавлять отмену и ожидание в новую схему. Доступ: английский; справка открыта, устанавливать Camunda не нужно.
2. Camunda — BPMN in Action — Найдите Best Practices for Process Modeling, Part 2. Во время просмотра обращайте внимание, какие действия входят в процесс и где он заканчивается. Доступ: английские видео; справка по BPMN также доступна текстом.

Что сделать

1. Нарисуйте в BPMN будущий путь бронирования. Подтверждение клиенту отправляется после успешного закрепления инструмента.
2. Добавьте три случая: клиент отменил заявку; время удержания брони истекло; программа недоступна. Покажите, кто действует дальше.
3. Создайте таблицу из 5 изменений: как сейчас, как будет, зачем меняем, что нужно подготовить, как проверим. Такую таблицу различий также называют gap-анализом.
4. Опишите пробный запуск на две недели: кто участвует, какие заявки берём, кто помогает при сбое и при каком результате остановим проверку.

Что сохранить

Схему TO-BE, таблицу пяти изменений и план пробного запуска.

Как проверить себя

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

Шаг 12. Написать понятные и проверяемые требования

Разберём на примере

Разработчику передали пожелание «Сделайте быстрое и удобное бронирование». Один человек понимает под этим ответ за секунду, другой — минимум полей. Без уточнения они могут сделать разную работу.

Требование описывает нужный результат или правило. Например: «Если дрель занята в выбранные даты, система не подтверждает бронь и объясняет причину оператору». Такое поведение можно проверить.

Требования описывают разные стороны задачи. Бизнес-требование — какого результата ждёт компания. Пользовательское — что человеку нужно сделать. Функциональное — как должна вести себя система. Ограничение — условие, в которое надо уложиться, например бюджет.

У каждого требования сохраните номер, источник и причину. Понятно написанное правило всё ещё может быть ненужным: отдельно проверьте, какую проблему оно решает.

Что прочитать и посмотреть

1. IREB — Foundation Level Handbook и Glossary — В Foundation Level Handbook найдите documenting requirements — запись требований, и quality criteria — признаки хорошего требования. Сравните с тремя своими записями. Доступ: английский; справочник бесплатный, для загрузки через IREB Cockpit может понадобиться аккаунт. Экзамен сдавать не нужно.
2. GOV.UK — пользовательские истории — Прочитайте, как связаны потребность человека и условия проверки результата. Доступ: английский; открытый текст.

Что сделать

1. Напишите 12 требований к прокату: по 3 бизнес-требования, пользовательских, функциональных и ограничения. Дайте им номера REQ-001…REQ-012.
2. Рядом с каждым запишите: откуда оно взялось, зачем нужно, насколько срочно, как проверите и какая сейчас версия. Придуманное правило пометьте как предложение.
3. Возьмите фразы «быстро», «удобно» и «все необходимые отчёты». Для каждой напишите вопрос на уточнение и пример более точной записи.
4. Найдите две записи, которые могут противоречить друг другу. Если не нашли, добавьте учебную пару и объясните, какое решение требуется.

Что сохранить

Таблицу 12 требований и список вопросов, которые нужно согласовать.

Как проверить себя

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

Шаг 13. Описать действия пользователя и условия приёмки

Разберём на примере

Оператор хочет видеть свободные дрели на выбранные даты, чтобы не обещать занятую. Это можно записать как пользовательскую историю, или user story: кто, что хочет сделать и зачем.

Если нужно разобрать подробности, напишите сценарий использования, или use case. Укажите, кто действует, что должно быть готово до начала, какие шаги идут дальше, что происходит при ошибке и чем всё заканчивается.

Критерии приёмки — условия, по которым команда проверит, что договорённость выполнена. Удобная форма примера: «Дано… Когда… Тогда…» — исходная ситуация, действие и ожидаемый результат. В материалах встретятся английские Given, When, Then.

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

Что прочитать и посмотреть

1. GOV.UK — пользовательские истории — Разберите форму пользовательской истории и acceptance criteria — условия её приёмки. Доступ: английский; открытый текст.
2. Agile Alliance — INVEST — Прочитайте расшифровку INVEST. Проверьте, можно ли ваши истории обсуждать и оценивать, достаточно ли они небольшие, самостоятельные, полезные и проверяемые. Доступ: английский; открытый текст.
3. Cucumber — Gherkin Reference — Найдите Given, When, Then. Запишите по образцу свою проверку на русском; устанавливать программу Cucumber не нужно. Доступ: английский; открытая справка, установка для упражнения не нужна.

Что сделать

1. Разделите большую задачу «управлять прокатом» на 5 историй. Для каждой запишите роль, действие и пользу. Например, начните с поиска свободного инструмента.
2. Для подтверждения брони опишите подробный сценарий: что нужно до начала, шаги оператора и ответы системы, результат в конце.
3. Добавьте ответвления: инструмента нет, не заполнены даты, клиент отменил заявку.
4. Напишите 4 примера «Дано / Когда / Тогда». Включите занятую дрель и случай, когда две брони стоят вплотную по времени: нужно явно определить, допустимо ли это.

Что сохранить

Пять историй, один подробный сценарий и четыре примера проверки.

Как проверить себя

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

Шаг 14. Определить качество работы и права доступа

Разберём на примере

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

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

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

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

Что прочитать и посмотреть

1. IREB — Foundation Level Handbook и Glossary — Найдите quality requirements — требования к качеству, и constraints — ограничения. Сравните примеры с поиском свободной дрели. Доступ: английский; справочник бесплатный, для загрузки через IREB Cockpit может понадобиться аккаунт. Экзамен сдавать не нужно.
2. GOV.UK — прототипы — Посмотрите, как черновики экранов помогают заранее проверить действия пользователя. Доступ: английский; открытый текст.

Что сделать

1. Сделайте таблицу для ролей: клиент, оператор, кладовщик, администратор. Возьмите 5 видов записей: карточка клиента, заявка, резерв, инструмент, журнал выдачи. Для каждой пары укажите разрешённые действия.
2. Напишите 3 требования к качеству: скорость поиска, восстановление после сбоя и работа интерфейса в выбранных условиях. У каждого укажите способ проверки и порог. Придуманные числа пометьте как предлагаемые.
3. Перечислите поля карточки клиента и для каждого объясните, зачем оно нужно. Ненужные поля удалите, неизвестное назначение запишите вопросом.
4. Укажите, кто должен подтвердить права, условия измерения и правила работы с данными.

Что сохранить

Таблицу доступа, три требования к качеству и вопросы для согласования.

Как проверить себя

Клиент не получает доступ к чужой заявке даже по прямой ссылке. У каждого требования понятно, что измерять и при каких условиях. Случайные числа не представлены как обязательная норма.

Шаг 15. Проверить будущие экраны на людях

Разберём на примере

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

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

Дайте задачу: «Забронируйте дрель на завтра с 10:00 до 18:00». Наблюдайте за попыткой и записывайте места, где человек остановился или ошибся. Подсказка «нажмите справа» скроет трудность, которую вы ищете.

Что прочитать и посмотреть

1. GOV.UK — прототипы — Прочитайте о видах прототипов. Выберите простую форму, в которой можно показать поиск, заявку и результат. Доступ: английский; открытый текст.
2. diagrams.net — редактор схем — Нарисуйте три экрана и сохраните их. Если удобнее, сделайте это на бумаге. Доступ: бесплатно; выбирайте сохранение на устройство, аккаунт не нужен.

Что сделать

1. Нарисуйте три экрана: поиск инструмента, заполнение заявки, результат бронирования. Добавьте сообщение на случай, если инструмент уже заняли.
2. Попросите двух людей по очереди найти дрель и оформить заявку на заданное время. Показывайте экраны в ответ на их действия.
3. Запишите, где участники ошибались, что ожидали увидеть и что говорили. Если это знакомые, играющие сотрудников, отметьте, что проверка учебная.
4. Измените места, где возникли трудности. Повторите эти задания и сравните попытки.

Что сохранить

Первую и исправленную версии экранов, заметки о попытках и список изменений.

Как проверить себя

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

Шаг 16. Разобраться, какие данные хранить и как их связать

Разберём на примере

В прокате есть две одинаковые дрели. Записи «дрель забронирована» недостаточно: кладовщику нужно знать, какую именно готовить. У каждого экземпляра должен быть свой номер.

Объект, о котором мы храним сведения, называют сущностью. Клиент, заявка и экземпляр инструмента — разные сущности. Их характеристики называют атрибутами, или полями: например, номер клиента, имя и способ связи.

Между объектами есть связи: у одного клиента может быть несколько заявок. Модель данных показывает эти объекты и связи. На этом шаге мы договариваемся об их смысле. Устройство настоящей базы данных потом уточняют с технической командой.

Что прочитать и посмотреть

1. PostgreSQL — учебник SQL — Прочитайте начало The SQL Language: что такое таблица, строка и столбец. Установка сервера сейчас не требуется. Доступ: английский; открытая документация.
2. diagrams.net — редактор схем — Нарисуйте объекты и соедините связанные. Подпишите, где одному объекту соответствует несколько других. Доступ: бесплатно; выбирайте сохранение на устройство, аккаунт не нужен.

Что сделать

1. Нарисуйте пять прямоугольников: клиент (Client), заявка (Request), тип инструмента (EquipmentType), экземпляр (EquipmentUnit), бронь (Reservation).
2. Дайте каждому объекту свой номер. Соедините связанные объекты и подпишите количество: например, один клиент — много заявок. Такую схему также называют ER-моделью.
3. Опишите минимум 15 полей. Для каждого укажите смысл, вид значения — текст, число или дата, обязательно ли оно, пример и проверку. Начните с номера и дат брони.
4. Проверьте по схеме четыре случая: две одинаковые дрели; две заявки одного клиента; перенос времени; отмена. Запишите, какие записи меняются в каждом случае.

Что сохранить

Схему объектов и связей, словарь полей и четыре разобранных случая.

Как проверить себя

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

Шаг 17. Получить и проверить данные с помощью SQL

Разберём на примере

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

SELECT задаёт столбцы результата, WHERE оставляет строки по условию. GROUP BY собирает строки в группы для расчёта: например, отдельно телефон и сайт. HAVING отбирает уже посчитанные группы.

JOIN соединяет таблицы по связанным полям. Здесь легко ошибиться: у одной заявки могут быть две записи об изменении статуса. После соединения эта заявка появится в двух строках. COUNT(*) посчитает обе строки; число разных заявок нужно считать отдельно.

Что прочитать и посмотреть

1. SQLBolt — интерактивный SQL — Пройдите уроки 1–6 и 10–12. В каждом сначала попробуйте написать запрос сами, затем сравните результат с заданием. Доступ: английский; бесплатные упражнения в браузере.
2. PostgreSQL — учебник SQL — Используйте как справку: Querying a Table — выбор данных; Joins Between Tables — соединения; Aggregate Functions — подсчёты. Доступ: английский; открытая документация.

Что сделать

1. Пройдите указанные уроки SQLBolt. Составьте 3 своих запроса к его таблицам и до запуска запишите, что ожидаете получить.
2. Возьмите данные шага 9. Представьте, что они лежат в таблице requests. Напишите запрос, который по каждому каналу считает число заявок, среднее время и количество конфликтов. Запрос можно сохранить в текстовый файл; устанавливать базу для этого упражнения не обязательно.
3. Проверьте ожидаемый результат в электронной таблице: отдельно отберите phone и web и пересчитайте значения.
4. Нарисуйте на бумаге одну заявку и две записи её статусов. Покажите результат JOIN и объясните, почему подсчёт строк даёт 2, хотя заявка одна.

Что сохранить

Файл с запросами, ожидаемыми результатами и ручными проверками.

Как проверить себя

Вы объясняете разницу WHERE и HAVING на примере групп. Понимаете, почему COUNT(*) после соединения может завысить число заявок. Результат по каналам совпадает с ручной проверкой.

Шаг 18. Понять, как программы обмениваются данными

Разберём на примере

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

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

Бизнес-аналитику нужно понять смысл результата. «Дрель занята» означает понятный отказ. «Ответ не пришёл» означает, что результат пока неизвестен: бронь могла успеть появиться. Если просто повторить создание, можно получить вторую запись.

Что прочитать и посмотреть

1. MDN — обзор HTTP — Найдите Requests, Responses и HTTP flow — запросы, ответы и порядок обмена. В примере покажите метод, код ответа и передаваемые данные. Доступ: английский; открытый текст.

Что сделать

1. Нарисуйте участников: клиент, сайт, программа бронирования, отправка уведомления. Стрелками покажите, кто кому передаёт данные и в каком порядке.
2. Сделайте таблицу одной операции бронирования: какие поля передаём, что получаем при успехе, что получаем при занятом инструменте, неверных датах и недоступной программе. Это черновик правил обмена, который также называют контрактом API.
3. Разберите случай: бронь создана, но ответ потерялся. Запишите, что видит клиент и как команда должна выяснить результат.
4. Подготовьте вопросы техническому специалисту: как узнать прежний результат по номеру запроса, как распознать повтор и кто разбирает случаи с неизвестным исходом.

Что сохранить

Схему обмена, таблицу ответов и вопросы технической команде.

Как проверить себя

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

Шаг 19. Расположить задачи по порядку и обсудить их с командой

Разберём на примере

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

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

В материалах вы познакомитесь со Scrum — способом организации работы команды короткими периодами. Он описывает участников, встречи и общие правила; отдельная должность бизнес-аналитика в нём не задана.

Definition of Done — общие требования к готовому результату команды, например обязательные проверки. Критерии приёмки из шага 13 описывают конкретную историю, например запрет двойной брони. Команде нужны оба уровня договорённостей.

Что прочитать и посмотреть

1. Scrum Guide — официальный текст и переводы — Откройте русский перевод 2020 года. Прочитайте об участниках команды, Product Backlog — списке работы, Sprint Review — обсуждении результата, и Definition of Done — общих правилах готовности. Доступ: есть русский перевод; бесплатно, экзамен и аккаунт не нужны.
2. Agile Alliance — INVEST — Вернитесь к Small и Valuable: проверьте, достаточно ли мала каждая задача и какую пользу она даст. Доступ: английский; открытый текст.

Что сделать

1. Соберите 10 задач в таблицу. Для каждой запишите номер, цель, пользовательскую историю, условия проверки, зависимость от других задач, риск и место в очереди.
2. Выберите 3–4 задачи для первого выпуска. Проверьте, что вместе они позволяют выполнить полезное действие от начала до конца.
3. Для отложенных задач коротко объясните причину: можно обойтись вручную, мало пользы сейчас или сначала нужно другое изменение.
4. За 20 минут обсудите первые задачи с партнёром. Соберите непонятные условия и вопросы для оценки разработки. Учебную оценку обозначьте как предположение.

Что сохранить

Список задач по порядку, состав первого выпуска и вопросы команды.

Как проверить себя

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

Шаг 20. Обновить документы, когда заказчик меняет задачу

Разберём на примере

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

Чтобы найти все затронутые части, свяжите цель, требование, схему, экран и проверку. Эти связи называют трассировкой требований. Например: уменьшить двойные брони → REQ-004 → проверка доступности на схеме → экран подтверждения → тест T-03.

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

Что прочитать и посмотреть

1. IREB — Foundation Level Handbook и Glossary — В Foundation Level Handbook найдите requirements management — работу с требованиями, versioning — версии, traceability — связи. Сравните со своей таблицей. Доступ: английский; справочник бесплатный, для загрузки через IREB Cockpit может понадобиться аккаунт. Экзамен сдавать не нужно.
2. GOV.UK — пользовательские истории — Повторите, как связать историю пользователя и её проверку. Доступ: английский; открытый текст.

Что сделать

1. Создайте таблицу: цель, номер требования, история пользователя, схема или экран, номер проверки. Заполните её для требований проката. Найдите строки без цели или проверки.
2. Добавьте просьбу о втором филиале. По очереди проверьте влияние на действия сотрудников, данные, доступы, обмен между программами, тесты и сроки.
3. Напишите запрос на изменение: что просит владелец, зачем, какие части затронуты, какие есть варианты, что ещё нужно оценить и какое решение предлагаете. Английское название такого запроса — change request.
4. Сохраните документы версии 0.1 и создайте 0.2. В журнале перечислите изменения. Если что-то отложили, укажите причину.

Что сохранить

Таблицу связей, запрос на изменение и две версии документов с журналом.

Как проверить себя

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

Шаг 21. Подготовить проверку готового решения

Разберём на примере

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

Проверку с представителями заказчика называют приёмочным тестированием, или UAT. Для каждого случая заранее запишите исходную ситуацию, данные, действия и ожидаемый результат. После выполнения отдельно запишите, что произошло.

Если результат отличается, выясните причину. Программа могла нарушить требование; требование могло оказаться неясным; пользователь мог предложить новую возможность. Эти случаи нужно различать, чтобы команда понимала, какую работу согласовать.

Что прочитать и посмотреть

1. Cucumber — Gherkin Reference — Найдите Scenario — отдельную проверку, и Scenario Outline — одну проверку с несколькими наборами данных. Возьмите форму записи для своих примеров. Доступ: английский; открытая справка, установка для упражнения не нужна.
2. GOV.UK — пользовательские истории — Сверьте проверки с условиями, которые записали в историях пользователя. Доступ: английский; открытый текст.

Что сделать

1. Подготовьте 12 проверок. Включите успешную бронь, конфликт, отмену, повторное нажатие, неверные даты, чужую заявку и сбой. Для каждой укажите номер требования, исходную ситуацию, данные, действия и ожидаемый результат.
2. Пройдите проверки на бумажных экранах с партнёром. Запишите, какой экран показываете после каждого действия. Отметьте, что это учебная проверка сценария на прототипе.
3. Опишите две найденные ошибки или два учебных примера ошибки: как повторить, что ожидали, что получилось, кому мешает и с каким требованием связано.
4. Для каждой ошибки предложите порядок исправления и объясните срочность. Не выполненные проверки так и отметьте.

Что сохранить

План приёмки, 12 проверок и две карточки ошибок.

Как проверить себя

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

Шаг 22. Подготовить сотрудников к запуску и проверить пользу

Разберём на примере

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

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

После запуска сравните показатели. Если конфликтов стало меньше, проверьте также, все ли заявки записываются и не выросло ли число отказов. На результат могут повлиять сезон, количество клиентов и другие изменения; сравнение «до и после» само по себе ещё не объясняет причину.

Что прочитать и посмотреть

1. GOV.UK — метрики сервиса — Выберите показатель улучшения и показатели, которые не должны ухудшиться. Например, меньше конфликтов при сохранении всех заявок в учёте. Доступ: английский; открытый текст.
2. GOV.UK — discovery — Вернитесь к проверке предположений. Запишите, какие результаты пробного запуска помогут решить, продолжать ли работу. Доступ: английский; открытый текст.

Что сделать

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

Что сохранить

План запуска, проверенную инструкцию и таблицу показателей для наблюдения.

Как проверить себя

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

Шаг 23. Сделать самостоятельный проект

Разберём на примере

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

Используйте приёмы, которые уже попробовали на прокате. Правила библиотеки придётся выяснить заново. Например, нужен ли промежуток между встречами и кто может занять комнату без брони?

Это второй учебный проект для портфолио — подборки работ, по которым можно увидеть ваши навыки. Важны ваши решения, основания для них и исправления после проверки.

Что прочитать и посмотреть

1. GOV.UK — discovery — Используйте вопросы исследования, чтобы проверить полноту своего разбора библиотеки. Доступ: английский; открытый текст.
2. Camunda — BPMN primer — Сверяйте обозначения, когда рисуете процесс новой задачи. Доступ: английский; справка открыта, устанавливать Camunda не нужно.

Что сделать

1. Составьте план на 2–3 недели или выберите подходящий вам срок. Опишите проблему и вопросы сотрудникам библиотеки. Проведите интервью либо учебную беседу по ролям; подпишите, какой вариант использовали.
2. Подготовьте схемы текущей и будущей работы, 10 требований, модель данных, черновики экранов, порядок задач и проверки приёмки. При необходимости вернитесь к соответствующим шагам карты.
3. Попросите партнёра добавить неожиданное условие: доступ внешних посетителей, закрытие комнаты или перенос времени встречи. Обновите затронутые документы.
4. За 10 минут объясните выбор решения и его ограничения. Попросите практикующего аналитика или коллегу разобрать работу по критериям ниже. Если проверяющего пока нет, отметьте оценку как предварительную.
5. Разберите замечания и сохраните исправления. Если проект связан с настоящей организацией, согласуйте, какие обезличенные материалы можно показывать.

Что сохранить

Проект библиотеки, записи решений, новое условие, замечания проверяющего и исправленную версию.

Как проверить себя

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

Шаг 24. Выбрать вакансии и подготовить рассказ о своих работах

Разберём на примере

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

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

Учебные проекты в резюме так и называйте. По ним можно показать ход работы, но они не добавляют годы опыта в компании.

Что прочитать и посмотреть

1. IIBA — The Business Analysis Standard — Посмотрите обзор работы аналитика. Для каждого знакомого действия найдите пример в своих проектах. Доступ: английский; обзор открыт, для загрузки может понадобиться аккаунт. Платную книгу BABOK покупать не нужно.

Что сделать

1. Откройте сравнение программ и вакансий. Выберите интересный вид задач: рабочие процессы, ИТ-проекты, внедрение программ или правила работы с данными.
2. Найдите 10 доступных сейчас вакансий своего региона. Для каждой сохраните ссылку, дату, задачи, обязательные навыки и пожелания.
3. Рядом с каждым важным требованием запишите: что уже умею, какой пример могу показать, чего ещё не хватает. Выберите 3 пробела для дальнейшей учёбы.
4. Подготовьте резюме и короткие описания проектов проката и библиотеки: задача, ваши действия, решение, проверка и ограничения.
5. Проведите пробное собеседование со знакомым. Объясните, почему выбрали решение и что проверили бы дальше. Подготовьте вопросы о задачах, команде и помощи начинающему сотруднику.

Что сохранить

Таблицу вакансий, резюме, два описания проектов и план работы над тремя пробелами.

Как проверить себя

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

Шаг 25. Сравнить направления развития компании

Разберём на примере

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

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

Цепочка ценности показывает, как работа компании приводит к полезному результату для клиента: подобрать инструмент, забронировать, выдать исправный экземпляр, принять обратно. Карта возможностей перечисляет, что компания умеет делать: обслуживать клиентов, управлять запасом, ремонтировать инструменты.

В материалах может встретиться SWOT — список сильных и слабых сторон, возможностей и угроз. Для каждого пункта нужны сведения, которые его подтверждают.

Что прочитать и посмотреть

1. IIBA — The Business Analysis Standard — Найдите Strategy Analysis — стратегический анализ. Прочитайте о текущем положении, желаемом результате, рисках и плане изменений. Доступ: английский; обзор открыт, для загрузки может понадобиться аккаунт. Платную книгу BABOK покупать не нужно.
2. GOV.UK — discovery — Повторите вопросы об ограничениях и возможных способах решения. Доступ: английский; открытый текст.

Что сделать

1. Возьмите учебную сеть из трёх пунктов проката. Запишите одну цель, показатели её достижения и проекты, которые могут помочь. Изобразите их связи.
2. Сравните закупку инструментов, открытие ещё одного пункта и улучшение бронирования. Для каждого укажите нужные данные, затраты, ожидаемую пользу и риск.
3. Нарисуйте путь клиента от выбора инструмента до возврата. Рядом перечислите возможности компании, которые нужны на каждом участке. Отметьте, где есть слабое место.
4. Проверьте рекомендацию для трёх учебных ситуаций: спрос вырос, спрос снизился, обслуживание инструментов подорожало. Запишите, при каком условии измените выбор.

Что сохранить

Записку до двух страниц с рекомендацией, сравнением вариантов, цепочкой действий и картой возможностей.

Как проверить себя

Цель описывает результат для компании. Каждый проект связан с этой целью. Видно, каких данных не хватает для решения. У утверждений о реальных конкурентах есть источники; вымышленные условия подписаны.

Шаг 26. Описать сложные правила и исключения

Разберём на примере

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

Например, возьмите три признака с ответом «да / нет»: новый клиент, дорогое оборудование, есть просрочки. Получится 8 сочетаний. Для каждого нужно определить результат. Если значение неизвестно, отдельно решите, кто его уточняет и можно ли продолжать выдачу.

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

У ожидания тоже должно быть правило. Например, срок подтверждения истёк — сотрудник проверяет ситуацию, бронь снимается по согласованным условиям. В BPMN ожидание времени можно показать событием-таймером.

Что прочитать и посмотреть

1. Camunda — справочник BPMN — Прочитайте о сообщениях, таймерах, частях большого процесса и обработке исключений. Найдите обозначение для каждого нового случая в своей схеме. Доступ: английский; открытые примеры.
2. Camunda — BPMN in Action — По желанию найдите видео Insurance Industry. Обратите внимание, как решение по правилам связано с последовательностью действий. Доступ: английские видео; справка по BPMN также доступна текстом.

Что сделать

1. Создайте таблицу для трёх признаков из объяснения. Заполните все 8 сочетаний и предложите залог или направление на ручную проверку. Суммы и правила подпишите как учебные.
2. Добавьте случай, когда история просрочек неизвестна. Укажите, кто её проверяет и что до этого видит оператор.
3. Проверьте, что для одного набора условий не получаются два противоречащих ответа. Запишите источник или причину каждого правила.
4. Дополните BPMN-схему ожиданием подтверждения, сроком окончания резерва и передачей сложного случая ответственному сотруднику. Такая передача называется эскалацией.
5. Пройдите 5 случаев, включая ответ вовремя, истечение срока и ответ после истечения. Запишите итог для клиента и инструмента.

Что сохранить

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

Как проверить себя

Все восемь сочетаний имеют понятный результат. Неизвестные сведения обработаны отдельно. После истечения срока инструмент не остаётся бесконечно занят без объяснения.

Шаг 27. Провести обсуждение и сравнить готовые программы

Разберём на примере

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

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

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

Что прочитать и посмотреть

1. IIBA — The Business Analysis Standard — Найдите обзор совместной работы, принятия решений и оценки результата. Используйте вопросы из него при подготовке встречи. Доступ: английский; обзор открыт, для загрузки может понадобиться аккаунт. Платную книгу BABOK покупать не нужно.
2. GOV.UK — прототипы — Возьмите подход к проверке сценариев, чтобы подготовить задания для показа готовой программы. Доступ: английский; открытый текст.

Что сделать

1. Проведите встречу с двумя партнёрами: распределите роли владельца, бухгалтера и оператора, а ведение разговора совместите с одной ролью или пригласите ещё человека. Заранее запишите вопрос встречи и нужное решение.
2. Составьте список обязательных условий и желательных удобств. Обсудите, кто утверждает выбор и какие сведения ещё нужны.
3. Сравните две вымышленные готовые программы и собственную разработку. Для желательных свойств задайте важность и оценку по одной шкале, например от 0 до 5. Рядом сохраните основание оценки; вымышленные свойства подпишите.
4. Подготовьте 4 задания для демонстрации программы. Включите конфликт бронирования и проверку прав. Отдельно попросите показать выгрузку данных и опишите переход на другой продукт.
5. Подведите итог: какой вариант проходит обязательные условия, какой рекомендуете и при каких новых сведениях пересмотрите решение.

Что сохранить

План и итоги встречи, таблицу сравнения, задания для демонстрации и рекомендацию.

Как проверить себя

В записи встречи видны разные интересы и принятое решение. Каждая оценка имеет основание. Программа с нарушенным обязательным условием не проходит отбор за счёт удобств.

Шаг 28. Выбрать дальнейшее направление и проверить свои пробелы

Разберём на примере

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

Выберите область, в которой хотите продолжать. Можно изучать внедрение учётных систем, например ERP или 1С; работу над ИТ-продуктами; процессы компании; правила хранения и использования данных — это направление часто называют Data Governance.

Инструменты искусственного интеллекта, или AI, могут предложить вопросы и заметить противоречия в тексте. Каждое замечание нужно проверить по условиям задачи. Для упражнения используйте только вымышленные сведения. Придуманное инструментом правило ещё не является договорённостью с заказчиком.

Ожидания от senior различаются по компаниям. Обычно это работа с большей ответственностью и сложными задачами. Опыт таких решений набирается в проектах с обратной связью.

Что прочитать и посмотреть

1. IREB — Foundation Level Handbook и Glossary — Просмотрите содержание Handbook и отметьте темы работы с требованиями, в которых ещё не уверены. Доступ: английский; справочник бесплатный, для загрузки через IREB Cockpit может понадобиться аккаунт. Экзамен сдавать не нужно.
2. MDN — обзор HTTP — Если выбрали работу над ИТ-продуктами, повторите обмен между программами и обработку ошибок. Доступ: английский; открытый текст.
3. PostgreSQL — учебник SQL — Если выбрали работу с данными, найдите темы SQL, которые ещё не можете объяснить на своём примере. Доступ: английский; открытая документация.

Что сделать

1. Выберите одно направление. Найдите 5 свежих вакансий и выпишите общие задачи, нужные знания и примеры работ, которыми их можно подтвердить.
2. Подберите небольшой следующий проект. Например, для внедрения учётной системы — разобрать перенос записей об инструментах и проверить, что после переноса не потерялись активные брони.
3. Возьмите 10 своих вымышленных требований. Попросите партнёра или, по желанию, доступный AI найти противоречия. Проверьте каждое замечание по исходным условиям. Добавьте известную вам ошибку и посмотрите, найдёт ли её проверяющий.
4. Составьте план на 90 дней: задача, чему нужно научиться, кто проверит результат, за что отвечаете вы и когда пересмотрите план. Добавьте дату повторной проверки ссылок и вакансий.

Что сохранить

План дальнейшей учёбы, следующий проект и таблицу проверки замечаний партнёра или AI.

Как проверить себя

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