Бесплатный фрагмент - Как создать подразделение IT-бизнес-анализа

Я искренне благодарю вас за интерес к моей книге.

Надеюсь, она станет источником вдохновения

для воплощения ваших самых невероятных идей и проектов.

ОБ АВТОРЕ

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

Получив степень магистра с отличием по специальности «Математические методы в экономике», я с воодушевлением начала карьеру в финансах. Шведский Swedbank стал моей первой профессиональной школой, затем я продолжила карьеру в российском ВТБ. За годы в банкинге мне посчастливилось изучить множество компаний — от крупных корпораций до небольших семейных бизнесов. Я вникала в их финансовые документы, изучала процессы и решения, стоящие за цифрами. Мне было интересно понять внутреннее устройство бизнеса: причины принятых решений, свя зи между бизнес-процессами и то, что помогает предприятиям справляться с вызовами. Позднее эти знания станут значительным вкладом в мой «портфель аналитика» и помогут сформировать понимание взаимосвязей, от которых зависит успех бизнеса.

Несмотря на успехи в банкинге, меня не оставлял интерес к миру IT. Еще в университете, будучи студенткой факультета информационных технологий, я с интересом следила за достижениями в этой области. На втором курсе я начала подрабатывать тестировщицей интерфейсов в компании-разработчике одной из крупнейших программных систем для бухгалтерии — «1С: Предприятие». Это был мой первый робкий шаг в IT-индустрию, который приоткрыл завесу в мир, полный возможностей для роста, инноваций и создания решений, буквально способных изменить реальность. По иронии судьбы компания «1С» впоследствии выкупит значительную долю в amoCRM — одной из известнейших компаний российского IT и моем первом серьезном работодателе в индустрии.

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

Пройдя путь от самых начальных позиций, я возглавила одно из ключевых направлений компании — проект amoCRM Global, ориентированный на рынок США. Этот проект стал для меня не просто рабочей задачей, а настоящей школой профессионального становления. Именно здесь я научилась видеть проекты в масштабах всей компании, принимать быстрые и выверенные решения и эффективно работать в условиях постоянных изменений.

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

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

Милана Котова

ВВЕДЕНИЕ

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

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

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

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

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

Глава 1. КТО ТАКИЕ АНАЛИТИКИ В IT

Именно такой вопрос задал недавно мой старый друг. Мы познакомились во времена моей работы в банке, где он был нашим клиентом. С тех пор многое изменилось: я перешла из банковской сферы в IT, он переехал в Северную Америку, занимаясь проектом разработки и внедрения платежных систем. В одном из наших разговоров я упомянула, что сейчас работаю бизнес-аналитиком. Его реакция удивила меня: «А кто такой бизнес-аналитик в IT и в чем заключается твоя работа?» Услышать такой вопрос от человека из одной индустрии было неожиданно, но это заставило меня задуматься. Если даже специалисты из IT не всегда до конца понимают роль аналитика, то что говорить о людях из других сфер?

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

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

Бизнес-аналитик (Business Analyst) — глубоко погружен в предметную область проекта. Его задача — выявить истинные потребности заказчика и перевести их на язык, понятный команде разработки. Это не просто связующее звено, а специалист, который должен понимать цели проекта, чтобы превращать идеи заказчика в четкие, структурированные требования.

Системный аналитик (System Analyst) — это специалист, который работает с требованиями к функционалу системы, опираясь на бизнес-требования и адаптируя их к техническим особенностям проекта. Он прорабатывает детали архитектуры, контролирует совместимость с существующими системами и учитывает потенциальные технические ограничения. Часто роль системного аналитика пересекается с функциями бизнес-аналитика или разработчика.

Дата-аналитик (Data Analyst) — специалист, работающий с большими массивами данных. Он выявляет тренды, закономерности и инсайты, необходимые для принятия стратегических решений. Анализируя данные с помощью таких инструментов и языков программирования, как Excel, SQL, Python, R, он создает информационную основу для выработки рекомендаций.

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

BI-аналитик (Business Intelligence Analyst) отвечает за преобразование данных в полезную информацию для принятия управленческих решений. Он визуализирует данные в виде дашбордов и отчетов с помощью BI-инструментов: Tableau, Power BI, Google Data Studio, SAP. Основная задача — представить данные для принятия обоснованных решений на основе аналитики.

Аналитик информационной безопасности (Security Analyst) работает с данными сетей и систем, связанными с кибербезопасностью, анализирует потенциальные угрозы, разрабатывает меры по их предотвращению.

Аналитик бизнес-процессов (Business Process Analyst) — это специалист, который анализирует, оптимизирует и автоматизирует бизнес-процессы компании, чтобы повысить их эффективность, снизить затраты и улучшить результаты.

