Введение
Представьте, что перед вами стоит задача переправлять груз на другой берег. Вы съездили в командировку в другую страну, увидели чугунный мост и твердо решили – вам надо!
Вернулись, выбили бюджет, команду и началась стройка. Проходит год, заложенный на проект, мост не готов: то чугун не той марки, то прораб уволился, то наводнение. Вы начинаете разумно и неразумно экономить, ведь бюджет закончился. Пускаете в ход свое обаяние и выбиваете еще денег, которых снова не хватает на задуманный в вашей голове результат, проходите все этапы принятия и волевым решением закрываете проект.
Стоя на деревянных перекрытиях, которые должны были быть гранитной брусчаткой, задаете себе вопрос «Зачем я вообще в это ввязался? Для чего был нужен мост?.. Точно, два раза в год отправлять 15 кг груза!»
И начинаете подозревать, что проблема изначально решалась не мостом.
Что, если в самом начале к реке вместе с вами подошёл бы человек, который начал бы задавать вопросы:
— Что именно мы переправляем?
— Как часто?
— Что для нас важнее — скорость, стоимость или надежность?
Услышав ответы, он наверняка предложил бы: «А что, если вместо многомиллионного моста мы просто купим надежную лодку? Она справится с нашей задачей, будет готова через неделю и сэкономит нам львиную долю бюджета». Проще говоря, ответив на эти вопросы, Вы бы сами скорее всего предложили лодку.
На наш взгляд, эта метафора прекрасно отражает суть бизнес-анализа в IT-разработке. Это не про то, чтобы «лучше описать мост». Это про то, чтобы услышать истинную потребность и найти самый оптимальный путь для ее удовлетворения. Часто к реке выходят только Заказчик с его «мостом» и Системный аналитик без мандата на проверку бизнес‑гипотезы. В итоге Системный аналитик вынужден реализовывать решение, целесообразность которого не была подтверждена на уровне бизнес‑требований, поскольку на процессном уровне не выделяются этапы, которые позволяют за предложенным решением истинную потребность и найти самый оптимальный путь ее удовлетворения.
Именно эта ситуация — хроническая «просадка» этапа обследования бизнес-потребности — стала главной темой нашего исследования в ходе реализации проекта компании Axenix по оптимизации процессов для российского банка. Мы – Дарья Августанович, Lead анализа, и Александра Ионова, руководитель проектов – взялись за решение задачи повышения уровня зрелости этапа бизнес- и системного анализа.
Определения
Прежде чем перейти к описанию кейса, рассмотрим определения:
Все начинается с формулировки бизнес-проблемы со стороны Бизнес-заказчика. В контексте этой статьи под «Бизнесом» мы подразумеваем владельцев продуктов и подразделений, определяющих экономику и развитие; процессных методологов, отвечающих за регламенты и контроль; внутренних заказчиков из подразделений, которым нужны IT-решения для выполнения практических задач.
Содержание работ Бизнес-анализа может довольно сильно отличаться в зависимости от специфики деятельности компании, но в целом — это процесс исследования и дизайна. Результат Бизнес-анализа - Бизнес-требования. Это документ на человеческом языке, который отвечает на вопросы: «Какую бизнес-проблему мы решаем?», «Какое решение мы для этого реализуем?», «Как изменится жизнь пользователей?», «Как мы поймем, что достигли успеха?» Этот документ понятен Бизнесу и позволяет получить обдуманное согласование выбранного решения.
Системный анализ — это процесс конструирования выбранного решения, он относится к процессу разработки. Его задача — понять, КАК именно мы построим то, что придумали. Системный аналитик берет готовые бизнес-требования и переводит их на язык систем: проектирует API, описывает алгоритмы, продумывает все «если» и «но», создавая техни��еское руководство к действию для разработчиков. Результат системного анализа — Функциональные спецификации/Техническое задание. Это чертеж для строителей, подробная инструкция «что куда подключать».
Итак, в идеале этап Бизнес-анализа формируют связь между бизнесом и командой разработки. Что же происходит, если в организации решают, что бизнес и команда разработки «сами договорятся»?
Кейс
Клиент – российский банк для частных лиц – обратился в Axenix с задачей помочь провести оптимизацию IT-функции банка, которая насчитывает более 500 сотрудников. IT-функция использует как методики классического проектного управления (Waterfall), так и гибкие методологии (Kanban). Проблемы: огромные затраты на IT, низкая удовлетворенность Бизнеса результатом, большой Work in progress.
В процессе обследования этапа постановки задачи и анализа были проведены десятки интервью, опросы, проанализированы проблемные кейсы. Мы поняли, что столкнулись с довольно распространенной картиной: функция исследования и проработки бизнес-потребности размыта между разными ролями, не формализована (в отличии от других этапов разработки), а потому неэффективна, что приводит к системным сбоям на всех уровнях.
Такой подход означает, что Системный аналитик принимает на вход сырые, неоднозначные вводные от Бизнеса и вынужден то ли выполнять предыдущие этапы самостоятельно (не имея для этого ни ресурсов, ни шаблонов, ни, возможно, соответствующих компетенций), то ли сразу приступать к системному анализу. Цитаты из интервью с бизнес-заказчиками красноречиво сигнализируют о симптомах:
«Ни одна задача не выходит на продуктив без ошибок. Функционал вроде бы соответствует ТЗ, но на практике ломает соседние процессы и создает негативный опыт для клиентов»
«Мы тратим время не на развитие продукта, а на поиск и исправление проблем»
«Команда IT неверно поняли задачу, функционал оказался не востребован, мы потратили на переделки полгода»
«Системные аналитики очень медленно выполняют свои задачи. Разработка простаивает»
«Задачи могут ждать реализации годами, нужно больше ресурсов»
Интересно, что описанные проблемы адресуются к функции IT в целом, но практически никто не критикует этап Бизнес-анализа: сложно критиковать то, чего нет. Большой объем негатива направлен в сторону системного анализа, может сложиться впечатление, что именно эту функцию и стоит усиливать в первую очередь; достается и разработке с тестированием. Возможно, поэтому ежегодно растет ФОТ на IT, при этом скорость выполнения задач едва ли удается увеличить. Системные аналитики не остаются в стороне со своими обвинениями: бизнес-требования невнятные и постоянно меняются. Команда перегружена, а бизнес все равно не удовлетворен результатом.
Почему так произошло? Организация, стремясь к гибкости, возложила на Бизнес-функцию исследования и анализа решения, но не компенсировала дополнительную роль ни четкими стандартами, ни новыми выделенными компетенциями. В результате Бизнес данную роль не принял и переложил на системного аналитика. Системный аналитик, в свою очередь, вынужден проводить бизнес-анализ, так как именно на него легла вся ответственность за требования в полном объеме. Системный аналитик также не получил ни новых стандартов, ни дополнительных компетенций, ни времени для выполнения данного этапа. В итоге четко выделенной функции нет, куски Бизнес-анализа разорваны между ролями:
Владельцами бизнеса/продукта (думают о стратегии и экономике);
Владельцами функций/подразделений (думают об эффективности процессов);
Методологами (фокусируются на соблюдении регуляторных требований, оптимизации банковских процессов);
Владельцами очереди заявок, которые вынуждены «дорабатывать» фичу за заказчиком;
В значительной же мере функция бизнес-анализа выполняется системными аналитиками, которые вынужденно разбираются с «вкинутыми» в них пожеланиями и идеями;
Также в значительной мере задачи Бизнес-анализа просто пропускаются;
Что делать?
Для решения проблемы нужен системный подход, который, на наш взгляд, состоит из трех элементов:
Выделить этап. Для начала следует формализовать в процессе разработки обязательный этап анализа бизнес-потребностей. Этот этап должен быть встроен в workflow до передачи задачи в системный анализ.
Внедрить артефакт. Результатом этого этапа должен стать конкретный артефакт — «Бизнес-требования (БТ)». Этот документ, написанный на человеческом языке, который подлежат обязательному согласованию с бизнес-заказчиком. Это превращает абстрактные «пожелания» в четкую задачу с понятными границами.
Определить ответственность. Выделить отдельную роль (бизнес-аналитика), обладающую нужными компетенциями, которая будет отвечать за этап и артефакт.
В нашем кейсе мы столкнулись с трудностями по третьему пункту: заказчик настаивал на решении проблемы силами существующей команды. Иными словами, этап и артефакт были выделены, однако ответственность за них была распределена между текущими ролями: Бизнес-заказчик берет на себя глубокое погружение в проблему и обоснование ценности, Системный аналитик развивает навыки исследования и проектирования бизнес-сценариев.
Однако, на наш взгляд, такое решение хорошо только как промежуточное, и мы надеемся, что Заказчик выделит Бизнес-аналитика в отдельную роль. Почему компромисс — это только полшага?
Почему Бизнесу сложно быть "самому себе аналитиком"?
«Вот тут я буду спать, тут — есть, а тут — пусть будет фонтан!» - примерно так же выглядел бы запрос бизнеса, если бы ему пришлось строить дом. Системный аналитик тщательно переносит эти идеи на чертежи и начинается стройка… В результате почему-то ужинать приходится на кровати, в ванной зияет дыра в крыше (задумывалось, что это помогает сэкономить воду, позволяя мыться под дождем…), а фонтан оказался никому не нужен, что, впрочем, к лучшему, потому что слив никто не предусмотрел.
Все это не вопрос компетенции или желания бизнеса сформировать качественные требования, это фундаментальный конфликт ролей и мышления.
Бизнес, обладая экспертностью в своей зоне ответственности, как правило, по умолчанию не обладает знаниями, навыками и инструментарием бизнес-аналитика. Никто не считает, что можно написать код на Java без специального обучения, однако иллюзия о том, что бизнес-анализ может быть выполнен любым сотрудником, встречается часто и часто же дорого обходится;
Бизнес сфокусирован на целях и функциях, его задача зарабатывать деньги или обеспечивать процессы. И едва ли компания выиграет от того, что бизнес будет тщательно изучать окружение своих продуктов или отделов вместо того, чтобы выполнять основные функции («зарабатывать деньги»);
Бизнес не видит экосистему. Его взгляд замыкается на его продукте. Он не думает и не должен думать о том, как новая функция повлияет на мобильное приложение, колл-центр, отдел безопасности;
Бизнес не видит альтернатив. Его решение — единственно верное в его глазах. Сразу два когнитивных искажения говорят о том, что с научной точки зрения взглянуть на свою идею критически намного сложнее, чем кажется на первый взгляд. «Эффект якоря» заставляет давать завышенную оценку первому пришедшему на ум решению, а «предвзятость подтверждения» - подгонять доказательства под имеющееся решение вместо того, чтобы опровергнуть его и искать альтернативы. Эти же искажения мешают проработать негативные сценарии;
Еще одно когнитивное искажение - «проклятие знания» - мешает инициатору-эксперту сформировать качественные и понятные требования: он живет своими процессами годами и на автомате пропускает очевидные (для него) шаги и термины. Он не может абстрагироваться от своей экспертизы и посмотреть на процесс глазами нового пользователя или другого подразделения. Поэтому он создает «дырявые» требования: в его голове всё сходится, но на бумаге остаются роковые пробелы. «В требованиях отсутствовало обязательное поле на фронте. Для бизнеса это было настолько само собой разумеющимся, что оно даже не было озвучено»
Бизнес не может быть сам себе аналитиком по той же причине, по которой хирург не может сам себе делать операцию на аппендицит. Нужна дистанция, специализированный инструментарий и взгляд со стороны.
Если говорить про банковскую сферу, то мы довольно часто сталкиваемся с мнением, что функцию бизнес-анализа должны выполнять банковские методологи. Банковский методолог — это ��пециалист, который разрабатывает и описывает внутренние процессы банка, а также создает и поддерживает нормативные документы, чтобы обеспечить соответствие законодательству и эффективную работу. Он действительно лучше всех знает банковские процессы и может подсказать, как создавать новые продукты из текущих процессов. Однако по умолчанию фокус методолога направлен внутрь организации, на ее процессы, а также на соблюдение требований, в то время как для качественного анализа нужен взгляд на клиента, на рыночные возможности и на скрытые, не формализованные еще боли. Таким образом, методолог, вероятно, может взять на себя выполнение роли бизнес-анализа, однако, во-первых, для этого нужно развивать дополнительные компетенции, которых может не быть, во-вторых, методологу необходимо выделить дополнительное время для данной роли.
С бизнесом все ясно… так пускай эту роль выполняет системный аналитик?
Почему совмещение Бизнес‑ и Системного анализа в одном лице приводит к потерям?
Вернемся к примеру про строительство дома. Почему системного аналитика не смутила дыра в потолке? Почему он не подумал о том, действительно ли нужен фонтан?
Ключевой вопрос Системного аналитика: «КАК это реализовать?» Он берет готовую, согласованную бизнес-цель и проектирует технический путь её достижения. Его задача — убедиться, что система будет работать корректно, надёжно и эффективно. Системный аналитик не заточен на то, чтобы задавать вопрос «ЗАЧЕМ нам это делать?» Зрелый Системный аналитик может поднять красные флаги по вопросам целесообразности задачи либо если видит несостыковки на уровне архитектуры, безопасности, данных и стоимости владения. Однако в целом он исходит из того, что поиск корневой проблемы и оптимального решения проработаны на предыдущем этапе.
Если бизнес-аналитик смотрит на задачу глазами пользователя или бизнеса, то фокус системного аналитика — целостность системы. Он смотрит на задачу изнутри IT-ландшафта. Его волнует, как новая функция впишется в существующую архитектуру, не сломает ли она другие процессы, как будут взаимодействовать API и где храниться данные. Он защищает интересы системы.
Системный аналитик мыслит в рамках технических ограничений. Услышав идею, он сразу начинает подбирать для неё технические решения и наталкивается на известные ему ограничения: «Это нельзя сделать, потому что наше API не поддерживает такие запросы», «Это займёт полгода, потому что нужно менять ядро Legacy-системы». Бизнес-аналитик должен мыслить в рамках «идеального мира». Его задача — сначала сформулировать, что именно нужно бизнесу и клиенту в идеале, без оглядки на технику. Это позволяет находить неочевидные и более эффективные бизнес-решения.
Системный аналитик говорит на языке функциональных спецификаций, UML-диаграмм и нефункциональных требований. Его документ — это инструкция для разработчика. Попытка Системного аналитика напрямую пообщаться с бизнес-заказчиком часто приводит к взаимному непониманию. Бизнес сообщил нам в интервь��: «Мы вынуждены согласовывать спецификации, не читая. Потому что мы все равно их не понимаем»
Системный аналитик является главным инженером решения и — особенно в высокорискованных доменах (банки, регуляторные требования, данные) —накладывает право вето на нереализуемые или небезопасные решения. Но без Бизнес-аналитика — архитектора ценности — это вето может похоронить перспективную бизнес-идею без поиска альтернатив. Без диалога данных ролей есть риск строить либо надежные, но никому не нужные системы, либо генерировать рискованные и нежизнеспособные идеи.
Негативные последствия
Чтобы оценить эффект от «экономии» на этапе исследования бизнес-задачи мы сделали модель для сравнения стоимости ошибок в зависимости от этапа их обнаружения. Для расчета модели приняты следующие параметры:
Для расчета взята задача со следующим объемом работ по этапам: • Бизнес-аналитик: 5 человеко-дней (чд) • Дизайн: 2 чд • Системный аналитик: 6 чд • Разработчик backend: 6 чд • Разработчик frontend: 6 чд • Тестировщик: 6 чд
| Средняя ЗП для расчета: • Бизнес-аналитик: 167 тыс./руб. • Дизайн: 127 тыс.руб. • Системный аналитик: 224 тыс./руб. • Разработчик backend: 244 тыс.руб. • Разработчик frontend: 224 тыс.руб. • Тестировщик: 150 тыс. руб. (Данные по зарплатам с Habr. Карьера) Дополнительные затраты (налоги, ДМС, офис и пр.) на сотрудника учтены с коэффициентом 1,5 к ЗП. Не учтено: - управленческие затраты; - риски потери дохода и репутации.
|
Дополнительные параметры: • Ошибка приводит в полной переработке задачи • Работы идут последовательно. Запараллеливание работ (дизайн в параллель с анализом, frontend в параллель с backend) увеличит стоимость ошибки | |
Ошибка, обнаруженная на этапе исследования потребности равна стоимости самого бизнес-анализа (63 тыс.руб.). Если же бизнес-анализ не проведен/проведен некачественно, это увеличивает риск возникновения ошибки на последующих этапах. Если та же самая ошибка обнаружится на этапе тестирования, она будет стоить компании в среднем 460 тыс.руб., то есть до 8 раз выше.
Отсутствие формализованного этапа бизнес-анализа приводит также к неоптимальной загрузке команды. Системный аналитик получает сырые требования, которые необходимо сначала проработать с точки зрения бизнес-анализа, что ожидаемо, затягивает работу аналитика. Если бы Системный аналитик занимался только системным анализом, он смог бы подготовить требования для 2-3 разработчиков за период. Однако поскольку Системный аналитик вынужден сначала углубляться в бизнес-анализ (который к тому же не является его специализацией) за тот же период он подготовит системные требования только для 1-2 разработчиков. В результате мы наблюдаем либо перегруз и выгорание системных аналитиков вкупе с простоями разработки (как в исследуемом кейсе), либо вынужденное расширение штата системных аналитиков.
Заключение
История клиента, о котором идет речь выше, как и опыт многих других наших заказчиков, убедительно доказывает: попытка сэкономить на качественном бизнес-анализе — это иллюзия. На самом деле компания платит многократно дороже: испорченной репутацией, ушедшими клиентами, сорванными сроками и выгоревшими сотрудниками, которые вынуждены тушить постоянные пожары.
Критическая важность бизнес-анализа заключается в том, что он находится в самом начале цепочки. Ошибка, заложенная на старте, подобна кривизне в первом кирпиче большого здания: она не останется незамеченной, а будет многократно усилена и проявится на каждом последующем этапе. В лучшем случае это выльется в постоянные доработки, переделки и конфликты по всей цепочке — от заказчиков до тестировщиков. В худшем — мы безупречно, в срок и в рамках бюджета разработаем и внедрим то, что идеально решает не ту проблему.
Выстраивание сильной, централизованной и компетентной функции бизнес-анализа — это не затраты, а инвестиция в предсказуемость, скорость и, в конечном итоге, в качество цифровых продуктов.
Возникает резонный вопрос: разве описанные проблемы не должен решать продуктовый подход? Безусловно, должен. Но он — финальная цель, а не стартовая точка. Если ваша компания только движется в сторону продуктовой модели, бизнес-анализ выступает мощным инструментом оперативного улучшения. Он не конкурирует с продуктовым подходом, а решает те же задачи discovery (подробнее о discovery в рамках продуктового подхода – ссылка на статью ) — прояснение требований, приоритизацию и доставку ценности — в рамках существующей, часто "проектной", реальности.
Наш опыт в сопровождении продуктовых трансформаций показывает, что выстраивание процессов бизнес-анализа - прагматичное и быстро окупаемое решение. При этом роль бизнес-аналитика органично вписывается и в продуктовые команды. Такой специалист обладает набором навыков, критически важных для продуктовой разработки: умение соединять бизнес и ИТ, выявлять реальные потребности пользователей, оценивать бизнес-эффект и грамотно расставлять приоритеты. В результате он становится естественной частью новой структуры, обеспечивая преемственность и усиливая её эффективность.
