Используя Метод для запуска проектов последний год, я собрал в достаточном количестве ошибки заполнения Устава Проекта, чтобы поделиться с вами в этой статье.
Самая частая ошибка, которую я замечаю в профессиональной, и не только, деятельности, связана с запусками проектов. А точнее с незапусками проектов. Почему-то люди считают что для того, чтобы запустить проект, нужно много всего подготовить предварительно, написать ТЗ, сформулировать БРИФ, посчитать бюджет, да и вообще, сделать предпроектную подготовку!
Однако
Бывает только один случай, когда действительно есть предпроектная подготовка – когда нужно подготовить предложение в рамках сотрудничества по созданию продукта на заказ (заказная разработка). Получается есть проект, в результате которого будет подготовлен ТЗ или БРИФ, необходимый заказчику для определения границ проекта и необходимости продукта.
История
Не так давно я познакомился с Уставом проекта (project canvas) из Метода Пульса и начал его применять в работе, в менторстве, а так же я провел много мастер-классов в Нетологии. Ранее уже упоминал про самую частую ошибку – незапуск проекта до подготовки, а вот вторая по частоте ошибка – это запуск проекта без устава проекта! Да, да, люди начинают работать иногда без цели и смысла, иногда без формирования требований, бюджета и всего, что нам нужно для фокусировки и понимания контекста, и из-за этого часто появляются скрытые цели, увеличивается объем проекта и затягиваются сроки.
В процессе написания статьи я понял, что есть еще проблемы с ведением проектов в принципе. И если коротко, то я считаю, надо максимально быстро инициировать проект, как только нужны действия и результаты в каком-то направлении, независимо от количества людей, наличия информации и т.п. Но об этом, может, напишу позже, но сейчас мы рассмотрим самые частые ошибки, которые допускают люди при запуске проекта, а именно при заполнении устава проекта и постановки цели проекта.
Самые частые ошибки заполнения шаблона устава проекта
Топ-10 самых частых ошибок заполнения устава проекта:
- Указание действия вместо конкретного результата в блоке “Что” раздела “Цель”
Людям, видимо, свойственно мыслить действиями, а не результатом. Но в этом блоке важно написать именно результат действий, без глаголов.
- В “Критерии Завершения” пишут критерий, который зависит не только от нас
Важно понимать, что есть границы как у проекта, так и у команды проекта. Поэтому важно в “Критерий Завершения” указывать конечную точку проекта, которая находится в зоне ответственности команды.
- В “Критерии Завершения” указывают “Критерий Успеха”
Очень часто путают успех и завершение проекта и не могут определить, в чем между ними разница. Самое основное, успех зависит не только от наших действий, завершение зависит только от наших действий.
- “Характеристики (требования) результата” воспринимают как план проекта
Устав проекта, как договор, создается до любой деятельности по проекту, а планирование проекта, это и есть деятельность. Поэтому план не надо строить до запуска. В требованиях нужно лишь перечислить именно требования, которым должен соответствовать конечный результат для заказчика.
- Указывают в блоке “Материальные ресурсы” вещи необходимые, но еще не существующие
Эта ошибка опять же относится к планированию проекта, но для старта проекта нужно лишь указать то, чем располагаем в данный момент времени. То есть какие у нас ограничения на ресурсы.
- “Масло масленное” – блоки “Что” и “Зачем” не отличаются по смыслу
Часто пишут: “Сделать что-то для того, чтобы было”. При этом “Зачем”, то есть смысл, не раскрывается. Блок “Зачем” нужен ведь для того, чтобы команда понимала “А нафига?”. Пока тебе ставят задачи без пояснения “Зачем”, у тебя почти никогда не будет мотивации.
- Блоки “Что” и “Критерий Завершения” не соотносятся друг с другом
Поскольку результат проекта и его завершение напрямую в зоне ответсвенности команды, значит эти блоки следует проверять на связанность и логичность. Так же сам критерий нам говорит о том, нужно еще “копать” или уже можно “не копать”.
- Блоки “Зачем” и “Критерий Успеха” не соотносятся друг с другом
Поскольку смысл проекта и его успех не в зоне ответсвенности команды, значит эти блоки связаны на уровне границ ответственности, и следует их проверять на связанность между собой. Так же сам критерий нам говорит о том, насколько мы попали в “зачем” или нет.
Ошибки применения устава
Давайте детальнее разберем главные ошибки
Использование глаголов
И так, самая распространенная ошибка среди все ошибок заполнения устава проекта, которую я наблюдаю и при обучении студентов и при работе с коллегами, это использование глаголов (действий) в блоке “Что” Устава проекта. Если мы посмотрим на тот же PMBOK, то увидим там такое определение, как:
Проект – временно́е предприятие, направленное на создание уникального продукта, услуги или результата.
PMBOK, 2013
Получается, что целью проекта должен быть конкретный результат, конкретный продукт или оказанная услуга. Еще Стивен Кови писал в своей книге “7 навыков высокоэффективных людей”, что надо начинать любое действие, представляя конечный результат.
Во время заполнения устава проекта начинают планировать проект
Подбор людей, поиск ресурсов, закупка оборудования, определение бюджет, оценка сроков и т.п. Все это – этапы и список работ по самому проекту. Не существует предпроектной подготовки. Звучит абсурдно, но любые действия для достижения результата – это уже действия для достижения результата, а следовательно, работы по самуму проекту. Не понимаю, почему люди не понимают этого.
Устав проекта это граница, это договор, который составляется перед началом любой деятельности. Это как “договорится на берегу” перед тем, как идти в далекое плавание. Поэтому важно составлять устав проекта с верхнеуровневыми требованиями, целями, угрозами и ресурсами. Без всякой “предпроектной” подготовки.
Во время заполнения участников проекта, начинают поиск людей
А нужно указать людей, которые будут ответственны за подбор команды. В идеале конечно иметь свободную команду высокомотивированных профессионалов, готовую сразу же начать делать проект. Но в жизни так почти никогда не бывает. Поэтому подбор команды должен быть запланирован в саму работу по проекту, а не до него.
Участники не могут договориться о единственной цели и результате
Сколько было встреч и переговоров, когда у каждой заинтересованной стороны были свои интересы, и никто не был готов прийти к единому мнению. Поэтому очень важно в блоке “Цель” в каждой области писать только по 1 предложению. Только один стикер.
Важно прийти к общему понимаю необходимого результата от проекта, чтобы все участники и заинтересованные стороны понимали одинаково суть проекта, его требования, угрозы и весь контекст.
Ошибки проведения мероприятия по запуску проекта
Текст с нескольких метров уже не виден
В итоге они загибаются, и их тоже становится не видно
Как результат, цель может не соответствовать причинно-следственным связям, логичности и как следствие, может быть не достижима
Дело в том, что устав проекта, это договор между заинтересованными сторонами – исполнителями и теми, кто заказывает работу. Поэтому при заполнения устава проекта должны присутствовать все стейкхолдеры, грубо говоря заказчики, и все исполнители или хотя бы лидеры от всех направлений
Коллекция плохих целей
- Сделать, чтобы сделать
- Сделать все, что запланировали
- Сделать 1-ую юзер историю
- Зарелизить X
- Сделать SSO в прод
- Добавить оповещения, изменения вида к существующему календарю на портале обучения
- Настроить дев окружение и тулы для разработки и деплоя API
- Релиз мобильного приложения в testFlight
- Сэкономить бизнесу 30 тыс руб ежемесячных платежей за счёт переезда на новый прод
- Освободить учредителей от обслуживания клиентов за счёт автоматизации
- Снизить расходы на обслуживание
- Подготовить инфраструктуру к масштабированию
- Повысить customer satisfaction за счёт оптимизации UX
- Сдать проект Х и выдать Продакт Оунера замуж
- Снизить себестоимость продукта на Х%
- Получить N лидов из канала Х не дороже Y рублей
- Забетонировать подушку… с приемкой ГИПом
- Клиент успешно может оформить X продукт в процессе открытия счета
Почти все они содержат действия вместо описание результата. Так же часто встречается конкретное решение (способ достижения). Отсутствуют критерии успеха и завершения, не понятен смысл проекта, а зачем?
Примеры корректного заполнения блока “Цель”
- Мы делаем “SSO готовое к нагрузке” для того, чтобы “Сократить затраты на разработку одинаковых систем аутентификации в разных продуктах”, до тех пор, пока не случится “Все продукты используют SSO” и мы узнаем, что проект успешен, когда “Разработка первой версии нового продукта заняла меньше 4 недель”.
- Мы делаем “Инфраструктуру, готовую к масштабированию” для того, чтобы “Сохранить лицо технологической компании”, до тех пор, пока не случится “Все продукты компании используют новую инфраструктуру” и мы узнаем, что проект успешен, когда “В течении 1 года не было жалоб на доступность продуктов компании в СМИ”.
Итого
Есть прекрасный инструмент и алгоритм, с помощью которых можно качественно обозначить цель проекта и все его детали перед запуском, и это – Устав проекта по Методу Пульса. Однако следует помнить, что мастерство приходит с практикой, поэтому надо не бояться брать и делать.
Лично у меня прошло достаточно времени, пока я сам собирал эти самые ошибки, и теперь мне достаточно быть внимательным при заполнении, чтобы разглядеть ошибки. Так что дерзайте, у вас теперь есть не только алгоритм, критерий проверки, но и самые частые ошибки для качественного определения целей и границ своих проектов.
Евгений Корытов, эксперт в области создания и управления веб-продуктами
