Основные проблемы при работе с требованиями
Проблема №4. Не те источники
Как уже упоминалось, проблемы при работе с требованиями не существуют изолированно: каждая из них проявляется вследствие других проблем, одновременно усиливая отрицательные воздействия и порождая новые следствия.
Так как же формируется проблема неверного и неполного определения источников требований? Исходя из предыдущих статей, определением источников требований занимаются:
сотрудники, не имеющие должного опыта, и не обученные должным образом,
сотрудники, не располагающие достаточным временем,
сотрудники, не вооруженные правильным методом.
Не удивительно, что эти сотрудники выбирают легкие и быстрые пути: взять ТЗ/спецификацию от прошлого подобного проекта, и определить этот документ, как основной источник требований. На самом деле факт привлечения прошлого опыта к текущему проекту не является проблемой. Проблемой является то, что на этом поиски источников требований завершаются. Но прошлый проект не является полной копией текущего проекта. Несмотря на схожесть с прошлым, новый проект содержит в себе новые требования Заказчика: улучшенные параметры, расширенные потребности в функциях, изменившийся контекст системы. За прошедшее время изменились также стандарты и доступные технологии.
Не было требований к интегрированной логистической поддержке, а они появились.
Не было требований к стоимости и другим параметрам жизненного цикла, а они появились.
Не было требований к выполнению процессов разработки, а они возникли.
И заимствованное «старое» ТЗ развивается в режиме «лоскутного одеяла», когда несистемно, и, зачастую, случайно, в него добавляются разделы, которые содержат в себе противоречащие требования. Обнаруживаются эти противоречия только в момент приемки системы.
При разработке информационных систем часто возникает следующая ситуация: Заказчик сообщает, что его специалисты и так перегружены работой, однако отвлекать их нет необходимости. Есть человек, который будет «точкой входа», задавайте все вопросы ему. Этот человек сам в удобное время расспросит нужных людей, и пришлет вам ответ. Далее события развиваются весьма предсказуемо:
«точкой входа» со стороны Заказчика назначается не очень опытный специалист, не особо загруженный важной работой (или, наборот, очень опытный специалист, перегруженный важной работой);
потребности множества заинтересованных сторон подменяются представлением об эти потребностях, которое формируется в голове «точки входа»;
важнейший инструмент получения требований от людей, открытые вопросы, становится недоступен, поскольку «точка входа» требует конкретных вопросов;
ответы на заданные вопросы изобилуют загадочными формулировками и терминами, а просьбы разъяснить, что имелось в виду, только усложняют ситуацию;
и, в итоге, если у «точки входа» есть явно ошибочное мнение или представление об обсуждаемом вопросе, поправить его некому.
Итогом данной ситуации обычно является разработка системы на основе неполных требований, и результат, как всегда, обнаруживается в лучшем случае во время приемки системы. Обнаружение упущенных требований во время эксплуатации системы является гораздо более неприятным исходом.
Часть 5. Не тот инструмент
