Погружение в бизнес-анализ мы начнем со второго этапа схемы из предыдущей заметки — с анализа текущей ситуации (AS IS). Почему не с планирования: планирование бизнес-анализа мы обсудим в конце цикла, когда изучим все типовые этапы — во избежание коллапса мозга от обилия незнакомой терминологии и процессов.
В общем, начинаем мы творить магию с изучения AS IS — того, “как оно сейчас” у заказчика (человека или организации, которые готовы платить нам деньги). Зачем мы делаем это? Ответ прост: чтобы понять причины того, почему заказчик готов инвестировать деньги в проект. Но опять-таки, а зачем? Готов и готов — пусть платит, мы не жалуемся. Да, так можно работать и так работают, но давайте вспомним любое наше взаимодействие с теми, кто нам что-либо продает (не считая, условно, покупки хлеба). Не было ли для нас более ценным, когда продавец входил в режим консультанта и пытался понять, что и почему мы ищем, пытаясь решить нашу проблему, а не тупо продать то, за чем обратились? В IT-разработке это еще актуальнее — инвестиции в IT зачастую очень велики. Исполнителям платят большие деньги за работу, и промахи в проектах, особенно стратегического плана, крайне обидны и чувствительны для кошелька. И на протяжении всего IT-проекта “аналитик-помощник” (который стремится решить проблемы заказчика) гораздо ценнее “аналитика-передаста” (пересылальщика информации от заказчика команде разработки).
Важно: напомню посыл из предыдущей заметки — анализ AS IS, будучи частью стратегического анализа/discovery, уместен только тогда, когда вся эта фаза актуальна для проекта. Обязательно узнайте это у вашего БА-лида, проектного менеджера или любого иного человека, который может очертить спектр ваших обязанностей и картину бизнес-анализа на проекте. К тому же следите за реакцией заказчика на те работы, которые вы предлагаете или пытаетесь делать — вероятно, сам заказчик не видит смысла в том, чтобы вы в режиме консультанта лезли в душу и пытались делать что-либо за рамками непосредственной разработки (мы ведь тоже не любим, когда продавец пытается навязать иные диалоги, когда мы точно знаем, что хотим купить).
Переведем цель этапа на официальный язык: цель в том, чтобы понять бизнес-потребности заказчика и их контекст (причины, масштаб, эффект и пр.).
Бизнес-потребности (Business Needs) — это проблемы или возможности у/для заказчика, ради решения/достижения которых инициировано изменение. Изменение (Change) — это термин из BABOK и его Business Analysis Core Concept Model и означает, грубо говоря, те телодвижения, которые заказчик у себя затеял и осуществление которых готов финансировать. Мы как исполнитель помогаем заказчику осуществить изменение путем реализации того решения (Solution), которое ему поспособствует.
Бизнес-потребности (Business Needs) — это проблемы или возможности у/для заказчика, ради решения/достижения которых инициировано изменение. Изменение (Change) — это термин из BABOK и его Business Analysis Core Concept Model и означает, грубо говоря, те телодвижения, которые заказчик у себя затеял и осуществление которых готов финансировать. Мы как исполнитель помогаем заказчику осуществить изменение путем реализации того решения (Solution), которое ему поспособствует.
Важно:
1) Бизнес-потребности формулируются как потребности заказчика (организации или физического лица — смотря, кто к нашу компанию обратился). Это не потребности рынка, отдельного пользователя Васи или иных стейкхолдеров, какими бы важными они ни были. Это всегда потребности того человека или организации, которые платят нам деньги.
2) Бизнес-потребности отражают причины, стоящие за тем, что наша команда в дальнейшем будет разрабатывать/дорабатывать/покупать/настраивать и т. п. Здесь важно не путать бизнес-потребности заказчика с его потребностями уровня заинтересованного лица. Чтобы не подвиснуть на сложной терминологии, приведу пример: допустим, мы общаемся с начальником отдела компании-заказчика, где есть проблема с контролем работы сотрудников. Если мы в лоб зададим вопросы этому самому начальнику, мол, какие у тебя есть потребности, он может дать как ценную информацию, так и не очень: а) из-за недостаточного контроля сотрудников страдает эффективность работы компании; б) процесс контроля для начальника неудобен — приходится опрашивать каждого сотрудника на предмет проделанной ими за день работы. И если первое выглядит как причина разработки проекта и мотивация для компании вложить в это деньги, то второе — скорее всего, нет: это личная боль начальника отдела, с которой нам также придется поработать, но не на текущем этапе и не в контексте корневых причин проекта.
3) Бизнес-потребности — это не требования в информационной картине аналитике. Требования направлены в будущее (TO BE) и касаются решения, которое наша команда будет реализовывать. На этом этапе речь вообще не идет о решениях — еще рано. Потребности описывают текущую ситуацию (AS IS) и выражаются в виде проблем или возможностей.
1) Бизнес-потребности формулируются как потребности заказчика (организации или физического лица — смотря, кто к нашу компанию обратился). Это не потребности рынка, отдельного пользователя Васи или иных стейкхолдеров, какими бы важными они ни были. Это всегда потребности того человека или организации, которые платят нам деньги.
2) Бизнес-потребности отражают причины, стоящие за тем, что наша команда в дальнейшем будет разрабатывать/дорабатывать/покупать/настраивать и т. п. Здесь важно не путать бизнес-потребности заказчика с его потребностями уровня заинтересованного лица. Чтобы не подвиснуть на сложной терминологии, приведу пример: допустим, мы общаемся с начальником отдела компании-заказчика, где есть проблема с контролем работы сотрудников. Если мы в лоб зададим вопросы этому самому начальнику, мол, какие у тебя есть потребности, он может дать как ценную информацию, так и не очень: а) из-за недостаточного контроля сотрудников страдает эффективность работы компании; б) процесс контроля для начальника неудобен — приходится опрашивать каждого сотрудника на предмет проделанной ими за день работы. И если первое выглядит как причина разработки проекта и мотивация для компании вложить в это деньги, то второе — скорее всего, нет: это личная боль начальника отдела, с которой нам также придется поработать, но не на текущем этапе и не в контексте корневых причин проекта.
3) Бизнес-потребности — это не требования в информационной картине аналитике. Требования направлены в будущее (TO BE) и касаются решения, которое наша команда будет реализовывать. На этом этапе речь вообще не идет о решениях — еще рано. Потребности описывают текущую ситуацию (AS IS) и выражаются в виде проблем или возможностей.
Примеры бизнес-потребностей:
- К нам обратился Ваня, который хочет сайт-визитку с информацией о себе и своих карьерных достижениях. Бизнес-потребность в виде проблемы, которую Ваня нынче испытывает и ради решения которой к нам пришел, может звучать так: недостаточная осведомленность целевой аудитории о Ване и о том, какой он крутой.
- У нас проект внутренней автоматизации, и мы в рамках своей же компании участвуем в разработке системы заказа обедов в офис. Бизнес-потребность нашей компании как заказчика в виде проблемы может звучать так: потеря лояльности сотрудников из-за отсутствия удобной системы питания в офисе.
- К нам обратился гениальный стартапер с идеей по разработке новой соцсети с уникальными фишками. Бизнес-потребность стартапера в виде возможности может звучать так: получение прибыли за счет платных фич для пользователей новой соцсети.
- Неайтишный пример: в рамках курса по бизнес-анализу я также стараюсь не упускать этот этап и выяснять у заказчика (т. е. того, кто хочет пройти курс) его бизнес-потребности до покупки. Для чего ему нужен курс? Если я получаю информацию вида “приобрести знания/навыки в IT БА для дальнейшего трудоустройства на позицию jun БА в РБ” (сформулировано как возможность), я могу с чистой душой подтвердить “рабочесть” такого решения, как наш онлайн-курс по БА, и двигаться дальше. В случае же нестыковок между бизнес-потребностью и желаемым решением, я постараюсь это подсветить, чтобы убедиться, что заказчик их понимает. Например, нужно получить только теоретические знания? Есть более дешевый курс, ориентированный на теорию и минимум практики. Под БА понимается работа с данными? Это аналитика, а не анализ, и курс не об этом. Нужно для mid/senior-уровня? Курс ориентирован на начинающих, пусть в нем и хватает продвинутых фишек. Не в РБ? Вот какие могут быть риски и вариации в понимании того, кто такой IT БА в разных странах и чем он должен заниматься.
Теперь, что означает “понять контекст, стоящий за потребностями”? Едва ли нам достаточно, когда к нам обратится Ваня из примера выше, выйти на сухую формулировку “недостаточная осведомленность целевой аудитории о Ване и о том, какой он крутой”. Наша задача в дальнейшем — помочь Ване в разработке того решения, которое огненно решит эту проблему. А для этого хорошо бы изучить эту потребность вдоль и поперек. Чем Ваня занимается? Кто его целевая аудитория? Где она? Что она сейчас знает о Ване и в результате каких его действий? Зачем Ване нужна ее бОльшая осведомленность? Как Ваня понимает, что аудитория сейчас недостаточно осведомлена? В чем смысл жизни?
Изучая вопросы выше, мы погружаемся в деятельность заказчика. Мы изучаем его бизнес-домен (предметную область; зачастую она гораздо более сложна, чем приведенные примеры: представьте, что “Ваня” — это компания, предоставляющая услуги по ипотечному кредитованию в Уганде), составляем глоссарий терминов этого домена, изучаем его организацию, если это не физическое лицо — ее процессы, архитектуру, технологии, политики, а также окружающий контекст (например, политики государства в данной отрасли).
Важно: делаем мы все описанное не ради самого факта накопления информации. Изучение контекста направлено на прояснение бизнес-потребностей, т. к. именно в этом наша цель на данном этапе. Не стоит слепо применять модные техники из Интернета или BABOK, которые нацелены на комплексное изучение организации и ее процессов. В IT бизнес-анализе наша конечная цель — поспособствовать качественной реализации IT-решения. Мы не специалисты по бизнес-трансформациям и не бизнес-консультанты. Изучать тут имеет смысл только то, что поясняет бизнес-потребности. Как только считаете, что поняли их суть и AS IS вокруг них — стопоритесь. Остальное доизучите тогда, когда появится очевидная необходимость.
Поняв, с чем нам нужно выйти из данного этапа, поговорим о том, как все это сделать. В предыдущей заметке я пояснил, что основная цель цикла — дать некий quick start guide по работе на каждом этапе.
Начнем с того, что анализ текущей ситуации — это, как и большинство работ аналитика, работа с информацией. В данном случае — с информацией о бизнес-потребностях заказчика и их контексте. Работа с информацией, если вспомнить и слегка дополнить любимого дядюшку Вигерса — это ее извлечение из тех, кто ей владеет (или из тех мест, где она сокрыта), анализ (убрать лишнее, систематизировать, привести в качественный вид), документирование (если нужно зафиксировать для будущего использования — а нужно это чуть реже, чем всегда), а также проверка и управление в дальнейшем (поддержка в юзабельном и актуальном состоянии). Основное из этого мы далее и затронем.
Не секрет, что основная работа этапа — это выкопать эту информацию из ее источников, причем как лежащую на поверхности, так и сокрытую в глубинах разумов или недрах документации. Простейшее, с чего нужно начать — это спросить. Спросить кого? Заказчика, вестимо. Или же его представителя — например, нам выдали в качестве контактного лица того, кто в данном проекте представляет интересы компании. Как правило, это наш первый стейкхолдер, с которым мы начинаем работу над проектом. Как спросить? Ну, как аналитики мы знаем про интервью (письменные, устные, очные, удаленные ), воркшопы и опросы. Выбираем тут, что душе угодно, но, как правило, стартерпак аналитика — это интервью с записью и заранее высланной агендой (повесткой). Предупреждаем собеседника о том, касательно чего будем его пытать, после чего созваниваемся и приступаем к раскопкам описанных выше вещей. Вероятно, понадобится несколько встреч и дополнительных коммуникаций для того, чтобы закрыть этап.
Примеры вопросов в их “голой” формулировке (т . е. без дополнительной обертки и витиеватостей):
- Каковы причины старта проекта?
- Что сейчас не так в этом плане? Какие возможности вы видите за реализацией проекта?
- Почему наблюдаются эти проблемы?
- Как целевые процессы работают сейчас?
- На что влияют озвученные проблемы?
Важно:
1) Донесите до заказчика, ради чего вы эту работу собираетесь делать. Естественно, в терминах ценности для него/проекта. Выше я упоминал, что заказчик может крайне скептически быть настроен на подобную работу. Т. е. посылы таковы:
1) Донесите до заказчика, ради чего вы эту работу собираетесь делать. Естественно, в терминах ценности для него/проекта. Выше я упоминал, что заказчик может крайне скептически быть настроен на подобную работу. Т. е. посылы таковы:
- Мы хотели бы начать с изучения причин реализации проекта.
- В будущем это поможет нам активно участвовать в генерации идей и нацеленности на корневые причины в плане ценности.
- Если согласны с тем, что это принесет пользу, давайте это все и обсудим.
Как и с извлечением любой информации, полезной аналитику, есть много советов и практик, позволяющих сделать это с большей эффективностью и меньшей болью для собеседника. Рассмотрим ключевые:
1) Повестки (agendas) и протоколы (minutes, follow-ups). Не забываем про полезность этих штук. На текущем этапе они особенно полезны, т. к. 1) заказчику надо внятно донести, что мы от него хотим, что будем выспрашивать и для чего — вероятно, ему надо к такой беседе подготовиться, плюс кого-то с собой захватить, 2) собранный по итогам открытых вопросов хаос нужно будет привести в упорядоченный вид (очистить от шелухи) и попросить заказчика подтвердить итоговое понимание — на данном этапе легко искаженно понять термины домена и суть происходящего в целом, т. к. для заказчика это будет первым “визитом к психотерапевту” и он будет наваливать вам море слов, в котором предстоит не утонуть.
То бишь до встречи/созвона высылаем заказчику письмом следующие детали:
После встречи/созвона высылаем заказчику письмом следующее (ниже будет не полный “типовой” шаблон протокола, а только то, что полезно в большинстве ситуаций):
В целом, про организацию встреч детальнее можно почитать тут, тут и тут.
То бишь до встречи/созвона высылаем заказчику письмом следующие детали:
- Цель встречи
- Когда и где (тут, естественно, приводим нужные ссылки и инструкции, если актуально — например, как приконнектиться к онлайн-сессии)
- Длительность
- Кто там нужен (поясните заказчику, что он может пригласить и других людей, если сочтет полезным в контексте обсуждаемых вопросов)
- Программа (список обсуждаемых вопросов в той детализации, которая видна заранее и которую сочтете ценным для донесения получателю)
- Сопроводительные материалы и экшн-план для подготовки (в контексте обсуждения AS IS это не особо, как правило, актуально, но оставлю на всякий случай)
После встречи/созвона высылаем заказчику письмом следующее (ниже будет не полный “типовой” шаблон протокола, а только то, что полезно в большинстве ситуаций):
- Ключевые пункты из полученной на встрече информации (обязательно пропущенные через себя и приведенные в качественный вид) с просьбой поправить или подтвердить понимание.
- Саммари по дальнейшим действиям — в особенности, если такие действия упоминались на встрече (“Ты, заказчик, поспрашиваешь у сотрудников о…; мы начнем работу над…”; “встречаемся снова в следующее полнолуние там-то…”). В идеале — по формуле “кто, что, когда”. Про экшн-айтемы можно еще тут и тут посмотреть.
В целом, про организацию встреч детальнее можно почитать тут, тут и тут.
2) Записываем встречу. В идеале — с согласия участников. Т. е. заранее прорабатываем то, как технически мы это будем делать (настраиваем параметры Зум-встречи, ставим себе и проверяем работу скрин-рекордеров наподобие Bandicam, готовим диктофон на телефоне и пр.), как будем спрашивать про уместность записи (не забываем обезопасить и “продать” это в терминах ценности) и что будем делать, если получим отрицательный ответ. А стоит ли вообще записывать? Да, стоит, не ленитесь (как записывать, так и изучать записи впоследствии):
а) На данном этапе заказчик дает вам золотую информацию. Упустить потребность из-за того, что пришлось одновременно конспектировать и поддерживать беседу — так себе результат. Аналитик должен уметь бережно работать с информацией. Иногда одно слово, которое вы выудите из хаоса, может стать зацепкой и развернуть изучение еще одной потребности или иного важного аспекта.
б) Никто не любит повторяться. От аналитика ожидается, что он как раз натренирован минимизировать подобное. Это особенно важно на текущем этапе — как в контексте значимости информации для всего дальнейшего проекта, так и в плане того, что в этой точке вы еще пока проявляете себя для заказчика. Все мы люди и всегда что-то упускаем, но есть простейшее решение: записать и внимательно после переслушать.
а) На данном этапе заказчик дает вам золотую информацию. Упустить потребность из-за того, что пришлось одновременно конспектировать и поддерживать беседу — так себе результат. Аналитик должен уметь бережно работать с информацией. Иногда одно слово, которое вы выудите из хаоса, может стать зацепкой и развернуть изучение еще одной потребности или иного важного аспекта.
б) Никто не любит повторяться. От аналитика ожидается, что он как раз натренирован минимизировать подобное. Это особенно важно на текущем этапе — как в контексте значимости информации для всего дальнейшего проекта, так и в плане того, что в этой точке вы еще пока проявляете себя для заказчика. Все мы люди и всегда что-то упускаем, но есть простейшее решение: записать и внимательно после переслушать.
3) Применяем активное слушание:
а) По ходу встречи направляем собеседника в нужную сторону: объясняем на старте, что хотим услышать (т. е. повторяем то, что было в агенде), и мягко корректируем по ходу действа, если видим, что получаем не то, что нужно.
б) Убеждаемся, что верно понимаем информацию в процессе: переспрашиваем, перефразируем сложные моменты для подтверждения (“Давайте я попробую сформулировать сказанное своими словами…”; “Правильно ли я понял, что…”).
в) Поддерживаем интерес собеседника: показываем собственную заинтересованность, разбавляем умеренными эмоциональными реакциями, улыбаемся и машем.
а) По ходу встречи направляем собеседника в нужную сторону: объясняем на старте, что хотим услышать (т. е. повторяем то, что было в агенде), и мягко корректируем по ходу действа, если видим, что получаем не то, что нужно.
б) Убеждаемся, что верно понимаем информацию в процессе: переспрашиваем, перефразируем сложные моменты для подтверждения (“Давайте я попробую сформулировать сказанное своими словами…”; “Правильно ли я понял, что…”).
в) Поддерживаем интерес собеседника: показываем собственную заинтересованность, разбавляем умеренными эмоциональными реакциями, улыбаемся и машем.
4) Помним про воронку извлечения информации (именно ее стоит пройти, чтобы сказать, что вы извлекли информацию, а не алгоритм “спросил -> послушал”):
а) Открытые вопросы: собираем все, что собеседник готов высказать по теме (“Расскажите про причины старта проекта.”) ->
б) Закрытые вопросы: проясняем непонятное и доскребаем то, что еще хотим узнать (“То есть это влияет на…? А на что еще это влияет? А кто занимается этим процессом у вас?”) ->
в) Убеждаемся в корректности понимания: ключевые моменты перефразируем и отражаем от собеседника (“Правильно ли я понял, что ключевая причина — …., но еще есть вот такой аспект, который важно учесть…?”) ->
г) Подтверждаем итог как целостную картину: суммируем все полученное, но в пропущенном через себя целостном виде (“Давайте подытожим: проект обусловлен такими вот тремя бизнес-потребностями: … Все? Есть, что добавить?”).
Пункты в и г можно покрыть протоколом, т. е. уже письменно после беседы.
а) Открытые вопросы: собираем все, что собеседник готов высказать по теме (“Расскажите про причины старта проекта.”) ->
б) Закрытые вопросы: проясняем непонятное и доскребаем то, что еще хотим узнать (“То есть это влияет на…? А на что еще это влияет? А кто занимается этим процессом у вас?”) ->
в) Убеждаемся в корректности понимания: ключевые моменты перефразируем и отражаем от собеседника (“Правильно ли я понял, что ключевая причина — …., но еще есть вот такой аспект, который важно учесть…?”) ->
г) Подтверждаем итог как целостную картину: суммируем все полученное, но в пропущенном через себя целостном виде (“Давайте подытожим: проект обусловлен такими вот тремя бизнес-потребностями: … Все? Есть, что добавить?”).
Пункты в и г можно покрыть протоколом, т. е. уже письменно после беседы.
5) Не забываем о важности точного понимания терминологии — о глоссарии:
а) Как только встречаем неизвестные термины или множественные/туманные трактовки знакомых слов, переспрашиваем сразу, чтобы убедиться, что понимаем вкладываемый им в них смысл.
б) Фиксируем определения (не обязательно сразу на встрече, конечно) и отражаем их от заказчика, чтобы подтвердить единое понимание. Мир полнится кучей примеров, когда работа шла в неверном направлении из-за разницы в понимании терминов. Дополнительно можно почитать тут и тут.
а) Как только встречаем неизвестные термины или множественные/туманные трактовки знакомых слов, переспрашиваем сразу, чтобы убедиться, что понимаем вкладываемый им в них смысл.
б) Фиксируем определения (не обязательно сразу на встрече, конечно) и отражаем их от заказчика, чтобы подтвердить единое понимание. Мир полнится кучей примеров, когда работа шла в неверном направлении из-за разницы в понимании терминов. Дополнительно можно почитать тут и тут.
6) Стараемся общаться языком собеседника, т. е. не перегружаем его IT-терминами и терминами бизнес-анализа в частности. При этом можем либо использовать их и сразу же пояснять, что в них вкладываем, либо в принципе заменять на простые слова (т. е. не “А сейчас мы обсудим бизнес-потребности, которые стоят за изменением и решением”, а “Давайте обсудим причины проекта”). В целом, рекомендую в коммуникациях идти по концепции “Объясню понятно и просто”, а не “Умно заверну, дабы собеседник понял, какой я офигенный” — второе несет ценность лишь в крайне узких ситуациях.
Далее капитан скажет очевидную вещь, но все, что наизвлекали, фиксируем (документируем) — информация не должна храниться в голове. Причем конечная цель — зафиксировать это в пропущенном через себя виде, т. е. не стенографию изначального хаоса, а переформулированную и структурированную (упорядоченную по темам) информацию. Пользуем тот инструмент, который по душе или который используется на проекте для хранения проектной информации: Word- или Google-документы, странички в Confluence или, как вариант быстрого конспектирования, mind maps (кстати, не пренебрегайте этим вариантом — это отличный способ структурированно вести в процессе и хранить конспект). Структура документа/странички тут не особо важна — каких-то общепринятых популярных шаблонов для информации из данного этапа нет.
Также можно попользовать две полезные визуальные модели (как рисовать совместно в процессе бесед, так и вне них, но с последующим отражением от заказчика):
1) Модель бизнес-домена — помогает структурированно подать и закрепить понимание предметной области.
2) Диаграмма Исикавы — если необходимо покопать в корни какой-либо бизнес-потребности. Строим ее в комбинации с "почемучкой" (5 Why's).
2) Диаграмма Исикавы — если необходимо покопать в корни какой-либо бизнес-потребности. Строим ее в комбинации с "почемучкой" (5 Why's).
