+38 (093) 580-29-22 info@lokhnin.com

Разработка требований — очень важный этап в любом проекте разработки программного обеспечения. Да и в любом другом проекте — тоже самое. Если допущена ошибка в постановке задачи, то даже при 100% качественном выполнении требований, цель проекта достигнута не будет. С требованиями нужно работать очень аккуратно.

software-requirments

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

С моей точки зрения существует две существенные проблемы разработки требований:

  • туманные спецификации — очень часто прочитав техническое задание вообще непонятно что нужно сделать. Особенно сильно этим страдают специалисты по 1С, которые находятся в прямом контакте с пользователем. На втором месте — сторонники гибких методологий. Такой подход работает, но далеко не всегда. Никто не будет разрабатывать программную систему для управления полётами без детальных спецификаций;
  • организационные проблемы — заказчики почему то считают, что времени на сбор требований и разработку архитектуры должно уйти очень немного. Даже если нужно разработать комплексную корпоративную информационную систему более чем на 1000 пользователей. И это вызывает огромнейшие организационные проблемы.

Туманные спецификации

Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты. Это просто факт. В 99% случаев, команда, которая работает над сбором требований и определением спецификации к системе никак не мотивирована на решение конфликтов!

Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации. Или на худой конец – валить проблемы спецификаций на заказчиков. Никто никогда даже не пытается выявить и решить конфликты на этапе сбора требований!

Мой опыт проектного менеджмента подсказывает, что нужно приложить все возможные усилия для работы с рисками ДО начала проекта, а не делать «туманную спецификацию» и оставлять решение проблем «на потом». Более подробно: про управление рисками с точки зрения РМВоК.

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

Организационные проблемы

Очень часто заказчик системы до конца не понимает что именно он хочет. При этом внедрить систему нужно «внезапно». «Внезапно» — новое слово в определении дедлайна (наконец то заказчики начали уходить от термина «нам нужно ещё вчера»).

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

Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу). Возникает парадокс: чтобы закончить проект с меньшими сроками и трудозатратами – нужно недогружать ресурсы.

Кстати, к такому же выводу пришёл и Голдратт в своей теории ограничений. Обеспечивать максимальную загрузку нужно только «узкого горлышка». Вся организация «по сути» должна работать на это ограничение. Загрузка других подразделений (функций) приведёт только к негативным последствиям.

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