ТРИЗ в бизнес-анализе

Теория решения изобретательских задач как инструмент для бизнес-анализа

Краудсорсинг в бизнес-анализе. Разрешение одного противоречия в управлении требованиями

18.11.2012
New_preview_8-1_new

“Краудсорсинг – это главный управленческий прорыв XXI века”
Герман Греф

 

Статья содержит описание решения одного противоречия в управлении требованиями.
У меня появилось сразу несколько поводов для написания этой статьи. Во-первых, это дискуссия о трендах развития области управления требованиями, состоявшаяся среди членов сообщества analyst.by. Во-вторых, свежий опыт участия в краудсорсинговом проекте Сбербанка. И в-третьих, эта статья – еще один аргумент для тех скептиков, которые сомневаются в ценности ТРИЗ для бизнес-анализа.

Проблема управления требованиями

Сегодня уже никого не нужно убеждать, что управление требованиями, в том числе, сбор, анализ, обработка и оценка реализации требований, является необходимой составной частью процесса разработки информационных систем. Важность этих видов деятельности выражается еще и в том, что сегодня управлением требованиями занимаются специально обученные люди – системные и бизнес-аналитики. Кроме аналитиков в той или иной степени требованиями занимаются и другие люди: владельцы продукта (product owners), тестировщики (QA специалисты), «юзабилисты» (UX специалисты и специалисты по интерфейсам), продавцы, маркетологи и многие другие. Не стоит также забывать о руководителях проектов (project managers) и, конечно же, о разработчиках (developers).

Но так было не всегда! В популярной в свое время в ИТ-среде книге Фредерика Брукса «Мифический человеко-месяц. Или как создаются программные системы» повторного издания 1995 года автор рассказывает, что в те почти античные для ИТ-сферы времена уже осознавалась важность управления требованиями, но в книге нет упоминания всех тех специалистов, которые занимаются управлением требованиями сегодня.
 
В связи с этим обстоятельством возникает несколько интересных, на мой взгляд, вопросов:

  1. Какой фактор повлиял на появление всех этих новых специальностей?
  2. Продолжает ли этот фактор действовать сегодня?
  3. Если да, то каким образом действие этого фактора повлияет на развитие ИТ-сферы в будущем?

Обсуждение путей решения проблем
Если мы зададим эти вопросы экономисту, то он ответит, что мы наблюдаем естественный процесс углубления разделения труда, связанный, с одной стороны, с ростом сложности технологий разработки информационных систем, а с другой стороны, необходимостью повышения производительности труда в ИТ-сфере. Из этого ответа следует, что нас ожидает в будущем появление новых специальностей, в том числе, связанных с управлением требованиями.

Бизнес-аналитик может предложить другой ответ, определив, какую именно проблему решает появление специальных людей, ответственных за управление требованиями. В ИТ-сфере известен следующий феномен: стоимость внесения изменений в информационную систему тем выше, чем на более поздней стадии проекта такие изменения вносятся. Если, условно, стоимость внесения изменений на стадии технического задания составляет 1 руб., то на стадии спецификаций стоимость будет уже 10 руб.; на стадии разработки – 100 руб., а на стадии внедрения – 1000 руб.

Раньше (всего-то 10-20 лет назад) сбором и управлением требованиями, а также управлением изменениями (основной причиной которых являются неточно определенные требования) занимались сами разработчики информационной системы. Для предотвращения экспоненциального роста затрат на изменения на поздних стадиях проектов управление требованиями (и частично изменениями) переложили на плечи аналитиков. Другими словами, появление аналитиков – это способ снижения совокупных затрат на проекты, связанных с управлением требованиями и изменениями.

Однако, мы сталкиваемся с новым противоречием:

Если на ранних стадиях проекта разработки информационной системы требования будут выявляться и анализироваться точнее, то мы можем добиться снижения затрат, связанных с внесением дорогостоящих изменений на поздних стадиях проекта, но при этом нам потребуется включить в проект специальных людей (аналитиков), которые будут заниматься управлением требованиями. Это приводит к усложнению управлением проекта, в том числе, усложнению коммуникаций между участниками проекта.

Как быть?

