Готовы ли вы услышать правду?

Перевод статьи Дэна Норта - "Are you ready for the truth?"

Внедрение гибкой (Agile) методологии разработки является кардинальным изменением для многих топ-менеджеров и бизнес-спонсоров. Не стоит недооценивать важность введения их в игру в самом начале взаимодействия, и желательно максимально сгладить для них начальный этап внедрения Agile-практик. Мы хотим обеспечивать наших спонсоров своевременной, точной информацией, которую они могут успешно использовать для принятия решений о том, как управлять проектом. Проект, управляемый по гибкой методологии, предлагает как раз такие данные, но чтобы их можно было использовать, мы должны убедиться, что люди, которые получили их, смогут интерпретировать эти данные и в полной мере извлечь из них пользу.
Для команды разработчиков Agile является неким сдвигом в сознании: от крупных объемов работы к более мелким, итерационным, к методам работы в тесном сотрудничестве. Этот сдвиг в сознании наступает довольно быстро. С небольшой хорошо мотивированной командой и достаточно высокой пропорцией (лучше всего 50/50) в ней «Agile-драйверов» новая команда может подхватить «общепринятый» TDD, парное программирование, практику непрерывной интеграции, написание пользовательских историй и пр., буквально в течение нескольких недель.
С другой стороны, у бизнес-спонсоров свой путь. Они обычно смотрят диаграммы Гантта, которые показывают процент завершенных задач по разработке, и – позор нам! - эти же диаграммы Гантта используются и для менеджеров проектов, будучи, в лучшем случае, умеренно правдивыми. В наше оправдание мы говорим что-то вроде: а зачем им знать повседневную динамику цикла поставки? Если мы немного отклоняемся от сроков, почему бы не добавить чуть глянца, мы ведь не хотим никого тревожить. И, в любом случае, никому не понравится, чтобы его проекту был постоянно дан желтый свет.
Отслеживание хода Agile-проекта даёт больше деталей, чем заказчики когда-либо видели
А потом внезапно происходит гибкое планирование (Agile planning) - и отверзаются врата ада! Внезапно мы докладываем только о фактически реализованных и поставленных функциях. О том, что они могут приоритизировать и запускать в работу. О вещах, которые они могут верифицировать. Понятие «готово на 80%» уходит прочь. Или готово, или нет. И, наконец, это самое «велосити». За этим словом ничего не стоит. Это просто «темп, в котором мы работаем». На протяжении нескольких недель высокая «велосити», а потом – низкая «велосити». Разработка движется таким путем: у вас бывают хорошие и плохие недели, сложные или более легкие задачи. Через некоторое время, когда команда начинает лучше и оценивать, и делать поставку, «велосити» становится равномерной, но при этом все равно будут свои пики и спады.
У нас принято докладывать только о хороших новостях. В нашей культуре принято не расстраивать людей (особенно людей, которые –а) могут на нас наорать, б) платят нам зарплату), что означает, что эти люди привыкли слышать только хорошие новости – по крайней мере, до конца проекта, когда отвратительная правда о превышении сроков и расползании границ проекта, а также впечатляющий список ошибок вылезает на свет божий.
Убедитесь, что они готовы к правде
В чем тут суть? Как тренер, вы несете ответственность за то, чтобы подготовить бизнес-спонсоров и руководство (в том числе вышестоящий IT менеджмент) к тому, как правильно интерпретировать прогресс в Agile-проекте. «Плохие» новости не всегда плохие – зачастую это просто новости. Любой рычаг, который позволяет нам хоть немного сдвинуть в нужном направлении Agile-проект, может заставить наших бизнес-спонсоров чувствовать себя неуютно, и помочь им преодолеть это – в зоне нашей ответственности (поскольку мы их втянули в этот Agile). Они оказываются на таком уровне получения и прозрачности информации, которого никогда не достигали ранее – больше точек получения данных и сами данные лучшего качества – и работа с таким уровнем детализации проекта требует определенной подготовки.
Мы как бы даем им микроскоп и позволяем задавать вопросы, относительно тех деталей, которые они никогда ранее не видели. Конечно, мы можем натаскать руководителя проекта так, чтобы он представлял информацию о ходе проекта в наиболее удобоваримом для высшего руководства виде, но всегда предпочтительнее избегать подобного жонглирования цифрами. Если мы сделаем все правильно, у бизнес-спонсоров будут гораздо большие возможности для контроля за проектом – в отношении управления, руководства, финансирования, обеспечения ресурсами и т.д. - чем они когда-либо имели, так что это стоит затраченных усилий.
Существует такая тенденция: запускать Agile-процесс внутри команды разработчиков. Давайте заставим разработчиков разрабатывать по TDD, бизнес-аналитиков писать пользовательские истории, руководителей проектов следить за ходом проектов в стиле Agile. Проблема такого подхода в том, что эта новаторская очень точная информация о ходе проекта вываливается перед руководством в совершенно дословном формате – а руководство абсолютно не готово к этому, и рефлекторно решает, что Agile «не работает». Для менеджера, руководящего портфелем проектов, если один-единственный Agile-проект в его портфеле является тем, что постоянно предоставляет «плохие новости» (а если быть честными – то данные этого проекта более точные), это скорее всего вызовет излишний негатив у тех людей, которые по-вашему представлению должны спонсировать и лоббировать переход на Agile.
Резюмирую. Вы должны вовлекать бизнес - и технических спонсоров в процесс внедрения Agile как можно раньше, но при этом должны помочь им разобраться в той новой, более полной и более прозрачной информации, которую они будут в этом случае получать. Имеет смысл больше времени уделять менеджерам проектов, вовлекая их в разнообразные обсуждения, которые неминуемо будут иметь место при переходе к новому, более эффективному способу поставки и отслеживания хода проектов разработки ПО.
Chief technology officer "Один Сервис.ВЦ" - Денис Олейник