PRO "требования-зомби"

или ошибки при составлении пользовательских требований Помните тот проект? Тот самый, где команда вложила недели, а фича легла на полку мертвым грузом🗃 Где разработчики переписывали код по несколько раз. Где заказчик в итоге сказал: "Это не то, что я хотел!" 🤦‍♂ Я тоже помню. На прошлом месте работы я был full-stack'ом: и требования собирал, и ТЗ писал, и с разработкой работал, но требованиями я занимался больше всего времени. Тогда я усвоил на собственном опыте, что требования - это про "ЗАЧЕМ" и "ЧТО" ⚠, а не про "КАК". Сейчас, смотря на требования со стороны системного анализа, я вижу: требования про "КАК" - это 💣 под проектом: техдолг растёт, сроки срываются, а команда теряет время на переделках вместо создания ценности. Вроде бы всё просто: аналитик собирает требования, команда реализует — пользователи счастливы. Но почему тогда снова и снова: ✔ делают фичу, которой никто не пользуется; ✔ реализуют не то, что нужно; ✔ получают «требования», в которых больше про кнопки, чем про смысл? Всё дело в 4 коварных ловушках: 1 Design Fixation: Когда "влюбляются" в одно решение (часто первое) и слепо его проталкивают, игнорируя суть потребности. Пример: "Вставьте здесь калькулятор!" (Вместо "Пользователю нужно быстро оценить стоимость") 🧟 2 Solution Jump: Мгновенный прыжок с "у нас проблема" на "давайте сделаем вот этот конкретный скрипт/интерфейс/интеграцию" 🚀 ⁠3 Premature Solutioning: Преждевременное погружение в технические детали до понимания масштаба и целей. Рождает монстров в спецификациях ⏱ 4 Over-specification / Lack of Abstraction: Неумение отделить "ЧТО" от "КАК". Требования превращаются в техническое задание.🌀 💡 В ближайших постах — коротко, на историях и с примерами — разберу, как эти ошибки выглядят в реальности, как их избежать и что с ними делать, если они случились. —— Всем proдуктивной недели! 💪 #PROтребованния #требования