Самая распространенная причина провала IT-проектов — это не баги, не плохие девелоперы и даже не токсичные клиенты. Это нечеткие, неполные или размытые требования. То, что на старте кажется «ну мы же договорились», превращается в бесконечные доработки, испорченные отношения и ощущение, будто ты постоянно что-то не учел. Формально все есть: встречи, заметки, документы. Но реальность — совсем другая. Клиент недоволен, команда демотивирована, а ты не можешь четко объяснить, почему все выглядит не так, как «ожидали».
В этой истории рассказываем, как один PM попал в эту ловушку — и как ему удалось из нее выбраться.
Как PM научился собирать требования так, чтобы больше никто не писал «это не то, чего мы ожидали»
Саша работает проектным менеджером в небольшой аутсорс-компании уже второй год. Вроде бы все хорошо: проекты есть, клиенты есть, команда работает. Но каждый старт нового проекта вызывал у него тревогу. Слишком знакомое чувство, когда ты запускаешь спринт, сдаешь первое демо — и клиент пишет:
«Это не то, чего мы ожидали. Почему вы не спросили раньше?»
И дальше — все по кругу: правки, митинги, фоллоу-апы, команда на грани, клиент — в отчаянии. Саша пытался все фиксировать в Google Docs, создавал Confluence-страницы, но этого хватало ровно до момента, когда клиент вспоминал:
«Мы же говорили, что будет по-другому».
В какой-то момент я начал бояться стартов новых проектов, потому что знал: что-то точно пойдет не так», — вспоминает Саша.
Одно забытое обсуждение — и контракт на грани срыва
Один из клиентов, крупный e-commerce из Штатов, на второй неделе разработки выразил «глубокое разочарование» из-за того, что их ключевой флоу выглядел не так, как обсуждалось. Проблема была в том, что это обсуждение вообще не было задокументировано. А Саша полагался на свои заметки и память. Клиент пригрозил расторгнуть контракт, и только быстрый rescue call со стороны CTO спас ситуацию.
Это был тот самый момент, когда Саша вечером пошел гуглить «как правильно собирать требования в проектах». Так он наткнулся на курс PM Hard Skills: Planning.
Обучение, которое изменило игру
На сайте IAMPM программа курса расписана достаточно подробно. Но после того, как Александр оставил заявку, с ним связалась менеджер. Саша думал, что она просто расскажет о стоимости, когда проходят лекции, что нужно подготовить. Но сначала менеджер выявила ключевые проблемы и убедилась, что курс действительно может их закрыть.
«Мы пообщались минут 8. Я хоть и был готов сразу покупать курс, мне было приятно, что менеджер узнала о моих потребностях и только подкрепила фактами, что обучение решит мои проблемы».
На курсе Саша сразу попал в среду практиков. Никакой воды — только кейсы, шаблоны и живые ситуации.
Особенно ему запомнились такие темы:
- Stakeholder Map + Project Brief. Теперь каждый проект он начинает с карты стейкхолдеров и утвержденного брифа, где фиксирует цели, KPI, ограничения и критерии успеха.
- Business Case vs User Stories. Он четко разделяет, что важно для бизнеса, а что — для пользователей. И не смешивает это в одно требование «где-то в чате».
- Discovery checklist и интервьюирование клиента. Теперь у него есть скрипт, как грамотно провести первый разговор с клиентом и извлечь максимум нужной информации.
- WBS + Scope Baseline. Научился декомпозовать фичи и фиксировать объем, а главное — согласовывать его до старта работ.
- И, конечно, шаблоны. Более 25 готовых документов, которые можно взять и сразу заполнять — без беготни по интернету в поисках примеров.
Что изменилось на работе
Через 3 недели после старта курса Саша начал использовать шаблоны в реальном проекте с новым клиентом. На демо они показали то, что было согласовано в Scope Baseline. Клиент сказал:
«Я чувствую, что мы с первого дня на одной волне».
Вместо эмоциональных правок — конкретные комментарии к конкретным User Stories. Вместо «вы не так поняли» — ссылка на Project Brief. Вместо паники — структура и контроль.
«Я впервые почувствовал, что могу управлять ожиданиями, а не бежать за ними», — говорит Саша.
Вывод
Александр начинает каждый проект с Discovery Checklist, stakeholder-анализа и фиксации scope. Он стал тем человеком, который знает, что и зачем он делает — и наконец не слышит фразы «это не то, что мы хотели».
Если вы тоже не хотите гадать, чего на самом деле хочет клиент — возможно, пришло время пройти PM Hard Skills: Planning. Хотите быть PM, который «надеется, что все получится», или PM, который строит процесс? Выбор за вами.