Бизнес-анализ от а до я: гид для начинающих

На основе своего опыта могу сказать, что 70-80% рекомендаций, которые я получал, действительно помогли мне улучшить качество выполнения задач. Интересно, что даже если комментарии напрямую не влияли на улучшение, их анализ и применение к текущей ситуации помогали выявлять другие 'пробелы' в создаваемом решении, на которые я бы, возможно, никогда не обратил внимание без этих замечаний. Например, создавая описание реакции системы на нажатие кнопки пользователем, коллега предложил, что 'выполнение открытия дополнительного поля по нажатию на кнопку должно быть описано отдельным сценарием'. Хотя функциональность кнопки была минимальна и я изначально считал, что разделять описание не нужно, проверка моего текста выявила важный 'пробел' – я не описал поведение кнопки при её повторном нажатии. В итоге, отзыв оказался чрезвычайно полезным. в) В любой деятельности всегда существует возможность для улучшений, и эти улучшения можно придумывать бесконечно, даже в самой, казалось бы, простой работе. Улучшения эти могут фактически изменять кажущуюся однообразность рабочих дней. Один из самых простых и эффективных мотиваторов к улучшениям, который я использую на протяжении всей своей карьеры, очень прост: следуйте главному принципу любого развития – личностного, физического, профессионального. Заканчивая день, спросите себя: «Что я сегодня сделал лучше или эффективнее, чем вчера?» Если есть ответ, значит, вы развиваетесь.

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

Я кратко описал свои рабочие будни, и, возможно, у некоторых читателей возник вопрос во время прочтения: «А что насчет самих требований? Вы много рассказали про дизайн, но про требования – ничего». Я выбрал хронологический порядок изложения, так как именно так все происходило на начальном этапе моей работы, где акцент делался в первую очередь на изучение и получение опыта в дизайне требований.

Теперь давайте подробнее рассмотрим, как я работал с требованиями. Занимался я этим как дополнительной активностью, изучая, что такое требования и как они формируются. Изначально требования ко мне поступали уже в готовом виде в формате списка от моего ведущего БА. Я анализировал документ с требованиями, который затем проверял и подписывал клиент, и, возможно, мой ведущий БА дополнительно разделял их на более мелкие части.

Мы классифицировали требования на два основных типа: функциональные и бизнес. Это разделение до сих пор кажется мне самым простым, логичным и последовательным подходом.

Сначала формируются бизнес требования к системе, которые обычно разрабатываются бизнес-аналитиками в тесном взаимодействии с клиентом. Эти требования устанавливают границы желаемого решения со стороны клиента и, как правило, представляют интересы бизнеса. Однако важно понимать, что хотя это и бизнес-требования, они все же касаются системы, а не бизнес-процессов или конкретной деятельности клиента. Обычно каждое бизнес-требование формулируется одним предложением, написанным языком, понятным для бизнес-клиента, и в то же время определяет ожидания от системы. Например, 'Система должна иметь возможность хранения информации о клиентах' или 'Оплата заказа в системе должна поддерживать оплату пластиковыми картами и с банковского счета'. Здесь мы видим формулировку желаний бизнеса без углубления в детали реализации – это важно для клиента, поэтому длинный список таких требований создается и подписывается, чтобы клиент мог быть уверен в их выполнении.

Все остальные детали описываются в функциональных требованиях, которые являются декомпозицией бизнес-требований. Они необходимы для того, чтобы с необходимой точностью и детализацией определить, какие именно функции должна поддерживать система. Функциональные требования, которые я изучал, обычно формулируются одним, максимум двумя предложениями, что обеспечивает их лаконичность и целенаправленность.