Модель основных понятий бизнес-анализа

baccm3Буквально вчера вышел в свет второй номер журнала Российских Бизнес Аналитиков и начинается он со статьи Георгия Савельева «Сущность биpнес-анализа», в которой, в частности, речь идет о новой модели компетенций бизнес-аналитика. Мне очень нравится как Георгий рассказывает о бизнес-анализе и особенно о том, что его назначением является выявление и устранение неопределенности, а результат деятельности аналитика не картинки и тексты, а ментальные модели, обеспечивающие понимание. Обязательно посмотрите эту статью. От себя лишь добавлю несколько слов о новой модели ключевых понятий Business Analysis Core Concept Model (BACCM). Может показаться, что она слишком сложная, особенно по сравнению с предыдущей из 2-ой версии BABOK Guide. Прежняя модель включала всего три понятия: предметная область, решения и требования. В новой модели их шесть и среди них есть такие непонятные слова как needs, values, changes. Зачем все это надо? И так ведь все понятно. Аналитик собирает требования у заказчика и транслирует их разработчику. На самом деле, это очень упрощенная модель и на практике все выглядит совершенно по-другому.

Разработчики с утра до вечера правят баги и пишут новый функционал. Сорокачасовой рабочей недели им ясно на это не хватает. Заказчик все равно не доволен. Вместо обещанного решения от ИТ он получает проблему. Очередь из запланированных доработок  выстраивается на несколько лет вперед. Все начинают искать виноватых. Сначала на эту роль назначают тестировщиков, не способных обеспечить должное качество ПО, потом разработчиков, но в результате добираются и до аналитиков. И вот уже никто не сомневается в том, что истинная причина всех проблем в плохих требованиях. Я выскажу крамольную мысль, но причина не в требованиях. Требования никогда не бывают полными непротиворечивыми, однозначно трактуемыми и т.д. как того требует IEEE-830. Причина в том, что стоимость внесения изменений превосходит ту пользу, которую заказчик от них получит. Проще говоря, мы тратим больше, чем зарабатываем и единственный адекватный вопрос в такой ситуации: зачем мы все это делаем?

В этом нет ничего нового. Экономически обосновать затраты на разработку ПО всегда было сложно. И есть достаточное количество публикаций с данными о том, что затраты на ИТ не окупаются. Но давайте не будем спешить. Если в организации налажен процесс проектного управления, то она не станет инициировать проекты не имеющие положительного бинес-кейса. Скорее всего, и у нашего проекта с экономикой когда-то все было не плохо. Что же случилось и почему сейчас все стало так сложно? Для того чтобы раскрыть ответ на этот вопрос мне понадобиться простая картинка. По оси X(время) мы будем отмечать появление релизов нашего ИТ-решения. На оси ординат мы отобразим сразу два параметра: ценность, которую приносит заказчику наш продукт и затраты на его создание, доработку и поддержку.

solution

В первой версии системы у нас все хорошо. Мы, как люди опытные, реализовали в ней наиболее приоритетные требования. Принцип Парето никто не отменял и реализация 20% таких требований приводит к получению 80% процентов выгоды. Ценность решения для заказчика очевидна, да и мы не сильно перетрудились. Премии, шампанское, статья в районной газете.

К версии номер 2 ситуация немного меняется. Все висящие низко яблоки(quick wins) мы уже сорвали, а так как при запуске сильно спешили, то сорвали вместе с ветками. Остались более сложные и менее важные требования от первой версии, появилось какое-то количество новых требований и возникших в ходе эксплуатации пожеланий. В системе накоплен некоторый технический долг и изменения стало вносить сложнее. Постепенно утрачивается экспертиза, т.к. ключевых людей вытаскивают на другие проекты. Но желание долгосрочных отношений с заказчиком и опыт прошлых побед помогает нам справиться и со вторым релизом.

Релиз номер 3. Осень. Солнце уже не светит так ярко, опадает листва, птицы улетают на юг, а наши боссы уже включили выручку от этого релиза в годовой план по прибыли. Заказчик особо ничего не хочет. Ему осталось сделать косметические изменения, чтоб получить последние 10% ценности. Если это случится, то проект будет признан экономически успешным. Разработчики понимают, что система получилось не очень хорошей.  Самые неугомонные из них вынашивают идею большого рефакторинга. Когда о том что, по мнению программистов, самое время заново переписать всю систему узнает заказчик, он впадает в ярость. Поэтому реализуем требования заплатками и костылями. К этому времени «умные» с проекта уже соскочили и, в отличии от нас, Новый год они будут встречать дома с семьей.

Как не попасть в ситуацию номер 3 и что делать, если она все же случилась. Воздержусь от банальных заявлений о том, что в релизе номер 1 надо было думать об архитектуре, создавать повторно используемые компоненты, писать тестовые скрипты и документацию. Это уже неактуально. Вот что действительно следовало сделать с самого начала, так это научиться измерять наши затраты и выгоды заказчика. Не обязательно в деньгах, можно и в любых других попугаях. И делать это должен бизнес-аналитик, причем не от релиза к релизу, а на регулярной основе. Сидеть вместе с бизнесом и методично измерять его пользу (см. Верните аналитика в бизнес). Тогда хоть можно попытаться уклониться от ненужного релиза.

Что делать если релиза номер 3 не избежать? На самом деле, в такой ситуации нет ничего из ряда вон выходящего. Люди, которые занимаются крупными B2B продажами, сталкиваются с ней постоянно. Обычно им надо продать решение на несколько миллионов долларов. А удовлетворение потребности заказчика в автоматизации позволяет заработать несколько тысяч. Казалось бы задачка не решаемая. Вовсе нет. С точки зрения продаж ситуация номер 1 существенно хуже. Заказчик знает чего хочет и может себе это позволить. Он контролирует ситуацию. Скорее всего, конкретную сделку закроет тот, кто предложит наименьшую цену, что всегда рискованно и не особо выгодно с точки зрения экономики. Однако, наш опыт подсказывает, что компании регулярно покупают ИТ-решения на миллионы долларов. Почему так происходит? Все дело в откатах… нет, в технологии продаж и предпродажной работы.  Продавцы крупных ИТ-решений хорошо понимают, что  высказанные клиентом потребности это только часть айсберга и при умелой работе можно насобирать потребностей  не на один миллион. Чем они собственно и занимаются в ходе presale. Предлагаю вернуться к статье Георгия Савельева и найти в ней цитату Марка Твена: «Проблемы создает не то, чего мы не знаем, а известное нам наверняка, которое на деле таковым не является». Продавцы работают «в голове клиента» с его ментальной моделью, перестраивая её в свою пользу. Аналитик мог бы делать то же самое, но на порядок профессиональней, если бы не был занят конспектированием очередной порции требований. А тем временем все новые «вкусные» требования уходят в соседний проект. А если они окажутся слишком сложными или не очень нужными, то их тоже перенесут на релиз номер 3.

Конечно, все что я описал выше, в некотором роде, гипотеза, требующая проверки и подтверждения в реальных проектах. Но о словах needs, value, solution, определенно стоит задуматься. Уверен, что и другие статьи во втором номере журнала российских бизнес-аналитиков окажутся не менее интересными. Планирую со временем прокомментировать их в своем блоге. Большое спасибо авторам и участникам выпуска журнала.

Модель основных понятий бизнес-анализа: 2 комментария

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *