На звонке мы определили, какие вопросы БА должен прояснить с клиентами, так как, например, были неясности в бизнес-требованиях, которые по своей природе не должны быть детализированы. Также я получил ценное замечание, о котором совсем не подумал – об интеграции моей функции с существующей в нашем продукте системой управления адресами. Поскольку адреса используются во множестве модулей/компонентов, у нас есть отдельный компонент, предназначенный для этой цели. Мы обсудили необходимость создания карты интеграционных связей между элементами, а также необходимость мне изучить нашу существующую систему управления адресами. Последним пунктом обсуждения стали первые требования из декомпозиции, которые были наиболее понятны и которые можно было начать документировать. В результате звонка появились задачи для каждого из нас, которые нужно выполнить в определённые сроки. БА попросил меня также прислать итоги нашего звонка в письме. Как всегда, любое обсуждение планируемых задач с коллегой оказалось очень полезным – это большой плюс работы в команде, даже если команда маленькая. В течение 30 минут после звонка я отправил митинг-ноутс (Meeting Notes) в письме, где включил информацию о том, что мы обсудили, кто и что должен сделать и когда. Хочу сделать акцент на этом фантастически полезном и ценном артефакте – «митинг-ноутс», который я использую в своей работе в ИТ уже 10 лет и везде, где это возможно. Почему фантастически? Потому что этот артефакт помогает мне структурировать планы мои, команды и клиента; минимизировать риски возможных неясностей во время совещаний; защитить от возникновения любых видов споров как внутри команды, так и с клиентом по поводу договоренностей, указанных в этих записях; определить ответственные стороны и сроки выполнения; и является самым надежным коммуникационным каналом для сохранения информации. Когда у каждого участника совещания есть, по сути, копия документа о договоренностях в его личной электронной почте, то очень сложно изменить эту информацию. Я лично всегда отправляю митинг-ноутс, даже когда меня никто об этом не просит. Это дает мне 100% уверенность, что информация донесена всем, даже если на самом совещании кто-то был не вовлечен по каким-либо причинам; такой человек может потом найти время и прочитать митинг-ноутс позже. И за свою карьеру у меня было множество случаев, когда этот артефакт спасал от масштабных проблем или споров на разных уровнях менеджмента между клиентами и моей компанией. Например, когда речь идет о финансах, и кто-то на стороне клиента упустил важный пункт, который был указан в митинг-ноутс, этот человек может пытаться убеждать на словах, что чего-то не было или что-то было неправильно понято. Однако, пересылка участнику митинг-ноутс письма шестимесячной давности, где он был в числе получателей и согласился со всем предложенным, решает проблему положительно почти всегда. Я приведу небольшой пример митинг-ноутс, который отослал, чтобы показать именно структуру митинг-ноутс письма – простую и очень эффективную.

Письмо, которое я отправил своему БА:

Тема письма: «Митинг нотсы от 10 июля: обсудить функцию управление адресной информацией»

Тело письма: «

Обсудили:

Требования к новой функции

Требования, которые можно брать в работу

Требования, которые нужно прояснить с клиентом (номера требований)

Экшн айтем (action items – пункты действий):

Прояснить бизнес требования с клиентом/// ведущий БА /// до конца недели (список требований прикреплен)

Изучить и включить интеграционный маппинг/// Миша /// следующие две недели.

Подготовить дизайн к требованиям А,Б,С, И так далее/// Миша /// эта неделя.

Дополнение: допиши если я что-то упустил.»

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

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

– «Система должна предоставлять возможность создать адрес для клиента»

– «Система должна предоставлять возможность редактировать адрес для клиента»

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

Атомарность требований позволяет затем значительно упростить решение любых вопросов, например, с клиентом, когда появляются запросы или пожелания к дополнению или изменению требований. Приведу простой пример, с которым я сталкивался: клиент может просмотреть и согласиться с требованиями №2 и №3, но пояснить, что для №1 он хотел бы уточнить, из каких частей приложения можно будет инициировать создание адреса. В этом случае, возможно, потребуется изменение только одного требования, в то время как остальные два уже будут утверждены. Этот пример, конечно, условный и масштабируемый – у меня было 50, 100 и даже 300 таких требований, и их простота и самодостаточность обеспечивали эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а другую часть – как требующих прояснений.

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

Вы, возможно, сейчас задаете мне вопрос: «Зачем их отправлять, если уже обсудили бизнес-требования и понятно, что нужно делать?» Тут всё просто – каждый проект имеет контекст, который позволяет определить критерии, по которым просмотр и утверждение требований требуется клиентом или нет. В моем случае было несколько критериев: 1) это был проект, использующий водопадную методологию разработки, когда сначала подготавливается абсолютно вся документация, прежде чем начать создавать продукт/систему разработчиками. Соответственно, очень важно с самого начала определить даже на функциональном уровне, что хочет клиент. 2) Проект имел конкретные сроки, в которые мы должны были создать продукт. Поэтому именно утверждение клиентом требований позволяло быть уверенным и застрахованным от рисков изменения требований при старте разработки, так как утвержденные клиентом требования уже не могли быть изменены.