[БЕЗ_ЗВУКА] В предыдущем уроке мы рассмотрели ключевой этап работы над гибким проектом — этап реализации. Мы разобрали основные моменты, на которые менеджеру стоит обращать внимание на данном этапе, и основные отличия от традиционных подходов к управлению проектами. В agile-методологиях этап реализации каждой итерации имеет четкие сроки, и по завершении этого времени мы получаем новую версию работающего продукта, успев реализовать тот список функций, который был запланирован. Помимо демонстрации этой версии продукта заказчику, которую также называют инкрементом продукта, обязательной практикой является проведение глубокого анализа: что получилось и что не получилось реализовать за время работы в итерации. Именно этому и посвящен этап адаптации. И хотя по срокам он значительно меньше самого этапа реализации, по своей сути и ценности для конечного продукта он играет огромную роль. Обычно этап адаптации начинается после демонстрации продукта заказчику в конце итерации, прямо в тот же день, а также распространяется на начало следующей итерации, когда мы пересматриваем приоритеты в оставшихся задачах. Там мы учитываем новую информацию, которую получаем в результате анализа. Ключ к успешной адаптации — это правильные вопросы. При этом не надо ждать формального наступления этапа адаптации, чтобы получить обратную связь. Этот процесс должен идти параллельно с повседневной работой, накапливая исходные данные. Необходимо приоритизировать обратную связь и выявлять корни причин различных проблем. Накопив достаточное количество вопросов, мы проводим официальную церемонию. В Scrum такая церемония называется ретроспективой. Как руководителю проекта, вам нужно будет обучить команду тому, что делать, когда возникают проблемы. Имейте в виду, что управление проблемами больше связано с отношениями и тем, как мы взаимодействуем друг с другом, а не с тем, как мы тактически пытаемся решить эти проблемы. Речь идет о построении доверия друг к другу, необходимое для того, чтобы совместно вести прямой и честный разговор о проблеме, используя достоверную информацию. Конфликты в любом коллективе неизбежны. Поэтому их следует умно и своевременно сглаживать. Вот несколько хороших методов, которые можно использовать для себя и для команды. Напомните членам вашей команды: атаковать нужно всегда проблему, а не человека, требовать от членов команды решать конфликты друг с другом напрямую, профессионально и с уважением, каждый должен приводить конкретные факты, а не слухи или домыслы. Если члены вашей команды не могут прийти к соглашению, попросите их представить свой сценарий с продуманными плюсами и минусами. Члены команды, находящиеся в конфликте, должны затем поделиться с вами информацией, объяснив точку зрения своих коллег. Это бывает весьма эффективно, так как многие члены команды приходят к решению самостоятельно. Если же возникает ситуация, когда от участника, из-за которого возникла конкретная проблема, не поступает предложений по ее разрешению, имеет смысл провести мозговой штурм по нахождению решения всей командой. И здесь тоже есть рекомендуемый способ работы: генерируйте идеи всей командой и зафиксируйте все озвученные варианты, не критикуя их. После чего проведите так называемое кулачное голосование. Его суть заключается в том, чтобы после озвучивания вслух предлагаемого решения, все участники церемонии на счет раз два три подняли вверх руку с несколькими пальцами. Пальцы символизируют баллы по пятибалльной шкале. Решение берется в работу только тогда, когда вся команда показала три и больше пальца. Итак, каждый человек голосует пальцами. Пять означает, что ему действительно нравится предложенное решение. Четыре означает, что он им в целом доволен. Три означает, что оно по его мнению рабочее, но могло бы быть и получше. Два пальца указывают, что есть какие-то оговорки. И один палец говорит о том, что есть серьезные опасения. Если кто-то показал один или два пальца, то он обосновывает свое сомнение в правильности решения. Если вы проведете такое голосование по всему списку предложенных вариантов, то сможете оценить качество предлагаемых решений и выбрать самое лучшее из них. Еще раз повторюсь, что решение берется в работу только после того, как абсолютно все участники показали минимум три пальца. Кстати, правила проведения кулачного голосования — это отличный вариант для описания этой процедуры в нормах команды, тех самых, о которых мы говорили в уроке о представлении проекта. Лично вы, как руководитель, должны принимать решение только тогда, когда ваша команда не смогла этого сделать. Когда вы принимаете решение, сделайте его ясным и укажите обоснование вашего решения. Попросите их о поддержке на основе принятого решения. Хорошей практикой считается публиковать три главных проблемы проекта где-то в комнате на видном для всей команды месте, чтобы каждый участник знал о ключевых проблемах проекта и уделял им внимание, учитывая важность решения именно этих проблем. Таким образом, ключевым посылом для этапа адаптации является регулярный сбор обратной связи. Размещайте в общей комнате или в специальном разделе в вашем программном обеспечении соответствующую информацию о проблемных вопросах, на решение которых уходит времени больше, чем планировалось. А отрабатывайте их на запланированной в конце каждой итерации церемонии адаптации. Это позволит вам при подведении итогов в конце итерации иметь значительно больше информации и предложений, нежели вы только начнете выявлять проблемы на самой церемонии. После получения отзывов и предложений постарайтесь правильно определиться с их приоритетностью. Для этого можно попросить членов команды расставить акценты в цепочке приоритетов и выделить среди них самые важные. Напомню, что основная идея agile — уметь адаптироваться под постоянно изменяющиеся потребности бизнеса. Именно на этапе адаптации мы часто можем увидеть вновь образующиеся категории связей, которые были не видны на этапе планирования. И здесь закладываются основы к обновлению бэклога проекта. Иногда выявление таких связей может привести к пересмотру всех связей функций. Иногда требует обновления оценок трудозатрат по функциям. Главное, что у вас должно получиться в завершение этапа адаптации, — конкретный список выявленных проблем и недочетов функций, которые вы реализовывали в предыдущей итерации, а также набор согласованных вариантов решения этих вопросов. Еще одним важным моментом является культура проведения церемонии по адаптации. Необходимо создать атмосферу доверия и раскрыть участников команды, чтобы они не боялись почувствовать себя виновными в возникновении той или иной проблемы, а наоборот, чувствовали себя сопричастными к конечному результату и вырабатывали конструктивные идеи. Для этого существуют различные игровые форматы проведения адаптационных совещаний, некоторые из которых мы рассмотрим в другом модуле. Важно также понимать, что на этапе адаптации мы работаем не только над улучшением продукта, но и над улучшением процесса взаимодействия команды. Если вам удалось выявить системные проблемы, например, когда от итерации к итерации от участников команды вам поступают жалобы на то, что пользовательские истории не соответствуют правилам их написания и их сложно брать в работу, имеет смысл провести дополнительное обучение участников команды по написанию качественных пользовательских историй. Тем самым, вы адаптируете свой рабочий процесс и повысите общую командную эффективность.
