🔤🔤🔤 "требования-зомби" или ошибки при составлении пользовательских требований

Помните тот проект? Тот самый, где команда вложила недели, а фича легла на полку мертвым грузом🗃 Где разработчики переписывали код по несколько раз. Где заказчик в итоге сказал: "Это не то, что я хотел!" 🤦‍♂️

Я тоже помню. На прошлом месте работы я был full-stack'ом: и требования собирал, и ТЗ писал, и с разработкой работал, но требованиями я занимался больше всего времени. Тогда я усвоил на собственном опыте, что требования - это про "ЗАЧЕМ" и "ЧТО" ⚠️, а не про "КАК".

Сейчас, смотря на требования со стороны системного анализа, я вижу: требования про "КАК" - это 💣 под проектом: техдолг растёт, сроки срываются, а команда теряет время на переделках вместо создания ценности.

Вроде бы всё просто: аналитик собирает требования, команда реализует — пользователи счастливы.

Но почему тогда снова и снова:
✔️ делают фичу, которой никто не пользуется;
✔️ реализуют не то, что нужно;
✔️ получают «требования», в которых больше про кнопки, чем про смысл?

Всё дело в 4️⃣ коварных ловушках:

1⃣ Design Fixation: Когда "влюбляются" в одно решение (часто первое) и слепо его проталкивают, игнорируя суть потребности.
Пример: "Вставьте здесь калькулятор!" (Вместо "Пользователю нужно быстро оценить стоимость") 🧟

2⃣ Solution Jump: Мгновенный прыжок с "у нас проблема" на "давайте сделаем вот этот конкретный скрипт/интерфейс/интеграцию" 🚀

⁠3⃣ Premature Solutioning: Преждевременное погружение в технические детали до понимания масштаба и целей. Рождает монстров в спецификациях ⏱️

4⃣ Over-specification / Lack of Abstraction: Неумение отделить "ЧТО" от "КАК". Требования превращаются в техническое задание.🌀

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

——

Всем proдуктивной недели! 💪

✌️ PRO SA |👍 ОТЗЫВЫ |👩‍🎓 НСА 2.0

#PROтребованния #требования