Вы только еще задумываетесь о том, чтобы стать бизнес-аналитиком? Или Вы опытный бизнес-аналитик с десятками успешных проектов за плечами? В любом случае, Вы не могли не задавать себе вопрос – где находятся вершины мастерства бизнес-анализа. В этой статье я попытаюсь дать ответ на этот вопрос с точки зрения работы с требованиями.
Базовый уровень
Основной девиз начинающего бизнес-аналитика звучит так: «Делай, как написано в инструкции». Основная цель бизнес-аналитика на этом этапе своего развития – научиться основам мастерства в бизнес-анализе, не допускать элементарных ошибок в своей работе.
Работа бизнес-аналитика начинается с выявления заинтересованных сторон.
Заинтересованная сторона (stakeholder) – физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям [1].
На этом этапе важно выявить все заинтересованные стороны – никого не пропустить. Пропущенные заинтересованные стороны – эта ошибка является, наверное, наиболее распространенной в работе начинающего бизнес-аналитика. Такая ошибка приводит к пропущенным требованиям, которые останутся скрытыми от бизнес-аналитика и команды проекта.
Основные техники выявления заинтересованных сторон [2]:
- номинирование заинтересованных сторон основным заказчиком;
- изучение документации;
- выявление заинтересованных сторон на основании шаблона «колесо заинтересованных сторон»: владельцы, менеджеры, сотрудники, администраторы (супервизоры), поставщики, партнеры, пользователи, конкуренты.
Кейс №1. Web-сайт с заявкой посетителя
Компания занимается доставкой воды. Она заказала разработку web-сайта. Одно из требований директора компании к web-сайту состояло в том, чтобы на сайте была форма заявки на доставку воды. Нужно определить заинтересованные стороны.
На форуме [3] было размещено следующее сообщение (орфография сохранена):
Хотелось бы услышать советы, как вы поступаете в ситуациях, когда Клиент не хочет выполнять свою работу, т.е. он не заинтересован в вашей услуге или не понимает, почему он тоже должен работать.
Приведу примеры:
1. Компания занимается доставкой воды, этой компании разрабатывают web-сайт с формой заявки на доставку воды.
Но менеджеры компании отказываются обрабатывать заявки в электронном виде, просто «забывают» о них, работают в привычном режиме, по телефону.
Мы сообщаем об этом их директору, он обещает разобраться, но ситуация повторяется.
2. Аналогичная ситуация в частной клинике. Пациенты записываются на прием, но администратор клиники не хочет перезванивать или проверяет почту раз в неделю, когда уже поздно.
3. Автосервис. То же самое.
Как быть нам как подрядчику?
«Забить», пусть решают сами, свою работу мы выполнили — так рассуждает большинство, но мы так не можем, хотя бы жалко так бросать неплохой проект.
Продолжать убеждать руководителя компании, чтоб он убеждал своих менеджеров обрабатывать заявки, нельзя ведь перевоспитывать Клиента :).
Предложить директору техническое решение в обход менеджеров, чтоб заявки сами попадали в их базу (которая чаще всего не работает, либо ведется как попало).
Может, у вас есть иной опыт решения подобных проблем?
Очевидно, описанная в кейсе проблема возникла из-за того, что на стадии выявления заинтересованных сторон по каким-то причинам не было уделено должного внимания менеджерам компании. Соответственно, их требование «не увеличивать количества источников поступления заявок от покупателей» осталось скрытым. Это привело к необходимости искать дополнительные решения уже после завершения разработки web-сайта, т.е. на стадии его внедрения.
Что должен знать и уметь БА базового уровня?
Для того, чтобы правильно выявлять заинтересованные стороны, БА должен обладать навыками системного мышления. БА должен уметь понимать, как разрабатываемая информационная система будет вписываться в процессы заказчика. Для этого БА должен пользоваться следующими техниками:
- многоэкранная схема системного мышления;
- анализ жизненного цикла системы;
- основы бизнес-систем (B2B) и дизайн-мышления (B2C).
Уровень продвинутого бизнес-аналитика
У Вас за плечами багаж опыта в виде десятка выполненных проектов и надпись на визитке «очень грамотный бизнес-аналитик». Вы уже понимаете, как иногда трудно извлекать требования заинтересованных сторон. Но Вы также понимаете, как важно извлекать требования заинтересованных сторон на ранних стадиях проекта, как сложно вносить изменения, когда по ходу проекта вдруг всплывают новые, не выявленные ранее требования.
Основные техники для извлечения требований заинтересованных сторон [4]:
- интервью;
- рабочие совещания (обсуждения);
- анкетирование;
- фокус-группы;
- прототипы;
- сценарии.
Вы, наверное, задумывались, почему применение разнообразных техник извлечения требований не гарантирует, что все требования будут выявлены, а также не останется скрытых требований, которые всплывут на поздних стадиях проекта.
Я попробую дать свой ответ с помощью диаграммы Кано, на которой изображены различные типы ожиданий заинтересованных сторон.
Performance needs (ожидания повышения эффективности) находятся в фокусе внимания заинтересованных сторон. Именно ради реализации этих ожиданий заказчик чаще всего и затевает проект. Часто эти ожидания связаны с решением конкретной бизнес-проблемы заказчика.
Как правило, бизнес-аналитику легко работать с ожиданиями повышения эффективности. Заинтересованные стороны подробно рассказывают о них, поскольку эти ожидания находятся в фокусе внимания. Соответственно, бизнес-аналитик должен тщательно зафиксировать эти ожидания и трансформировать их в требования.
Сложнее работать с базовыми ожиданиями (Basic needs) заинтересованных сторон. Этот вид ожиданий является одним из основных источников скрытых (неявных) требований.
Неявные требования [5] – требования, которые явным образом не описаны в документации, но:
1) зависят от других явных требований;
2) подчиняются законам математики, физики;
3) вытекают из жизненных реалий.
Одна из основных причин того, что именно базовые ожидания являются основным источником неявных требований, состоит в том, что заинтересованные стороны рассматривают такие требования как само собой разумеющиеся.
Кейс 2. Треугольник
Источник: [1]
Чтобы бизнес-аналитик мог эффективно работать с базовыми ожиданиями заинтересованных сторон, он должен хорошо разбираться в предметной области заказчика. Однако, не всегда проекты выбираются в соответствии с областью экспертизы бизнес-аналитика – бизнес-аналитик часто сталкивается с новыми предметными областями.
Что должен знать и уметь продвинутый БА?
Для того, чтобы правильно выявлять базовые ожидания, БА должен обладать навыками системного мышления и знаниями универсальных законов развития систем. БА должен в очень короткие сроки суметь разобраться в предметной области заказчика и понять основные принципы функционирования его системы. Для этого БА должен владеть следующими техниками:
- причинно-следственный анализ;
- общая теория систем и процессов (например, бизнес-систем);
- структурный анализ систем и процессов (как устроены система или процесс);
- функциональный анализ систем и процессов (как система или процесс функционирует)
Бизнес-аналитик высшего класса
Для того, чтобы быть конкурентоспособным, сегодня уже недостаточно реализовать ожидания повышения эффективности и базовые ожидания заказчика. Бизнес-гуру утверждают, что для успеха нужно удивить заказчика. Удивить его можно, если предоставить заказчику решение, которое реализует его сверхожидания (excitement needs).
Опытные бизнес-аналитики – настоящие мастера бизнес-анализа, имеющие за плечами не один десяток реализованных проектов, – могут за кружкой чая рассказать несколько историй, когда удавалось реализовать сверхожидания заказчиков, и о том, какое огромное удовлетворение получали все участники такого проекта.
Сложность со сверхожиданиями состоит в том, что заинтересованные стороны не могут их сформулировать. Бизнес-аналитик должен выявить эти сверхожидания какими-то другими способами.
Кейс №3. Планирование документооборота
В системе корпоративного документооборота есть возможность планировать сроки движения документа: документ создан в организации, известны (нередко даже нормативно определены) сроки обработки и движения этого документа для каждого подразделения организации. Когда же документ обрабатывается у контрагента, планировать сроки обработки такого документа затруднительно, так как неизвестны нормативы контрагента. Можно было бы согласовать нормативы с контрагентом и зафиксировать их в договоре, но если контрагентов очень много (десятки тысяч), то такие согласования становятся недопустимо трудоемкими.
Сверхожидания, как правило, связаны с какой-то нерешенной проблемой в бизнес-системе заказчика. Заказчики даже могут осознавать наличие проблемы, но они не знают, как ее решить. В лучшем случае заказчик может рассказать бизнес-аналитику о существовании проблемы. Но, как правило, заказчик редко акцентирует внимание на таких нерешенных проблемах, руководствуясь принципом: «если уж мы не знаем решения, то чем тут может помочь новый человек со стороны?»
Что должен знать и уметь БА высшего класса?
Для того, чтобы выявлять и решать проблемы заказчика и тем самым удовлетворять его сверхожидания, бизнес-аналитик должен обладать специальными навыками и применять особые техники:
- Причинно-следственный анализ противоречий (дерево текущей реальности, дерево противоречий, RCA+, VCM+);
- Алгоритм Решения Изобретательских Задач (анализ противоречий);
- Техники ТРИЗ по устранению противоречий.
Особенность методов и техник ТРИЗ состоит в том, что для их овладения требуется определенный склад мышления, который в ТРИЗ называется изобретательским мышлением. Для того, чтобы его развить в себе, необходимо затратить определенное время на тренировку. Не каждый бизнес-аналитик, достигнув определенного уровня зрелости, способен принять вызов и освоить новую для себя область.
Экстра-класс (80 уровень)
Есть специалисты, которые умеют работать с будущим. В разных сферах деятельности их называют по-разному: футурологи, прогнозисты, дженералисты, визионеры… и даже гадалки.
Кейс №4. Развитие услуги спутникового мониторинга
Услуга спутникового мониторинга предоставляет клиентам данные о состоянии транспортного средства (ТС) в режиме реального времени. Эти данные используются клиентами в процессах управления эксплуатацией ТС. А как будут развиваться потребности в будущем?
Бизнес-аналитик 80 уровня умеет спрогнозировать развитие бизнес-системы заказчика, в том числе ее продуктов, рынков и бизнес-модели, а также определить требования, которые возникнут в процессе такого развития. При этом бизнес-аналитик будет сталкиваться с еще не возникшими проблемами и должен находить решения для таких проблем. Важно отметить, что такие проблемы могут быть еще не видны даже заказчику, но бизнес-система ими уже «инфицирована». Искусство бизнес-аналитика 80 уровня как раз и состоит в том, чтобы видеть невидимое.
Что должен знать и уметь БА экстра-класса?
Для того, чтобы уметь прогнозировать развитие бизнес-систем, БА должен обладать навыками продвинутого системного мышления и изобретательского мышления, в том числе, уметь пользоваться следующими техниками:
- Общие закономерности и линии развития систем;
- Исследование больших данных и поиск новых закономерностей;
- Прогнозирование развития систем.
Заключение
В этой статье деятельность бизнес-аналитика рассматривалась только с точки зрения работы со скрытыми требованиями. Хотя работа с требованиями и является одним из основных элементов в деятельности бизнес-аналитика, все же деятельность бизнес-аналитика сводится не только к работе с требованиями.
Но важно осознать, что достижение высот мастерства возможно. Всему можно научиться, а практический опыт отшлифует приобретенные знания и умения и неизбежно приведет Вас к вершинам мастерства.
Ссылки
- ISO/IEC 15288:2008, ISO/IEC 29148:2011
- по материалам http://requirementstechniques.wordpress.com/stakeholders-stakeholder-identification-requirements/
- Форум triz-ri.ru
- по материалам http://requirementstechniques.wordpress.com/elicitation/
- Юденко Н. Явные и неявные требования. https://www.youtube.com/watch?v=4AYoRhbViwA
Эффективный методв выявления «Basic needs» — техника наблюдения (активного/пассивного). К сожалению в статье она не отнесена к требуемым знаниям БА продвинутого уровня.
См. ниже. п. 2.
Денис, вы правы, техника наблюдения тоже может применяться для сбора требований.
Но она тоже не дает гарантии получения полных требований, так как мы можем наблюдать деятельность в течение ограниченного периода времени. Не факт, что в течение этого периода времени в наблюдаемой деятельности встретятся всех возможные кейсы. Могут быть редко встречающиеся кейсы, но очень важные кейсы, которые просто не попадут в сферу внимания аналитика.
Техника наблюдения не просто может, а активно применяется именно для понимания рабочего окружения и скрытых требований. Прелесть данной техники в ее простоте и эффективности.
Как побочный результат — выстраивание доверительных отношений с представителями заказчиком.
А гарантию выявления полных требований не дает ни одна техника.
Относительно временных трудозатрат и выявления редко случающихся кейсов. Существует практика автоматизированного наблюдения со сбором статистических данных. Она может помочь решить данные пробелемы. Главное, чтобы заказчик разрешил съем такой информации.
Для важных, но редко случающихся кейсов зачастую предусматривают специальные административные функции (ручное внесение правок и т.п.)+ workaround. Кроме того, именно в ходе наблюдения возникают вопросы типа «А что вы делаете, если этих данные нет» и т.д. Наблюдая за процессом и понимая какой информацией, алгоритмами и т.д. оперирует конечный пользователь, аналитик генерирует вопросы относительно исключительных ситуаций.
Денис, лишь я хочу обратить внимание на то, что при сборе базовых ожиданий аналитик попадает в особую ситуацию: люди, за которыми он наблюдает, совершают само собой разумеющиеся действия, а аналитик видит эти действия, возможно, впервые в жизни. Требуются особые навыки, чтобы разглядеть и не упустить из виду важные особенности, которые являются само собой разумеющимися для наблюдаемых.
Что касается автоматизированного наблюдения, то в будущем роль этой техники для извлечения требований будет только возрастать. Один из современных трендов — интернет вещей — как раз и базируется на том, что все предметы и системы вокруг нас будет оснащаться датчиками и сенсорами и генерировать данные о том, как этими предметами и системами пользуются. Естественно, для БА эти данные станут неоценимым источником для анализа и выявления требований, в том числе, скрытых, о которых сами пользователи иногда даже не подозревают.
В рамках активного наблюдения аналитик просить объяснить, почему люди поступают так или иначе (в т.ч. думать вслух_. Т.е. упустить возможности становится сложнее.
А если мы налюдаем в качестве подмастерья, т.е. выполняем под присмотром соответсвующие действия, то упустить общие закономерности становится сложнее.
Денис, я согласен, что при активном наблюдении можно очень хорошо погрузиться в предметную область, даже достигнуть уровня выше подмастерья. Но, здесь мы сталкиваемся с противоречием между глубиной погружения в предметную область и временем, необходимым для такого погружения.
И дабы разбавить позитивом это обсуждение (а заодно и дополнить мой список http://www.slideshare.net/nadiatarasiuk/ss-35130610) я добавлю в перечисленное еще один способ поиска скрытых требований: аналитик рассказывает, как он понимает работу системы, например, игрушечному жирафу.
Таким образом, подробно формулируя для жирафа логику работы системы, аналитик может найти «узкие места», логические нестыковки, а также правильно сформулированный жирафу вопрос может уже содержать половину нужного ответа
по аналогии с https://en.wikipedia.org/wiki/Rubber_duck_debugging.
Разумеется, это шутка, но доля здравого смысла в таком подходе тоже присутствует)
Вот как это называется, оказывается… Похоже я в команде периодически для разработчиков вместо rubber duck:).
Андрей, на мой взгляд было бы полезно в статье сразу ставить ссылки на более подробное описание, которое ты уже давал здесь или на triz.by. Например, для «многоэкранная схема…», «VCM+» и т.д.
з.ы. Да, я в курсе, что есть гугл.
Подробнее о модели Кано по ссылке: http://www.fdfgroup.ru/?id=281