Бизнес-анализ от а до я: гид для начинающих

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

Описание функциональности:

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

Шаги/Сценарий:

На странице профиля компании система отображает раздел «Кредитная информация».

В разделе «Кредитная информация» отображаются следующие поля/данные:

Кредитный рейтинг (название) – текстовое, неизменяемое.

Кредитный рейтинг (значение) – неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.

Кредитный статус (название) – текстовое, неизменяемое.

Кредитный статус (значение) – неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.

Кредитные условия (название) – текстовое, неизменяемое.

Кредитные условия (значение) – неизменяемые, три текстовых поля со значениями:

а) разрешенная рассрочка: «ХХ» месяцев;

б) статус контракта: «активен», «неактивен» или «истек»;

в) размер задолженности: «нет» или «размер задолженности».

Кредитная история (название) – текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).

Заключение:

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

Изменение данных:

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

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

Для этих целей я разрабатываю два дополнительных документа:

Спецификация по пользовательскому интерфейсу (СПИ / User Interface Specification), которая содержит макеты того, как будет выглядеть раздел «Кредитная история» для пользователя.

Спецификация по модели данных (СМД / Data Model Specification), описывающая хранение данных, использованных в функциональном дизайне.

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

Почему визуальная составляющая хранилась в отдельном документе? На тот момент я не обладал достаточным опытом, чтобы изменить подход, но теперь предпочитаю наиболее оптимальный подход: описание функциональной и визуальной частей в одном месте. Это даёт любому пользователю артефакта сразу понятную картину: что, как и где должно работать. Модель данных, на мой взгляд, должна создаваться отдельно и не может быть представлена кусками в каждом функциональном дизайне. Цель документирования всей модели данных в одном месте – это визуализация и создание полной картины о модели данных, её корректности, логичности и связей между всеми объектами, их атрибутами и свойствами. Не буду углубляться сейчас, так как вернёмся к этому позже в следующих шагах подробно.

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

Вот, собственно, что я хотел рассказать про реальные первые месяцы моей работы бизнес-аналитиком. Я не общался с клиентом и не занимался выявлением бизнес- или функциональных требований – таких обязанностей у меня не было, так как не было и опыта, и нужно было сначала изучить базовые активности. Я даже не знал, какой используется и из чего состоит цикл разработки программы/системы. А использовали мы методологию разработки, которая называется «Водопад» (Waterfall). Почему «Водопад»? Потому что создание системы/продукта поделено на этапы, которые всегда выполняются в последовательном порядке – один за другим. Отсутствие этих навыков и знаний – было ли это плохо или негативно в плане моего опыта? На мой взгляд, нет, так как я получал полноценный опыт в самом базовом и необходимом БА навыке – документирование требований и их дизайна.

То, что я описывал выше, как вы поняли, это «жесткие» навыки (Hard skills). А вот какие из «мягких» навыков (Soft skills) я бы подсветил, в которых я получал опыт и считал важными? Думаю, я стартовал с трех основных мягких навыков, которые я назову в формате ролей: командный игрок, мистер-вопрошайка и тайм-менеджер. Уточню, что некоторые приобретенные способности, которые я называю «мягкими» навыками выше, не являются прямо официальными навыками, которые указаны в книгах, или, возможно, они указаны, но в других терминах. Я написал именно «стартовал», так как все эти три навыка я продолжал развивать на протяжении своей БА карьеры. Расскажу кратко о них и почему именно они мне показались (или нет) важными на старте:

Командный игрок

Я начинал свою карьеру в команде, состоящей всего лишь из меня и ведущего бизнес-аналитика, но это уже была команда! Эффективная команда – это залог успешного достижения любых целей в любой деятельности (и не только в ИТ-сфере, разумеется). Один из критериев «эффективной» (продуктивной, быстрой, ценной и т. д.) команды – это ситуация, когда все её участники являются командными игроками. Иначе командой это назвать нельзя. Кто такой «командный игрок» в плане работы? Для меня это человек/коллега, который: понимает и знает (да! у командного игрока есть обязанность «понимать и знать») командные цели, проблемы, планы, подходы к работе; умеет и обладает способностями принимать решения вместе с командой, воспринимать любые отзывы и критику от команды позитивно и использовать их для своего профессионального улучшения и для достижения целей команды, оценивать и принимать подход к распределению задач рационально с точки зрения эффективности для всей команды, быть честным и открытым для команды даже при обнаружении самостоятельно созданных проблем, постоянно стремиться к улучшению процессов в команде, слушать команду, соблюдать авторитет ведущего команды (ведь именно он в итоге ответственен за команду перед всеми выше стоящими) и последнее простое, но очень важное – уважать свою команду в любых плоскостях (например, никогда не опаздывать на встречи или, если не успевает, предупреждать).

