Содержание:

• Определение бизнес-анализа.
• Уровень задач.
• Эволюция подходов к решению задач. Базовые архетипы мышления.
• Закон Парето и жизненный цикл разработки программного обеспечения.
• Основные виды проектной документации.
• Виды подходов к решению задач.

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

Понимание цели гораздо важнее, чем наличие некоторого количества решений.

Решений сейчас существует достаточно много. Далеко не всегда эти решения можно применить в конкретной ситуации, в конкретной организации, для конкретного бизнеса.

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

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

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

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

С точки зрения рассмотрения организации целиком, уровень задачи может быть
различным.

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

Мы можем заниматься решением различного уровня задач.

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

В такой ситуации логичен вопрос, а нужен ли бизнес-аналитик?

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

Самый верхний уровень бизнес-задач наиболее близок к названию «бизнес-анализ».
Это — решение стратегических задач, связанных с тем, как мы будем перестраивать
деятельность организации, и с вызовами, которые могут возникнуть в контексте уровня предприятия.

Если мы нарисуем каскад причинно-следственных связей, то получим следующую
цепочку:

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

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

В нашем курсе мы будем рассматривать уровни, связанные с решением бизнес-задач и IT-задач, в том объеме, в котором это необходимо для того, чтобы поставить задачу для разработки программного обеспечения.

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

Исторически исследователи выделяют несколько архетипов мышления.

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

Многие виды животных обладают такими навыками, как собирательство или
транспортировка.

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

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

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

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

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

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

Дивергентно-конвергентное мышление можно представить в виде двух
преимущественных подходов, на которых фокусируется мышление человека.

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

Без обоих этих вариантов решение как таковое либо не функционально, либо
невозможно.

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

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

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

Третий архетип мышления — это архетип великого строителя.

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

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

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

Для достижения этого результата потребовалось много изобретений, и одно из этих
изобретений — календарь.

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

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

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

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

Одного отдельного решения, которое помогает решить только одну часть проблемы,
будет явно недостаточно.

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

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

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

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

Верно и наоборот. Оставшиеся 80% объема работ, который может быть выполнен с
точки зрения реализации системы, в лучшем случае соответствует 20% возможного
эффекта.

Таким образом, произвольные 20%, если они не включают в себя основные факторы,
неизбежно ведут к очень скромной реализации.

Мы подходим к интересному фактору. По статистике, которую делают лучшие
компании, бизнес и системный анализ, как правило, занимает 20-25% от общих
трудозатрат. Четверть усилий, которых мы можем не приложить, не делать, чтобы
определить, какие требования, какие пожелания, какие проблемы не стоят того, чтобы их решать, если мы осуществляем по ним только бизнес-анализ, а не полный цикл разработки, составляют 20% от общего объема.

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

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

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

Ну и соответственно, если мы применяем или осуществляем бизнес- и системный
анализ неверно, — все-таки занялись выбором возможных факторов, выбрали
факторы, но выбрали их неправильно, —, по закону Парето, математически мы
получим в лучшем случае 5% от возможного эффекта.

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

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

p.s. Приведенные цифры не являются математически верным расчетом - просто
для иллюстрации

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

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

В области проблем на уровне заказчика мы имеем дело с потребностями, которые мы оформляем и документируем при решении задач, связанных с бизнес-требованиями.

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

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

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

Чем сложнее система, тем изощреннее материалы, и, наоборот, чем проще решение,
тем проще может оказаться внедрение.

Когда мы говорим о бизнес-процессах, на этом этапе у нас процессы to be — т. е.
процессы, которые будут. Если мы будем проводить анализ проблемы, работать с
бизнес-процессами на этапе постановки задачи, то здесь мы будем исследовать
процессы as is, или как они есть сейчас.

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

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

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

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

Обращаю ваше внимание: это — не проблема поиска решений, а проблема
конкретного подхода к решению задач на каждом из этапов.

Четкое разделение артефактов с зонами ответственности, когда у нас не происходит
коллективной работы, приводит к проблемам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует тренд уменьшения количества систем в управлении, но оттого, что мы
уменьшаем количество систем, объединяя их в некоторые конгломераты,
принципиальная сложность не уменьшается. И, соответственно, все эти системы
связаны бизнес процессами.

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

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

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

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

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

То есть здесь мы также можем выделить V-образный процесс, в котором каждый из
уровней должен быть завершен.

С точки зрения документов и требований, которые могут быть выделены и с которыми работают в корпоративной среде, можно выделить отдельно документированные и прорабатываемые типы требований такие как :

• первичные требования ,
• бизнес-цели и задачи,
• требования заинтересованных сторон,
• требования пользователей, четко выделенное ограничение.

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

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

На рисунке представлена одна из карт функций закрепленных за отделением
бизнес-анализа для крупной организации.

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

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

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

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

На втором уровне зрелости появляется дисциплина под названием "Управление
требованиями". Основная задача этой дисциплины — возможность проконтролировать результат, что то, что мы попросили сделать поставщика, то он и сделал.

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

Необходимо прослеживать связи между требованиями и результатом. Когда мы что-то делаем, мы должны отслеживать, а было ли это в требованиях и соответствует ли оно требованиям, и, естественно, работать над обнаруженными несоответствиями между требованиями и работами, которые мы проводим.

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

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

Следующий уровень, третий уровень зрелости компаний разработчиков ПО —
Capability Maturity Model — связан с созданием решения, которое наиболее полно и
эффективно решает задачу заказчика. Мы не реализуем то, что нас попросили
буквально, мы сначала разрабатываем запрос и, так как мы являемся экспертами в
области решений, предлагаем решение, которое наилучшим образом позволяет
достичь той цели, которую преследует наш заказчик.

Здесь появляются дополнительные процессы, связанные с необходимостью работы
над потребностями заинтересованных сторон. Мы должны координировать интересы заинтересованных лиц. На уровне управления требованиями мы собрали требования, и если сторона заказчика их подписала, значит, для нас проблем нет.

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

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

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

В рамках нашего курса мы будем опираться на следующие этапы с требованиями:

1) сбор требований,
2) формирование бизнес-требований (осуществлять анализ проблемы,
формулировать проблему и возможности решения).

И подытожим это всё определенной типовой структурой, в рамках которой мы можем оформить бизнес-требование.