Примеры прикладных задач аналитиков на IT-проектах

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

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

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

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

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

Глава 2.
АНАЛИТИК В IT: АРХИТЕКТОР МОСТОВ МЕЖДУ БИЗНЕСОМ И ТЕХНОЛОГИЯМИ

Роль бизнес- и системного аналитика в IT -проектах

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

---

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

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

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

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

Задачи бизнес- и системного аналитика

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

1. Сбор и анализ требований

● Сравнение решений конкурентов для определения их сильных и слабых сторон.

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

● Анализ существующей документации и спецификаций (руко водства, API и т.д.).

● Выявление скрытых потребностей и потенциальных рисков, ограничений.

2. Управление требованиями

● Формализация и документирование функциональных и нефункциональных требований.

● Приоритизация требований.

● Управление изменениями требований, оценка их влияния, согласование корректировок с командой.

● Подготовка тест-кейсов для проверки соответствия продукта требованиям.

3. Работа с техническими аспектами

● Проектирование и документирование API-интерфейсов.

● Анализ зависимости между системами и разработка стратегии интеграции.

---

● Участие в разбиении монолитного приложения на микросервисы.

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

4. Взаимодействие с командой и пользователями

● Организация и проведение воркшопов, демо и рабочих встреч.

● Подготовка задач для UI/UX-дизайнеров и разработчиков с учетом приоритетов.

● Проведение обучения пользователей и подготовка инструкций.

● Анализ метрик внедрения и сбор обратной связи для улучшений.

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

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

Аналитик как архитектор жизненного цикла проекта

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

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

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

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

Мы договорились, что основным фокусом книги станет рассмотрение бизнес- и системной аналитики. Для удобства я предлагаю объединить функции этих ролей под общим названием — IT-бизнес аналитик, поскольку на практике их задачи часто выполняются одним специалистом. Однако при необходимости я буду подчеркивать различия между этими ролями. Такая концепция станет основой книги, позволяя сосредоточиться на ключевых аспектах организации работы IT-бизнес-аналитика.

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

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

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

Глава 3. ПРОБЛЕМЫ И ВЫЗОВЫ БЕЗ СТРУКТУРИРОВАННОЙ АНАЛИТИКИ

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

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

Рассмотрим примеры и потенциальные угрозы для проекта без аналитика.

Конфликты и недоразумения — враги любого проекта

Когда в проекте отсутствует аналитик, способный четко формулировать задачи и объединять интересы всех участников, команда начинает работать вразнобой. Разработчики сосредоточиваются на написании кода, не особенно фокусируясь на том, как он отразится на конечном пользовательском опыте. Дизайнеры нередко создают визуально привлекательные интерфейсы, которые на практике оказываются неудобными в использовании или даже технически нереализуемыми. Не каждый API способен поддержать творческие замыслы UI-дизайна. Менеджеры же, сосредоточившись на соблюдении сроков, порой упускают из виду соответствие конечного продукта ожиданиям и требованиям заказчика.

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

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

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

Потеря мотивации: когда команда не видит общей картины

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

Однако отсутствие этого представления порождает вопросы вроде: «Зачем мы это делаем? Какой смысл в этом блоке? Кто и для чего будет это использовать?» и так далее.

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

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

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

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

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

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

Роль аналитика здесь становится незаменимой. Именно аналитик помогает команде увидеть общий контекст, объяснить ценность каждой, пусть даже крошечной задачи, и связать ее с ожидаемым результатом. Возможно, кто-то возразит, что это задачи руководителя проекта (Project Manager) или владельца продукта (Product Owner). Однако, во-первых, не всегда такие роли выделены в отдельные должности, а в методологиях Agile, например, роль менеджера проекта и вовсе упразднена. Во-вторых, на практике никто не обладает столь глубоким пониманием контекста и деталей проекта, как аналитик.

Сложности в тестировании: ошибки, которых можно было избежать

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

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

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

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

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

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

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

Адаптация новых сотрудников: неочевидный вклад аналитика

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

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

Пример: На одном из проектов, куда я пришла с нулевым опытом в сфере технологий туризма, мне пришлось потратить месяцы, чтобы разобраться в архитектуре и логике системы. Сложные данные API поставщиков авиабилетов и отелей, внешние и внутренние интеграции масштабного B2B-проекта с B2C-компонентами — непростая задача с высоким порогом входа. Без подробных инструкций и хоть какой-то базы знаний процесс погружения в проект сильно затянулся в попытках выстроить понимание на базе бесконечных вопросов и разрозненных ответов. Тогда этот опыт стал для меня наглядным примером того, как не стоит строить работу вокруг продукта.