Статья предназначена для бизнес- и системных аналитиков, формирующих требования к информационным системам. Также эта информация будет полезна разработчикам и другим лицам, работающим в бизнесе производства программного обеспечения. В статье обсуждается формирование и документирование требований. В частности, рассматривается тот случай, когда аналитику говорят: «все ваши требования бесполезны, потому что никак не объясняют разработчику, что нужно сделать и, главное, зачем».
Разберем процесс, как это обычно происходит. Аналитик получает запрос на изменение функционала в виде тикета из техподдержки, технического задания или прямой жалобы клиента. Суть запроса в том, что что-то там в системе плохо и нужно подумать, как это исправить. Или что нужно сделать вот тут на этом экране еще одну такую возможность. Или нужно, чтобы «у пользователя была возможность сделать вот это». Часто аналитик просто записывает требование в том виде как оно пришло: в виде нескольких предложений или user story, формирует из этого задачу на изменение (или несколько задач) и отправляет её разработчику. Далее происходит то, что описано в последнем предложении предыдущего абзаца. Разберемся почему.
Проблема №1. Что непонятно разработчику? Ему непонятно, какие экраны в системе менять, какие кнопки, поля, вкладки и API и прочее нужно доработать/создать для выполнения требований клиента. То, что приходит от аналитика является функциональными требованиями, а разработчику нужна функциональная спецификация (другие названия: реализация, дизайн) с детальным описанием необходимых изменений. Например, вместо описания функциональности с детализацией уровня
«Когда пользователь нажимает кнопку ОК, окно диалога закрывается и в фокусе оказывается главное окно, которое было до появления диалога». (функциональная спецификация)
разработчик получает описание с детализацией уровня
«Пользователь должен иметь возможность закрыть окно диалога и вернуться в главное окно» (функциональное требование).
В последнем описании отсутствуют 2 детали реализации:
* окно закрывается при нажатии кнопки ОК,
* фокус возвращается в главное окно автоматически.
Даже если разработчик самостоятельно додумает эти недостающие детали, их отсутствие в тексте исходной задаче создаст проблемы. Например, тестировщику будет непонятно что проверять в рамках данной задачи. Как правило, в таких случаях тестировщики идут/звонят разработчикам и просят рассказать, «что именно было сделано» в рамках этой задачи. Для определения точного поведения данного функционал в будущем, например, при появлении дефекта (бага) или при возникновении необходимости изменений, от разработчиков потребуется изучить исходный код той ревизии “где точно все работало правильно”, а от тестировщиков — найти соответствующий тест-кейс. Все это влечет дополнительные временные затраты по сравнению с простым прочтением функциональной спецификации, которая могла бы быть зафиксирована в исходной задаче аналитиком.
Многие аналитики сознательно не описывают функциональную спецификацию и ограничиваются лишь требованиями, поскольку хотят оставить свободу выбора решения разработчику. И многие разработчики даже требуют(!), чтобы в задаче не было деталей реализации и чтобы у них была свобода выбора того, как именно реализовывать функциональное требование. Этому есть две причины: 1) желание разработчика знать, зачем вообще, что-то менять; 2) существование нескольких способов реализовать одно и тоже функциональное требование в системе, из которых (по чистому невезению) аналитик выбрал не самый простой. Так же есть и 3я причина, собственное эго разработчика, но в данной статье мы не будем это обсуждать. Первая причина, «желание знать зачем» обсуждается ниже. Что делать со второй — рекомендуется обсуждать с разработчиком основные моменты функциональной спецификаций. Причем, по возможности, делать это _до_ фиксации спецификации в тексте задаче. Если возможность обсудить отсутствует (например, если разработчики находятся в 10 часовых поясах от вас или в компании-подрядчике), то все равно необходимо записывать в задаче спецификацию, и только затем отправлять разработчику на согласование. Эффективность такого подхода будет выше, поскольку затраты времени аналитика на последующее переписывание задачи все равно будут меньше затрат времени нескольких людей на выяснение точного поведения системы, вызванное отсутствием в задаче спецификации.
Часто возникает вопрос, должен ли аналитик описывать требования к базе данных в задаче, например, структуру таблиц, названия полей и тп.? Короткий ответ — нет. Аналитик должен специфицировать только ту часть программного обеспечения, которая видна пользователю. Это пользовательский, интерфейс публичные API и видимые параметры оборудования, например, размер монитора. Да, в этой статье мы говорим о программном обеспечении, но поскольку в «чистом» виде его практически никто не использует и пользователь всегда взаимодействует с программой через прослойку оборудования, то в спецификации требований необходимо указывать допустимые параметры этой прослойки.
Еще одной распространенной ошибкой как аналитиков, так и разработчиков является описание деталей реализации (по факту, функциональной спецификации) в _комментариях_ к задаче. Причем часто создается по нескольку комментариев для одного и того же функционала (это называется обсуждением). Следует ли из-за этого вообще не пользоваться комментариями? Конечно же нет, но промежуточные договоренности по функциональной спецификации, а особенно финальные, следует фиксировать именно в тексте задачи, а не где-то еще. И повторно упомянем, что лучший способ договориться — это все-таки созвониться с разработчиком и обсудить основные детали голосом, и только потом записывать их в задаче.
Проблема №2. Почему разработчику непонятно «зачем делать»? Потому что в задаче отсутствует то, что называется бизнес-требованием (другие названия: проблема или problem statement), либо, что даже чаще, из описания бизнес-требования исходная проблема пользователя все равно не ясна, поскольку в описании слишком много упоминается само программное обеспечение, а не бизнес или ситуация пользователя. Один из примеров непонятного описания проблемы:
«В системных справочниках реализовано поле „наименование англ.“, но поле никогда не заполнялось. Наличие незаполненных полей в справочниках не устраивает заказчика, т.к. указывает на неактуальность справочников».
Ну неактуальны справочники, и что? Кто от этого страдает? Собрав совсем немного дополнительной информации можно описать проблему лучше:
«Администраторы клиента тратят дополнительное время на контроль актуальности классификаторов, представленных в виде справочников. Так происходит из-за наличия в списке элементов справочника дополнительных полей, про которые непонятно заполнять их или нет».
Что поменялось? Во-первых, стали очевидны конкретные люди, у которых проблема (администраторы) Во-вторых, стало понятно измерение проблемы (затраты времени). Если еще понять, как часто контролируются классификаторы (тратиться лишнее время), то уже можно определить приоритет проблемы (и задачи). А если еще объяснить, почему вообще классификаторы должны быть актуальны, то получится совсем идеальное описание.
Описание проблемы еще называют «problem statement» (см. ссылку выше) и, хотя у Голдсмита перечислены аж 6 шагов ее определения, имеет смысл упрощение до всего лишь 3х:
Шаг1. Описание категории пользователя;
Шаг2. Определение и описание бизнес-задачи пользователя, которая или не решается, или требует дополнительное время/деньги, или влечет наказание за нарушение закона;
Шаг3. Описание недостатка в программном обеспечении, не позволяющего решить бизнес-задачу.
Рекомендуется именно такой порядок описания проблемы, поскольку никому не хочется читать лишние слова — описание программного обеспечения.
В заключении, обобщая указанные проблемы, хочется отметить, на что при документировании требований аналитику следует тратить время, а на что нет. Критически важны только две вещи: документирование проблемы пользователя и документирование функциональной спецификации изменений. Именно эти два пункта должны присутствовать в каждой задаче для разработчиков и тестировщиков. Это гарантированно решает озвученную в начале статьи проблему.
На все остальные активности по управлению и документированию требований, такие как функциональные и нефункциональные требования, user stories, use сases, затраты времени необходимо минимизировать, поскольку ничего из этого не объясняет самые важные вещи: 1) что именно разрабатывать/тестировать, 2) кто из пользователей выиграет от этих действий и в чем сейчас состоит его проблема. Функциональные требования нужны, когда по описанию проблемы (по бизнес-требованиям) невозможно охватить решающую проблему функциональную спецификацию из-за ее объема. Как следствие, создается промежуточный, более компактный, слой требований, который в конечном счете все равно приводит к появлению спецификации. Но поскольку этот слой требований промежуточный, его желательно пропускать — что экономит время.
P.S. Шаблон для описания задачи в JIRA. Задачи (но не баги) оформляются согласно следующим ниже шаблонам полей Summary, Problem, Description. Все 3 поля обязательны для заполнения.
Summary:
Problem:
Description:
Разберем процесс, как это обычно происходит. Аналитик получает запрос на изменение функционала в виде тикета из техподдержки, технического задания или прямой жалобы клиента. Суть запроса в том, что что-то там в системе плохо и нужно подумать, как это исправить. Или что нужно сделать вот тут на этом экране еще одну такую возможность. Или нужно, чтобы «у пользователя была возможность сделать вот это». Часто аналитик просто записывает требование в том виде как оно пришло: в виде нескольких предложений или user story, формирует из этого задачу на изменение (или несколько задач) и отправляет её разработчику. Далее происходит то, что описано в последнем предложении предыдущего абзаца. Разберемся почему.
Проблема №1. Что непонятно разработчику? Ему непонятно, какие экраны в системе менять, какие кнопки, поля, вкладки и API и прочее нужно доработать/создать для выполнения требований клиента. То, что приходит от аналитика является функциональными требованиями, а разработчику нужна функциональная спецификация (другие названия: реализация, дизайн) с детальным описанием необходимых изменений. Например, вместо описания функциональности с детализацией уровня
«Когда пользователь нажимает кнопку ОК, окно диалога закрывается и в фокусе оказывается главное окно, которое было до появления диалога». (функциональная спецификация)
разработчик получает описание с детализацией уровня
«Пользователь должен иметь возможность закрыть окно диалога и вернуться в главное окно» (функциональное требование).
В последнем описании отсутствуют 2 детали реализации:
* окно закрывается при нажатии кнопки ОК,
* фокус возвращается в главное окно автоматически.
Даже если разработчик самостоятельно додумает эти недостающие детали, их отсутствие в тексте исходной задаче создаст проблемы. Например, тестировщику будет непонятно что проверять в рамках данной задачи. Как правило, в таких случаях тестировщики идут/звонят разработчикам и просят рассказать, «что именно было сделано» в рамках этой задачи. Для определения точного поведения данного функционал в будущем, например, при появлении дефекта (бага) или при возникновении необходимости изменений, от разработчиков потребуется изучить исходный код той ревизии “где точно все работало правильно”, а от тестировщиков — найти соответствующий тест-кейс. Все это влечет дополнительные временные затраты по сравнению с простым прочтением функциональной спецификации, которая могла бы быть зафиксирована в исходной задаче аналитиком.
Многие аналитики сознательно не описывают функциональную спецификацию и ограничиваются лишь требованиями, поскольку хотят оставить свободу выбора решения разработчику. И многие разработчики даже требуют(!), чтобы в задаче не было деталей реализации и чтобы у них была свобода выбора того, как именно реализовывать функциональное требование. Этому есть две причины: 1) желание разработчика знать, зачем вообще, что-то менять; 2) существование нескольких способов реализовать одно и тоже функциональное требование в системе, из которых (по чистому невезению) аналитик выбрал не самый простой. Так же есть и 3я причина, собственное эго разработчика, но в данной статье мы не будем это обсуждать. Первая причина, «желание знать зачем» обсуждается ниже. Что делать со второй — рекомендуется обсуждать с разработчиком основные моменты функциональной спецификаций. Причем, по возможности, делать это _до_ фиксации спецификации в тексте задаче. Если возможность обсудить отсутствует (например, если разработчики находятся в 10 часовых поясах от вас или в компании-подрядчике), то все равно необходимо записывать в задаче спецификацию, и только затем отправлять разработчику на согласование. Эффективность такого подхода будет выше, поскольку затраты времени аналитика на последующее переписывание задачи все равно будут меньше затрат времени нескольких людей на выяснение точного поведения системы, вызванное отсутствием в задаче спецификации.
Часто возникает вопрос, должен ли аналитик описывать требования к базе данных в задаче, например, структуру таблиц, названия полей и тп.? Короткий ответ — нет. Аналитик должен специфицировать только ту часть программного обеспечения, которая видна пользователю. Это пользовательский, интерфейс публичные API и видимые параметры оборудования, например, размер монитора. Да, в этой статье мы говорим о программном обеспечении, но поскольку в «чистом» виде его практически никто не использует и пользователь всегда взаимодействует с программой через прослойку оборудования, то в спецификации требований необходимо указывать допустимые параметры этой прослойки.
Еще одной распространенной ошибкой как аналитиков, так и разработчиков является описание деталей реализации (по факту, функциональной спецификации) в _комментариях_ к задаче. Причем часто создается по нескольку комментариев для одного и того же функционала (это называется обсуждением). Следует ли из-за этого вообще не пользоваться комментариями? Конечно же нет, но промежуточные договоренности по функциональной спецификации, а особенно финальные, следует фиксировать именно в тексте задачи, а не где-то еще. И повторно упомянем, что лучший способ договориться — это все-таки созвониться с разработчиком и обсудить основные детали голосом, и только потом записывать их в задаче.
Проблема №2. Почему разработчику непонятно «зачем делать»? Потому что в задаче отсутствует то, что называется бизнес-требованием (другие названия: проблема или problem statement), либо, что даже чаще, из описания бизнес-требования исходная проблема пользователя все равно не ясна, поскольку в описании слишком много упоминается само программное обеспечение, а не бизнес или ситуация пользователя. Один из примеров непонятного описания проблемы:
«В системных справочниках реализовано поле „наименование англ.“, но поле никогда не заполнялось. Наличие незаполненных полей в справочниках не устраивает заказчика, т.к. указывает на неактуальность справочников».
Ну неактуальны справочники, и что? Кто от этого страдает? Собрав совсем немного дополнительной информации можно описать проблему лучше:
«Администраторы клиента тратят дополнительное время на контроль актуальности классификаторов, представленных в виде справочников. Так происходит из-за наличия в списке элементов справочника дополнительных полей, про которые непонятно заполнять их или нет».
Что поменялось? Во-первых, стали очевидны конкретные люди, у которых проблема (администраторы) Во-вторых, стало понятно измерение проблемы (затраты времени). Если еще понять, как часто контролируются классификаторы (тратиться лишнее время), то уже можно определить приоритет проблемы (и задачи). А если еще объяснить, почему вообще классификаторы должны быть актуальны, то получится совсем идеальное описание.
Описание проблемы еще называют «problem statement» (см. ссылку выше) и, хотя у Голдсмита перечислены аж 6 шагов ее определения, имеет смысл упрощение до всего лишь 3х:
Шаг1. Описание категории пользователя;
Шаг2. Определение и описание бизнес-задачи пользователя, которая или не решается, или требует дополнительное время/деньги, или влечет наказание за нарушение закона;
Шаг3. Описание недостатка в программном обеспечении, не позволяющего решить бизнес-задачу.
Рекомендуется именно такой порядок описания проблемы, поскольку никому не хочется читать лишние слова — описание программного обеспечения.
В заключении, обобщая указанные проблемы, хочется отметить, на что при документировании требований аналитику следует тратить время, а на что нет. Критически важны только две вещи: документирование проблемы пользователя и документирование функциональной спецификации изменений. Именно эти два пункта должны присутствовать в каждой задаче для разработчиков и тестировщиков. Это гарантированно решает озвученную в начале статьи проблему.
На все остальные активности по управлению и документированию требований, такие как функциональные и нефункциональные требования, user stories, use сases, затраты времени необходимо минимизировать, поскольку ничего из этого не объясняет самые важные вещи: 1) что именно разрабатывать/тестировать, 2) кто из пользователей выиграет от этих действий и в чем сейчас состоит его проблема. Функциональные требования нужны, когда по описанию проблемы (по бизнес-требованиям) невозможно охватить решающую проблему функциональную спецификацию из-за ее объема. Как следствие, создается промежуточный, более компактный, слой требований, который в конечном счете все равно приводит к появлению спецификации. Но поскольку этот слой требований промежуточный, его желательно пропускать — что экономит время.
P.S. Шаблон для описания задачи в JIRA. Задачи (но не баги) оформляются согласно следующим ниже шаблонам полей Summary, Problem, Description. Все 3 поля обязательны для заполнения.
Summary:
<Название задачи. Вместо общих слов «доработка», «изменение», «задача на» рекомендуется указывать конкретное выполняемое в задаче действие или самое важное из нескольких действий>
Problem:
<Описание проблемы: пользователь(ли), невозможность/сложность реализации бизнес-задачи/процесса средствами ПО или несоответствие между бизнес-задачей и ПО>.
Description:
<опционально> Где: <Точное описание процедуры получения пользователем доступа к экрану ПО, на котором необходимо выполнить изменения>.
<Точное описание всех изменений в ПО, видимых пользователю. Без упоминания деталей бизнес-процесса и причин, по которым изменения требуются>
<опционально> Задача на внедрение:
<Точное описание всех конфигурационных настроек в ПО, в том числе невидимых пользователю, которые необходимо выполнить _после_ релиза изменений. Например, запуск скрипта или настройка справочников>