Михаил Бахрах – Бизнес-анализ от а до я: профессионализм без усилий (страница 5)
Ответственный исполнитель
Моё видение: ответственность – это внутреннее качество, связанное с осознанием своих обязанностей.
“Я делаю это, потому что понимаю, что должен, чтобы завершить проект успешно.”
Ключевые характеристики:
• самодисциплина и организованность,
• понимание последствий своих решений,
• готовность признавать и исправлять ошибки,
• следование установленным правилам и процессам проекта.
Возможно, кто-то сейчас думает: “Ох, всё это давно понятно – прыгну к следующей главе” – и это нормально. Но мне нравится следовать простым принципам, чтобы достигать больших результатов.
Вот как я измеряю свой уровень ответственности – критерии, которые, возможно, будут полезны и читателю:
1. Я всегда отвечаю в кратчайшие сроки – принятие ответственности.
Даже если нет полной информации – я подтверждаю получение запроса. Просто “ок”, “принято”, “проверю и отпишу” – это всего 2–5 секунд, но критически важно в мире удалённых, асинхронных коммуникаций.
Такой ответ может разблокировать всю цепочку людей, ожидающих информацию.
2. Я подтверждаю тип действия, который выполню – осознание ответственности.
Задачи бывают разные, и уровень ответственности может трактоваться по-разному. Например:
Менеджер говорит “Подготовь презентацию”. БА думает, что займётся только своей частью, но команда может ожидать больше.
Поэтому я сразу уточняю, что именно входит в мою зону ответственности.
3. Я сообщаю промежуточный статус – контроль ответственности.
Если готова часть – я сообщаю. Если задача завершена – тоже обязательно сообщаю.
Неочевидность завершения может создать задержки, даже если всё было сделано.
4. Я не “перекидываю” задачи напрямую другим – расширение ответственности.
Если задача адресована мне, я стараюсь не переадресовывать её, а взять под контроль и довести до конца.
Это позволяет мне развивать экспертизу, навыки и понимание бизнес-домена.
Я говорю: “Я проанализирую с командой и дам ответ через 4 дня” – вместо “обратитесь к другим”.
Итог:
Для БА эти критерии особенно важны, потому что именно БА – “мост” между потребностями бизнеса и конечным ИТ-продуктом.
А в условиях удалённой работы и глобальных распределённых команд, ответственность приобретает ещё большее значение.
Теперь мы перейдём к более практической и, возможно, интересной части – конкретным навыкам.
Как я упоминал ранее, для каждого уровня будет два раздела:
1. Профессиональные навыки
2. Навыки или факторы мышления
Начнём с профессиональных и первого в списке —“Инициатор и создатель структур артефактов”.
Каждый навык я буду описывать в 4-5 подразделах, чтобы рассказать про него всесторонне. Названия навыков будут указаны также на английском – изначально я формулировал их именно на английском языке.
Инициатор и создатель структур артефактов
/Artifacts patterns driver/
Описание
Если смотреть на навыки бизнес-аналитика глобально, очевидно, что один из ключевых должен быть связан с артефактами, которые являются основным результатом его работы. Мы все знакомы с различными типами артефактов: диаграммы, схемы, пользовательские истории, сценарии использования, интеграционные спецификации, разные виды требований и так далее. Чем больше у аналитика опыта, тем шире его экспертиза в этой области.
Если говорить об этапах развития этого навыка, то сначала аналитик учится создавать базовые артефакты – часто на основе уже существующих. Затем он осваивает разные типы артефактов, работает с несколькими одновременно, адаптирует их к контексту проекта, создает сложные, составные структуры. На определённом этапе приходит следующий уровень зрелости: умение создавать и инициировать структуры и шаблоны артефактов. Именно этот навык, на мой взгляд, должен быть полностью освоен на уровне результато-ориентированного бизнес-аналитика (РО БА). Напомню, под этим уровнем я понимаю профессионально зрелого, опытного старшего аналитика (определение этого уровня раскрыто в моей предыдущей книге).
Что это за навык?
Это способность и знание, позволяющие РО БА формировать критерии, создавать и эффективно применять шаблоны и структуры артефактов на проектах любой сложности – с учётом контекста и целей. Такая работа обеспечивает бесшовную интеграцию системы артефактов в процессы и масштабируемость решений. Важно уточнить: этот навык – не про создание самих артефактов, а про проектирование и внедрение системы шаблонов и структур, на основе которых создаются артефакты.
Чем отличается артефакт от его шаблона?
Возьмём, к примеру, пользовательскую историю. Артефакт – это конкретная история с критериям приемки: «Как пользователь, я хочу…». Шаблон артефакта – это структура, определяющая формат будущих историй, включая метаданные (данные о данных). В этом случае – поля: заголовок, описание, критерии приемки, пользовательский интерфейс и т.д.
Можно сказать: «Я всегда пишу истории в одном формате, и всё работает», – и это вполне приемлемо на определённом уровне зрелости. Но разница между просто бизнес-аналитиком и результато-ориентированным аналитиком как раз в том, что у последнего есть опыт создания шаблонов и понимание, когда и какой из них применим. В одном проекте работает один формат, в другом – совершенно другой. Навык позволяет эффективно распознавать потребности в шаблонизации и действовать быстро: создавать, внедрять и адаптировать шаблоны под задачу, продукт, аудиторию.
Главная ценность этого навыка – снижение усилий на создание артефактов (как личных, так и командных) при максимизации их пользы для всех заинтересованных сторон.
Также важно, что в английском названии навыка я специально использовал слово driver – инициатор. Такой аналитик не просто может разработать эффективный шаблон – он сам инициирует, продвигает и внедряет шаблоны в процессы. Он – идейный лидер в этой области. Его мышление настроено на то, что при старте любой активности (проекта, продукта, инициативы) он первым делом анализирует, какие шаблоны артефактов потребуются, и создает их с учётом специфики контекста. Это глубоко встроено в его профессиональную практику.
Важно отметить: я говорю про шаблонизацию любой аналитической деятельности, а не только пользовательских историй или требований. Примеры включают: заметки с митингов (meeting notes), планирование и проведение встреч, подготовку и проведение discovery-фазы (фаза исследования/выявления требований – ее мы обсуждали в предыдущей книге), отчётность – и всё остальное, где есть повторяющиеся, структурируемые элементы.
Применение навыка:
Обсудим практическое применение навыка. Я приведу пример, который не содержит описания про популярные БА-артефакты, такие как, например, пользовательские истории, но в то же время позволяет отлично раскрыть специфику создания структуры/шаблона определённого типа артефактов.
Ситуация: начинается новый проект, на котором есть 4 стрима/команды. Есть экселька/таблица с пачкой (800–900) функций от клиента. Есть продукт, который нужно трансформировать/кастомизировать под эту пачку требований. Дальнейшие шаги?
Решение: моя первая мысль – это проанализировать контекст. Я разбираюсь, какова цель предоставления этих требований от клиента. А цель, как первый этап, – это проверить соответствие требований плану и возможностям продуктовой компании, а также подтвердить общее понимание каждого требования между клиентом и исполнителем. В первую очередь мне становится интересно, в каком правильном формате эти требования могут быть представлены для команды, чтобы начать с ними работать. Я анализирую информационную систему для выбора и решаю в пользу системы, похожей на Джиру (JIRA), но позволяющей полностью создавать индивидуальные/кастомные конфигурации сущностей. Я не планирую сразу же обсуждать с командой, как и в каком формате мы будем писать дизайн требований, критерии приёмки. Первой задачей для меня является построить информационную модель артефактов таким образом, чтобы минимизировать сложность восприятия информации, а также максимально упростить навигацию/использование артефакта. Принимая во внимание контекст и цель, я создаю шаблон сущности одного требования, который содержит для начала следующие поля:
• “название”, “описание” – базовые поля, чтобы понять требование;
• “статус” – обязательное поле для отслеживания изменений/переходов в жизненном цикле требования;
• “ответственный стрим/команда” – определение ответственных;
• “доступность в продукте” – понимание, существует ли в продукте такая функциональность уже или нет;
• “комментарии” – поле, где любой участник сможет оставить комментарии;
• “категория требования” – категория требования для группировки.
Факторы, которые я учитываю:
• возможности информационной системы/программы для создания записей;
• контекст проекта;
• чёткое определение цели или результата работы с конкретным артефактом.
Подход, который я использую всегда при подготовке шаблонов артефактов, – “обкатка” / “тестирование” модели как можно раньше. В данном примере выше я, после подготовки модели, не делаю экспорт всех 800 требований в новую систему и не прошу БА начать работать над требованиями. Первым делом, как только я создал первую версию шаблона, я тут же беру одно требование и пытаюсь сам создать его в системе – если мне всё понятно и все нужные данные хорошо ложатся в модель, то ок, и я могу идти “дальше”. И я подробно заполняю все известные данные по требованию в системе. И из моего опыта почти всегда появляется какой-нибудь упущенный момент. И это вполне ожидаемо – невозможно учесть всё и сразу, когда создаёшь шаблон артефакта. И в этом и плюс подготовки сначала шаблона артефакта – чтобы его “обкатать” и получить потом шаблон, который можно будет применять к 10, 100, 1000 сущностей без боязни сломать модель, если, например, какое-то поле не будет учтено.