Цитаты из книг автора «Алексей Минкевич»

Устав может корректироваться в ходе реализации проекта. Почему? Например, у бизнеса поменялись цели. Такое бывает: время не стоит на месте, рынок меняется. В управлении проектами нет документов, которые «ламинируются». Любые планы нужно будет обновлять согласно новым вводным. Обратите внимание, что такая же история происходит и со стартапами. Очень редко стартап становится успешен со своей оригинальной идеей. Обычно только в ходе работы становится понятно, что именно нужно рынку. И успеха добиваются те, кто способен быстро адаптировать свою идею под нужды рынка или, если потребуется, полностью изменить ее.

6. Ориентировочный бюджет проекта. В этом пункте указывается объем средств, который заказчик готов потратить на реализацию проекта. 7. Ключевые заинтересованные стороны. Это список людей или организаций, которые активно вовлечены в проект и могут оказывать существенное влияние на проект и его результаты. При этом проект также оказывает влияние на них. Крайне важно в самом начале идентифицировать все ключевые заинтересованные стороны, так как обычно это люди, принимающие решения. Главные требования к проекту будут исходить именно от них. Если в начале проекта менеджер пропустит хотя бы одного такого человека, то рано или поздно он обязательно появится и принесет с собой новые требования. Как правило, они существенно увеличивают содержание работ. Самое страшное происходит в случае, если этот человек появляется на стадии приемки. Тогда проект оказывается в большой беде, так как, скорее всего, многое необходимо будет переделывать. Мы рекомендуем совмещать список заинтересованных сторон с матрицей ответственности, то есть не просто узнать, кто влияет на проект, но и зафиксировать, кто и за что будет отвечать. Пример приведен в таблице 1. Вот и все содержание устава проекта. Но это не так мало, как может показаться на первый взгляд. На то, чтобы составить и согласовать со спонсором устав проекта, может уйти от пары дней до нескольких недель.

проект запущен: 6 июля; API между мобильным приложением и сервером согласованы: 5 сентября; разработка серверного решения завершена и протестирована: 10 октября; разработка мобильного приложения завершена: 4 ноября; тестирование решения завершено: 2 декабря; проект успешно завершен: 12 декабря. Обратите внимание, что ключевые события указываются в прошедшем времени, что дает менеджеру четкое понимание того, выполнены эти задачи или нет. Если писать в настоящем времени («Разработка мобильного приложения: 4 ноября»), не будет понятно, что имелось в виду: мы планировали начать разработку, вести разработку или закончить разработку к 4 ноября. Прошедшее время четко дает понять, что работа должна быть завершена к соответствующей дате.

5. Ключевые и контрольные события. В уставе проекта оговариваются ключевые и контрольные события — важные события в проекте — и то, когда они должны произойти. Например, проект начинается 6 июля. Менеджер планирует, что backend-разработчики должны сделать серверную часть по проверке фотографий из паспортов к октябрю. Для этого нужно успеть за месяц согласовать контракты API между сервером и мобильным приложением. Если удастся, то только в этом случае можно будет закончить мобильное приложение к ноябрю. К этому же времени нужно будет обучить работе с приложением десять первых представителей банка, чтобы те смогли протестировать его в «боевых» условиях. Если все пойдет именно по такому графику, то в начале декабря будут закончены испытания и выпущено приложение. Таким образом, в уставе у нас получится следующая запись. Ключевые и контрольные события:

4. Ограничения и допущения. Ограничения проекта — это перечисление факторов, которыми в проекте нас ограничивает заказчик. Есть решения, которые уже приняты, и мы их не можем менять. В нашем банковском примере есть всего одно ограничение. Ограничения: решение должно работать на телефоне Lenovo P780 под управлением Android 5.1.

3. Требования / результаты поставки. Здесь нужно описать крупные результаты поставки проекта и основные требования к ним. В итоге должен получиться список дел, «to do» проекта. Если все пункты этого списка выполнены, проект успешно завершен. Немного забегая вперед, скажу, что это первая, высокоуровневая иерархическая структура работ проекта. Список результатов поставки для примера с банком: разработать мобильное приложение для телефона Lenovo P780 с функционалом, описанным в целях проекта; обновить банковское серверное решение для поддержания работы приложения; закупить 200 телефонов Lenovo P780; разработать обучающие видеоматериалы по работе с приложением; провести обучение 30 представителей банка; внести соответствующие изменения в регламент работы колл-центра технической поддержки банка. Если мы выполним все эти задачи, проект будет успешно завершен.

Как это прописать в уставе? Примерно так. Решение: необходимо разработать мобильное приложение под Android, которое умеет фотографировать паспорт потенциального клиента, отправлять фото паспорта и обмениваться информацией с серверами банка. Приложение должно позволить сотруднику банка выполнить следующие действия: пройти авторизацию в приложении; используя камеру телефона, сфотографировать паспорт потенциального клиента. Приложение должно распознать штрих-код паспорта, отослать картинку и данные штрих-кода в расчетный центр банка. Информация проходит проверку системы безопасности и принимается решение, можно ли открыть клиенту кредит с лимитом в 100 руб.; если ответ положительный, приложение должно считать QR-код с конверта с кредитной картой, создать нового пользователя в банке и привязать к нему кредитную карточку, а потом подтвердить успешность операции. Важным требованием является возможность работы приложения в условиях медленного мобильного интернета (на тот случай, если в населенном пункте нет 3G). Только после этого представитель банка может выдать новому клиенту карточку с кредитом в 100 руб. Чтобы активировать ее, клиенту необходимо приехать в ближайшее отделение банка и подписать соответствующий договор.

Цель проекта. Описание того, каким образом будут достигнуты бизнес-цели проекта. Бизнес принимает решение о запуске конкретного проекта, проанализировав различные альтернативы и выбрав один вариант. В примере с банком таким решением может быть, например, приложение, помогающее выдавать мини-кредиты. Оно служит единственной бизнес-цели — увеличить базу клиентов банка. Решение должно быть задокументировано кратко и на высоком уровне. Это своеобразная карта, по которой нужно двигаться, чтобы помочь бизнесу достичь цели.

Если вы знаете, для чего делается проект, то сможете лучше им управлять. Ведь в этом случае каждое возникающее пожелание и изменение будет проверяться на соответствие бизнес-цели. Если изменение не приближает нас к цели бизнеса, то от него нужно отказаться. В продуктовой разработке этот принцип справедлив для нового функционала. Если у вас есть идея что-либо добавить в продукт, то нужно сначала проверить, помогает ли она достичь цели бизнеса.

другими людьми; четкую работу с изменениями по ходу проекта; использование верных инструментов, таких как Trello, Jira, MS Project и прочих; управление ожиданиями заинтересованных сторон: проект можно считать успешным, если заказчик доволен, даже если он получил не то, что задумывалось изначально; и, конечно, яркое и запоминающееся завершение проекта.