Основные проблемы при работе с требованиями

info@vsetut.pro

О проекте

Вернуться

05.05.2024 10:15:39 | Хабр

Хабы: Управление разработкой, Управление продуктом, Управление проектами

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

Среди тех, кому рассылается ТЗ, обязательно найдется как минимум один человек дотошный и придирчивый, от которого будет много замечаний, уточнений и исправлений. Это значит, что остальные из списка рассылки могут расслабиться и не особенно вчитываться или поручить «почитать» ТЗ кому-то, кто не очень занят в настоящий момент.

Потом разработчик ТЗ исправит все внесенные замечания, получит все подписи – согласования, утвердит ТЗ у начальства, которое его даже не будет читать, и передаст кому-то: в отдел закупок; или Заказчику, если ТЗ разрабатывалось под него.

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

Подробнее