Борис Вольфсон - Гибкое управление проектами и продуктами

Подчеркну, что у самого вероятного исхода (завершение за 8спринтов) кумулятивная вероятность составляет всего 57,3 %.

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

В этом разделе я расскажу об особенностях Scrum в заказной разработке, которая отличается от тепличных условий внутренней разработки, и можно ли применять Scrum в таких условиях, а также на что надо обратить внимание прежде всего.

Первый вопрос, который обычно возникает, – как продать Scrum клиенту, ведь его не очень волнует, каким иностранным словом вы называете свои внутренние процессы. На данном этапе очень важно объяснить заказчику (полагаем, что спринты у нас двухнедельные), что он сможет:

• каждые две недели получать новый функционал, который можно попробовать и выпустить на рынок для зарабатывания денег;

• каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО;

• регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта.

Второй вопрос, который появляется сразу после первого, – как отразить процесс в контракте. Наилучшим вариантом здесь будет заключение контракта типа «время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но следует отметить, что при таком подходе и риски перекладываются на него. Еще скажу, что при таком варианте резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.

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

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

Главным документом в проекте, с которого обязательно стоит начать его разработку, является видение проекта. Этот краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т. д. Словом, он заменяет целый пакет документов, который принято использовать в тяжеловесных методологиях. Для создания видения можно использовать инновационные игры, разного рода мозговые штурмы и фреймворки.

Следующим этапом идет выявление персон и их активностей (вплоть до отдельных историй пользователя), которые фактически являются легковесным и более визуальным вариантом экторов и пользовательских сценариев. Уже традиционно данную активность Scrum-команды реализуют в виде построения карт историй (Story Mapping), результатом которого становятся доски и целые стены с визуализацией активностей в проекте.

Построение карт историй на практике

Обязательно нужно вытащить представителей заказчика на процессы по выработке видения и построение карт историй (а на последнее собрание – еще и потенциальных пользователей).

Обратная сторона медали – это выбор платформы для разработки и создания архитектуры. Конечно, я имею в виду не Big Upfront Design, а более гибкий подход, ведь десятки или сотни диаграмм, пылящихся в дальнем ящике стола, – это не наша цель. Задача у нас – сделать продукт, минимизировав потери.

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

Можно взять ICONIX в качестве подмножества UML и процесса, но он будет скорее замещать построение карт историй, чем дополнять его.

В нулевой спринт входит и подготовка к первому. Для этого необходимо описать истории пользователей, спроектировать для них интерфейс и оценить. Работу лучше всего построить в этом порядке, так как он способствует более качественному пониманию требований и их оценке.

Не буду подробно останавливаться на традиционных практиках Scrum, хочу отметить лишь, что в них нужно по возможности вовлекать заказчика. Программа-минимум – это посещение заказчиком всех демонстраций. Вам жизненно необходимо «подсадить» заказчика на свой ритм работы, чтобы он хотел получать очередной инкремент функционала как наркотик. Это очень поможет выстроить атмосферу доверия между вами.

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

Гибкий подход подразумевает выстраивание по-настоящему партнерских отношений с заказчиком. Необходимо выработать стратегию работы с «вредными» клиентами, ведь построить с ними партнерские взаимоотношения чрезвычайно сложно.

Давайте подумаем, как дифференцировать заказчиков по «вредности» и как (и стоит ли) работать с «вредными». Сначала определимся, кого считать «вредным» клиентом. Обычно в отношении заказчиков используется термин «лояльность». В самом простом случае клиентов можно разделить на три группы: нелояльные, средние и лояльные.

Лояльный клиент доставляет меньше всего проблем, обычно делает заказ на большую сумму, чем средний. К тому же он часто делает повторные заказы. Таких клиентов надо холить и лелеять, для чего можно разработать программу повышения лояльности – от предоставления скидок до специальных условий работы.