Почему этот «мягкий» навык я включаю в начальный список? Я думаю, на любом этапе профессионального развития человек должен стараться приобретать те навыки, которые наиболее актуальны в данный момент времени. Когда только начинаешь путь бизнес-аналитика, то почти нет жестких навыков, которыми ты можешь выделиться и помочь команде или проекту. И команда (проектная или БА) может оценивать тебя именно по мягким навыкам, которые, в свою очередь, могут существенно ускорить и улучшить приобретение жестких навыков. И так как я уже упомянул слово «команда», становится логичным, что первый и ключевой навык должен быть связан с командой. Не может быть сценария, когда у бизнес-аналитика нет команды, так как процесс создания продукта или проекта невозможен без команды. И соответственно бизнес-аналитик, который является хорошим (а лучше «отличным») командным игроком, – это то, на что команда будет смотреть в первую очередь. Команда может сказать: «Да, этот бизнес-аналитик ещё новичок и не очень разбирается в БА-специфике, но он отличный командный игрок – мы им довольны».

Почемучка

В силу специфики работы бизнес-аналитика, этот навык просто обязателен с самого начала карьеры. Вся наша работа связана с получением информации из различных источников, её трансформацией и передачей. Первый пункт особенно важен, так как он является исходной точкой, и изменить эту последовательность нельзя. Сначала информацию нужно получить. Получение информации в работе бизнес-аналитика – один из ключевых и непрерывно повторяющихся процессов. В процессе «Получить информацию» конечно же есть активность «выслушать и записать» и множество других важных активностей. Особенно важной является активность «задавать вопросы», без которой любая полученная информация может оказаться некорректной, неверной, недостаточной, неполной и даже бесполезной. Что здесь добавить – активность «задавать вопросы» это ключевой навык на протяжении всей жизни человека, особенно в первые несколько лет, начиная с рождения. Ведь через вопросы ребёнок познаёт и изучает мир, изначально даже задавая вопросы без слов – жестами и звуками. Если вы становитесь бизнес-аналитиком, то вам необходимо, так сказать, вернуться в детство и воспринимать эту активность как обязательную часть работы. Вы никогда не сможете создать требование, дизайн и, в конечном итоге, продукт высокого качества, если, например, к вам подойдет человек и скажет: «Я хочу зеленую кнопку в этой программе», а вы, после этого, просто напишете требование и дизайн для своей команды, состоящее из одного предложения: «Клиент хочет зеленую кнопку». Можно сказать, что именно вопросы создают востребованные решения и продукты. Что же, на мой взгляд, включает в себя этот навык «Почемучка»? На мой взгляд, бизнес-аналитик должен обладать следующими способностями: умение задавать вопрос вовремя, правильно формулировать и, при необходимости, визуализировать вопрос, определять и привлекать нужную целевую аудиторию для получения информации, оценивать как значимость вопроса, так и ценность получаемой информации, и, конечно, самое важное – не бояться задавать вопросы, даже если они кажутся слишком простыми, очевидными или даже глупыми. Возможно, пункты выше кажутся очень простыми, но это только на первый взгляд. За свою карьеру я видел достаточно реальных примеров, когда 4-6 месяцев работы целой команды могли быть потрачены напрасно из-за одного незаданного вовремя вопроса или вопроса, заданного неправильно или не тем людям. И это именно навык, который включает в себя приобретенные способности и знания – это не просто умение человека задать вопрос. Да, мы все можем задавать вопросы, для этого нужны только рот, язык, выдох и желание выразить что-либо в вопросительной форме. Например, один из эффективных вопросов, который помогает формировать правильную информацию, – это прямой вопрос: «А зачем нам это нужно?» Однако в большинстве случаев, особенно при взаимодействии с представителями клиента, такой вопрос может сразу и серьезно испортить отношения и замедлить прогресс проекта. В этом сценарии должна проявиться специфика навыка – задать этот простой вопрос правильно сформулированным образом, в нужное время и для правильной аудитории.

Управленец временем

Вот и последний из упомянутых «мягких» навыков – тайм-менеджмент или управление временем. Этот навык особенно важен и сложен для бизнес-аналитиков, поэтому его развитие следует начинать сразу же с начала карьеры. Что такое тайм-менеджмент простыми словами? Я бы описал его как способность человека в определённой обстановке (например, на работе) и в данном контексте (проектном, продуктовом, коммуникативном, командном и так далее) выполнять свои задачи (активности, процессы, артефакты) максимально эффективно с точки зрения распределения времени на задачи, которые нужно выполнить. Ключевая фраза «максимально эффективно» означает, что на все задачи затрачивается минимально возможное время при получении максимальной пользы/ценности от их выполнения с максимально возможным качеством. «Минимизация временных затрат» как показатель эффективности участвует, думаю, во всех сферах труда и личной жизни.

