Методика разработки бизнес-требований в проекте по автоматизации. Часть 2
Во второй статье бизнес-требования рассматриваются как требования бизнеса
Часть 1 | Часть 2 | Часть 3 | Часть 4
Введение
В первой статье мы рассмотрели понятие бизнес-требования как требования к бизнесу, которое отражается в различных нормативных актах:
нормативно-правовые акты страны: законы, приказы министерств, региональное законодательство и т.д.
локальные нормативные акты (ЛНА) предприятия: приказы генерального директора, должностные инструкции, технологические карты и т.д.
договоры с третьими лицами
В рамках данной статьи мы рассмотрим вторую часть бизнес-требований — требование бизнеса.
При этом под бизнесом мы понимаем конкретных ответственных лиц предприятия: руководство, сотрудников, владельцев бизнес-процессов, владельцев бизнес-функций.
Требование к бизнесу означает, что сотрудник предприятия берет на себя ответственность выполнить определенные обязательства. Для выполнения работы ему нужны возможности и ресурсы, и для того чтобы их получить, он предъявляет собственные требования, которые бизнес-аналитик должен преобразовать в требование к решению.
В проекте по автоматизации ключевыми являются требования к системе, однако в процессе разработки бизнес-требований сначала важно определить именно требование к решению, так как само решение может даже не включать автоматизацию.
Требование к ответственному лицу
Рассмотрим пример из предыдущей статьи про налоговую декларацию, но для начала обновим нашу канву для описания требований, взяв за основу слово БИЗНЕС. С помощью этой мнемотехники можно быстро составить список вопросов для ответственного лица в разговоре о его обязанностях: прежде чем выяснять требования бизнеса, необходимо выяснить требования к бизнесу.
База требования. В каком нормативном акте содержится требование к организации / бизнес-процессу / бизнес-функции? Кто источник требования? При каком условии это требование вступает в силу?
Исполнитель. Кто должен выполнить требование?
Заказчик. Кто выгодоприобретатель? Кто будет принимать исполнение требования?
Нормативная Единица требования. В чём заключается требование? Что именно нужно выполнить?
Стандарт требования. По каким параметрам требование можно считать выполненным?
Опишем требование к владельцу бизнес-процесса, то есть главному бухгалтеру, по канве (подробности можно посмотреть в первой статье)
На основании должностной инструкции, подписанной генеральным директором,
главный бухгалтер должен в инспекцию ИФНС предоставить декларацию по налогу на прибыль не позднее 25 числа месяца, следующего за отчетным кварталом, в электронной или бумажной форме, установленной приказом ФНС России от 23.09.2019 N ММВ-7-3/475.Опасения и ожидания ответственного лица
Стандарт ISO/IEC/IEEE 29148 и Руководство по написанию требований международного совета по системной инженерии (INCOSE) рассматривают требования стейкхолдера как результат работы с потребностью. В отличие от потребности, которая выражена разговорным языком от людей с определенной точкой зрения, формулировка требования более структурирована и объективна.
В стандарте ISO/IEC/IEEE 29148 потребности описываются понятием concerns — опасения, в INCOSE используется слово expectations — ожидания. В рамках данной статьи мы предлагаем
выделить это описание в отдельный этап при разработке требований,
вместо понятия стейкхолдер использовать понятие ответственное лицо, так как стейкхолдер может быть как внутренним по отношению к организации, так и внешним, а также может не нести ответственности перед компанией. В данном же случае нам важно подчеркнуть именно факт наличия обязательств.
выявить опасения / ожидания ответственного лица
↓
описать потребности ответственного лица
↓
сформулировать требования к решению
В примере из предыдущей статьи у главного бухгалтера есть рабочая инструкция по проверке декларации по налогу на прибыль, однако на практике редко встречается, чтобы все процессы компании были досконально описаны в локальных нормативных актах. В случае отсутствия ЛНА целесообразно начать с проработки бизнес-процесса.
Первоначально мы можем попросить ответственное лицо назвать свои опасения: какие риски он несёт при невыполнении взятых на себя обязательств? Например, главный бухгалтер может выразить опасения следующим образом:
«Я боюсь сдать некорректную налоговую декларацию из-за того, что я не успею её проверить, а данных очень много. Потом придётся отвечать на запросы от налоговой инспекции по камеральной проверке»
«Я боюсь не сдать налоговую декларацию вовремя из-за того, что программа долго её рассчитывает и отправляет, тогда придётся платить штраф».
Когда риски проработаны и найдены точки бизнес-процесса, влияющие на подбор решения, мы узнаём от ответственного лица его ожидания, которые в нашем примере могут звучать так:
при проверке налоговой декларации мне нужно два дня, чтобы сверить данные бухгалтерского и налогового учета,
я закладываю один день на то, чтобы сверить данные налоговой декларации с данными налогового учета,
обычно я согласовываю размер уплачиваемой прибыли с генеральным директором за день до отправки налоговой декларации.
Каждое из этих ожиданий можно досконально проработать, задавая вопросы о том, как именно главный бухгалтер сравнивает данные, почему на это нужно именно такое количество дней, есть ли тут задел для оптимизации процесса. Для целей статьи нет необходимости детализировать каждый подпроцесс.
Потребности ответственного лица
Ворох опасений и ожиданий мы приводим в более формализованный вид потребностей. Их можно описывать в разных форматах, рассмотрим два из них: User Story и Job story.
User Story — способ описания потребности, сформулированный как одно или более предложений на повседневном или деловом языке пользователя. В рамках данной статьи мы трактуем User Story следующим образом:
Роль, которую выполняет ответственное лицо в компании.
Потребность, выполнение которой закроет основные опасения и ожидания ответственного в проекте по автоматизации
Результат, который стремится получить ответственное лицо для того, чтобы выполнить взятые на себя обязательства.
Как главный бухгалтер, я хочу иметь в запасе как минимум 4 дня, чтобы сверить налоговую декларацию с данными налогового учета.Изначально Job Story — фреймворк из концепции Jobs To Be Done для исследования целевой аудитории, её мотивов и проблем. В целях данной статьи мы используем этот способ, если мы хотим сосредоточить внимание на контексте, в котором у ответственного лица возникли сложности.
Как только в базе сформированы все данные по налоговому учету, я хочу успеть сформировать декларацию в течение своего рабочего дня, чтобы успеть её проверить до 25 числа месяца, следующего за отчетным кварталом.Из потребностей ответственного лица мы разрабатываем одно или несколько требований к решению, которое в данном случае будет звучать так:
Решение должно для главного бухгалтера предоставить декларацию по налогу на прибыль не позднее 20 числа месяца, следующего за окончанием отчетного квартала, чтобы осталось время на проверку налоговой декларации.Заключение
Во второй части из серии статей с описанием методики разработки бизнес-требований в проекте по автоматизации мы рассмотрели логику сбора требований с ответственного лица:
Выяснить требование к ответственному лицу согласно мнемотехнике БИЗНЕС:
Собрать опасения и ожидания ответственного лица, связанные с выполнением взятых на себя обязательств.
Сформулировать потребности ответственного лица в виде User Story или Job Story:
Проработать требования к решению.
В следующей части мы рассмотрим разветвление требований к бизнесу на требования к бизнес-процессам и бизнес-функциям.
В этой серии статей не будут рассматриваться другие этапы работы с требованиями в проекте по автоматизации:
определение проблем, целей и ограничений проекта,
определение списка стейкхолдеров,
процесс интервьюирования,
описание бизнес-процессов,
генерация вариантов решений,
проработка системных требований.