Бизнес-анализ — отделение анализа от проекта и создание календаря
Отделение анализа от дизайна
(решите, что необходимо, прежде чем решить, как это реализовать)
Успешные проекты решают проблемы бизнеса
Взгляд на бизнес-цели, которые вы пытаетесь достичь, прежде чем приступить к технологиям, позволит вам разумно использовать технологии, управлять масштабами и сокращать расходы, создавая системы, которые работают для ваших клиентов.
Легко сосредоточиться на технических характеристиках любой конструкции и упустить из виду смысл ее существования. Каждый проект существует для решения проблемы. Либо то, что у вас есть, работает недостаточно хорошо и нуждается в доработке, либо вам нужно придумать что-то совершенно новое. Ведь «если не сломано, не чини, создание календаря«.
Слишком часто давление сроков и бюджетов заставляет нас игнорировать важный процесс анализа потребностей бизнеса и сразу переходить к технологиям. Но как часто оказывается, что система делает не совсем то, что требуется. Пользователи вынуждены использовать обходные пути, уменьшая некоторые из преимуществ, которые мы должны были предоставить, что также влияет на доверие к нам. Как часто нам приходится вкладывать дополнительное время и средства в выпуск Версий 2 (и 3, и 4, и…), когда тщательная работа могла заранее выявить реальные потребности?
Жизненный цикл классического водопада
Существует много вариантов жизненного цикла разработки системы (SDLC), и следующая терминология может не соответствовать используемой в вашей методологии. Содержание фаз, безусловно, упрощено в этой таблице, но проекты следуют следующим фазам:
(ФОТО НЕДОСТУПНО ЗДЕСЬ — вы можете скачать эту статью с картинками с [http://www.irm.com.au/businessanalysispapers.htm]или посмотреть картинку в [http://www.irm.com.au/images/waterfallcycle.jpg])
Выход из каждой фазы является входом в следующую. Грязь на входе, гадость на выходе. Или, говоря более изящно, из свиного уха невозможно сделать шелковый кошелек. Вы не можете внедрить хорошую операционную систему без хорошей протестированной системы, вы не можете создать хорошую систему без хороших технических спецификаций, и вы не можете разработать хорошую систему без хорошей бизнес-спецификации.
Убедитесь, что талантливые люди используются в начале проекта, чтобы быть уверенными, что вы сможете получить хорошие результаты в конце.
Не обманывайте себя, думая, что вы делаете кому-то одолжение, пропуская бизнес-анализ и переходя сразу к проекту, или комбинируя и то, и другое. Если сроки сжаты, договоритесь о поэтапном развертывании. Если бюджет ограничен, удалите некоторые функции.
Многие исследования, в том числе работа Бёма, постоянно показывают, что увеличение стоимости исправления ошибок растет экспоненциально по мере того, как позже происходит исправление в SDLC. Исправление ошибки, которая стоит 1 доллар на этапе инициализации, будет стоить 10 долларов, если оставить ее для анализа, 100 долларов на дизайне и 1000 долларов, если ничего не будет сделано в ожидании реализации. Но как часто мы говорим: «Мы сможем исправить это в коде»?
Программные инструменты не думают за вас
Был бы Шекспир лучшим писателем, если бы у него был текстовый процессор?
Любой инструмент поверит тому, что вы ему скажете. Есть несколько отличных инструментов, которые избавят вас от бессмысленной хакерской работы, чтобы вы могли сосредоточиться на том, что у вас получается лучше всего. Но не думайте, что если у вас есть наилучший инструмент, ваши системы будут такими лучшими, какими они могут быть. Если вы мне не верите, возьмите свой любимый текстовый процессор и напишите сонет, который люди будут любить цитировать через 400 лет.
Вы все еще должны думать сами. Вот что такое бизнес-аналитика.
Отделите бизнес-анализ от технического проектирования
Бизнес-аналитика — это рассмотрение того, что должно делать ваше решение, а проектирование — это то, как это сделать с помощью доступных технологий. Имея это в виду, будет легче избежать смешивания двух фаз. какая а также Как. Это поможет вам построить более надежную систему.
То, чем занимается ваш бизнес, меняется не так сильно, как то, как оно реализуется. Технологии меняются быстрее, чем нужно бизнесу. Реструктуризация компаний. Но то, что они делают, не изменилось, изменилось только то, кто это делает. Business Intelligence дает логическую картину ваших процессов и потребностей в данных и не привязана к физической реализации.
ИТ-специалисты и бизнес-пользователи регулярно жалуются на недопонимание. Конечно, они не понимают друг друга. Технические специалисты заботятся о том, чтобы получить максимальную отдачу от своих технологий, пользователи озабочены достижением своих бизнес-целей. Бизнес-анализ должен аккуратно восполнить этот пробел.
Техническое задание, составленное на этапе Инициации, должно четко содержать Проблему, которую необходимо решить, Цель, которую необходимо достичь для решения этой проблемы, Ограничения и Объем.
Цель бизнес-анализа:
- найти причину проблемы — ведь на самом деле люди описывают симптомы, а не проблемы
- посмотреть на альтернативные решения, которые позволят достичь цели
- выбрать наиболее приемлемое решение
- подробно задокументировать это решение, чтобы команда проекта не сообщала о неясностях;
Методы бизнес-анализа
Для углубления в проблемы и поиска решений используется множество приемов, выходящих за рамки данной статьи. К ним относятся тщательно структурированные интервью, сбор документов, мозговой штурм, анализ рисков, анализ затрат и результатов и многое другое.
Инструменты бизнес-анализа и создание календаря
Для анализа нужны всего четыре инструмента: два для процессов и два для данных.
Для процессов схема потоков данных (DFD) показывает бизнес-процессы в системе и их взаимосвязь, а бизнес-спецификации показывают бизнес-правила для каждого процесса. Для данных диаграмма отношений сущностей (диаграмма ER) показывает вещи, которые должны быть сохранены с точки зрения бизнеса, а словарь данных перечисляет определенные элементы (поля), необходимые для каждой сущности, и их связи с потоками данных в DFD.
Цель этой статьи не в том, чтобы показать вам, как создавать эти модели, а в том, чтобы продемонстрировать важность их использования в бизнес-модели, а не в технической.
Любой идиот может нарисовать ER-диаграмму.
Верно, но качество получаемой модели зачастую оставляет желать лучшего. Отразите потребности бизнеса в модели и ничего не оставляйте на волю случая. Будьте осторожны с такими вещами, как обязательные и необязательные отношения и элементы данных, поскольку ваша окончательная система должна соответствовать 100% бизнес-требований, а не наиболее вероятным событиям. Никогда не пытайтесь совмещать документирование требований к бизнес-данным с проектированием базы данных.
Если бизнес-модель точна, ее будет легко внедрить и легко модифицировать с учетом требований бизнеса и новых технологий.
Почему диаграмма потоков данных лучше, чем иерархия функций
Иерархия функций показывает основные функции в системе и подробно описывает их, но не показывает требования к данным для этих процессов. Очень легко непреднамеренно обойти низкоуровневые процессы. Иерархия функций не сразу очевидна для пользователя, которому необходимо перепроверить точность модели.
Диаграмма потока данных также показывает основные функции и детали, но поскольку потоки данных действуют как «клей», который скрепляет процессы, такую диаграмму легко построить в сотрудничестве с представителем бизнеса. «Какая информация вам нужна для завершения этого процесса? Откуда это? Какая информация генерируется? Куда идет?» Таким образом, в модель можно постепенно добавлять отдельные процессы, и ничего не будет упущено. Вы можете детализировать сложные процессы и группировать связанные процессы.
Большую диаграмму потоков данных трудно читать и поддерживать, и поэтому она теряет свою эффективность в качестве средства коммуникации как с бизнес-пользователями, так и с технической командой. Вместо этого создайте около семи процессов на диаграмме и переходите к более подробным диаграммам с системой нумерации для справки. Например, детали процесса 3 будут пронумерованы 3.1, 3.2, 3.3 и т. д. и появятся на диаграмме 3. Затем диаграммы верхнего уровня можно использовать для обсуждения с руководством, а диаграммы нижнего уровня — для двойной проверки. подробно с пользователями, которые являются экспертами в этой области. Иерархия функций теперь существует автоматически. Отдельно рисовать не надо.
Многие аналитики предпочитают использовать модель процесса, включающую «плавающие пути», чтобы определить, кто выполняет каждый процесс. Это просто схема потока данных в другом формате. Можно начать анализ с такой диаграммы, но в конце анализа плавательные дорожки должны исчезнуть, так как модель должна быть достаточно устойчивой, чтобы пережить изменения в компании. Вы документируете, что нужно сделать, а не кто и как.
Потоки данных должны быть указаны вместе с их подробным содержанием в словаре данных, как и хранилища данных. Постепенно диаграмма потока данных поможет построить модель данных, чтобы определения данных поддерживали процессы.
Включите в диаграмму потока данных все процессы, даже те, которые кажутся тривиальными. Недавно я услышал о проекте, который попал в ловушку «Отчетность — это просто, давайте прибережем ее напоследок». На момент составления данных, необходимых для отчетов, не было.
Несколько версий модели
Во-первых, задокументируйте свою существующую систему, включая все ее ошибки, не добавляя никаких улучшений. Причина проблем находится снаружи, и вам не следует делать поспешных выводов о наилучшем способе ее решения.
Удалите путь из текущей физической модели, получив текущую логическую модель. Затем выработать наилучший способ решения проблем и учесть новые требования. Это дает новую логическую модель, готовую к проектированию.
В некоторых случаях проблемы можно решить, просто изменив способ работы, что сэкономит ненужные расходы на проектирование. Лишает ли это технической команды их работы? Нисколько. Они могут быть уволены, чтобы применить свой опыт там, где это окажет наибольшее влияние на другие проекты.
Написание спецификаций
Не пишите одну большую спецификацию. Это будет плохо, потому что вы упустите какую-то деталь и не сможете легко ее изменить. И никто не сможет запомнить все это. Вместо этого напишите единую спецификацию для каждого детализированного процесса — «мини-спецификацию». Каждый может быть перепроверен с соответствующим бизнес-экспертом. Набор всех этих мини-спецификаций и есть ваша спецификация на всю систему. Каждый из них по отдельности прост в обслуживании, не влияя на остальные характеристики.
Спецификации не должны содержать никакой технической информации — только бизнес-правила процесса. Команда дизайнеров может разработать лучший способ сделать это возможным.
Что автоматизировать?
Просмотр диаграмм потоков данных с представителями бизнеса и технической командой позволит вам выбрать наилучшую реализацию. Это основано на таких факторах, как то, что приемлемо для бизнеса, что технически возможно, что соответствует бюджету и временным ограничениям.
Вы можете выбрать полную автоматизацию, частичную автоматизацию, поэтапное внедрение или другую замечательную идею. Тогда вперед к команде проекта.
Сочетание анализа и дизайна
Никогда не делай этого. Вы ничего не экономите.