Бизнес-анализ от а до я: гид для начинающих
Шрифт:
Процесс документирования дизайна может занимать различное время и объем работы. Одно требование может быть оформлено на полстраницы формата А4 и занять 30 минут для написания. Другое требование может распространяться на 10 страниц и требовать неделю работы. Существуют различные форматы и подходы к дизайну, выбор которых зависит от множества факторов и контекста проекта. В эти дни и недели такая активность занимает примерно 80 процентов моего рабочего времени.
Я документировал дизайн простым и надежным способом – в обычном текстовом документе (MS Word). Никаких специальных дополнительных программ не требовалось. Этот документ был доступен онлайн для моего ментора, который проверял мои дизайны и оставлял комментарии прямо в файле, на которые я затем делал правки. Это был непрерывный процесс документирования,
Одно из наиболее приятных ощущений в этом процессе – наблюдать, как с течением времени количество комментариев уменьшалось, что отражало прямую зависимость улучшения качества моей работы. Хочу еще раз подчеркнуть важность работы в команде, особенно с опытными коллегами на начальном этапе карьеры: доверие к профессионализму вашего наставника позволяет легко определить и отслеживать улучшение собственных показателей качества, без необходимости изучения сотен страниц литературы по ключевым показателям продуктивности.
Скучно ли это – создавать дизайн требований с утра до вечера, неделями? Для меня это было чрезвычайно интересно, так как а) я создавал! Это один из главных двигателей моей удовлетворенности от работы, и я буду часто это повторять на протяжении книги. Ощущение, что ты что-то создаешь, невероятно приятно. Важно прослеживать, даже если только в своем воображении, как твоя деятельность влияет на финальный итог. Допустим, я описал обычную кнопку, которая активирует функцию в системе. Я представляю, как после разработки и тестирования, эту систему предоставят клиенту, который в свою очередь сделает её доступной своим пользователям. Пользователи, например, продавцы в магазине, будут использовать функцию, созданную по моему дизайну, для обслуживания клиентов. Хоть это и ИТ система, программа, но в 99% случаев они нужны для внедрения в бизнес-процессы, а это значит, что я упрощаю повседневную жизнь кого-то.
б) Наличие ментора и работы в команде позволяет мне совершенствовать своё мастерство каждый день. Люди по своей природе стремятся найти причину и дать полезный комментарий к любой активности другого, когда их об этом просят – конечно, если им не лень и они заинтересованы в процессе. Людей, которые равнодушны к своим обязанностям, лучше не выбирать в качестве менторов. Так в чем суть? Работа каждого дня над дизайном требований не может быть монотонной, когда вы получаете комментарии и предложения по улучшению. Комментарии не всегда могут быть приятными – на самом деле, они почти всегда вызывают дискомфорт. Однако одна из ключевых компетенций хорошего бизнес-аналитика – это умение эффективно воспринимать критику. Под 'эффективно' я подразумеваю следующий процесс: сначала внимательно слушать, затем анализировать, применять полученные замечания к своей ситуации и, наконец, принимать решение – улучшит ли предложение качество работы.
На основе своего опыта могу сказать, что 70-80% рекомендаций, которые я получал, действительно помогли мне улучшить качество выполнения задач. Интересно, что даже если комментарии напрямую не влияли на улучшение, их анализ и применение к текущей ситуации помогали выявлять другие 'пробелы' в создаваемом решении, на которые я бы, возможно, никогда не обратил внимание без этих замечаний. Например, создавая описание реакции системы на нажатие кнопки пользователем, коллега предложил, что 'выполнение открытия дополнительного поля по нажатию на кнопку должно быть описано отдельным сценарием'. Хотя функциональность кнопки была минимальна и я изначально считал, что разделять описание не нужно, проверка моего текста выявила важный 'пробел' – я не описал поведение кнопки при её повторном нажатии. В итоге, отзыв оказался чрезвычайно полезным. в) В любой деятельности всегда существует возможность для улучшений, и эти улучшения можно придумывать бесконечно, даже в самой, казалось бы, простой работе. Улучшения эти могут фактически изменять кажущуюся однообразность рабочих дней. Один из самых простых и эффективных мотиваторов к улучшениям, который я использую на протяжении всей своей карьеры, очень прост: следуйте главному принципу любого развития – личностного, физического, профессионального. Заканчивая день, спросите себя: «Что я сегодня сделал лучше или
Конечно, ежедневно вносить улучшения может быть сложно, поэтому периоды для сравнения могут варьироваться. Но если вы не сравниваете результаты своего труда с предыдущими, как можно понять, улучшилась ли ваша экспертиза или, возможно, даже ухудшилась? Одним из аспектов этого мотиватора, который я особенно ценю, является его психологическое влияние на общее состояние после проверки улучшений. Если вы завершаете задачу, день или неделю, видя, что создали артефакт следующего уровня качества, пусть даже немного лучше предыдущего, это придает позитивный настрой и энергию на весь оставшийся день или начало следующего периода. По крайней мере, у меня это так работает – может быть, я чрезмерно оптимистичен.
Я кратко описал свои рабочие будни, и, возможно, у некоторых читателей возник вопрос во время прочтения: «А что насчет самих требований? Вы много рассказали про дизайн, но про требования – ничего». Я выбрал хронологический порядок изложения, так как именно так все происходило на начальном этапе моей работы, где акцент делался в первую очередь на изучение и получение опыта в дизайне требований.
Теперь давайте подробнее рассмотрим, как я работал с требованиями. Занимался я этим как дополнительной активностью, изучая, что такое требования и как они формируются. Изначально требования ко мне поступали уже в готовом виде в формате списка от моего ведущего БА. Я анализировал документ с требованиями, который затем проверял и подписывал клиент, и, возможно, мой ведущий БА дополнительно разделял их на более мелкие части.
Мы классифицировали требования на два основных типа: функциональные и бизнес. Это разделение до сих пор кажется мне самым простым, логичным и последовательным подходом.
Сначала формируются бизнес требования к системе, которые обычно разрабатываются бизнес-аналитиками в тесном взаимодействии с клиентом. Эти требования устанавливают границы желаемого решения со стороны клиента и, как правило, представляют интересы бизнеса. Однако важно понимать, что хотя это и бизнес-требования, они все же касаются системы, а не бизнес-процессов или конкретной деятельности клиента. Обычно каждое бизнес-требование формулируется одним предложением, написанным языком, понятным для бизнес-клиента, и в то же время определяет ожидания от системы. Например, 'Система должна иметь возможность хранения информации о клиентах' или 'Оплата заказа в системе должна поддерживать оплату пластиковыми картами и с банковского счета'. Здесь мы видим формулировку желаний бизнеса без углубления в детали реализации – это важно для клиента, поэтому длинный список таких требований создается и подписывается, чтобы клиент мог быть уверен в их выполнении.
Все остальные детали описываются в функциональных требованиях, которые являются декомпозицией бизнес-требований. Они необходимы для того, чтобы с необходимой точностью и детализацией определить, какие именно функции должна поддерживать система. Функциональные требования, которые я изучал, обычно формулируются одним, максимум двумя предложениями, что обеспечивает их лаконичность и целенаправленность.
Например, для бизнеса требование о возможности управления информацией о клиентах может включать от 100 до 200 функциональных требований. Одно из них может формулироваться как «Система должна предоставлять пользователю возможность создать профиль клиента», другое – «Система должна поддерживать в профиле клиента следующие 10 параметров:…» и так далее. Из таких требований четко становится понятно, какая функция системы ожидается, например, функция создания профиля пользователя. Это функциональное требование также обсуждается с клиентом и подписывается им.
Затем такое требование попадает ко мне, и я разрабатываю дизайн, описывающий, как будет реализовано создание профиля клиента. Важно отметить, что все бизнес-требования и функциональные требования связаны между собой в специальном документе, который называется матрицей прослеживаемости (Traceability Matrix). Этот документ помогает быть уверенным в том, что все созданные функциональные требования необходимы и связаны с бизнес-требованием, и наоборот, что все бизнес-требования имеют функциональную реализацию.