Простой пример применения навыка тайм-менеджмента в личной жизни (многие, я уверен, так делают) – например, каждый день дома я убираю со стола посуду в посудомойку. В среднем это 6 тарелок. Если я отношу каждую тарелку на кухню в посудомойку, то это занимает примерно 6 секунд на каждую и 36 секунд на все тарелки. Если посчитать обед, завтрак и ужин, то это 108 секунд в день. Округлим до 2 минут для простоты. Значит, в месяц это 60 минут или 1 час. В год это 12 часов на уборку тарелок в посудомойку. А если я немного изменю процесс и все тарелки буду ставить на поднос или друг на друга и относить одним разом на кухню, то это займет не 36 секунд, а в три раза меньше времени – допустим, около 12 секунд. Соответственно, при годовом расчёте можем уменьшить первоначальные 12 часов в три раза, то есть до 4 часов, и тогда 8 часов мы сэкономим. Таким образом, у нас есть 8 часов в год, которые я гипотетически могу потратить, как захочу.

В этом примере ключевой момент заключается в том, что время обладает гибкостью и всё зависит от того, как человек планирует своё время. Планирование – это важно. Одна из ключевых частей управления временем – это его планирование. Планирование времени включает в себя распределение времени на задачи – ежедневные, еженедельные, ежемесячные и так далее. Наша жизнь состоит из постоянных задач, и от того, как мы планируем обязательные задачи, зависит, сколько у нас будет свободного времени на необязательные задачи (например, отдых). Естественно, желательно, чтобы времени на отдых было как можно больше.

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

Когда я начал карьеру бизнес-аналитика, я задал себе вопрос: «Чем я могу выделиться среди других БА в нашей компании?». Одним из ключевых отличий, которое я выбрал, стал навык и подход к планированию. Оценивать свое развитие в этом направлении было довольно просто. После нескольких месяцев работы в качестве БА, продолжая совершенствовать свои умения, я помню случаи, когда ведущий БА поручал мне задачу по документированию требования, говоря, что на это уйдет примерно две недели. Я планировал так, чтобы завершить задачу за пять дней. Это была моя цель, и развитие этого навыка было прямо пропорционально увеличению моей ценности для компании. В будущем часто возникали ситуации, когда я соглашался участвовать в срочных проектах с очень сжатыми сроками, что я рассматривал как преимущество. Подробнее о таких ситуациях я расскажу в следующих главах.

