
Astra inclinant, non necessitant
В школе и вузе нас учат решать задачи, быть исполнителем. А вот быть заказчиком, ставить задачи, никто не учит. Из-за этого типичный руководитель проектов постоянно сталкивается с некачественными постановками. В этой статье поговорим, как с такими постановками работать, не посылая заказчиков, но и не беря на себя большие риски.
Проблема плохих постановок
В целом, управление ожиданиями, важнейшая часть работы пиэма начинается с постановки задачи от заказчика. А заказчик не то, что не умеет ставить задачи, он вообще, плохо представляет, что хочет. В лучшем случае, у него есть видение цели, но не более.
Поэтому он поставляет вам не постановки, а галлюцинации.
Возможные действия неопытного пиэма
Здесь у вас, как у исполнителя, есть несколько вариантов, что делать:
- Посылать. Если вы работаете в большой компании, в которой можно затеряться, может и прокатить. У вас есть все формальные основания — на основании такой постановки ничего оценить нельзя, заказчику отказать. К сожалению, вы столкнётесь с проблемой ещё не раз и если постоянно будете посылать заказчика, вами быстро заинтересуется PMO и уволит в два счёта.
- Принимать галлюцинации в работу. Сейчас бы ввязаться в бой, а там будет видно. Делать всё, чтобы понравиться заказчику и выстроить с ним хорошие отношения. Неплохо работает в начале проекта, но уже к середине станет понятно, что реализовать всё, что хочет заказчик, невозможно, не хватит ресурсов. А в конце выяснится, что реализовали не пойми что и виноваты, конечно, вы. И вас снова уволит PMO.
- Задавать вопросы и тянуть время. Устраивать бесконечные консультации и синхронизации, привлекать аналитиков, запрашивать кейсы, в общем, прокрастинировать как профессионал. Но тут вы перекладываете на заказчика, ждёте, что он предоставит нормальную постановку, а у него только мутное видение. Тоже не катит.
Метод допущений и ограничений
Этот метод — отличный инструмент для доделки полученных галлюцинаций и превращения их в подобие ТЗ, годное для оценки. Он нужен для установки того, что сейчас называется модным словом «границы». Только не личные, а границы проекта.
Допущения — это инструмент, определяющий, что делать надо.
Ограничения — это инструмент определяющий, что делать не надо.
Примеры допущений:
- Вы по опыту знаете, что затребованный проект потребует длительных согласований, где-то на три месяца, а просят сделать этап за две недели. Вы не посылаете заказчика, а прописываете допущение, что все департаменты согласуют всё за две недели.
- Пора стартовать проект, но ресурсное ведомство всё ещё не выделило команду. Вы прописываете допущение, что команду таки выделят, либо дадут денег на аутсорс.
- Поставили задачу сделать аналогично, но чуть более усложнённый вариант, а вы прописываете по пунктам все усложнения, их состав и требования к ним.
Примеры ограничений:
- Вас попросили об аналогичной фиче, вы же прописываете в ограничениях конкретику, что она будет без интеграции со сторонними сервисами.
- Заказчик просит реализовать эквайринг, вы прописываете, что будет работать приём платежей только по СБП, а Яндекс пей, Альфа пей, Сбер пей не будут поддерживаться, по крайней мере, в первой итерации.
После того, как сформулировали допущения и ограничения и согласовали с заказчиком, идёте к лидам компонентов за оценкой. Если они задают вопросы — формулируете дополнительные допущения или ограничения и пускаете согласование по второму кругу.
Потом применяете волшебные формулы с рисками и буферами, передаёте итоговый документ с оценкой, допущениями и ограничениями заказчику для итогового согласования.
Как только Заказчик утверждает такую оценку — объем согласован, и вы молодец.
Ваши допущения и ограничения не меняют видение заказчика и не противоречат ему, они его детализируют.
Всё должно быть оформлено письменно.
Так мы из размытого ХЗ сделали что-то вроде детализированного ТЗ. Хотя до полноценного ТЗ ещё далеко, но уже что-то.
Как использовать метод не нужно.
В общем, не увлекайтесь. Не надо записывать каждую мелочь, это инструмент для структурирования мышления заказчика, а не воплощения вашей тревожки. Простой способ понять, надо ли записывать данное допущение или ограничение — сделайте мысленную оценку в деньгах, разберитесь, насколько сильно оно влияет на проект. Если там речь о нескольких десятках или даже сотнях тысяч рублей, оно того не стоит, просто заложите в риски.
Если у вас получилось больше пятнадцати допущений, есть смысл реально провести ещё одну сессию с заказчиком и сузить круг. Если не получится — будет аргумент для выделения дополнительных денег на проработку ТЗ.
Резюме
Допущения и предположения позволяют вам:
- Не посылать заказчика, подставляя под удар свою карьеру;
- Быстро реагировать на прилетающие требования;
- Находиться в более конструктивной позиции, чем применяя методы из начала статьи;
- Корректно управлять ожиданиями.
Главный вывод такой, что «это невозможно» — плохой подход. Намного лучше подход: «это возможно, при таких-то условиях». Или, как говорят хорошие юристы: «это возможно, но будут такие-то последствия».