Хотел назвать статью «ошибки при работе с требованиями», но потом понял, что единственной ошибкой было бы решение не работать с требованиями. Если решение работать с требованиями принято, то, скорее всего, следствием будут не столько ошибки, сколько проблемы и трудности. Вот про эти проблемы, с которыми сталкивается любая организация или проектный коллектив, я и собираюсь написать.
Проблема №1. Не те люди
С точки зрения работы с требованиями, системы, которые мы разрабатываем, можно разделить на два больших класса:
системы, в которых требования «падают» сверху. Требования исходят от заказчика, принимаются в проект вместе с договором, и практически не изменяются в ходе разработки. Сами изделия обычно не содержат исключительной новизны, и являются подобием изделий, которые организация уже разрабатывала ранее. К проектам такого рода можно отнести разработку составных частей и систем самолетов, космических аппаратов, автомобилей, АСУ ТП и подобных.
системы, требования для которых приходится активно собирать у различных заинтересованных сторон. Требования в этом случае разрабатываются в начале проекта с достаточно широкими допусками и содержат только верхнеуровневое описание системы. Более точные требования формируются в ходе разработки как результат активного взаимодействия с широким кругом заинтересованных сторон. В основном, заинтересованные стороны это пользователи создаваемой системы. Типичным представителем проектов такого типа являются проекты по созданию информационных систем и программных средств. Хотя у организации может быть солидный опыт разработки информационных систем, «из архива» в этом случае работать не получится. Каждый проект содержит большой процент новизны. Требования в этом случае продолжают поступать от заинтересованных сторон не только в ходе всей разработки, но и после ее завершения, в ходе опытной эксплуатации и технической поддержки.
Конечно, деление это на классы условно, и можно перечислить еще ряд типов систем или проектов, но с точки зрения работы с требованиями их так или иначе можно свести к двум уже упомянутым типам.
Разработка систем, ведущаяся на основе солидного задела, многолетнего опыта и большого числа уже проведенных проектов зачастую приводит к тому, что разработка требований (будь то ТЗ или спецификация) становится рутинной задачей, которую можно поручить любому относительно свободному сотруднику. Относительно свободный сотрудник – этот тот человек, которого по причине отсутствия опыта в целом (только закончил обучение) или отсутствия опыта в этой организации (недавно принят на работу) берет в качестве примера уже имеющийся набор требований (ТЗ или спецификацию), и переписывает его на новый лад. При этом он:
не проходил специальное обучение (с обязательным практикумом) по работе с требованиями;
не достаточно глубоко разбирается в предметной области;
плохо понимает, с какими заинтересованными сторонами и как именно он должен взаимодействовать;
плохо понимает методологию инженерии требований и ее взаимодействие с процессами архитектурного проектирования, верификации и валидации, управления конфигурацией;
и, возможно, просто не способен к этой специфической деятельности.
В результате задачу по анализу и разработке требований выполняет сотрудник, который зачастую просто не может ее выполнить на достаточно высоком уровне качества.
![Рисунок 1. Работа системного аналитика\аналитика требований Рисунок 1. Работа системного аналитика\аналитика требований](https://habrastorage.org/getpro/habr/upload_files/22a/559/266/22a5592669cb23b9986b38195be99f2d.png)
Если речь идет об информационной системе, то разработкой требований должны заниматься уже как минимум два сотрудника:
системный аналитик, или аналитик требований, должен превратить требования пользователя в системные требования и поместить их в спецификацию. Необходимые навыки и подготовка этого сотрудника примерно такие же, как и в предыдущем разделе;
бизнес-аналитик, должен выявить проблемы (боли), потребности и пожелания Заказчика, и превратить их в требования пользователя. Этот специалист должен обладать незаурядными навыками общения, добывания и проверки информации, налаживания отношений и разрешения конфликтов.
Бизнес-аналитик это человек, направленный на общение, контактный, восприимчивый, обладающий развитыми навыками коммуникации, умеющий задавать открытые вопросы, обладающий навыками активного слушания, и прошедший соответствующее обучение и тренинг. При этом обучения и тренинга не достаточно, если отсутствует личностная склонность к деятельности такого рода.
![Рисунок 2. Работа бизнес-аналитика Рисунок 2. Работа бизнес-аналитика](https://habrastorage.org/getpro/habr/upload_files/d30/cff/df4/d30cffdf4c123d1a10fa72fe66a32979.png)
Опыт работы по внедрению методологии и программных инструментов инженерии требований на протяжении более 15 лет показывает, что организации, в которых есть хорошо подготовленные и бизнес, и системные аналитики встречаются крайне редко. Проблему отсутствия необходимых компетенций в организации возможно решать, используя следущие подходы:
найти и принять на работу людей с необходимыми компетенциями. Это задача отдела управления персоналом;
обучить и развить навыки тех сотрудников, которые в настоящий момент уже работают в организации, должным образом простимулировав выполнение ими дополнительных обязанностей;
сформировать хорошо документированный процесс инженерии требований в организации, переносящий часть знаний, необходимых для выполнения соответствующей деятельности, в документированные процедуры.
В обучении и тренинге сотрудников, а также в разработке документированного процесса инженерии требований помощь может оказать компания, в которой я работаю, В3 Прожектс.
Комментарии (8)
porn
05.05.2024 09:57+4Вы зачем аж 5 раз это запостили?!
TVExpert
05.05.2024 09:57+5Мелкими кусочками.
Видимо есть расчёт, на то, что читатель так или иначе наткнётся на одну из частей, ему "станет интересно" и он (читатель) будет тратить своё время и "копать" ресурс в поисках остальной воды-водяной от данного автора.
WhatAboutSE Автор
05.05.2024 09:57Чтобы хватало терпения дочитать до конца.
white-wild
05.05.2024 09:57+3В итоге каждая часть выглядит незаконченной, обрубленной и вызывает некоторое недоумение.
Лучше одну полноценную статью.
WhatAboutSE Автор
05.05.2024 09:57Поскольку я на Хабр еще не писал, учту это пожелание. Разные платформы разным образом воспринимают длинные материалы.
TVExpert
05.05.2024 09:57+1Что мешало предварительно "осмотреться" ?
Хотя бы минимально "прощупать" поле, для которого готовится материал ?
Usage
Если в компании есть возможность отдавать специалистов на курсы, то у заказчика ( гос. структурах) такой возможности нет. И проблема встает ребром, за такую зарплату хоть кого найти чтоб делал. При написании технического задания если говорить про контракты с единственным исполнителем, заказчик чувствует более уверенно, так как ТЗ и технический замысел продумает исполнитель. В этой ситуации много подводных камней как при сопровождении контракта, так и дальнейшее сопровождение полученного продукта. А если конкурс, там заказчик начинает брать подобное ТЗ и как говорится «из говна и палок» начинает творить чудеса)). Результат всей деятельности зависит от разности ЗП специалиста данного уровня в компании и у гос. заказчика, что приводит к перекосу в среде гос. закупок. Заказчик чаще выбирает на разработку, модернизацию сложных систем единственного исполнителя, конкуретность падает из-за отсутствия конкурсов. И все это из-за кадрового голода в нынешней ситуации.
WhatAboutSE Автор
Согласен с вами. Как полагаете, что можно сделать в такой ситуации? Насчет гос. структур, то я проводил обучение в таких структурах, и полагаю, что не возможности нет, а желания.