Добро пожаловать на третий модуль нашего курса "Жизненный цикл Agile-проекта". В конце предыдущего модуля мы рассмотрели в общих чертах, что такое жизненный цикл Agile-проекта и его основные характеристики. На протяжении данного модуля мы углубленно изучим каждый из этапов жизненного цикла. Пока мы все еще не будем углубляться в конкретную методологию и рассматривать, например, Scrum-церемонии, так как изучаемые сейчас общая философия и этапы Agile-проекта универсальны. В данном уроке мы рассмотрим, какие мероприятия рекомендуется проводить на начальном этапе представления проекта — в том числе, как определить, имеет ли смысл применять к проекту именно гибкие методологии разработки, или для него вполне достаточно традиционного подхода к проектному менеджменту. А также рассмотрим основные параметры устава проекта. Одним из наиболее важных факторов успеха для гибкого подхода является выбор правильного проекта для применения гибких методов. Какие факторы для подобного выбора наиболее важны? Во-первых, вам нужно быстро создать качественный продукт, но есть возможность выводить его на рынок поэтапно. Это идеальное начало для применения гибких методологий. Затем вы ожидаете, что требования будут изменены или развиваться. Кроме того, ваша организация готова освободить очень способных членов команды, которые могут самостоятельно принимать решения о продукте, который вы производите. И что самое важное, продукт может доставлять бизнес-ценность поэтапно. Могу привести пример хорошего Agile-проекта, над которым я недавно работал. Когда проект только начинался, он представлял из себя одну форму для заказа билетов на автобусы с возможностью регистрации. Больше не было, в принципе, ничего. Минимальный набор работающего функционала, с которым можно начинать зарабатывать деньги. После запуска проекта начали понемножку появляться и другие возможности — запоминание адресов и маршрутов, форма дополнительных требований к автобусу, включая, например, наличие кондиционера (что оказалось очень важной для пользователя функцией), возможность оставлять комментарии по поводу совершенных поездок. Еще через некоторое время появилась онлайн-карта с возможностью выбора остановок. Потихоньку простенький сервис превратился в полноценный многофункциональный портал. Но при этом дополнительный функционал появлялся после анализа его необходимости и ценности для пользователей и только добавлял удобство в использовании сервиса. Для меня это яркий пример Agile-подхода к разработке. Поставляйте рабочий продукт как можно раньше и делайте это на регулярной основе. Заботьтесь о качестве и ваших пользователях, делая продукт удобным для них. Получайте обратную связь и изменяйте продукт, реагируя на изменения требований к нему. Именно об этом нам и говорят Agile-принципы. Итак, что же еще необходимо сделать на этапе представления проекта? Необходимо четко определить и зафиксировать это в итоговом документе (чаще всего такой документ называют уставом проекта), что мы должны получить от проекта в конечном итоге — цели клиента, конечную цель проекта, целевую аудиторию, получаемые конкурентные преимущества. В уставе проекта должны быть указаны обязанности спонсора проекта и менеджера проекта, обозначены полномочия руководителя. В качестве примера можно привести следующий набор разделов устава. Начальные условия (Project Background) — что привело к инициации проекта, входные условия (так называемая "боль заказчика"). Цели и ожидания проекта (Project Objectives/Expectations) — чего мы хотим достичь на выходе. Это что-то должно быть измеримым и не допускать двойного толкования. Например, цель сделать систему CRM, чтобы привлекать больше клиентов, — как-то не совсем конкретно, согласитесь. А вот разработать и внедрить систему CRM для сотрудников отдела продаж дальневосточного филиала до определенной даты для обеспечения мгновенного доступа к информации о тратах клиентов в разные периоды года — это уже немножко другое. Содержание и результаты (Scope and Deliverables) — что именно мы включаем в состав проекта и какие конкретные результаты получим. Например, если нужно выпустить новую систему CRM, то на выходе мы должны иметь саму систему, сервера, на которых мы ее поставим, обученных пользователей и документацию для передачи в поддержку, а может, и саму организованную с нуля поддержку. В этом разделе вы четко ограничиваете, что вы сделаете. Еще очень полезно сюда же включать подраздел со списком того, что в содержание проекта не входит в явном виде, чтобы всё это согласовали, и потом никто не удивлялся, почему вы в рамках проекта еще и систему управления инцидентами для техподдержки системы не внедрили. Ключевые требования и характеристики (Requirements and Characteristics) — то, что не является результатом проекта, но важно для него. Если опять вернуться к системе CRM, то типовым требованием может быть: срок обучения сотрудника системе не должен превышать одного рабочего дня; поддержка системы не должна быть дороже 200000 рублей в год; в системе одновременно должно работать не менее 300 человек, и подобное. Бюджет и сроки (Cost and Timalines) — деньги, сроки и взаимоотношения с другими сторонами проектного треугольника. Например, сюда полезно вписать приоритеты по убыванию (типа бюджет, содержание, сроки). То есть потратить больше денег — прямо никак нельзя; уменьшать получаемые результаты — сильно нежелательно, но можно в самом крайнем случае; а если надо ради первых двух пунктов увеличить срок — то это ОК. Ключевые участники (Key Stakeholders) — основные заинтересованные лица (как минимум спонсор, заказчик, те, кому придется делиться с вами ресурсами в матричной структуре, ваш руководитель, держатель бюджета и так далее). Включать сюда всю компанию не стоит. Просто подумайте и напишите, кто должен знать о проекте на данной стадии и к чьему авторитету вам будет полезно апеллировать в ходе проекта. Допущения и ограничения проекта, основные риски (Project Assumptions and Restrictions, Main Risks). В целом цель включения их в устав проекта — это донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать. И чтобы потом никто не говорил: "А нам так не сказали". Структура устава проекта не является догматичной и зависит как от квалификации менеджера проекта, так и от традиций компании, в которой инициируется проект. Вы сами определяете, какого уровня детализации в уставе будет достаточно, чтобы подписать устав и тем самым дать официальный старт проекту. Довольно часто после того, как вы записали в устав общее видение проекта и его границы, создается еще один более детализированный документ — Product Data Sheet, известный как технический паспорт проекта. В отличие от устава, такой документ может содержать информацию более глубокого уровня. Например, количество планируемых итераций, ориентировочный бюджет и так далее. Еще одним важным отличием технического паспорта от устава является то, что в нем могут быть зафиксированы предполагаемые ограничения проекта. Они могут быть экономическими, техническими, политическими, временными, командными, связанными с особенностями окружающей среды или безопасностью. Вот несколько конкретных примеров ограничений проекта. Проект должен быть завершен к концу третьего квартала. Проект должен соответствовать ГОСТу. Проект не должен быть реализован в период с 15 декабря по 10 января. Также на этапе представления чрезвычайно важно определить коллективные инструменты для совместной работы команды — например, Messenger и Task Manager, то есть программное обеспечение для организации коллективной работы над задачами, для облегчения коммуникативного взаимодействия. На рынке есть много инструментов для совместной работы. Размер проекта, количество заинтересованных сторон и объем специфических функций определяют, насколько продвинутый инструмент совместной работы вам необходим. Мое предложение — начать с небольшого количества инструментов с низкой степенью сложности и добавить другие инструменты, если и когда они потребуются. Советую обратить внимание на наличие следующих характеристик при выборе программного обеспечения для коммуникации: отслеживание и отчетность по статусам задач, помощь в совместной работе над задачами и push-уведомления для информирования. Поскольку проекты Agile связаны с тесным сотрудничеством, важно, чтобы команда понимала, как она будет работать, где она будет непосредственно располагаться, есть ли условия для ежедневного активного общения и проведения совещаний. Также важно зафиксировать командные нормы, чтобы все участники чувствовали себя в более организованной и защищенной среде. Примерами эффективных командных норм могут быть, например, такие позиции. Не отвечайте на звонки и текстовые сообщения во время встреч. Будьте уважительны друг к другу, разделяйте роли и обязанности каждого члена команды. Если не получается решить конфликт на вашем уровне, попробуйте воспользоваться помощью руководства. Конкретный список таких норм вырабатывается на общем командном совещании на основании опыта коммуникации ее участников. Давайте подведем итог нашего урока. В завершение этапа представления у нас должен быть подписан как минимум устав проекта — устав даже на одной страничке А-4, подписанный всеми заинтересованными лицами, лучше, чем неподписанный на десяти страницах. И требование подписать его до перехода на этап планирования и начала работ — не просто профессиональное требование, а аксиома.
