Хотел назвать статью «ошибки при работе с требованиями», но потом понял, что единственной ошибкой было бы решение не работать с требованиями. Если решение работать с требованиями принято, то, скорее всего, следствием будут не столько ошибки, сколько проблемы и трудности. Вот про эти проблемы, с которыми сталкивается любая организация или проектный коллектив, я и собираюсь написать.

Проблема №1. Не те люди

С точки зрения работы с требованиями, системы, которые мы разрабатываем, можно разделить на два больших класса:

• системы, в которых требования «падают» сверху. Требования исходят от заказчика, принимаются в проект вместе с договором, и практически не изменяются в ходе разработки. Сами изделия обычно не содержат исключительной новизны, и являются подобием изделий, которые организация уже разрабатывала ранее. К проектам такого рода можно отнести разработку составных частей и систем самолетов, космических аппаратов, автомобилей, АСУ ТП и подобных.

• системы, требования для которых приходится активно собирать у различных заинтересованных сторон. Требования в этом случае разрабатываются в начале проекта с достаточно широкими допусками и содержат только верхнеуровневое описание системы. Более точные требования формируются в ходе разработки как результат активного взаимодействия с широким кругом заинтересованных сторон. В основном, заинтересованные стороны это пользователи создаваемой системы. Типичным представителем проектов такого типа являются проекты по созданию информационных систем и программных средств. Хотя у организации может быть солидный опыт разработки информационных систем, «из архива» в этом случае работать не получится. Каждый проект содержит большой процент новизны. Требования в этом случае продолжают поступать от заинтересованных сторон не только в ходе всей разработки, но и после ее завершения, в ходе опытной эксплуатации и технической поддержки.

Конечно, деление это на классы условно, и можно перечислить еще ряд типов систем или проектов, но с точки зрения работы с требованиями их так или иначе можно свести к двум уже упомянутым типам.

Разработка систем, ведущаяся на основе солидного задела, многолетнего опыта и большого числа уже проведенных проектов зачастую приводит к тому, что разработка требований (будь то ТЗ или спецификация) становится рутинной задачей, которую можно поручить любому относительно свободному сотруднику. Относительно свободный сотрудник – этот тот человек, которого по причине отсутствия опыта в целом (только закончил обучение) или отсутствия опыта в этой организации (недавно принят на работу) берет в качестве примера уже имеющийся набор требований (ТЗ или спецификацию), и переписывает его на новый лад. При этом он:

• не проходил специальное обучение (с обязательным практикумом) по работе с требованиями;

• не достаточно глубоко разбирается в предметной области;

• плохо понимает, с какими заинтересованными сторонами и как именно он должен взаимодействовать;

• плохо понимает методологию инженерии требований и ее взаимодействие с процессами архитектурного проектирования, верификации и валидации, управления конфигурацией;

• и, возможно, просто не способен к этой специфической деятельности.

В результате задачу по анализу и разработке требований выполняет сотрудник, который зачастую просто не может ее выполнить на достаточно высоком уровне качества.

Если речь идет об информационной системе, то разработкой требований должны заниматься уже как минимум два сотрудника:

• системный аналитик, или аналитик требований, должен превратить требования пользователя в системные требования и поместить их в спецификацию. Необходимые навыки и подготовка этого сотрудника примерно такие же, как и в предыдущем разделе;

• бизнес-аналитик, должен выявить проблемы (боли), потребности и пожелания Заказчика, и превратить их в требования пользователя. Этот специалист должен обладать незаурядными навыками общения, добывания и проверки информации, налаживания отношений и разрешения конфликтов.

Бизнес-аналитик это человек, направленный на общение, контактный, восприимчивый, обладающий развитыми навыками коммуникации, умеющий задавать открытые вопросы, обладающий навыками активного слушания, и прошедший соответствующее обучение и тренинг. При этом обучения и тренинга не достаточно, если отсутствует личностная склонность к деятельности такого рода.

Опыт работы по внедрению методологии и программных инструментов инженерии требований на протяжении более 15 лет показывает, что организации, в которых есть хорошо подготовленные и бизнес, и системные аналитики встречаются крайне редко. Проблему отсутствия необходимых компетенций в организации возможно решать, используя следущие подходы:

• найти и принять на работу людей с необходимыми компетенциями. Это задача отдела управления персоналом;

• обучить и развить навыки тех сотрудников, которые в настоящий момент уже работают в организации, должным образом простимулировав выполнение ими дополнительных обязанностей;

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

В обучении и тренинге сотрудников, а также в разработке документированного процесса инженерии требований помощь может оказать компания, в которой я работаю, В3 Прожектс.

Часть 2. Не то время