Основные проблемы при работе с требованиями
Проблема №3. Не тот метод
Проблема дефицита времени и персонала, имеющего должную квалификацию и опыт, приводит к тому, что разработка требований приобретает характер легкий и незатратный. Всего-то необходимо взять ТЗ от прошлого похожего проекта, переписать под параметры нынешнего, и затем разослать всем, кого, так или иначе, касаются те или иные разделы ТЗ.
Среди тех, кому рассылается ТЗ, обязательно найдется как минимум один человек дотошный и придирчивый, от которого будет много замечаний, уточнений и исправлений. Это значит, что остальные из списка рассылки могут расслабиться и не особенно вчитываться или поручить «почитать» ТЗ кому-то, кто не очень занят в настоящий момент.
Потом разработчик ТЗ исправит все внесенные замечания, получит все подписи — согласования, утвердит ТЗ у начальства, которое его даже не будет читать, и передаст кому-то: в отдел закупок; или Заказчику, если ТЗ разрабатывалось под него.
Это метод? — да, это метод. Но это не тот метод, который приводит к хорошим требованиям и к хорошим результатам. На моих курсах по управлению требованиями один из слушателей рассказал о следующей ситуации. ТЗ было разработано именно так, как написано выше. Заказчик ТЗ согласовал. Систему разработывали в плотном контакте с Заказчиком, и разработанная система вполне Заказчика устроила. А вот когда стали разрабатывать программу и методику испытаний в соответствии с требованиями ТЗ, выяснилось: устраивающая Заказчика система и ТЗ не соответствуют друг другу. При этом ТЗ изменить по формальным причинам было невозможно (или нежелательно). Поэтому программу и методику испытаний разрабатывали вместо требований (а не в соответствии с ними), и по ней принимали готовую систему.
Подобный подход похож на метод техасского стрелка, когда сначала стреляют по амбару, а затем обводят кругами место, куда было больше всего попаданий.
Мы не знаем, сколько упущенных функций, черных лебедей и тривиальных ляпов в результате было в этой системе. Мы не можем прогнозировать, в какой момент, и в какой ситуации эта киберфизическая система поведет себя непредсказуемо. Но мы можем уверенно сказать — описанный выше метод плох.
На наших занятиях по управлению требованиями мы предлагаем другой метод:
сначала определить все заинтересованные стороны;
с заинтересованными сторонами, путем моделирования поведения, жизненного цикла, миссии, режимов и состояний будущей системы как можно тщательнее исследовать область проблем;
определить методы структурирования, формулирования, идентификации и прослеживания требований, и записать эти определения в формально принятый документ (стандарт на разработку требований);
разработать требования;
одновременно разрабатывать методы подтверждения требований;
верифицировать разработанные требования на соответствие стандарту;
валидировать разработанные требования и методы их подтверждения, вновь используя методы моделирования и методы валидации, связанные с групповым участием заинтересованных сторон.
Всему этому мы обучаем на курсах по управлению требованиями. И, если есть желание — помогаем внедрить данный подход путем оказания консалтинговых услуг.
Часть 4.