Возвращаясь к управлению временем, этот навык важен и сложен одновременно, что делает его особенно значимым. Навык управления временем является сложным, так как работа бизнес-аналитика не подразумевает однообразных и четко определенных процессов – каждый проект и продукт уникален, и БА должен адаптировать свои подходы под каждую задачу. Под каждый проект и продукт нужно соответствующим образом управлять временем. БА должен уметь понимать контекст и эффективно управлять своим временем. Под «важен» я имею в виду высокую ценность и приоритет этого навыка и связанных с ним активностей. Вернусь снова к теме «планирования времени и задач» как к примеру сложности и важности этого процесса. Для меня это до сих пор самая значимая и сложная ежедневная задача. Пока я не запланирую свой день, я не приступаю к выполнению задач. Иногда мне приходится тратить 30, 60, а иногда и 90 минут просто на идентификацию, анализ, подготовку и планирование дневных задач, включая их приоритизацию и декомпозицию. Однако, когда планирование завершено и я точно знаю, что максимально эффективно организовал свое рабочее время, мне становится легко и прозрачно выполнять все запланированные задачи без малейшего сомнения. Детали, рекомендации и подходы мы рассмотрим в следующих главах. Может показаться немного сумбурно, но таковы мои размышления о навыке управления временем. Остается только один важный аспект, без которого описание этого навыка нельзя считать завершенным: описание того, что должен уметь человек, и какими способностями он должен обладать (по моему мнению), и всегда с уточнением «максимально эффективно» относительно активностей/задач/процессов: планировать, приоритизировать, декомпозировать/дробить, распределять/определять время выполнения, оставаться сфокусированным, делегировать, всегда видеть целевую цепочку, принимать решения. Кратко о каждом умении: Планирование – это начало любой активности вообще и включает в себя такие аспекты, как определение самого процесса и подхода к планированию в зависимости от контекста, разработка и документирование артефактов планирования, а также непрерывный мониторинг, проверка и актуализация плана. Непрерывная приоритизация активностей обеспечивает понимание и уверенность в том, что выполнение задач происходит с максимально эффективным использованием времени и приносит максимальную ценность для конечных целей. Приоритеты могут меняться со временем или быть статичными, но должен быть четко определен их порядок и критерии. При наличии прозрачного приоритезированного списка активностей/задач исключаются факторы сомнения о затрачиваемом времени на задачу – это важно как психологически, так и профессионально, поскольку когда я выполняю какую-либо задачу, у меня нет сомнений о её актуальности и полезности. Декомпозиция очень важна, особенно по мере вашего профессионального роста и, соответственно, увеличения сложности проектов/продуктов, в которых вы участвуете. Неправильная или недостаточная декомпозиция может привести к серьезным задержкам в выполнении задач и неэффективному использованию времени. Нельзя удержаться и не привести пример, с которым, я думаю, большинство из вас сталкивалось как в рабочих, так и в личных делах. Вот пример из внерабочих активностей, основанный на реальных событиях: скоро день рождения у моей жены, и у меня есть задача «Поздравить с днем рождения». Для этой активности, естественно, может быть очень простой план без какой-либо декомпозиции, который выглядит как «Поздравить с днем рождения = купить подарок» и всё готово. Или можно подумать и сделать декомпозицию, например, на три пункта: 1. Подготовить поздравление. 2. Подготовить подарок. 3. Определить место для празднования. Эти три пункта, в свою очередь, содержат подпункты. Например, пункт №1 может включать: 1. Придумать сценарий поздравления. 2. Закупить необходимые материалы. 3. Подготовить части поздравления. Каждый из этих пунктов можно далее декомпозировать. Например, пункт №2 разбить на подпункты: 1. Материалы для подготовки видеопоздравления. 2. Материалы для оформления стола. 3. Контекстные материалы. Из этих я еще сделаю разделение, например, для пункта 3 на: надувные шары, фотографии для украшения стен, коробки для подарков, упаковочная бумага и так далее. И вот после всех уровней декомпозиции у меня есть довольно простые задачи, которые я могу запланировать выполнить в уже примерно понятные временные сроки и даты. Да, тут нет ничего сверхъестественного, и всё действительно просто – именно в этой простоте декомпозиции кроется сверхэффективность. Декомпозиция позволяет концентрироваться на конкретной, понятной и выполнимой в краткосрочной перспективе задаче или активности. Следующее умение, связанное с распределением и определением времени, выделяемого на какую-либо задачу, думаю, не требует объяснений, так как в большинстве случаев любая глобальная активность или цель всегда имеет временные рамки. Соответственно, любые ваши действия, чтобы рассматриваться как эффективные с точки зрения времени, должны быть оценены: сколько времени они займут и когда наиболее правильно будет их выполнить. С умением «быть сфокусированным» тоже всё просто и важно. Включая упомянутые выше умения, такие как приоритизация, планирование и декомпозиция, у вас должна быть ясная картина, чем и когда заниматься. Затем важна личная способность а) быть сфокусированным на одной задаче в данный момент времени (никакого мультитаскинга), и б) всегда иметь в фокусе общую картину глобальной цели, когда вы тратите своё время на конкретную активность.Следующая способность, "делегирование", подразумевает, что вы понимаете и распределяете задачи среди коллег, чётко осознавая, какую пользу это принесёт в контексте затрат времени и ценности для конечных целей. Если вы работаете в команде бизнес-аналитиков, то не должно быть сценариев, когда вы пытаетесь взять на себя все важные, сложные или крупные задачи, ведь у вас также есть умение декомпозировать, которое может помочь распределить задачи внутри команды. Также у вас обязательно будут активности, зависящие от внутренних и внешних факторов – у вас должно быть понимание и подход, в каком формате, как, зачем и с какими ожиданиями делегировать задачи другим.

"Видеть целевую цепочку" – это навык, который требует практики и опыта. Я бы описал его как способность быть сфокусированным – в любой момент и при любых обстоятельствах вам должна быть ясна связь от начальной стадии до конечной цели всех задач и проектов. Если я вношу изменения в одно поле на странице веб-сайта, я должен понимать, как это повлияет на один из бизнес-процессов, в рамках которого используется этот веб-сайт, что в свою очередь влияет на результаты работы нашей команды. И последнее умение, которое звучит удивительно просто – умение принимать решения. Да, именно это умение напрямую влияет на эффективное использование времени. Колебания в принятии решений не допустимы. Это особенно просто, если всегда помнить и повторять себе, что откладывание или избегание принятия решения (что ведет к задержкам и, следовательно, к неэффективному использованию времени) можно преодолеть, напоминая себе: «В принятии решения всегда есть опции, из которых надо выбрать. С любой выбранной опцией я продвинусь вперед. Если что-то пойдет не так, я всегда смогу принять следующее решение, и это нормально». Таков подход. Не должно быть ситуации, когда мы говорим: «Я пока не могу принять решение», особенно если все перечисленные выше умения уже применены и использованы. Применение описанного подхода минимизирует любые сомнения. Вот и всё, что я хотел сказать про навык тайм-менеджмента; описать его не так уж и просто, но я постарался.

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

