Теперь перейдём к документированию дизайна функционального требования. Для начала уточню, что я подразумеваю под 'дизайном': это описание, спецификация или план, который демонстрирует, как должна работать или выполняться функция, чтобы соответствовать функциональному требованию. Интересный факт: если вы зададите вопрос в англоязычной поисковой системе о том, что значит слово 'design', то вам покажут определения, упоминающие 'план' или 'спецификацию' и 'функцию', даже не связанную с ИТ-сферой.

Почему акцент на документировании дизайна? Всё просто. Основная цель бизнес-аналитика почти всегда заключается в подготовке документа или артефакта для команды разработчиков, чтобы они могли создать систему именно так, как её планирует использовать пользователь. Наличие только функционального требования без дизайна не даст разработчикам необходимой информации о том, что именно нужно создать. В моей 10-летней практике я не встречал случаев, когда было бы иначе. Хотя в интернете можно найти мнения, что в рамках некоторых 'гибких' методологий разработки, продукты создаются именно так – разработчикам передаётся только требование, и они каким-то образом создают то, что нужно.

Процесс документирования дизайна может занимать различное время и объем работы. Одно требование может быть оформлено на полстраницы формата А4 и занять 30 минут для написания. Другое требование может распространяться на 10 страниц и требовать неделю работы. Существуют различные форматы и подходы к дизайну, выбор которых зависит от множества факторов и контекста проекта. В эти дни и недели такая активность занимает примерно 80 процентов моего рабочего времени.

Я документировал дизайн простым и надежным способом – в обычном текстовом документе (MS Word). Никаких специальных дополнительных программ не требовалось. Этот документ был доступен онлайн для моего ментора, который проверял мои дизайны и оставлял комментарии прямо в файле, на которые я затем делал правки. Это был непрерывный процесс документирования, комментирования от ментора и соответствующих обновлений с моей стороны.

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

Скучно ли это – создавать дизайн требований с утра до вечера, неделями? Для меня это было чрезвычайно интересно, так как а) я создавал! Это один из главных двигателей моей удовлетворенности от работы, и я буду часто это повторять на протяжении книги. Ощущение, что ты что-то создаешь, невероятно приятно. Важно прослеживать, даже если только в своем воображении, как твоя деятельность влияет на финальный итог. Допустим, я описал обычную кнопку, которая активирует функцию в системе. Я представляю, как после разработки и тестирования, эту систему предоставят клиенту, который в свою очередь сделает её доступной своим пользователям. Пользователи, например, продавцы в магазине, будут использовать функцию, созданную по моему дизайну, для обслуживания клиентов. Хоть это и ИТ система, программа, но в 99% случаев они нужны для внедрения в бизнес-процессы, а это значит, что я упрощаю повседневную жизнь кого-то.

б) Наличие ментора и работы в команде позволяет мне совершенствовать своё мастерство каждый день. Люди по своей природе стремятся найти причину и дать полезный комментарий к любой активности другого, когда их об этом просят – конечно, если им не лень и они заинтересованы в процессе. Людей, которые равнодушны к своим обязанностям, лучше не выбирать в качестве менторов. Так в чем суть? Работа каждого дня над дизайном требований не может быть монотонной, когда вы получаете комментарии и предложения по улучшению. Комментарии не всегда могут быть приятными – на самом деле, они почти всегда вызывают дискомфорт. Однако одна из ключевых компетенций хорошего бизнес-аналитика – это умение эффективно воспринимать критику. Под 'эффективно' я подразумеваю следующий процесс: сначала внимательно слушать, затем анализировать, применять полученные замечания к своей ситуации и, наконец, принимать решение – улучшит ли предложение качество работы.