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

Создание требований

Рассмотрим бизнес-требование: «Профиль компании должен содержать информацию о кредитоспособности компании». Это требование от бизнеса и клиента ясно формулирует необходимость проверки платежеспособности компании-покупателя перед совершением коммерческих операций с предоставлением товаров в рассрочку.

На основе этого бизнес-требования я разработал функциональное требование: «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента, включая кредитный статус, кредитный рейтинг и текущие кредитные условия».

Давайте разберём идентификатор этого требования: «ФТ-СУК-КР-1». «ФТ» означает «Функциональное Требование». «СУК» указывает на систему, к которой относится требование – Система Управления Клиентами. «КР» обозначает конкретный модуль или компонент системы – Кредитный модуль. Номер требования – 1. Правила создания таких идентификаторов позволяют легко определить, о чем идет речь в требовании. Текст требования может быть изменен, но идентификатор остается неизменным и играет ключевую роль в матрице связей/отслеживания и в любых других документах, связанных с этим требованием. Функциональное требование включает в себя несколько важных пунктов, каждый из которых имеет ключевое значение:

«Система» – это кажущееся простое слово подтверждает, что именно наша система должна реализовать указанную функциональность. Это утверждение дает 100% гарантию включения функции в систему.

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

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

«информацию о:…» – здесь конкретно перечисляются параметры, которые должна отображать система. Это может включать параметры, которые обязательно будут реализованы, а также те, которые могут быть добавлены позже, если это будет возможно в рамках проекта.

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

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

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

Дизайн требования

Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом "Спецификация по функциональному дизайну" (Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.

Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1. "ФД" здесь обозначает "Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например, "Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.

Описание дизайна:

"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."

Входные условия:

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

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

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

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

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

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

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

Кредитный рейтинг (значение) – неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 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 предложениях, то поделюсь следующим: первый стартовый этап освоения базовых навыков и понимания формата работы бизнес-аналитика занял у меня примерно два месяца. В это время я сосредоточился на жёстких навыках, таких как документирование требований и дизайнов к ним, а также изучение базовых процессов выявления требований, понимание структуры требований и дизайнов, определение критериев готовности. В сфере мягких навыков акцент был сделан на управлении временем, умении задавать вопросы и, конечно, командной работе.