На первый взгляд, в каждом проекте мы можем достичь определенного баланса между точностью управления требованиями и размером проектной команды, а также связанной с этим сложностью управления проектом. Этот баланс находится где-то между затратами на изменения, связанные с ошибками в управлении требованиями, и затратами на управление проектами. Можно даже придумать уравнение баланса с большим количеством переменных, описывающих аналитические, девелоперские и коммуникационные навыки членов команды и тому подобное.

Однако те из вас, кто познакомился с Обзором ТРИЗ для системных и бизнес-аналитиков, уже догадались, что может быть найдено решение проблемы управления требованиями, устраняющее указанное выше противоречие.

В нашем случае в качестве идеального конечного результата должен выступать неизвестный пока Х-элемент, который с высокой точностью обеспечит выявление, анализ, оценку требований на ранней стадии проекта по разработке информационной системы, при этом не потребует привлечения в команду проекта большого количества аналитиков и усложнения системы управления проектом.

Мы опускаем описание хода анализа противоречия, как и этап синтеза решения для Х-элемента, поскольку это не является предметом данной статьи.

Одним из возможных кандидатов на роль Х-элемента являются пользователи информационной системы: пользователи информационной системы сами выполняют функции по определению, анализу и оценке требований.

Решение уже существует!

Сегодня уже существуют технологии, которые позволяют реализовать требования, определенные для Х-элемента.

Краудсорсинг (англ. crowdsourcing, crowd — «толпа» и sourcing — «использование ресурсов») — передача определённых производственных функций неопределённому кругу лиц. Решение общественно значимых задач силами множества добровольцев, часто координирующих при этом свою деятельность с помощью информационных технологий.

Широко известным примером успешного применения технологии краудсорсинга является проект свободной энциклопедии Wikipedia. Свежий пример – применение краудсорсинга для развития Сбербанка России.

На сегодняшний день известно большое количество платформ, обеспечивающих поддержку технологий краудсорсинга. Краткий обзор таких платформ можно посмотреть здесь.

Краудсорсинговые технологии не являются чем-то принципиально новым и для ИТ-сферы. Достаточно вспомнить технологию бета-тестирования информационной системы, суть которой состоит в привлечении большого количества пользователей для тестирования почти готовой системы.

Крауданализ

Краудсорсинговая платформа позволит привлечь большое количество пользователей разрабатываемой информационной системы, где они смогут высказываться о своих потребностях и предпочтениях.

На платформе можно предложить пользователям формулировать свои требования, заполняя определенные шаблоны, например «система название_системы должна выполнять функцию название_функции каждые единица_времени». Заполняя шаблоны, пользователи будут предоставлять требования в уже структурированном виде.

Швейцарский нож
Пользователи на платформе могут голосовать, устанавливая приоритеты для сформулированных требований.

Пользователи смогут отслеживать реализуемость требований, например, путем выставления оценок типа «насколько полно реализовано данное требование».

Пользователи смогут общаться на платформе друг с другом, обсуждать требования, генерировать новые идеи, оценивать друг друга и накапливать социальный капитал.

Краудорсинговая платформа позволит коллективно решать возникающие по ходу разработки проблемы, устраивать мозговые штурмы с участием большого количества людей.

Применение краудсорсинговой платформы кардинально изменит отношение пользователей к будущей информационной системе. Принимая участие в проектировании, пользователи будут рассматривать новую информационную систему как родную: бета-тестирование станет органичной частью процесса разработки; значительно сократятся или исчезнут совсем проблемы внедрения и обучения пользователей.

Очевидно, что применение краудсорсинговой платформы не исключает роль аналитиков; однако, роль аналитиков в проекте претерпит значительные изменения. Аналитикам не нужно будет встречаться с пользователями, проводить интервью, согласовывать документы с пользователями. Аналитики должны будут модерировать работу пользователей на платформе, формулировать задания, готовить для пользователей обзоры по различным темам, касающимся области применения информационной системы. Естественно, аналитики будут анализировать требования, сформулированные пользователями, и превращать их в документы для разработчиков информационной системы.

Можно также предположить, что применение технологий краудсорсинга для управления требованиями приведет к изменению бизнес-моделей, по которым сегодня организована работа ИТ-компаний. Однако это уже тема для отдельного разговора.

Комментарии:  0

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

Подписаться без комментирования