Когда в проекте начинаются проблемы с требованиями, чаще всего сначала смотрят на процесс. Не так описали задачу, не уточнили сценарии, плохо расставили приоритеты, забыли ограничения, не договорились о критериях готовности. Это всё действительно важно. Но, по моему, требования ломаются не только из‑за плохих шаблонов или небрежного описания задач.
Требования появляются не в вакууме. Сначала кто‑то должен поговорить с заказчиком, понять, что ему на самом деле нужно, отделить важное от второстепенного, задать неудобные вопросы, сверить ожидания с командой, учесть ограничения и не потерять смысл по дороге. И здесь мы спотыкаемся о банальный человеческий фактор.
Работа с требованиями сильно зависит от людей. От того, насколько заказчик готов объяснять свою задачу. Насколько команда понимает цель. Насколько разработчики готовы уточнять спорные места, а не молча брать в работу размытое описание. Насколько менеджер помогает с приоритетами, а не просто добавляет новые задачи сверху.
В таком случае нужно ли говорить, что плохие требования не всегда проблема одного аналитика? Иногда это симптом того, что в проекте вся система коммуникации работает плохо.
На примерах:
Если заказчик недоступен, требования будут неполными.
Если приоритеты постоянно меняются без объяснения причин, команда быстро перестанет воспринимать их всерьез.
Если люди не понимают, зачем делается задача, они будут выполнять ее формально.
Если в команде есть конфликты, важные детали могут просто перестать обсуждать.
И это только четыре возможных причины, в реальности их может быть куда больше.
Так как же демотивация команды влияет на качество продукта? Давайте разбираться.
Что в самих требованиях может влиять на мотивацию
Мне кажется, что мотивация команды при работе с требованиями часто начинается с очень простой вещи. Люди должны понимать, что именно они делают и зачем, но об этом часто забывают.
Когда требования полные и понятные, работать проще. У команды появляется опора. Можно разобраться в проблеме, увидеть зависимости, понять приоритеты и выбрать нормальное решение. В такой ситуации меньше ощущения, что ты идешь на ощупь и в любой момент выяснится, что половину задачи поняли неправильно.
Разумеется, хорошо описанные требования важны не только для аналитика, они помогают всей команде. Причем если вы имеете хорошо описанные требования, то если кто‑то из команды выпадает из процесса или подключается позже, ему не приходится восстанавливать всё по обрывкам переписок и чужим воспоминаниям.
Отдельно я бы выделила ясность требований. Это не совсем то же самое, что их подробность. Можно написать много текста, но всё равно оставить команду в неопределенности. Хорошее требование должно отвечать не только на вопрос «что сделать», но и на вопросы «для кого», «зачем», «при каких условиях» и «как мы поймем, что получилось правильно». Часто же бывает такое, что заказчик что‑то попросил, но сам не до конца понял, какую проблему решает своим запросом? Команда начинает уточнять, додумывать, возвращаться к обсуждениям, переделывать формулировки. Время уходит не на решение задачи, а на попытку понять, что вообще имелось в виду.
Ну и здесь мы спотыкаемся о самый неприятный эффект мутных требований. Команда может начать делать вообще не то.
Что еще может повлиять?
Масштаб проекта
Большие задачи могут мотивировать, потому что дают ощущение значимости. Когда проект заметный, сложный и влияет на многих пользователей, людям часто интереснее в него включаться. Появляется чувство, что ты делаешь не просто очередную мелкую доработку, а что‑то достаточно весомое.
Но сам по себе масштаб не спасает. Большой проект мотивирует только тогда, когда в нем есть структура. Если задача крупная, но при этом требования расплывчатые, приоритеты неясные, а участники постоянно тянут в разные стороны, масштаб быстро превращается не в источник энергии, а в источник хаоса.
Инструменты
На мотивацию влияют и инструменты, которыми команда пользуется для работы с требованиями. Я не про то, что нужно срочно внедрять очередную модную систему. Скорее про то, что людям проще работать, когда у них есть нормальные способы разобраться в задаче (схемы, прототипы, диаграммы, модели процессов, понятные шаблоны, удобные способы фиксировать изменения и так далее).
Инструменты здесь ценны не сами по себе, а как способ уменьшить неопределенность. Если схема помогает увидеть зависимость между требованиями, она полезна. Если прототип помогает заказчику понять, чего он на самом деле хочет, он полезен. Если шаблон превращается в формальность и только создает лишнюю работу, он уже не помогает.
Самый ценный фактор — видимый результат
Людей мотивирует, когда они понимают, что их работа кому‑то нужна. Когда продукт действительно решает проблему, заказчик доволен, пользователю стало проще, а команда видит, что усилия не ушли в пустоту.
Обратная ситуация демотивирует очень быстро. Если проект долго не приходит ни к какому завершенному результату, требования постоянно меняются, поставка откладывается, а команда не видит пользы от своей работы, интерес начинает падать. В какой‑то момент люди просто переключаются внутренне на другие задачи, потому что в этом проекте уже не чувствуют движения.
Плохие требования забирают у команды не только время. Они забирают уверенность, что работа вообще движется в правильную сторону.
Изменения требований не всегда зло, но многое зависит от момента
К изменениям требований часто относятся как к чему‑то однозначно плохому. Но я бы не сказала, что любое изменение автоматически ломает работу.
Иногда изменения действительно помогают. Заказчик лучше формулирует свою потребность, команда уточняет ограничения, появляются новые детали, которые раньше были неочевидны. В таком случае изменение требований может быть нормальной частью движения к более точному решению. Особенно если оно приходит вовремя и понятно, зачем оно нужно.
Но есть и другая сторона. Когда требования начинают постоянно меняться ближе к концу работы, это воспринимается уже совсем иначе. Команда успела вложить силы, что‑то спроектировать, реализовать, обсудить, возможно, протестировать. И тут внезапно появляются новые вводные, новые идеи, новые «давайте еще вот это добавим».
В такой ситуации изменение требований перестает выглядеть как уточнение. Оно начинает восприниматься как обесценивание уже сделанной работы.
Мне кажется, здесь хорошо видно различие между ролями. Для аналитика или менеджера изменение требований может выглядеть как естественная часть поиска правильного решения. Для разработчика или технического лида это часто выглядит как переделка, нарушение плана и дополнительная нагрузка, которая мешает текущей работе. И, если честно, со стороны разработки, даже для меня это иногда выглядит как издевательство над твоим трудом.
Неполные требования и плохая приоритизация бьют не только по срокам
Когда команда не понимает задачу целиком, появляется постоянная неопределенность. Непонятно, какие есть зависимости, что уже решено, что еще нужно уточнить, какие ограничения важны, а какие можно не учитывать. В итоге работа начинает буксовать: люди не могут нормально двигаться дальше, потому что любое решение может оказаться неправильным.
Это неприятное состояние. Ты вроде бы занят, но при этом не уверен, что делаешь нужную вещь. Постоянно приходится возвращаться к вопросам, которые должны были быть прояснены раньше.
Плохая приоритизация действует похожим образом. Если команда не понимает, что важнее, она легко начинает распыляться. Особенно плохо, когда задачи копятся, а потом в конце итерации внезапно оказывается, что нужно сделать всё сразу.
Технические ограничения нужно обсуждать раньше
Отдельная проблема возникает, когда ожидания заказчика расходятся с технической реальностью.
На раннем этапе у всех может быть красивая картинка будущей системы. Заказчик представляет одно, аналитик фиксирует это в требованиях, команда обсуждает возможное решение. Но потом выясняется, что часть идей плохо ложится на архитектуру, требует больше времени, конфликтует с уже существующими зависимостями или вообще не может быть реализована в том виде, в котором ее ожидали.
Поэтому технические ограничения лучше поднимать как можно раньше. Не после того, как ожидание уже продано заказчику, а на этапе обсуждения требований. Иначе команда получает не просто сложную задачу, а задачу с уже сформированными ожиданиями, которые теперь нужно болезненно менять.
Требования зависят от общения не меньше, чем от документов
Чем дальше, тем больше мне кажется, что требования нельзя рассматривать отдельно от общения. Можно написать хороший шаблон, завести правильные поля, договориться о структуре задачи. Но если люди плохо разговаривают друг с другом, требования всё равно будут страдать.
Для работы с требованиями важно, чтобы аналитик понимал заказчика, заказчик был готов объяснять контекст, разработчики могли задавать вопросы, а команда не боялась обсуждать спорные места. Это звучит очевидно, но на практике часто именно здесь всё и ломается. Особенно заметно это в распределенных командах, при работе с заказчиками из другой страны или предметной области, где люди используют разную терминологию.
Иногда проблема даже не в языке как таковом, а в том, что стороны вкладывают разные смыслы в одни и те же слова. Заказчик говорит привычными для себя терминами, команда слышит их по‑своему, и в результате требование вроде бы согласовано, но понято неправильно.
Команда тоже влияет на качество требований
Требования это не только зона ответственности аналитика. На них сильно влияет вся команда.
Если в команде есть люди, которые хорошо понимают предметную область, технические ограничения и свою роль, требования становятся точнее. Такие люди помогают задавать правильные вопросы, замечать противоречия, проверять реалистичность решений и не упускать важные детали.
С ответственными и вовлеченными участниками проще работать. Они не просто берут задачу как написано, а стараются понять, что за ней стоит. Это особенно важно в сложных проектах, где требования не всегда можно идеально сформулировать с первого раза.
Заказчик может быть источником ясности, а может быть источником хаоса
Роль заказчика в требованиях часто недооценивают. Хотя именно от него во многом зависит, насколько быстро команда поймет реальную задачу.
Хороший заказчик не обязан разбираться в разработке. Но он должен понимать свою проблему, быть доступным для вопросов, помогать с приоритетами и давать осмысленную обратную связь.
Когда заказчик включен в процесс, команде проще. Можно быстрее уточнять спорные места, проверять гипотезы, понимать предметную область и принимать решения.
Когда заказчик недоступен, противоречив или сам не понимает, чего хочет, работа с требованиями превращается в угадывание. Команда ждет ответов, возвращается к одним и тем же вопросам, спорит о трактовках и постепенно теряет интерес к проекту.
Особенно тяжело, когда заказчик не просто не помогает, а создает постоянное давление: меняет ожидания, не принимает решения, не слушает аргументы или просит «добавить еще вот это», не объясняя, какую проблему это решает.
Поэтому плохие требования часто появляются не в момент написания задачи. Они появляются раньше, в точке, где команда и заказчик не смогли нормально договориться.
Что с этим можно делать?
Мне кажется, требования нельзя улучшить только новым шаблоном. Шаблон может помочь, но он не починит коммуникацию, приоритеты и доверие внутри проекта.
Если требования постоянно ломаются, я бы смотрела на несколько вещей:
Понимает ли команда, зачем делается задача. Не только что нужно реализовать, а какую проблему это должно решить.
Можно ли быстро получить ответы от заказчика. Если за каждым уточнением нужно ждать неделю, требования неизбежно будут неполными.
Объясняются ли причины изменений. Одно дело, когда команда понимает, почему изменился приоритет или сценарий. Другое дело, когда изменения просто прилетают сверху.
Есть ли нормальная приоритизация. Если всё важное, значит, по сути, важного ничего нет.
Обсуждаются ли технические ограничения до того, как ожидания уже проданы заказчику. Чем позже всплывает ограничение, тем болезненнее его объяснять.
Можно ли в команде спокойно задавать вопросы и спорить по смыслу. Если люди боятся уточнять, требования будут выглядеть согласованными, но внутри останутся пустые места.
Ну и, как микровывод, могу сказать что редко плохие требования возникают из‑за одного человека. Часто это результат сломанной цепочки взаимодействия в проекте. Поэтому крайне важно, чтобы команда умела договариваться и принимать решения.
Хотите системно прокачаться в работе с требованиями, бизнес‑контекстом и коммуникацией между заказчиком и командой? Посмотрите курс «Системный и бизнес‑анализ». Он подойдет тем, кто хочет не просто фиксировать задачи, а разбираться в реальных потребностях бизнеса, моделировать процессы, выявлять противоречия и превращать разрозненные вводные в понятные требования для разработки.
А также приходите на бесплатные открытые уроки. На них можно разобрать практические подходы к работе с требованиями, процессами и архитектурой решений, задать вопросы преподавателям‑практикам и понять, какие инструменты помогают наводить порядок в проектном хаосе:
— 14 мая. 18:00. «Графическое описание бизнес‑процессов и требований». Записаться
— 2 июня. 20:00. «Объектная модель без боли: как превратить хаос требований в стройную архитектуру». Записаться
📌 А если интересует системное развитие в аналитике, моделировании процессов и работе с требованиями, посмотрите каталог курсов OTUS по аналитике и анализу.