IT бизнес-анализ — общий процесс

Друзья, в этом цикле я попробую реализовать нетипичную и кажущуюся непростой задачу: описать процесс бизнес-анализа в рамках IT-проекта в виде юзабельного гайда. Нетипичную — потому что подобного гайда в доступных терминах и подъемном объеме я не видел. Авторы обычно любят обсуждать отдельные техники, а не процесс целиком и полностью. Непростую — потому что задача, на мой взгляд, едва ли полноценно выполнима. Оба пункта вытекают из того, что IT бизнес-анализ — это творческое колдунство, весьма ограниченно подверженное алгоритмизации. То есть не всегда даже понятно, каким должен быть результат (точечные задачи бизнес-анализа могут варьироваться от проекта к проекту и от компании к компании), не говоря уже о том, что набор шагов почти всегда будет уникальным. Постановку миссии в ключе “помоги заказчику в реализации его потребностей” весьма сложно описать в виде чётких инструкций. Тем не менее, попробуем — хотя бы для большинства проектов, с которыми типовой айтишник сталкивается.

Замечу, что мне, например, гайда в стиле “возьми это за основу, а дальше уже допиливай” в свое время не хватало. Максимально близкое, что к нему было, это “Software Requirements” Карла Вигерса, но там надо было буквы активно потреблять. Надеюсь, что авторское видение (основанное на трудах Вигерса, плюс разбавленное крутыми практиками из BABOK, прочими классными теориями и личным опытом) в форме краткого гайда, покрывающего типовые стадии бизнес-анализа, поможет не растеряться начинающим и подтюнить процессы продолжающим.

Конечно, сразу море дисклеймеров:

Описать процесс бизнес-анализа от и до — мягко говоря, большая задача. Гайд будет упрощенным: будет покрывать не все виды проектов, не все подходы к разработке ПО (модели, методологии, фреймворки и иже с ними), не все типажи клиентов и их домены, не все контексты работы (в плане состава команды, ее опыта, распределенности и пр.) и уж точно не все сценарии развития событий (в особенности те, что о полнолунии в пятый месяц високосного года).
Бытует мнение, что одно из любимых выражений аналитика — it depends. Т. е. аналитик — не та роль, которая действует из раза в раз по единому алгоритму в условиях четко поставленной задачи. Это носильщик багажа техник, из которых он клепает конкретный процесс, адаптированный под здесь и сейчас. Но, повторюсь, мне не хватало в свое время базы, чтобы понимать, а как в принципе можно начать клепать этот самый конечный процесс. Было лишь туманное видение того, куда нужно копать, плюс корявые соображения о первых шагах — как у гномов из Южного Парка, ага. Собственно, усредненный типовой процесс в авторском преломлении тут и будет описан. Его можно и нужно менять, помножив на умственные усилия и контекст проекта.
Все будет весьма упрощенно. Это не спецификация — это quick start guide. С акцентом на то, что именно делать и какой молоток для этого взять. Будут условности, допущения и уж точно будет страдать научная точность. Полные книжки, которыми можно полирнуть эту базу, уже Карл и прочие замечательные спецы написали.

Для начала, схема процесса бизнес-анализа на IT-проектах такова:

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

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

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

Это не все, но ключевое.

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

Следующие три этапа — это фаза стратегического анализа aka discovery. Тут нам нужно понять, для чего и чем в общем и целом наша команда будет на проекте заниматься.

2) Анализ текущей ситуации (AS IS) — это понять, какие проблемы или видимые возможности побудили заказчика обратиться за разработкой ПО или любым другим сервисом, в рамках которого мы тут суетимся (разработка своего продукта, доработка чего-то существующего, поддержка чего-то живого в продакшне и т. п.). Для этого нам также нужно в домен (предметную область) и деятельность заказчика погрузиться.

3) Определение будущего состояния (TO BE) — понять, куда заказчик (тот, кто денежки компании-исполнителю платит) хочет прийти. Тут мы занимаемся проработкой бизнес-требований и прочих важных моментов, которые их пояснят и уточнят. Необходимо это для того, чтобы в сумме понимать, какой эффект необходим от движа, устроенного заказчиком, и какова будет стратегия достижения этого эффекта.

4) Идентификация и анализ решений, плюс выработка конечного решения и его объема (скоупа) — здесь мы вместе с заказчиком и прочими нужными людьми думаем о том, какое решение максимально эффективно поможет прийти в будущее состояние. Т. е. от “куда” идем, как это было в пункте выше, мы переходим к “с помощью чего” идем. Нам нужно по итогу определиться, что станет фокусом команды разработки (веб-приложение, мобильное приложение, сложная комбинация доработки бизнес-процессов и внедрения нескольких программных систем, допиливание существующей программной системы, покупка коробочного продукта и его настройка и т. п.). Это самое решение, а также понимание того, из чего оно общими мазками должно состоять (скоуп), и станут нашим фокусом на всех дальнейших этапах. Скоуп, кстати, порой сложно выработать сугубо с заказчиком: вероятно, придется заглянуть и к пользователям, в следующий этап — хотя бы одним глазком.

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

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

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

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

5) Теперь нам нужно понять, кто будет пользоваться нашей системой и что им от нее нужно / какие оно им может ценности принести. Для полноты помимо конечных пользователей стоит добавить сюда и прочих стейкхолдеров, у которых также могут быть хотелки, пожелания или ограничения касательно решения. Но на процентов 90, условно, это работа именно с пользователями. Естественно, в ногу с постулатом о “неводопадности” этапов, пользователей мы уже так или иначе поймем и до этой точки: в частности, когда мы говорили о возможных решениях и решали, на каком остановимся (сложно говорить о решениях, не понимая, для кого они и что, в общем и целом, они им должны давать — то бишь скоуп). Поэтому уточним: тут мы значительно более сфокусировано изучаем наших пользователей, делим всю эту когорту на категории и выясняем у них / о них, что именно решение должно им предоставлять.

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

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

7) Отдали по итогу предыдущего этапа требования в разработку — отдыхаем. Ага, подбираем губу с пола: на самом деле не отдыхаем, а активно или пассивно участвуем в процессе разработки, тестирования и поставки решения. К нам точно будут вопросы по требованиям — от команды, заказчика, менеджмента и т. п. К тому же практически любая разработка нынче итеративна, а потому мы будем активно работать над следующей итерацией решения (справедливости ради, подобная активность — это не поддержка команды, а новый мини-водопадик, который также начинается с discovery или чуть позже, с требований ЗЛ, но уже для другой итерации решения).

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

Плюс сюда стоит добавить такую активность, как оценка решения (оценка того, что решение помогает в достижении нужного эффекта, который мы определили в рамках discovery). Далеко не всегда это актуально, т. к. в большинстве случаев в заказной разработке исполнитель подобным не занимается, оставляя “бизнесовую” часть (то, действительно ли решение помогает организации идти в светлое TO BE) за рамками своих услуг. В собственной продуктовой же разработке это более актуально, но подобное будет головняком, скорее, менеджера продукта, нежели аналитика. Однако всякие процессы, комбинации ролей и зоны ответственности бывают, а потому эту часть также стоит упомянуть.

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

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