Открываю портал в дискуссию на тему “Надо ли читать “Проектирование требований к ПО” К. Вигерса и Дж. Битти в 2024 году?”

Напишу свое мнение по этому поводу.

Это фундаментальная книга с подробным описанием базовых паттернов проектирования ПО. Пять лет назад я была уверена, что эта книга должна быть обязательной для всех IT-специалистов, а не только для аналитиков. В ней описано, как подходить к разработке так, чтобы не переделывать или закрывать продукты сразу после релиза. Книга предлагает системный подход к проектированию и помогает оптимально выстроить процесс работы: сначала разобраться, что и зачем нужно сделать, и только потом приступать к работе. Об этом я даже писала статью.

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

Также сильно изменились требования к аналитикам. Сейчас от нас больше ожидают умение описать контракты API, структуры БД и интеграционные схемы. А разобрался ли аналитик, нужен этот функционал бизнесу или нет - беспокоит далеко не всех нанимающих менеджеров. Во время последних поисков работы в 2021 году про процесс разработки требований меня спросили где-то в 5 компаниях из 10.

На мой взгляд это не очень хороший тренд. На практике, какие бы амбициозные цели менеджеры не ставили - что-то серьезное меньше чем за полгода-год запустить не получается. В этот срок вполне можно поместить вдумчивое проектирование. Но вместо этого разработка идет по рваному скачкообразному процессу, где за день до релиза выясняется, что не сделан большой и важный кусок, без которого вообще никак. Релиз откладывается на 2 месяца, а в конце этого срока история повторяется.

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

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

А вы как считаете, нужна ли сегодня эта книга и описанные в ней приемы? И часто ли вы сталкиваетесь с неприятностями, которых можно было бы избежать, выдели команда больше времени на проработку требований?