Привет, Хабр! Я Анастасия Глущенко, бизнес‑аналитик направления BI в Департаменте аналитических решений, Корус Консалтинг. Люблю красивый, сочный визуал, а также яркие и емкие метафоры — короче говоря, я та еще сказочница. И в этой статье я расскажу именно о сказочных персонажах и ситуациях, которые встречаются на пути аналитика. Ведь всем знакома фраза «иди туда — не знаю куда, принеси то — не знаю что»?
Начну с контекста
Я работаю в консалтинге, поэтому регулярно взаимодействую с самыми разными людьми — любезными и грубыми, вежливыми и не очень. И иногда, казалось бы, два очень похожих проекта развиваются по совершенно разным сценариям из‑за особенностей взаимодействия как внутри команды, так и с заказчиком.
Действительно, в основе любого ИТ‑проекта лежит именно коммуникация, а взаимодействие с бизнесом, как правило, строится на следующих вопросах:
Как выявляете истинные потребности стейкхолдеров, а не только их хотелки?
Как решаете конфликты требований и приоритизируете их?
Какие методы для сбора информации используете?
Какие выводы делаете на основании сведений, полученных от стейкхолдеров?
Как презентуете результаты своей работы?
Ответы могут быть разные, но, несмотря на это, все ИТ‑проекты имеют определенную структуру, проходят через схожие этапы, а их конечная цель — создание ценности для заказчика.
Бизнес‑ценность — это основа основ, но иногда так бывает, что она не рождается. И мне всегда было интересно понять, в какой момент и по какой причине ценность продукта, решения или системы уходит на второй план. И для этого я выбрала не самый стандартный способ.
Дело в том, что я мама трехлетнего ребенка, и в моей жизни достаточно прочно поселились сказки. Я заметила, что в любой сказке сюжет развивается по схожему сценарию. Точно так же, как ИТ‑проекты проходят через определенные этапы. И я подумала, почему бы не посмотреть на ИТ‑проект, как на сказочную историю?
В этом нам поможет интересный труд «Морфология волшебной сказки» Владимира Проппа. Сразу оговорюсь, я очень далека от филологии, поэтому расскажу вам кратко для дальнейшего понимания: в книге Владимир Пропп описал общую для всех сказок структуру, сформировал типологию действующих лиц (герой, вредитель, даритель, волшебный помощник, царевна или ее отец, отправитель, ложный герой) и выделил 31 повторяющуюся постоянную функцию действующего лица. У каждого героя может быть одна или несколько функций. Потрясающая структура, в которую вписывается любая сказка от «Колобка» до «Гарри Поттера».
Труд получил широкое распространение по всему миру в смежных областях — кинематографе, драматургии. Особый же успех формула получила в политологии для создания политических нарративов. Бизнес‑аналитик тоже своего рода политик, вынужденный лавировать между интересами разных сторон. Поэтому морфологию волшебной сказки Владимира Проппа можно очень продуктивно переложить на работу бизнес‑аналитика, если рассматривать ИТ‑проект как сюжет о переходе заказчика из проблемного состояния в желаемое.
Я буду анализировать всем до боли знакомые проблемы коммуникации с заказчиком на примере сказки «Царевна Лягушка». А в качестве ИТ‑проекта возьмем, например, проект по разработке дашборда для крупного заказчика.
Сопоставление ролей в ИТ‑проекте и персонажей по Проппу
Итак, сперва с каждым персонажем сказки я сопоставила какую‑либо роль или сущность в ИТ‑проекте. Что у меня получилось:
Роли у Проппа | Роли в ИТ‑проекте |
Герой | Заказчик/Владелец продукта |
Отправитель | Совет директоров/Рынок/Кризис |
Антагонист | Текущая система/Разрозненные данные/Excel |
Даритель | Бизнес‑аналитик |
Помощники | Команда разработки |
Ложный герой | «Знающий» пользователь/«Power user» с Excel/Менеджер без полномочий |
Царь | Стейкхолдер с бюджетом |
Царевна | Ценность/Бизнес‑результат |
Важно обратить внимание, что бизнес‑аналитик здесь выступает не героем, а дарителем, и в дальнейшем вы поймете почему.
Основные функции и ситуации
Дальше я решила выделить несколько основных функций, которые упоминаются Владимиром Проппом и есть в каждой волшебной сказке, и соотнести их с реальными проектными ситуациями.
«Отлучка» — возникновение проблемы
В сказке все начинается с того, что герою чего‑то не хватает. Иван Царевич пускает стрелу, чтобы найти себе жену. Но находит лягушку.
В проекте же это первое соприкосновение с заказчиком, когда он приходит к нам со своей проблемой: падают продажи, нет возможности отслеживать картину бизнеса в реальном времени, нет доверия к цифрам в отчетах и так далее
Ключевая задача бизнес‑аналитика: не бежать решать проблему прямо здесь и сейчас, а зафиксировать ее, например, с помощью Problem Statement Worksheet, а также провести подробную пресейл‑оценку.
Нарушение запрета и вредительство (недостача)
В сказке, как правило, существует какой‑то запрет, который герой благополучно нарушает: нельзя сжигать лягушачью кожу, пока рано Василисе Премудрой быть в человеческом обличии. Иван Царевич ослушался и сжег лягушачью кожу, Василиса Премудрая отправляется к Кощею Бессмертному. Тут злодей наносит ущерб, появляется так называемая недостача.
В проекте злодей — это не какой‑то конкретный человек или действие, это комплексное явление. Например, ручные корректировки данных, Legacy‑система, отсутствие DG&DQ в целом и т.д
Ключевая задача бизнес‑аналитика: описать портрет этого злодея как процесс AS IS.
Отправление героя
В сказке Иван Царевич отправляется в путь за своей женой.
В проекте заказчик решается что‑то менять, соглашается инвестировать время и деньги, заключает договор, назначает команду со своей стороны, принимает правила игры.
Ключевая задача бизнес‑аналитика: и хоть на этом этапе большая роль отводится руководителю проекта, бизнес‑аналитик должен сформулировать бизнес‑цель и зафиксировать критерии успеха.
Испытание дарителем и получение волшебного средства
В сказке по пути герой встречает волшебного помощника — старика. Тот дает Ивану Царевичу волшебный клубок, который должен привести к Кощею.
В проекте это этап сбора и валидации требований. Бизнес‑аналитик задает неудобные вопросы, например: «Почему эту цифру вы берете из 1C, а эту считаете в Excel?». Заказчик может упираться.
Ключевая задача бизнес‑аналитика: не обижаться, не спорить, продолжать проверять гипотезы. Волшебное средство — это не готовый дашборд, как вы могли подумать (он лишь носитель магии), а зафиксированная методология расчета показателей, бизнес‑глоссарий, макеты дашбордов, прототип витрины, архитектура решения. В общем, все то, что находится «под капотом», потому что хороший бизнес‑аналитик не столько дает меч, сколько учит им пользоваться.
Борьба и победа
В сказке герой находит дуб, где спрятан сундук со смертью Кощея, и начинаются метаморфозы: яйцо в утке, утка в зайце и так далее. В конечном итоге Иван Царевич ломает иглу, на конце которой смерть Кощея, и побеждает злодея.
В проекте это этап реализации, в ходе которого возникают конфликты приоритетов, изменения скоуп. В итоге мы все‑таки побеждаем, выводим решение в прод, проходим приемо‑сдаточные испытания, проводим демо.
Бизнес‑аналитик здесь — переводчик, арбитр, хранитель смысла. Он следит за соблюдением договоренностей, зафиксированных в ТЗ, контролирует, чтобы все члены команды были в едином смысловом контексте, удерживает фокус, приоритизирует требования и задачи. На финальном этапе ключевая задача бизнес‑аналитика не просто проверить «работает или нет», а исчезла ли недостача — та самая «боль» заказчика, с которой он к нам пришел изначально. Критерий успеха — измененное поведение пользователя, а не UI (например, руководитель стал принимать управленческие решения быстрее на основании актуальных и наглядных данных на дашборде).
Возвращение и преследование
В сказке Иван Царевич возвращается домой с Василисой Премудрой.
В проекте это вся жизнь после релиза (а есть ли она вообще?). Появляются запросы на новые срезы, масштабирование системы на другие подразделения.
Бизнес‑аналитик продолжает работы в рамках ОПЭ, помогает управлять ожиданиями и отделить завершенный сюжет от нового.
Бизнес‑аналитик — это даритель, который помогает герою пройти путь, не присваивая себе подвиг и не путая сказку с инструкцией. В итоге дашборд — это финал сказки, а не ее начало. Если начать с визуализации, то герой не готов, волшебство не работает, заказчик разочарован.
Антипаттерны: где сказка «ломается»
В эту классную структуру, казалось бы, идеально вписываются все наши ИТ‑проекты. Но иногда заказчик все равно получает не то, что предполагалось изначально. И я выделила основные причины таких ситуаций.
Нет недостачи
Заказчик увидел красивый дашборд у конкурентов и хочет такой же: «Нам просто нужен дашборд, хотим как у X, мы не знаем зачем, но надо». Что происходит на самом деле: сказка начинается с волшебного предмета, а не с проблемы, герой не знает, зачем он в пути. На выходе мы получаем бесконечные правки, субъективную оценку результата и «красиво, но бесполезно».
Бизнес‑аналитик становится героем вместо заказчика
Такое часто случается, когда сталкиваются волевой и энергичный бизнес‑аналитик уровня эксперт и сомневающийся, нерешительный заказчик. Бизнес‑аналитик сам предлагает метрики и придумывает требования — «я лучше знаю, как вам надо». Даритель подменяет героя, и после релиза мы получаем отказ от продукта, потому что это не то, что заказчик имел в виду.
Ложный герой захватил сюжет
Все мы иногда сталкиваемся с такими персонажами, которые громче всех выкрикивают свою позицию на общих встречах — старожилы компании, Excel‑гуру, те самые незаменимые сотрудники заказчика. Что будет, если принимать на веру требования только таких персонажей? Ложный герой узурпирует право на интерпретацию реальности, и разработанный дашборд будет закрывать лишь локальные цели конкретных сотрудников. В результате руководство заказчика перестанет доверять данным на дашборде.
Даритель пропустил испытание
В силу нехватки времени или квалификации бизнес‑аналитик принимает требования без анализа с мыслью «потом разберемся», не задает дополнительных вопросов, не копается в контексте и деталях — как говорится, если заказчик не чувствовал себя неудобно, то бизнес‑анализа не было. В этом случае проект входит в реализацию «без магии». Мы не только разработаем не то, что хотел заказчик, но еще и накрутим туда лишней логики, лишних показателей, сомнительной методологии.
Победа формальная
Комплексное явление, которое заключается в том, что первоначальная проблема заказчика, его «недостача», не ликвидирована. Дашборд есть, решений на его основании нет. Показатели смотрят, но не используют. Ручные данные продолжают жить. Это означает, что бизнес‑цель и боль пользователя не закрыты. Нет истинного финала сказки, так как поведение героя не изменилось.
Вместо вывода
Я не претендую на серьезность использования этой модели по функциям Проппа везде и всюду. Но мне кажется, что, если посмотреть на работу бизнес‑аналитика с такой стороны, можно немного структурировать коммуникацию, снизить хаос требований, разглядеть типовые ловушки взаимодействия и найти ответ на вопрос «почему технически мы все сделали, а бизнес все равно недоволен?». Модель Проппа можно использовать:
● На старте проекта (кто герой и в чем его недостача?)
● При конфликте требований (это борьба с антагонистом или ложный герой?)
● При смене скоуп (это новый сюжет или продолжение текущего?)
● При выгорании (я случайно не стал героем вместо заказчика?)
Я составила небольшой чек‑лист для бизнес‑аналитика по функциям Проппа:
Функция | Вопросы | Красные флаги | Артефакт |
Отлучка | Можно ли четко сформулировать проблему? Чего бизнес не может сделать сейчас? | «Чтобы было красиво» | PSW |
Запрет | О чем не хотят говорить? Что заказчик не хочет обсуждать? | «Так исторически сложилось» | Пресейл‑оценка |
Недостача | Есть ли расхождения в цифрах? | «Данные плохие, у всех разные» | Процесс AS IS |
Отправление | Каковы критерии успеха? Назначены ли роли со стороны заказчика? | «Сделайте сами, мы потом посмотрим» | Матрица RACI |
Испытание дарителем | Есть ли у каждой метрики решение, владелец? | «Просто для информации» | Согласованные требования |
Получение волшебства | Можно ли заменить инструмент и сохранить ценность? В чем магия решения? | «Надо как в PBI» | Модель данных, прототипы, архитектура |
Борьба | Я все еще защищаю смысл, а не инструмент? | «Раз уж делаем, давайте все» | Бэклог с приоритетами |
Победа | Принимаются ли решения быстрее/иначе? | «Надо приучить пользоваться» | Вывод в прод, ПСИ, ретро |
Возвращение | Не происходит ли ничем не ограниченное «доделывание»? | «Ну это же мелочь» | Подписанные акты, протоколы тестирования |
На самом деле, если закрыть первый столбец «функция», останутся те вопросы, красные флаги и артефакты, которые призваны помочь бизнес‑аналитику в его работе и облегчить его взаимодействие с заказчиком.
С теми ситуациями, про которые я рассказала выше, мы все периодически сталкиваемся, но зачастую игнорируем их. А возможно, если бы мы уделяли им больше внимания, многих недоразумений удалось бы избежать, и мы бы всегда разрабатывали ценные для заказчика продукты.
Ведь на самом деле хороший ИТ‑проект — это правильно рассказанная сказка, где каждый знает свою роль, чтобы функции не перепутались.
