Определение scope

Как очертить объём проекта так, чтобы было понятно, что входит в текущий контур работ, а что не входит и требует отдельного решения

Эту страницу открывают, когда проект начинает расползаться: новые пожелания приходят быстрее, чем команда успевает фиксировать границы, а разговоры о сроках и ресурсах уже невозможно вести без раздражения.

Определение scope — это центральная часть рамки проекта. Без неё невозможно нормально вести планирование, работу с ресурсами, управление изменениями и большую часть переговоров со стейкхолдерами.

Что это за компетенция

Scope — это управляемая граница проекта: что входит в текущий контур поставки, что сознательно не входит, какие допущения приняты и при каких условиях объём может быть пересмотрен.

Сильный scope нужен не для того, чтобы «запрещать всё новое», а для того, чтобы любые изменения были видимыми, обсуждаемыми и управляемыми.

Зачем нужна

Навык нужен, чтобы:

  • не смешивать обязательный объём и будущие пожелания;
  • делать оценку и план реалистичнее;
  • объяснять, почему любое расширение имеет цену;
  • удерживать границы проекта при внешнем давлении;
  • связать работу команды с осознанным объёмом результата.

Где проявляется в реальной работе

Навык особенно важен:

  • на старте проекта;
  • при работе с требованиями;
  • во время перепланирования;
  • при обсуждении change request;
  • в проектах с высокой неопределённостью или большим количеством участников.

В аутсорсе scope часто связан с договором и ожиданиями клиента.

Во внутреннем проекте scope чаще размывается из-за неформальных договорённостей и «раз уж делаем, давайте добавим ещё».

Что ломается без неё

  • команда делает больше, чем планировала, но всё равно выглядит отстающей;
  • заказчик не понимает, почему новое пожелание влияет на сроки;
  • PM не может показать границу текущей поставки;
  • план и бюджет теряют устойчивость;
  • требования и приоритеты начинают конфликтовать друг с другом.

Что можно делегировать, а что нельзя

Нельзя делегировать ответственность за определение и удержание управленческой границы проекта.

Можно делегировать:

  • сбор входных требований для scope;
  • детализацию технических последствий изменения объёма;
  • оформление артефакта в документе.

Как выглядит слабый уровень

  • scope нигде явно не описан;
  • есть только backlog, где всё смешано в одном списке;
  • out of scope не зафиксирован вообще;
  • любое новое пожелание легко просачивается в работу без решения о последствиях.

Как выглядит сильный уровень

  • есть понятное описание, что входит и что не входит;
  • граница связана с целью проекта и результатом;
  • изменения проходят через явный управленческий контур;
  • у команды и стейкхолдеров единое понимание текущего объёма;
  • по каждому расширению можно обсудить цену и компромиссы.

Как понять, что это ваш пробел

  • можете ли вы письменно перечислить, что входит в текущий проектный контур;
  • есть ли отдельно список того, что сознательно не входит;
  • видно ли, как новые пожелания влияют на сроки и ресурсы;
  • есть ли у команды ощущение, что объём постоянно меняется без точки решения.

Что делать пошагово

1. Свяжите объём с целью и результатом. 2. Зафиксируйте, что входит в текущую поставку. 3. Отдельно перечислите, что не входит и почему. 4. Добавьте ключевые допущения, ограничения и зависимости. 5. Определите, как будет оформляться изменение объёма. 6. Синхронизируйте scope с планом, документами и статусной коммуникацией.

Рабочий шаблон

Полезно держать scope в пяти блоках:

  • входит в проект;
  • не входит в проект;
  • ограничения;
  • зависимости;
  • правила изменения объёма.

Типовые ошибки

  • считать, что scope = весь backlog;
  • не фиксировать out of scope;
  • соглашаться на расширение без пересмотра базового плана;
  • хранить границу проекта только в голове PM;
  • бояться называть лишнее лишним.

Как качать навык

Связанные материалы