Приехала я на выходные к родителям. Заранее сказала номер поезда и вагона, напомнила дату и время прибытия, договорились, что меня встретят на вокзале. Сразу после приезда сообразила какую важную информацию не обсудила перед поездкой. Как и положено родителям, им важно эмоционально подпитаться за счет вкусностей и полезностей для ребенка. Было куплено много копченого, соленого, сладкого и разного вкусного. Смотрю на стол и понимаю, что забыла предупредить о своей диете. Понятно что из этого вышло – свежие жареные котлеты, сало и вкусная колбаса остались нетронутыми, а эмоциональная подзарядка конвертировалась в хаос и разочарование. Вот как так? Можно пару десятков лет заниматься требованиями к процессам и решениям и все равно потерять совершенно очевидные шаги 😎
В классификации требований BABOK мне нравится отдельно выделенный вид требований к переходу (transition requirements). Сам по себе не лишний акцент на необходимости сформулировать условия перехода от текущего состояния к целевому.
Переходные требования (требования переходного периода): описывают возможности, которыми должно обладать решение, или условия, которым оно должно соответствовать, чтобы обеспечить переход из текущего состояния в будущее. Переходные требования решают такие вопросы, как конвертация данных, обучение, обеспечение непрерывности бизнеса. (из BABOK 3.0)
Чтобы сформулировать такие требования нужно очень хорошо понимать какие проблемы закрывает решение, анализировать разрыв между текущим и будущим состоянием, идентифицировать риски, предложить и согласовать стратегию работы с этими рисками. Это касается не только изменений ключевых процессов всей организации, но и небольших доработок. Перемещение поля из одного угла экрана в другой может потребовать обучения, если речь о фронт-офисном приложении для операционных сотрудников, которые потеряют время на поиск поля по экрану и так замедлится обслуживание клиентов.
Требования к переходу по особенностям выявления и частоте "забывания" близки к нефункциональным требованиям. Transition requirements узко направлены и чаще всего "одноразовые" так как касаются перехода от конкретного сценария к другому, картина один в один может больше не повториться. Само по себе такое требование предотвращает риск нарушить интересы заинтересованных сторон и создать новые риски. Условия перехода должны рассматриваться как часть общей стратегии перехода к целевому состоянию. Этими требованиями нужно заниматься, когда все части решения уже согласованы.
Заинтересованные стороны редко дают информацию об условиях перехода, они не готовы оценить и увидеть общие риски. Требуется наблюдательность и погружение во внутренние процессы. Примерный список вопросов, на которые нужно ответить:
📍Насколько изменение зависит от навыков пользователей?
▫️Нужно ли дополнительно информировать кого-то?
▫️Может ли отсутствие обучения повлиять на выполнение сотрудниками их работы?
📍Понадобится миграция данных?
▫️Нужно трансформировать существующие в БД данные? полностью или частично?
▫️Нужно перенести данные, которые до этого существовали вне системы? Например, автоматизируете процесс, который до этого поддерживался в файлах и в них накопились данные, без которых ваше изменение не взлетит
▫️Есть ли регуляторные ограничения переноса данных? Например, для переноса в систему клиентских данных нужно запросить отдельное согласие для такого способа обработки клиентских данных.
▫️Данные должны быть перенесены строго одновременно с внедрением новой фичи?
📍Что понадобится, чтобы отключить текущее решение?
▫️Можно просто отключить или нужен эволюционный план из нескольких шагов?
▫️Нужно удалить\архивировать какие-то данные? Заблокировать доступы? Допустимо ли это с точки зрения регуляторов?
▫️Существуют финансовые риски? Что будет если сделаем это позже?
В моей истории про еду и диету от неполных требований пострадала и я сама. Вокруг меня было много вкусного, а я была вынуждена говорить: "я это не ем" 🥹
#инструменты #кейсы