физического, профессионального. Заканчивая день, спросите себя: «Что я сегодня сделал лучше или эффективнее, чем вчера?» Если есть ответ, значит, вы развиваетесь.
Конечно, ежедневно вносить улучшения может быть сложно, поэтому периоды для сравнения могут варьироваться. Но если вы не сравниваете результаты своего труда с предыдущими, как можно понять, улучшилась ли ваша экспертиза или, возможно, даже ухудшилась? Одним из аспектов этого мотиватора, который я особенно ценю, является его психологическое влияние на общее состояние после проверки улучшений. Если вы завершаете задачу, день или неделю, видя, что создали артефакт следующего уровня качества, пусть даже немного лучше предыдущего, это придает позитивный настрой и энергию на весь оставшийся день или начало следующего периода. По крайней мере, у меня это так работает – может быть, я чрезмерно оптимистичен.
Я кратко описал свои рабочие будни, и, возможно, у некоторых читателей возник вопрос во время прочтения: «А что насчет самих требований? Вы много рассказали про дизайн, но про требования – ничего». Я выбрал хронологический порядок изложения, так как именно так все происходило на начальном этапе моей работы, где акцент делался в первую очередь на изучение и получение опыта в дизайне требований.
Теперь давайте подробнее рассмотрим, как я работал с требованиями. Занимался я этим как дополнительной активностью, изучая, что такое требования и как они формируются. Изначально требования ко мне поступали уже в готовом виде в формате списка от моего ведущего БА. Я анализировал документ с требованиями, который затем проверял и подписывал клиент, и, возможно, мой ведущий БА дополнительно разделял их на более мелкие части.
Мы классифицировали требования на два основных типа: функциональные и бизнес. Это разделение до сих пор кажется мне самым простым, логичным и последовательным подходом.
Сначала формируются бизнес требования к системе, которые обычно разрабатываются бизнес-аналитиками в тесном взаимодействии с клиентом. Эти требования устанавливают границы желаемого решения со стороны клиента и, как правило, представляют интересы бизнеса. Однако важно понимать, что хотя это и бизнес-требования, они все же касаются системы, а не бизнес-процессов или конкретной деятельности клиента. Обычно каждое бизнес-требование формулируется одним предложением, написанным языком, понятным для бизнес-клиента, и в то же время определяет ожидания от системы. Например, 'Система должна иметь возможность хранения информации о клиентах' или 'Оплата заказа в системе должна поддерживать оплату пластиковыми картами и с банковского счета'. Здесь мы видим формулировку желаний бизнеса без углубления в детали реализации – это важно для клиента, поэтому длинный список таких требований создается и подписывается, чтобы клиент мог быть уверен в их выполнении.
Все остальные детали описываются в функциональных требованиях, которые являются декомпозицией