Шаг 2 – отличный БА.

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

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

Что же такое функция? Возьмем пример из предыдущего этапа: у нас есть компонент системы под названием “система управления информацией о клиентах”. В этом компоненте существуют различные функции, такие как создание профиля клиента, редактирование профиля, просмотр и управление кредитной информацией о клиенте и многие другие. Каждую такую функцию можно далее разделить на множество подфункций или требований. Одно из требований, касающееся кредитной информации, мы уже рассмотрели на предыдущем шаге. Функция представляет собой определённый набор свойств и действий (как пользователя, так и системы), которые позволяют конечному пользователю выполнить полноценное и завершённое действие с определённым ожидаемым результатом. Как я упоминал ранее, например, функция "создать профиль клиента".

С течением времени я начал получать задачи по подготовке функций. Виды задач, активности и ответственность стали разнообразнее, что отражало мой продолжающийся профессиональный рост. Я ощущал, что уровень сложности моих задач повышается: теперь задача заключалась не просто в написании требований и их документировании. Теперь мне требовалось анализировать нужную функцию, декомпозировать её, определять и документировать необходимые требования и дизайн, корректно связывать все требования между собой в матрице требований, управлять статусом готовности и блокерами, а также подготавливать вопросы для заинтересованных сторон (stakeholders) со стороны клиента. Да, это был настоящий взрыв нового опыта! Как следствие, к задачам, связанным с функциями, добавились общие профессиональные задачи в связи с увеличившейся сложностью: проверка и поддержание (а при необходимости изменение) информационной модели/структуры требований и дизайна, поддержание их логичности, понимание работы с моделью данных, разработка спецификаций модели данных, понимание жизненного цикла разработки системы, а также развитие дополнительных и необходимых "мягких" навыков. Столько всего… наверное, я сразу «раскрыл карты» о навыках и активностях, которые буду дальше описывать, но так вот – никаких секретов! Единственное, я упомянул новое слово «стейкхолдер». Поясню: стейкхолдер – это человек, который ожидает и будет иметь какую-то выгоду от ИТ-продукта, который я создаю, или будет его использовать. В проектах компаний-поставщиков сервисов или продуктов, которые нанимают другие компании, основными стейкхолдерами всегда являются люди на стороне клиента, те, кто ожидает готовый продукт. Это может быть всего один человек, взаимодействующий с сервисной компанией, или множество людей на стороне клиента. Это люди разных уровней в организации клиента – от генерального директора до заместителя директора ИТ-департамента, экономического отдела или отдельной проектной команды, курирующей создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. Именно с ними БА выявляет требования к системе/продукту. Позже мы подробно рассмотрим БА-навык «управление стейкхолдерами».

С точки зрения процессов и активностей, у меня уменьшилось количество времени, которое я выделял ежедневно на обсуждения со своим ведущим БА, так как он стал более уверен в моем умении документировать требования и в моей профессиональности в целом. Иногда у меня даже не было ежедневных созвонов. Но вместо этого появились серьезные, хоть и нечастые, созвоны, где мы обсуждали мою подготовку документации по всей функции. Для описания активностей и навыков я возьму функцию, которой я занимался, – «Управление адресной информацией», которая является частью компонента «Система управления информацией о клиенте». Мне было поручено полностью подготовить необходимые дизайн-спецификации для разработки этой функции. Сначала мне нужно было прояснить бизнес-цели создания и понять, какие входные данные у меня есть. Единственным моим источником был мой ведущий БА, который работал и общался с командой клиента для выяснения любых вопросов. Я запланировал с ним звонок и начал готовиться к обсуждению. Заранее подготовил список вопросов, которые помогли бы мне определить границы задачи и прояснить неясные моменты. Я проверил существующие бизнес-требования, упоминавшие что-либо о адресной информации, и включил их в свой вопросный список, чтобы подтвердить, какие из них будут использоваться для создания функциональных требований. Я сделал черновую декомпозицию функции на набор предварительных функциональных требований.

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