Всего за 199 руб. Купить полную версию
Конечно, ежедневно вносить улучшения может быть сложно, поэтому периоды для сравнения могут варьироваться. Но если вы не сравниваете результаты своего труда с предыдущими, как можно понять, улучшилась ли ваша экспертиза или, возможно, даже ухудшилась? Одним из аспектов этого мотиватора, который я особенно ценю, является его психологическое влияние на общее состояние после проверки улучшений. Если вы завершаете задачу, день или неделю, видя, что создали артефакт следующего уровня качества, пусть даже немного лучше предыдущего, это придает позитивный настрой и энергию на весь оставшийся день или начало следующего периода. По крайней мере, у меня это так работает может быть, я чрезмерно оптимистичен.
Я кратко описал свои рабочие будни, и, возможно, у некоторых читателей возник вопрос во время прочтения: «А что насчет самих требований? Вы много рассказали про дизайн, но про требования ничего». Я выбрал хронологический порядок изложения, так как именно так все происходило на начальном этапе моей работы, где акцент делался в первую очередь на изучение и получение опыта в дизайне требований.
Теперь давайте подробнее рассмотрим, как я работал с требованиями. Занимался я этим как дополнительной активностью, изучая, что такое требования и как они формируются. Изначально требования ко мне поступали уже в готовом виде в формате списка от моего ведущего БА. Я анализировал документ с требованиями, который затем проверял и подписывал клиент, и, возможно, мой ведущий БА дополнительно разделял их на более мелкие части.
Мы классифицировали требования на два основных типа: функциональные и бизнес. Это разделение до сих пор кажется мне самым простым, логичным и последовательным подходом.
Сначала формируются бизнес требования к системе, которые обычно разрабатываются бизнес-аналитиками в тесном взаимодействии с клиентом. Эти требования устанавливают границы желаемого решения со стороны клиента и, как правило, представляют интересы бизнеса. Однако важно понимать, что хотя это и бизнес-требования, они все же касаются системы, а не бизнес-процессов или конкретной
деятельности клиента. Обычно каждое бизнес-требование формулируется одним предложением, написанным языком, понятным для бизнес-клиента, и в то же время определяет ожидания от системы. Например, 'Система должна иметь возможность хранения информации о клиентах' или 'Оплата заказа в системе должна поддерживать оплату пластиковыми картами и с банковского счета'. Здесь мы видим формулировку желаний бизнеса без углубления в детали реализации это важно для клиента, поэтому длинный список таких требований создается и подписывается, чтобы клиент мог быть уверен в их выполнении.
Все остальные детали описываются в функциональных требованиях, которые являются декомпозицией бизнес-требований. Они необходимы для того, чтобы с необходимой точностью и детализацией определить, какие именно функции должна поддерживать система. Функциональные требования, которые я изучал, обычно формулируются одним, максимум двумя предложениями, что обеспечивает их лаконичность и целенаправленность.
Например, для бизнеса требование о возможности управления информацией о клиентах может включать от 100 до 200 функциональных требований. Одно из них может формулироваться как «Система должна предоставлять пользователю возможность создать профиль клиента», другое «Система должна поддерживать в профиле клиента следующие 10 параметров:» и так далее. Из таких требований четко становится понятно, какая функция системы ожидается, например, функция создания профиля пользователя. Это функциональное требование также обсуждается с клиентом и подписывается им.
Затем такое требование попадает ко мне, и я разрабатываю дизайн, описывающий, как будет реализовано создание профиля клиента. Важно отметить, что все бизнес-требования и функциональные требования связаны между собой в специальном документе, который называется матрицей прослеживаемости (Traceability Matrix). Этот документ помогает быть уверенным в том, что все созданные функциональные требования необходимы и связаны с бизнес-требованием, и наоборот, что все бизнес-требования имеют функциональную реализацию.
В проектах по созданию крупных систем для поддержки бизнеса телекоммуникационных компаний, например, для одного модуля «система управления клиентами», может быть разработано 400-500 функциональных требований. При таких объемах информации создание документа, который хранит все связи между требованиями, становится абсолютно необходимым. Были случаи, когда именно благодаря этому документу удавалось находить несоответствия в связях и избавляться от ненужной работы, например, когда обнаруживалось функциональное требование, которое фактически не было связано ни с одним бизнес-требованием и, соответственно, уже не было актуальным, или когда бизнес-требование изменялось или удалялось после недавних обсуждений с клиентом.
По мере работы я начал самостоятельно формулировать функциональные требования к новым бизнес-требованиям, освоив процесс за 3-4 недели. Я уже мог понимать, как из бизнес-требования формируется функциональное требование и впоследствии превращается в дизайн.