На этом этапе я продолжаю работать с требованиями, уделяя больше внимания различным аспектам управления требованиями и стремясь принять на себя больше ответственности и самостоятельности для полноценного документирования функций системы. Теперь всё это происходит уже не под столь пристальным вниманием моего ментора – ведущего бизнес-аналитика.
Через пару месяцев мой проектный БА оценил развитие моих навыков и способности, и уже стал доверять мне документирование требований и дизайнов целых функций компонента системы. Это было несказанно радостно – ощущение, что ты создаешь что-то целостное от начала до конца, которое я описывал ранее, только усилилось.
Что же такое функция? Возьмем пример из предыдущего этапа: у нас есть компонент системы под названием “система управления информацией о клиентах”. В этом компоненте существуют различные функции, такие как создание профиля клиента, редактирование профиля, просмотр и управление кредитной информацией о клиенте и многие другие. Каждую такую функцию можно далее разделить на множество подфункций или требований. Одно из требований, касающееся кредитной информации, мы уже рассмотрели на предыдущем шаге. Функция представляет собой определённый набор свойств и действий (как пользователя, так и системы), которые позволяют конечному пользователю выполнить полноценное и завершённое действие с определённым ожидаемым результатом. Как я упоминал ранее, например, функция "создать профиль клиента".
С течением времени я начал получать задачи по подготовке функций. Виды задач, активности и ответственность стали разнообразнее, что отражало мой продолжающийся профессиональный рост. Я ощущал, что уровень сложности моих задач повышается: теперь задача заключалась не просто в написании требований и их документировании. Теперь мне требовалось анализировать нужную функцию, декомпозировать её, определять и документировать необходимые требования и дизайн, корректно связывать все требования между собой в матрице требований, управлять статусом готовности и блокерами, а также подготавливать вопросы для заинтересованных сторон (stakeholders) со стороны клиента. Да, это был настоящий взрыв нового опыта! Как следствие, к задачам, связанным с функциями, добавились общие профессиональные задачи в связи с увеличившейся сложностью: проверка и поддержание (а при необходимости изменение) информационной модели/структуры требований и дизайна, поддержание их логичности, понимание работы с моделью данных, разработка спецификаций модели данных, понимание жизненного цикла разработки системы, а также развитие дополнительных и необходимых "мягких" навыков. Столько всего… наверное, я сразу «раскрыл карты» о навыках и активностях, которые буду дальше описывать, но так вот – никаких секретов! Единственное, я упомянул новое слово «стейкхолдер». Поясню: стейкхолдер – это человек, который ожидает и будет иметь какую-то выгоду от ИТ-продукта, который я создаю, или будет его использовать. В проектах компаний-поставщиков сервисов или продуктов, которые нанимают другие компании, основными стейкхолдерами всегда являются люди на стороне клиента, те, кто ожидает готовый продукт. Это может быть всего один человек, взаимодействующий с сервисной компанией, или множество людей на стороне клиента. Это люди разных уровней в организации клиента – от генерального директора до заместителя директора ИТ-департамента, экономического отдела или отдельной проектной команды, курирующей создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. Именно с ними БА выявляет требования к системе/продукту. Позже мы подробно рассмотрим БА-навык «управление стейкхолдерами».
С точки зрения процессов и активностей, у меня уменьшилось количество времени, которое я выделял ежедневно на обсуждения со своим ведущим БА, так как он стал более уверен в моем умении документировать требования и в моей профессиональности в целом. Иногда у меня даже не было ежедневных созвонов. Но вместо этого появились серьезные, хоть и нечастые, созвоны, где мы обсуждали мою подготовку документации по всей функции. Для описания активностей и навыков я возьму функцию, которой я занимался, – «Управление адресной информацией», которая является частью компонента «Система управления информацией о клиенте». Мне было поручено полностью подготовить необходимые дизайн-спецификации для разработки этой функции. Сначала мне нужно было прояснить бизнес-цели создания и понять, какие входные данные у меня есть. Единственным моим источником был мой ведущий БА, который работал и общался с командой клиента для выяснения любых вопросов. Я запланировал с ним звонок и начал готовиться к обсуждению. Заранее подготовил список вопросов, которые помогли бы мне определить границы задачи и прояснить неясные моменты. Я проверил существующие бизнес-требования, упоминавшие что-либо о адресной информации, и включил их в свой вопросный список, чтобы подтвердить, какие из них будут использоваться для создания функциональных требований. Я сделал черновую декомпозицию функции на набор предварительных функциональных требований.
Декомпозиция началась с базовой функциональности по созданию, редактированию, просмотру и удалению адреса. Затем я подумал, что поскольку система предназначена для бизнес-клиентов, они наверняка могут иметь несколько адресов. Поэтому я добавил требования по управлению списком адресов. Очевидно, потребуются требования к работе с полями/параметрами создаваемого адреса: какие поля доступны, каковы их свойства и типы. Например, некоторые поля – это простые текстовые поля, а другие представляют собой список, из которого можно выбрать только одно из предопределённых значений. Также я включил функциональность различения типов адресов – например, физический адрес и адрес для выставления счетов, при этом основные адреса могут отображаться также на главной странице профиля клиента. Плюс такого подхода к декомпозиции, прежде чем начать писать детальные требования и дизайн, заключается в том, что ты уже разделил одну большую задачу на несколько и можешь выбирать, с какой лучше начать. Когда начинаешь работу, ты уверен, что не будет пересечений в разных активностях, которые могут привести к необходимости постоянно переделывать уже готовые артефакты (требования, дизайн и т. д.). Теперь можно было и обсудить всё с моим БА.
На звонке мы определили, какие вопросы БА должен прояснить с клиентами, так как, например, были неясности в бизнес-требованиях, которые по своей природе не должны быть детализированы. Также я получил ценное замечание, о котором совсем не подумал – об интеграции моей функции с существующей в нашем продукте системой управления адресами. Поскольку адреса используются во множестве модулей/компонентов, у нас есть отдельный компонент, предназначенный для этой цели. Мы обсудили необходимость создания карты интеграционных связей между элементами, а также необходимость мне изучить нашу существующую систему управления адресами. Последним пунктом обсуждения стали первые требования из декомпозиции, которые были наиболее понятны и которые можно было начать документировать. В результате звонка появились задачи для каждого из нас, которые нужно выполнить в определённые сроки. БА попросил меня также прислать итоги нашего звонка в письме. Как всегда, любое обсуждение планируемых задач с коллегой оказалось очень полезным – это большой плюс работы в команде, даже если команда маленькая. В течение 30 минут после звонка я отправил митинг-ноутс (Meeting Notes) в письме, где включил информацию о том, что мы обсудили, кто и что должен сделать и когда. Хочу сделать акцент на этом фантастически полезном и ценном артефакте – «митинг-ноутс», который я использую в своей работе в ИТ уже 10 лет и везде, где это возможно. Почему фантастически? Потому что этот артефакт помогает мне структурировать планы мои, команды и клиента; минимизировать риски возможных неясностей во время совещаний; защитить от возникновения любых видов споров как внутри команды, так и с клиентом по поводу договоренностей, указанных в этих записях; определить ответственные стороны и сроки выполнения; и является самым надежным коммуникационным каналом для сохранения информации. Когда у каждого участника совещания есть, по сути, копия документа о договоренностях в его личной электронной почте, то очень сложно изменить эту информацию. Я лично всегда отправляю митинг-ноутс, даже когда меня никто об этом не просит. Это дает мне 100% уверенность, что информация донесена всем, даже если на самом совещании кто-то был не вовлечен по каким-либо причинам; такой человек может потом найти время и прочитать митинг-ноутс позже. И за свою карьеру у меня было множество случаев, когда этот артефакт спасал от масштабных проблем или споров на разных уровнях менеджмента между клиентами и моей компанией. Например, когда речь идет о финансах, и кто-то на стороне клиента упустил важный пункт, который был указан в митинг-ноутс, этот человек может пытаться убеждать на словах, что чего-то не было или что-то было неправильно понято. Однако, пересылка участнику митинг-ноутс письма шестимесячной давности, где он был в числе получателей и согласился со всем предложенным, решает проблему положительно почти всегда. Я приведу небольшой пример митинг-ноутс, который отослал, чтобы показать именно структуру митинг-ноутс письма – простую и очень эффективную.
Письмо, которое я отправил своему БА:
Тема письма: «Митинг нотсы от 10 июля: обсудить функцию управление адресной информацией»
Тело письма: «
Обсудили:
Требования к новой функции
Требования, которые можно брать в работу
Требования, которые нужно прояснить с клиентом (номера требований)
Экшн айтем (action items – пункты действий):
Прояснить бизнес требования с клиентом/// ведущий БА /// до конца недели (список требований прикреплен)
Изучить и включить интеграционный маппинг/// Миша /// следующие две недели.
Подготовить дизайн к требованиям А,Б,С, И так далее/// Миша /// эта неделя.
Дополнение: допиши если я что-то упустил.»
Вот такое короткое письмо, из которого каждый понял, что от кого и когда требуется. Очень рекомендую его использование в любых ситуациях и для любой аудитории. Естественно, уровень детализации и стиль написания зависят от типа целевой аудитории. Если это менеджерское совещание, то формат должен отображать только суть, простым и понятным языком. Если же это созвон с техническими командами и проектными менеджерами, то можно и нужно описать детально принятые решения с техническими ключевыми моментами и детальным планом действий. Если есть сомнения в правильности понимания каких-то пунктов, то перед отправкой митинг-ноутс очень рекомендую напрямую уточнить у нужного человека, что именно имелось в виду. Если доступа у вас нет или прояснение невозможно, потому что клиент сказал что-то, что вы поняли, но возможно не на 100% правильно, то в самих митинг-ноутс обязательно нужно указать или оставить примечание к неясному пункту: «Пожалуйста, поправьте или дополните этот пункт, если есть неточности», и можно также упомянуть конкретного человека.
Затем я занялся документированием уже финального варианта функциональных требований, которые были готовы к просмотру клиентом. Я определил, в какой документ включить блок требований, и какой формат нумерации использовать. Формат нумерации я уже упоминал ранее и обсудил полезность этого уникального номера требования, который впоследствии может использоваться при обсуждении с членами команды или клиентом. При просмотре требований он позволяет сделать удобные ссылки на конкретное требование, без необходимости цитировать его полностью. Например, требование имеет номер ФР-СИМ-СИД-02. Клиент при проверке требований может сделать замечание: «Требование ФР-СИМ-СИД-02 не понятно, следует добавить детали». В плане формата требований я старался следовать простому правилу – стараться уместить требование в одно предложение, написать его в максимально простой форме. У меня было черновое требование, которое звучало как: «Должна быть возможность создавать адрес для клиента, заполнять необходимые поля и редактировать их при необходимости». Я разбил этот черновик на следующие требования:
– «Система должна предоставлять возможность создать адрес для клиента»
– «Система должна предоставлять возможность редактировать адрес для клиента»
– «Система должна содержать следующие данные в адресе: тип адреса, страна, штат, город, улица, номер здания, номер офиса, индекс.»
Атомарность требований позволяет затем значительно упростить решение любых вопросов, например, с клиентом, когда появляются запросы или пожелания к дополнению или изменению требований. Приведу простой пример, с которым я сталкивался: клиент может просмотреть и согласиться с требованиями №2 и №3, но пояснить, что для №1 он хотел бы уточнить, из каких частей приложения можно будет инициировать создание адреса. В этом случае, возможно, потребуется изменение только одного требования, в то время как остальные два уже будут утверждены. Этот пример, конечно, условный и масштабируемый – у меня было 50, 100 и даже 300 таких требований, и их простота и самодостаточность обеспечивали эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а другую часть – как требующих прояснений.
После подготовки всех функциональных требований я проверил, что все они имеют связи в матрице отслеживаемости требований. На тот момент я контролировал наличие связей между бизнес и функциональными требованиями. Я проверял, чтобы каждое функциональное требование соответствовало по крайней мере одному бизнес-требованию, то есть чтобы не было «бесполезных» функциональных требований, на которые будет потрачено время, но которые не нужны клиенту. Также я проверял, чтобы не было бизнес-требований, которые не указывают на какие-либо функциональные требования, т.е. чтобы я не упустил ничего, что хочет клиент. После того как все требования были написаны, я отправил их на проверку ведущему БА, который дал несколько комментариев. Я внес правки и, в итоге, функциональные требования были отправлены на просмотр и утверждение клиенту.