Как разобраться в существующей системе или процессе
В старой системе есть три правды: та, что написана, та, что рассказывают люди, и та, что записана в данных и логах. Знакомство с системой - это сверка этих правд.
В прошлых статьях мы учились задавать вопросы людям. Здесь мы разбираем, как входить в систему, которую мы не писали и которая уже работает. Система здесь - это любой работающий продукт или процесс, в который нужно внести изменение.
Кейс: админка «Узелка», которую никто не описывал
Для отмены заказа нужно добавить новый переход в статусах заказа. Админка «Узелка» работает уже давно. Описания статусов в документах нет, разработчик, который их делал, уже в команде не работает.
Если просто придумать новый статус, мы рискуем сломать то, что уже опирается на старые: склад, отчёты и письма покупателям. Сначала нужно понять, как статусы устроены сейчас.
От написанного к реальному
Знакомство удобно строить в порядке от того, что задумано, к тому, что происходит. Каждый источник даёт своё и не даёт другого.
- Документы. Смотрим не только текст, но и дату последнего обновления: старый документ описывает прошлое.
- Люди. Выясняем, кто работает с модулем и давно ли. Владелец модуля - тот, кто отвечает за него и может объяснить причины решений.
- Интерфейс. Проходим сценарий так, как его проходит пользователь, и записываем каждый шаг и каждое сообщение.
- Данные. Смотрим, какие значения статусов реально встречаются и как один заказ менял их со временем.
- Логи. Лог - это журнал событий системы: что и когда произошло. Ищем в нём один конкретный заказ по номеру и читаем его путь.
Как читать данные и логи подробнее, рассказано в статье 05-31. Здесь важно только место этих источников в общем плане.
Что делать с расхождениями
Расхождение - это случай, когда два источника отвечают по-разному. В старой системе они почти неизбежны, и важно не выбирать победителя самим.
Данные и логи показывают, что произошло на самом деле. Документ показывает замысел. Человек может объяснить причину, но помнит её по-своему. Поэтому расхождение мы не разрешаем сами: записываем оба ответа и несём вопрос владельцу.
В кейсе документ говорит «отмена до отправки», а в данных есть отмены и после сборки. Мы не делаем вывод, что прав документ. Мы записываем расхождение и спрашиваем заведующего складом, кто и почему снимает статус после сборки.
Что записать после знакомства
Итогом знакомства становится не длинный отчёт, а четыре списка: что система делает, кто чем владеет, где источники расходятся и что неизвестно.
Список расхождений и список неизвестного становятся основой вопросов к людям по логике из 02-04. Те же списки потом подходят для проверки неполноты требований, об этом расскажет статья 02-18.
Как распланировать знакомство
Порядок важнее сроков. Сначала читаем написанное и спрашиваем людей, потом смотрим, как система работает для пользователя и в данных, и в конце сверяем.
План на рисунке условный: три дня мы взяли как пример, на реальной системе сроки будут другими.
Где это встречается в работе
- При переходе на новый проект, где система уже работает.
- Перед доработкой модуля, описание которого устарело.
- Когда разработчик, знавший модуль, ушёл из команды.
- При разборе инцидента, когда нужно понять, как процесс работает на самом деле.
Итог
- В старой системе три правды: написанная, устная и фактическая.
- Источников пять: документы, люди, интерфейс, данные и логи.
- Расхождение не разрешают сами: записывают и несут владельцу.
- Итогом знакомства становятся четыре списка: что делает, кто владеет, что расходится, что неизвестно.
- Порядок плана: сначала написанное, потом реальное, затем сверка.
Что дальше
- 05-31: как работать с данными и логами подробнее.
- 02-18 Неполные и противоречивые требования: что делать с найденными пробелами.
- 02-03 Как выявлять требования: как повторить круг, если остались неясности.
5 вопросов