[БЕЗ_ЗВУКА] Итак, в предыдущих уроках модуля мы рассмотрели основные этапы жизненного цикла Agile-проекта. В разных гибких методологиях могут использоваться разные практики и инструменты, но суть у всех них одна — соответствовать духу и ценностям Agile. Как долго ни длились бы итерации, рано или поздно любой проект подходит к своему завершению. Если вы работали в традиционных проектах, то обычно для участников команды на этом проект и заканчивается. То есть сдали последнюю задачу и разошлись. Практика подведения итогов всей команды в традиционном менеджменте развита не очень сильно, хотя мы говорили о том, что это настоятельно рекомендуется делать в первом модуле нашего курса. Для Agile-команд это является обязательной церемонией и приглашать на нее стараются не только непосредственных участников команды, но и всех тех, с кем приходилось взаимодействовать на протяжении проекта вне команды. Почему же этап закрытия проекта так важен? Вот несколько причин, из-за которых этот этап становится таким эффективным. Он позволяет выявить и обобщить те ценности, которые извлекли для себя участники проекта, понять, чем люди были удовлетворены, а, соответственно, и дальше продолжать использовать эти практики, а что доставляло им дискомфорт. Логично стараться избегать такого негативного опыта в будущих проектах. Хорошие мероприятия по закрытию проекта позволяют получить эмоциональную разрядку и получить максимальное внутреннее удовлетворение от проделанной работы. Это очень важно для дальнейшей мотивации людей. Ведь не исключено, что с кем-то из нынешних участников вам придется работать уже в следующем проекте. Это дает нам шанс еще раз поделиться какими-то важными моментами, тонкими нюансами, которыми мы, возможно, не успели или просто забыли поделиться с коллегами, пока плотно работали над проектом. Это налаживает более тесные связи между участниками команды и всем остальным кругом лиц, кто поддерживал и помогал команде. Что обязательно следует сделать на этапе закрытия проекта? Результатами многих проектов, чаще не связанных с разработкой программного обеспечения, часто являются документы, слайды, видеоролики, результаты исследований, потребности пользователей, хранилище данных и так далее. Поскольку организация уже инвестировала время и деньги для создания этих материалов, первое и самое важное — систематизировать всю наработанную документацию в полном объеме для дальнейшего удобного использования. Если вы работали в современном Таск-менеджере, то это может сильно облегчить вам жизнь, так как в них есть очень удобная возможность экспорта списка задач с надстроенными параметрами, и за счет этого дальнейшая систематизация сильно упростится. Также может быть полезно создать единый главный документ, такое оглавление, в котором будут изложены материалы, подготовленные в ходе работы над проектом, и структура их архивирования. Представьте себя на месте нового участника команды, который только что подключился к проекту. В каком виде вам хотелось бы получить доступ к накопленным материалам, чтобы быстро включиться в работу? Представили? Вот для такого новичка и постарайтесь структурировать материалы так, чтобы он сам смог всё найти и ему не пришлось вас ни о чем спрашивать. Очень эффективным способом передачи такого архива является видеоконференция с демонстрацией экрана. Такие видео-встречи называют show and tell, показывай и рассказывай. Используя такие инструменты, например, как Google Drive, можно с легкостью предоставить доступ к архиву всей команде, а Google Hangouts или Skype, наглядно показать и рассказать им, где лежат те или иные материалы. Отличной идеей будет оставить доступ к такому облачному хранилищу всем желающим, так как им часто могут потребоваться образцы различных документов, и каждый такой раз, зная, что и где именно можно взять, они будут вам искренне благодарны. Следующая важная составляющая этапа закрытия — анализ полученного опыта. Причем важно задокументировать как положительный, так и отрицательный полученный опыт. Такую практику называют Lessons Learned, то есть дословно «выученные уроки». Подумайте, за что в работе над проектом можно поставить команде пятерку, а за что двойку. Какие риски произошли, а каких удалось избежать и за счет чего. Очень удобно прикладывать такие карточки полученных уроков в итоговый отчет по проекту. Образец шаблона такого отчета вы можете посмотреть в дополнительных материалах к уроку. Попробуйте заполнить его для какого-нибудь проекта, в котором вы недавно участвовали. И взять этот отчет-справку на планирование следующего проекта. Вы будете поражены, как много полезной информации вы сможете почерпнуть. Для эффективного анализа команде важно задать себе и честно ответить на следующие вопросы. В ходе проекта были извлечены важные уроки о том, как работала команда? Насколько вы действовали гибко? Как вы могли бы по-другому организовать? Что вы можете улучшить в среде вокруг команды? Например, по-другому организовать доступ к IT-ресурсам, пространство вашей команды. Были ли задействованы заинтересованные стороны? Если вы взаимодействовали с поставщиками, каков получился ваш опыт? Вы тратили деньги с умом? Вы могли бы взаимодействовать с ними снова? Должна ли ваша организация взаимодействовать с ними снова? Каков был ваш личный вклад? И самая приятная часть этапа закрытия проекта — проведите мероприятие, чтобы отпраздновать свои успехи. Ну то есть прямо настоящую вечеринку или банкет. Обязательно публично поблагодарите на нем всех участников за работу, чувство признания очень сильно мотивирует. Кстати, часто Agile-команды используют так называемые доски почета и благодарности. На них в процессе работы, обычно после ретроспектив, пишут слова благодарности за что-то конкретное другим коллегам. Например, за помощь в решении проблемы, с которой застрял другой участник команды. У нас в столовой, например, на флипчарте пишут отзыв о еде, благодарят поваров за вкусные котлетки и супы. Крайне полезным бывает фотографировать такие благодарности, чтобы показать их хронологию развития на завершающем мероприятии. Обычно люди просто в восторге от такого объема позитивной информации о себе и своих коллегах. Что можно раздать на память о проекте участникам на таком мероприятии? Есть одна действительно классная идея, но к ней надо готовиться заранее на протяжении всего проекта. Если вы фотографировали команду в рабочем процессе, сделайте небольшой фотоальбом и подарите его всем на финальном мероприятии. Вспомните, какие чувства у вас вызывает просмотр вашего школьного фотоальбома. Почему бы не сплотить вашу расстающуюся команду таким же способом? Также необходимо проверить, все ли технические дела завершены: выставлены счета, оплачены все услуги, закрыты все документы и так далее. Каких-то особых рекомендаций со стороны Agile-методологии в данном вопросе нет. Просто еще раз проверьте свою дисциплинированность. Если вы покидаете помещение, в котором работали всей командой по завершению проекта, хорошим тоном будет вспомнить о так называемом правиле бойскаута — уходить из площадки, приведя ее в такой вид, чтобы она стала лучше, чем когда вы на нее пришли. В завершение урока хочу дать еще один совет от себя. Несмотря на то, что вы плотно взаимодействовали друг с другом на протяжении проекта, не поленитесь и составьте отдельный контакт-лист всех участников и разошлите его между собой. Пускай в скором времени все разойдутся по новым проектам, и вы перестанете регулярно общаться друг с другом, но нетворкинг стоит над проектной работой и крайне важно не забывать развивать свои профессиональные отношения. Сегодня, кстати, достаточно просто продолжать поддерживать их в отдельных группах в мессенджерах. Итак, поздравляю вас с завершением полного цикла работы над гибким проектом. Пусть пока виртуально и без привязки к конкретным практикам из конкретных методологий, но я считаю, что понимание основ на именно вот таком общем уровне позволит любому человеку подключиться к любому Agile-проекту, независимо от того, какую методологию использует команда. В завершение данного модуля предлагаю вам рассмотреть еще несколько универсальных советов и рассмотреть типовые ошибки, которые возникают у Agile-команд. После чего в следующем модуле мы перейдем к изучению практики организации эффективных Agile-команд.
