Как создать подразделение IT-бизнес-анализа. От задачи до результата
- -
- 100%
- +
● Потеря связи между бизнес-целями и задачами команды. Когда участники проекта видят только список задач в таск-трекере – тот самый фрагмент большого пазла – при этом, не понимая, как такие задачи связаны с функционалом в целом или, бизнес-целями проекта, даже значимая задача превращается в нечто механическое и, по мнению членов команды, малозначительное. Без должного контекста, требование «добавить новое поле» для разработчика выглядит, как рутинное действие, а не вклад, к примеру, в повышение конверсии или улучшение пользовательского опыта.
● Отсутствие визуализации прогресса и результатов. Я большой сторонник визуализации – неважно, идет ли речь о рутинной встрече с заказчиком или о докладе для команды. Когда команда не имеет четкого представления о том, как ее работа влияет на движение проекта вперед, неизбежно снижается темп и вовлеченность. Даже успешное закрытие задач не приносит удовлетворения, если непонятно, какой вклад это внесло в общий результат. Визуализация прогресса – будь то дорожная карта проекта, диаграмма связей небольших задач с целями или просто демонстрация закрытых пользовательских историй – помогает ощутить значимость собственной работы.
Последствия, к сожалению, могут быть разрушительными. Это и снижение продуктивности, когда работа на автомате без понимания ценности задачи превращается в формальность; и рост числа ошибок, когда отсутствие вовлеченности приводит к упущению важных деталей; и, в конечном итоге, высокая текучесть кадров – когда даже мотивированные специалисты уходят в поисках проектов, где их вклад будет видимым и значимым.
Роль аналитика здесь становится незаменимой. Именно аналитик помогает команде увидеть общий контекст, объяснить ценность каждой, пусть даже крошечной задачи, и связать ее с ожидаемым результатом. Возможно, кто-то возразит, что это задачи руководителя проекта (Project Manager) или владельца продукта (Product Owner). Однако, во-первых, не всегда такие роли выделены в отдельные должности, а в методологиях Agile, например, роль менеджера проекта и вовсе упразднена. Во-вторых, на практике никто не обладает столь глубоким пониманием контекста и деталей проекта, как аналитик.
Сложности в тестировании: ошибки, которых можно было избежать
Тестирование – это финальный этап перед тем, как продукт или его компонент попадет к пользователю. Именно здесь выявляются ошибки, оставшиеся незамеченными на стадии разработки. Однако качество тестирования напрямую зависит от того, насколько четко сформулированы требования к системе. Когда таких требований нет или они описаны поверхностно, тестировщики фактически работают вслепую – с риском упустить то, о существовании чего даже не догадывались.
Пример: проект для финансового сектора. Команда тестировщиков обнаружила, что приложение не выдерживает высокой нагрузки: при большом количестве одновременных транзакций происходил сбой – критически важный сценарий для финансовых систем.
В ходе анализа выяснилось, что нефункциональные требования к производительности не были включены в спецификацию. Проще говоря, сценарий нагрузочного и стресс-тестирования при заданных параметрах просто не был предусмотрен. При этом функционал успешно проходил тесты в базовом режиме с одной-двумя транзакциями. Нужно ли говорить, что исправление ошибки заняло несколько недель и вызвало недовольство заказчика. При этом, если бы проблема не была обнаружена до выпуска, последствия могли бы оказаться гораздо серьезнее – от прямых финансовых потерь до репутационных рисков для компании.
В подобной ситуации роль аналитика могла бы стать решающей. На этапе сбора требований он бы уточнил у заказчика, насколько производительность критична для продукта, какие показатели считаются допустимыми, какова планируемая пиковая нагрузка, какой запас прочности система должна обеспечивать, какие сценарии могут привести к сбоям и как система должна себя вести в пограничных или регрессионных случаях.
Получение ответов на эти вопросы позволит аналитику сформулировать конкретные, измеримые требования к тестированию. Вместо размытых формулировок вроде «провести нагрузочное тестирование» в спецификации появились бы четкие метрики: максимально допустимое количество одновременных операций или пользователей, предельное время отклика, процент допустимых ошибок и т. д. Это позволило бы команде тестировщиков выстроить сценарии, максимально приближенные к реальным условиям эксплуатации.
Наконец, все параметры и сценарии были бы задокументированы и согласованы, чтобы каждый участник проекта понимал контекст, цели и критерии успешности. В результате тестирование стало бы предсказуемым, прозрачным и ориентированным на результат.
Роль аналитика на этапе тестирования трудно переоценить. Четко сформулированные требования не только помогают предотвратить ошибки и оптимизировать взаимодействие между командами, но и гарантируют, что продукт действительно будет соответствовать ожиданиям. Это экономит время, ресурсы и, что не менее важно, защищает репутацию компании.
Адаптация новых сотрудников: неочевидный вклад аналитика
Когда говорят о роли бизнес-аналитика, чаще всего вспоминают требования, диаграммы и общение с заказчиком. Но на практике вклад аналитика выходит далеко за эти рамки. Он нередко становится связующим звеном между всеми участниками проекта, хранителем знаний и тем, кто обеспечивает преемственность в команде. Особенно ярко это проявляется в процессе адаптации новых сотрудников – области, где роль аналитика на первый взгляд кажется минимальной, но на деле может оказаться решающей.
IT-команды – это динамичные экосистемы, где сотрудники часто меняются: кто-то уходит в отпуск, кто-то находит другое место работы, а иногда проект просто расширяется, требуя привлечения новых специалистов. В таких условиях адаптация новичков становится неизбежной частью работы. Однако, если у команды нет качественной документации, процесс адаптации превращается в настоящий квест – не только для новеньких, но и для их коллег, вынужденных постоянно отвлекаться на объяснения.
Пример: На одном из проектов, куда я пришла с нулевым опытом в сфере технологий туризма, мне пришлось потратить месяцы, чтобы разобраться в архитектуре и логике системы. Сложные данные API поставщиков авиабилетов и отелей, внешние и внутренние интеграции масштабного B2B-проекта с B2C-компонентами – непростая задача с высоким порогом входа. Без подробных инструкций и хоть какой-то базы знаний процесс погружения в проект сильно затянулся в попытках выстроить понимание на базе бесконечных вопросов и разрозненных ответов. Тогда этот опыт стал для меня наглядным примером того, как не стоит строить работу вокруг продукта.
И действительно, первое знакомство с проектом – сложный период для любого специалиста. Ты понимаешь, что не можешь не задавать вопросы, потому что иначе просто не получишь тот минимум знаний, который необходим, чтобы начать работу. В то же время осознаешь, что опытные коллеги, вместо того чтобы сосредоточиться на своих задачах, вынуждены тратить время на импровизированные воркшопы и создание мини-руководств на ходу.
Основная причина, по которой адаптация новых сотрудников часто затягивается, – отсутствие мало-мальски структурированной базы знаний. Вместо этого новички сталкиваются с разрозненными документами и «знаниями в головах бывалых», а порой и вовсе остаются без какой-либо вводной информации. Но даже если документация существует, она нередко оказывается устаревшей или написанной в таком виде, что без помощи разобраться в ней невозможно. Добавим к этому постоянный недостаток времени у опытных членов команды – в быстроразвивающихся проектах у них просто нет возможности полноценно заниматься обучением новичков. Результат налицо.
Аналитик может сыграть ключевую роль в предупреждении таких ситуаций. Именно он способен постепенно структурировать знания о проекте и сделать их доступными для всех. Не менее важно – разработать единые стандарты документации, чтобы она была применимой, достаточной и легко обновляемой. Это помогает не только новичкам, но и команде в целом: меньше времени тратится на обучение, плюс снижается риск потери информации при увольнении сотрудников-носителей знаний. Более подробно к стандартизации я обращусь в последующих главах.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.