Сегодня мы разберемся в том, что из себя представляет роль системного аналитика, рассмотрим его пользу для бизнеса и поймем, каких рисков можно избежать благодаря наличию этого специалиста в команде разработки.
Для обозначения профессии аналитика в отрасли информационных технологий часто используют размытое понятие “Аналитик в IT”, поскольку достаточно часто здесь смешиваются разные ипостаси аналитика: системный аналитик, бизнес-аналитик, аналитик данных и др.
Бизнес-аналитик - это специалист, который исследует бизнес-процессы, происходящие в организации заказчика, определяет слабые стороны в них и предлагает варианты исправления сложившейся ситуации. Бизнес-аналитик может работать не на комплексное улучшение всех некорректно настроенных процессов организации, а на развитие одного выделенного заказчиком направления. Не всегда эта работа связана с последующей разработкой программного продукта, поскольку автоматизация бизнес-процессов - лишь один из многих способов их оптимизации.
Системный аналитик включается в момент, когда определено, что улучшение в бизнесе заказчика последует именно из автоматизации части процессов. Именно на этом этапе заказчиком и разработчиком принимается решение о начале разработки и формировании команды разработки.
Системный аналитик переводит запрос бизнеса на язык разработки, оценивает реализуемость требования с учетом возможностей платформы разработки и скилла команды, собирает подробную информацию касательно разрабатываемого требования и преобразовывает все это в логичную постановку, которую возьмет в работу команда. По итогам реализации поставленной задачи команда должна получить функцию, которую можно предъявить заказчику.
Помимо этого системный аналитик обязательно проводит оценку всей поступающей к нему информации на достоверность и соответствие решаемой в данный момент конкретной задаче; систематизирует полученную информацию; убеждается в том, что новое требование заказчика не противоречит ранее реализованным; оформляет и добавляет задачу в пул и делает многое другое в зависимости от определенной в команде роли.
Рассмотрим каждое из выполняемых системным аналитиком действий подробнее.
Сбор и анализ информации
В первую очередь после поступления запроса на разработку аналитик начинает искать информацию по заданной тематике. Однако мало найти информацию - нужно еще и проанализировать ее на актуальность, пригодность для использования в данной конкретной области, достоверность, непротиворечивость по отношению к уже имеющейся информации и т.д. После того, как нужный анализ произведен - аналитик должен переработать всю полученную информацию в качественную цельную постановку, которая будет соответствовать требованиям законодательства, потребностям клиента, не будет противоречить уже существующим либо спроектированным функциям и на выходе позволит закрыть определенную бизнес-потребность.
Перечень источников, из которых мы можем получать информацию, индивидуален и зависит от конкретной задачи.
От этого же зависит и то, на какие основные моменты мы будем обращать внимание при проведении анализа.
Ниже мы рассмотрим только некоторые из источников.
Нормативная документация понадобится нам в случаях, когда существуют определенные требования законодательства по оказанию описываемой услуги. При анализе данных из этого источника обязательно стоит обратить внимание на сроки действия рассматриваемой нормативной документации, связанные документы, разъяснения отдельных положений компетентными органами. Проекты нормативной документации размещаются на федеральном портале, уже действующие документы - в справочно-правовых системах (Гарант, Консультант Плюс и т.д.). Аналитик, работающий с требованиями, составленными на основании нормативной документации, должен обязательно отслеживать изменения в просмотренных документах и готовить требования на соответствующую доработку функциональности.
Анализ аналогичных существующих на рынке решений позволит определиться с приоритетом реализации функций и продумать варианты их представления пользователю.
Проверенные интернет-источники позволят максимально глубоко погрузиться в предметную область и найти ответы на возникающие вопросы. Достоверность информации, полученной из одного источника, должна быть подтверждена еще несколькими. Особое внимание рекомендуется обращать на узкоспециализированные форумы, на которых зачастую встречаются реальные пользовательские кейсы и варианты их решения.
Освежить в памяти историю развития продукта, получить полную информацию о нем помогут задачи в трекерах и wiki-статьи. Причем здесь аналитик может отследить историю изменений требования и связанные требования для того, чтобы понять опыт реализации подобной функциональности, а также проанализировать, на какие смежные функции повлияет новая реализация.
Проверить продуктовые гипотезы и принять решение по дальнейшей доработке модуля помогут данные метрик. На основании данных метрик продукта аналитик может проверять различные продуктовые гипотезы, отслеживать статистические показатели по проекту для дальнейшего составления беклога и приоритезации задач.
Частичную информацию об обязательных нефункциональных требованиях к продукту можно почерпнуть из документации на смежные решения, с которыми будет интегрироваться продукт. Эта базовая информация в дальнейшем может быть использована для анализа совместимости продуктов, выбора способов проведения интеграции и т.д.
Важную информацию о приоритетных для реализации компонентах продукта, подробностях реализации можно получить во время формализованных и неформализованных интервью и бесед с представителями заказчиков, продакт оунером; сбора анкет и отзывов конечных пользователей.
Рекомендации по реализации пользовательских интерфейсов предоставят данные UX-исследований.
Приоритет задачи относительно других задач может проставить продакт оунер либо тимлид. Информация о приоритетах позволит аналитику спланировать свою работу и соблюсти сроки формирования артефактов.
Для экономии времени и повышения качества работы перед началом работы над задачей аналитик должен определить необходимые источники информации и глубину их проработки.
Управление требованиями
После анализа информации из всех необходимых и достаточных источников можно приступать к подготовке требований на разработку. В ряде случаев более эффективным будет написание требования параллельно с изучением информации.
Корректность формулировки и содержания требований крайне важна, поскольку именно они определяют всю дальнейшую разработку.
Первоначальное требование в зависимости от типа разработки (внутренняя либо внешняя), опытности команды, устоявшейся в команде методологии разработки, типа задачи может быть сформулировано в виде детализированной задачи, в формате User Story (US), в виде технического задания на реализуемую функциональность.
С течением времени бизнес-потребность может (и скорее всего будет) изменяться, что приведет к появлению новых, изменению существующих либо архивации устаревших требований. Обратите внимание на то, что удалять устаревшие и неактуальные требования можно только если реализованная функциональность описана в wiki-статье, и информация о ней не исчезнет через какое-то время.
Изменение бизнес-потребности приведет к тому, что аналитик должен будет встроить новое требование в уже существующий пул задач с учетом работающих компонентов продукта. Это требование может быть дополняющим, модифицирующим либо отменяющим уже существующие требования.
При работе с такими требованиями особенно важно приложить все усилия для сохранения целостности продукта. Поэтому перед непосредственным описанием постановки аналитик обязательно должен убедиться в том, что между новым и уже существующими требованиями отсутствуют противоречия, а в случае, если такие противоречия будут обнаружены, - совместно с продакт оунером выработать компромиссные пути их разрешения либо предоставить мотивированный отказ в запрашиваемой разработке.
Помочь в этом могут уже существующие в рамках проекта требования, которые аналитик поддерживает в логической взаимосвязи, а также трассировка требований - преобразование требования из бизнес-формулировки в формулировку, подходящую для адекватной оценки требования.
После того, как требование на доработку существующей функциональности проверено на непротиворечивость, оно формулируется в виде задачи на разработку (постановки).
О том, какая информация обязательно должна содержаться в хорошей постановке, а также о разновидностях требований и критериях их оценки мы расскажем в одной из следующих статей.
Консультирование команды
Консультированию команды на нашем канале посвящена отдельная статья.
Здесь мы верхнеуровнево рассмотрим, по каким вопросам к аналитику могут обращаться члены команды, и как это связано с типом реализуемой задачи.
Если действующее законодательство четко регламентирует порядок оказания услуги, которую мы автоматизируем, члены команды разработки могут обращаться к нам для разъяснения положений нормативной документации.
В случаях, когда постановка описана недостаточно подробно, члены команды могут обращаться к аналитику за трактованием отдельных ее положений.
Продакт оунер почти всегда заинтересован в прогнозировании рисков реализации проекта, и может прибегнуть к экспертной помощи аналитика.
Также команде будут интересны информация о позиции Заказчика, связи задачи с иными постановками, критерии приемки результата, сроки реализации и т.д.
Ведение WIKI проекта
После того, как постановка сформулирована, а заявленная в ней функциональность разработана, аналитик должен зафиксировать информацию об этом в Wiki - внутренней базе знаний проекта.
В Wiki описываются реализованные в продуктах функции, бизнес-требования, по которым они были разработаны, техническая информация.
Основное назначение такой базы - сохранение преемственности знаний у специалистов, которые занимаются проектом .
А что в итоге?
Рассмотрев все вышеописанные функции аналитика, мы подошли к получению ответа на самый важный вопрос: для чего нужен системный аналитик в команде разработки и с какими рисками для бизнеса этот специалист борется в процессе работы?
Прежде всего, системный аналитик помогает экономить время.
Задействованный в момент зарождения проекта аналитик позволяет более точно оценить сроки разработки за счет получения подробных требований от заказчика, участия в приоритизации полученных задач и оценке сроков разработки.
В процессе работы над проектом аналитик помогает соблюдать сроки разработки благодаря оперативному взаимодействию с заказчиком, полному владению информацией предметной области, своевременной поставке качественных задач и т.д.
Также присутствующий в команде аналитик помогает обеспечить заданный уровень качества.
На этапе зарождения проекта эта задача решается за счет фиксации договоренностей с заказчиком (технического задания), систематизации базовой информации, проработки схем автоматизируемых бизнес-процессов, предварительного согласования с заказчиком критериев приемки продукта.
При проработке проекта аналитик помогает соблюдать требуемое качество разработки за счет предварительной оценки рисков реализации функций, своевременного выявления актуальных требований к продукту, согласования с заказчиком вариантов изменения бизнес-процессов для повышения ценности итогового продукта и т.д.
Все это в целом ведет к уменьшению затрат, а также финансовых и репутационных рисков компании.
Есть дополнения? Давайте обсудим!
Текст: Татьяна Величкина
Редактор: Алёна Черкасова
Фото: найдены на просторах Сети