Бизнес-аналитика

Бизнес-аналитика

Руководители информационных служб (CIO), сталкивающиеся с проблемами проектов разработки программного обеспечения, как правило, обвиняют во всем несовершенные требования. По данным Национального института стандартов и технологии, требования являются наиболее распространенной причиной невыполнения графиков, неудовлетворенности заинтересованных сторон и упущений альтернативных затрат. Оценки показывают, что проблемы с требованиями обходятся американским компаниям в 30 миллиардов долларов в год и ответственны за критические проблемы времени вывода продукции на рынок.

В то же время, директора компаний (CEO), сталкивающиеся с теми же проблемами, склонны винить в этом руководителей информационных служб (CIO). Каким образом CIO может не допустить таких проблем разработки программного обеспечения, которые нарушают бюджеты и графики и наносят ущерб репутации? Одним из ответов на этот вопрос является сосредоточение на часто недооцениваемом, но крайне ценном «пехотинце» - бизнес-аналитике (BA).

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

Высокая цена преобразований

Недавний расчет показал, что устранение ошибки требований, обнаруженной на стадии тестирования, обходится более чем в 1000 долларов, в то время как устранение такой же ошибки на стадии определения и утверждения требований стоит менее 75 долларов. По данным Standish Group, почти каждый пятый проект разработки программного обеспечения потерпел неудачу в 2006 году вследствие недостаточных требований к приложению предприятия, ошибок в определении фундаментальной логики бизнеса или чрезмерно сложных циклов проектирования. Снижение такого уровня ошибок зависит от того, в какой степени BA сможет четко объяснить каждой из сторон потребности другой стороны.

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

Ошибки требований

Рассмотрим наиболее распространенные типы ошибок требований.

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

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

Чрезмерная детализация требований также известна как “feature-itis” («расползание возможностей») и представляет собой добавление многочисленных оговорок, которые могут быть полезны, по мнению различных заинтересованных сторон и разработчиков, но имеют лишь косвенное отношение к главным бизнес-целям проекта. Избежать чрезмерной детализации можно за счет сильного управления проектом и при участии бизнес-аналитиков, которые твердо ориентируются на главные цели бизнес-проекта, не поддаваясь соблазну расширить его за счет добавления несущественных функций.

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

Создание письменных документов спецификаций занимает слишком много времени, а сами такие документы могут иметь слишком большой объем, чтобы быть полезными. Как отметил в недавней статье в журнале Requirements Development Journal Курт Биттнер (Kurt Bittner), самое главное в требованиях – это не сам документ, а обсуждение, которое приводит к общему видению окончательного решения. Роль BA в облегчении такого обсуждения имеет первостепенное значение. В обсуждении, направленном на поиск общего решения, должны принимать участие все заинтересованные стороны. Обширный перечень требований может выглядеть внушительно, но на него часто не обращают внимания. Кроме того, после того как такой документ роздан, люди склонны полагать, что обозначенные в нем требования незыблемы, и не имеет смысла добиваться каких-либо изменений. Парадоксально, но часто о работе бизнес-аналитика судят по тому, удалось ли в должные сроки создать большой документ в соответствующем формате и со всеми необходимыми визами.

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

Бизнес-аналитикам не хватает полезных решений

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

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

Признавая указанные ограниченные возможности программного обеспечения для обработки текстов, некоторые организации поощряют бизнес-аналитиков к построению визуальных моделей требований в форме диаграмм процессов и деятельности. К сожалению, некоторые из часто используемых приложений, разработанных для этой цели, отличаются значительной трудоемкостью; они требуют использования неудобных приемов, основанных на "перетаскивании» (drag-and-drop), в связи с чем они медленно приносят результаты; кроме того, трудно поддерживать их соответствие изменяющимся требованиям. К тому же, для бизнес-аналитиков может оказаться затруднительным изучение определенных правил моделирования, таких как универсальный язык моделирования (UML): как мы уже говорили, основным языком, используемым ими для выражения требований, является английский. Наконец, среди применяющих визуальные модели, много таких, кто использует инструменты, не обладающие поддержкой автоматического обнаружения описанных выше видов ошибок спецификации (т. е. простых логических ошибок, таких как неполные условия, прерывания потока, неоднозначные передачи управления, непоследовательности наименования и т. п.).

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

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

Быстрая разработка: в поисках «обходного пути»

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

Недавний опрос сторонников быстрой разработки показал: хотя достижение полноты и точности бизнес-требований является необходимым компонентом «быстрого» процесса, традиционные методы определения требований рассматриваются ими как неэффективные (Scott W. Ambler, “The Agile Edge, Dr. Dobb’s Journal, August 2007; ). Тот же опрос показал, что команды быстрой разработки не считают подробные случаи использования и документы спецификаций требований действенными рабочими продуктами, считая гораздо более эффективными для разработки приложений в жестких временных пределах наброски в стиле презентаций, облегченные случаи использования и спецификации требований высокого уровня. Парадокс в том, что хотя группы быстрой разработки нуждаются в начальных требованиях высокого уровня, им, вместе с тем, не терпится начать кодирование. Они стремятся получать прототипы до выхода к потребителям для обеспечения обратной связи.

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

Цели команд быстрой разработки и цели бизнес-аналитика

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

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

• Простая запись историй пользователей и целей бизнеса в виде заметок на простом английском языке

• Автоматическое моделирование (т. е. построение моделей без процесса моделирования)

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

• Автоматическое обнаружение всех логических ошибок и несоответствий

• Утверждение требований посредством проведения заинтересованных сторон без задержки через сам процесс выявления

• Преобразование полученных утвержденных историй пользователей в планы испытаний

• Экспорт утвержденных требований в среду разработки нажатием кнопки.

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

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

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

Новые функциональные стандарты для бизнес-аналитиков

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

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

• быстро создавать диаграммы из текста, вводимого на простом английском языке

• находить логические ошибки программными средствами

• облегчать визуальный контроль требований для нахождения других ошибок на стадии выявления

• просматривать графическое представление рисков проекта до написания кода

• определять уровень «текучести» требований (ключевой показатель риска) и уровень прогресса в отношении определения требований по сравнению с наилучшими практическими моделями.

Раннее обнаружение имеет ключевое значение

Обучив бизнес-аналитиков и обеспечив их необходимыми средствами в отношении новых наилучших методов и продуктов, руководитель информационной службы может значительно улучшить результаты проекта и достичь нескольких преимуществ:

• Сокращение времени на определение требований. Доказано, что модели, составляемые «на лету» программным обеспечением, сокращают время на определение требований в 100 и более раз.

• Ускорение просмотра спецификаций предметными экспертами (SME). Интерактивная модель, в которой предметные эксперты обсуждают оперативно создаваемые модели, экономит время.

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

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

Заключение

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


Карта сайта


Информационный сайт Webavtocat.ru