Reverse Engineering требований. Часть 2. Особенности общения с бизнес-стейкхолдерами
Обновлено: 4 янв. 2019 г.
И снова здравствуйте! В предыдущей части мы сказали пару слов об общем подходе к восстановлению требований. Сегодняшней статьей мы начинаем погружаться в детали, а именно особенности интервьюирования бизнес-стейкхолдеров.
Представители бизнеса являются хорошим источником информации об исследуемом решении. Но здесь есть свои подводные камни, давайте разбираться, откуда они берутся.
Решение не может охватывать всех мыслимых кейсов использования. Даже при разработке космической и военной техники не получается предусмотреть все. Хотя это узконаправленное ПО, на проектирование которого тратятся огромные бюджеты, баги и пропущенные кейсы все равно проникают туда. (вот тут небольшая подборка: https://habr.com/post/381073/) Казалось бы, нет ничего страшного в том, что инженеры не учли что-то при производстве: недочеты можно исправить в следующей итерации. Но тут вступает в силу другой фактор: отсутствие поддержки.
Сразу после стадии внедрения, бизнес остаются один-на-один с решением. У него может быть поддержка, но она не вечна. Причины могут быть очень разные: начиная с завершения контракта (все же работает, зачем платить), заканчивая уходом фирмы-производителя с рынка.
И вот бизнес имеет на руках решение, которое больше не поддерживается создателями, и постепенно меняющийся контекст его использования. Начинают возникать различные непредусмотренные инструкциями кейсы. Естественно, что никто из ТОПов не будет останавливать бизнес-процессы только потому, что возник исключительный случай, которого нет в документации. Применяя смекалку будет найден обходной путь. Часто, кстати, такие кейсы не доходят не только до ТОП-менеджмента, ответственного за решение, но даже до действующей службы поддержки.
Таким образом, любая более-менее сложная и большая система начинает жить своей жизнью. Давайте пройдемся по группам пользователей, определенных в BABOK (свод знаний по бизнес-анализу) и посмотрим, что нас ждет в беседе с ними.
End User (конечные пользователи решения). Большой плюс в работе с ними в том, что они непосредственно взаимодействуют с решением и могут показать, как данное решение помогает им выполнять рабочие задачи.
С чем нужно быть осторожными:
Им может быть неинтересно рассказывать как оно работает прямо сейчас - это их ежедневная работа. И как следствие
рассказывая о системе, они могут без предупреждения перескочить на то, как бы им хотелось, чтобы она работала
Плохо умеют систематизировать свои знания, и очень часто забывают об операциях. Причем забыть могут как о самой частой операции (само собой разумеющиеся), так и об очень редкой (действие, происходящее раз в год)
Они знают только свою часть бизнес-процесса и имеют, как правило, только предположения о том, что происходит до них и после них. К сожалению, пользователи редко отделяют в речи предположения от точно известных фактов
Очень разнородны даже в рамках одного подразделения. Бывает так, что из всего отдела только один конкретный человек выполняет некоторую функцию. Большая удача, если вам об этом расскажут. Такое разделение обязанностей - очень частая причина пропуска информации
Вот хороший пример проблемы этой группы стейкхолдеров. “В большом многопрофильном стационаре возникла проблема с нашим, уже внедренным решением. Несколько важных статистических отчетов перестали сходится между собой. Разница была огромна, и мы помогали разбираться в причине. Технически мы установили что данные не заносятся в БД. Однако сотрудники отдела, отвечающие за их ввод, продемонстрировали нам свою работу, в процессе которой все заносилось полностью и корректно. Ошибок не возникало, в базу все складывалось, но потом из нее исчезало. Баги исключили. Через какое-то время (не без воли случая) мы узнали, что сотрудники этого же отдела, сидящие в соседнем кабинете (пусть будет кабинет 2), целенаправленно удаляют данные, которые заводят их коллеги. Статистики кабинета 2 не заносили данные в систему и не отвечали за тот самый несходящийся отчет из кабинета 1 (хотя в целом пересечения их функций было почти 100%), зато у них недавно появился свой собственный отчет (с которым в кабинете 1 не работали), который они строили на данных третьего отчета, который также строился на данных кабинета 1. Из-за схемы данных, получалось так, что часть вводимых данных им мешала получать нужные цифры, поэтому они их удаляли, чтобы решить конкретно свою задачу. Мы сделали им отдельный отчет и провели повторное обучение.”
Operational Support. Это очень интересная группа людей, которая может принести много полезной информации. Если конечный пользователь сталкивается с какой-то проблемой, он обращается сюда. В итоге информация может копиться, ведь единичный эпизод для пользователя, скорее всего выветрится из памяти, а вот саппорт получит с десяток похожих тикетов и сможет обобщить проблему. Кроме того, из-за того что поддержка работает с решением в целом, она может очертить большие фрагменты БП, а иногда и весь БП целиком. Однако, информация получаемая от них имеет свои особенности:
Люди часто срастаются с решением, начинают ассоциировать себя с ним. Из-за этого неоптимальные практики ими не признаются как проблемы, и не поднимаются в беседе (система хорошая, пользователи плохие)
Их знание процесса может быть поверхностно. Часто они не в курсе того, почему пользователи делают то, что делают, воспринимая это как факт. Однако, они могут давать свои интерпретации действиям и неосознанно выдавать их за факты.
Часто это малоинициативная группа, незаинтересованная в изменениях. Разговорить их тяжело.
Являясь техническими специалистами, могут уходить в чрезмерные детали.
Sponsor. Как человек отвечающий за границы решения (часто в виде контроля бюджета) может пролить свет на какие-то странные шаги в бизнес-процессе, о которых предыдущие группы не знают. Однако
Он крайне редко погружается до конца в проблему, а если и погружается, то забывает о ней сразу после решения.
Поскольку это обычно менеджер среднего звена и выше, он может перестать получать сведения об изменениях, происходящих внизу: на его уровень поступает обобщенная информация. Поэтому его представления о непосредственной работе оказываются устаревшими, но выяснится это только на сверке с информацией из других источников.
Крайне загруженный человек, до которого бывает тяжело добраться. Из-за этого много информации так и остается не найденной.
Customer (Клиенты бизнеса). Имеются ввиду клиенты бизнеса, который пользуется решением. Они не так часто вовлечены в работу с решением, и еще реже доступны для интервьюирования. Тем не менее, если есть возможность с ними поговорить (например через сбор фокус-группы), то с чем мы можем столкнуться?
Не умеет до конца пользоваться решением, из-за чего изобретает велосипед. в итоге вы получаете неверные сценарии работы.
Низкая заинтересованность и низкое доверие к работе с бизнес-аналитиком, представляющим стороннюю организацию.
Также им присущи недостатки конечных пользователей.
Regulator. На первых этапах обычно бесполезен как источник информации, однако он может прояснять отдельные ограничения решения про которые остальные участники были не в курсе. Этот тот самый человек, который скажет, что по другому нельзя, потому что есть закон/положение/рекомендации/стандарты.
Supplier/Vendor. Иногда решения использует уже готовые компоненты, предоставляемые третьими лицами. В этом случае они могут быть дополнительным источником информации по деталям реализации, но
Идут на контакт крайне редко (для этого надо как минимум заключенный договор поддержки).
Если вы снимаете с эксплуатации их решение, могут саботировать вашу работу.
Могут отсутствовать в принципе (например, обанкротились, ушли из рынка данной страны и т.д.).
К сожалению, нет волшебной кнопки, которая позволит решить все вышеописанные проблемы. В целом можно рекомендовать две вещи:
Кросс-проверки информации из разных подразделениях о работе друг друга
Сверка с другими источниками.
Техники "Наблюдение" и "Анализ документов"
Тренинги от "Art of Business Analysis":
Data Science и машинное обучение для бизнес-аналитиков (8-9 февраля, 2018)
Базовые компетенции бизнес-аналитика (16 февраля, 2019)
Комплексный тренинг по бизнес-анализу (20 - 24 марта, 2019)