Таблицы перехода из одной фазы в другую

(В корзине не может быть больше трех проектов одновременно.)

Таблица 1

Исходные данные	Создание	Завершение	Проверка
А	D	F
B	E
C

Работа над А начинается. D и Е находятся в фазе создания. F ждет проверки.

Таблица 2

Исходные данные	Создание	Завершение	Проверка
G		D	F
H	B	E
I	C	A

F проверяется. D и Е ждут проверки. G, Н, I – новые задачи, которые нужно выполнить. В и С в фазе создания. А в фазе завершения.

Таблица 3

Исходные данные	Создание	Завершение	Проверка
	G	D	F
H‑>	B‑>	E
I‑>	C‑>	A

Опции В и С уже созданы, но по правилу канбан их нельзя переместить в следующую корзину, в стадию проверки, пока не пройдут проверку А, D и Е. Нельзя начать работу над опциями Н и I, пока не освободится место в следующей корзине.

Я вводил эту систему в нескольких командах, и всегда она поначалу вызывала неприятие: корзины быстро заполняются – сначала корзина «Проверка», а потом и корзина «Завершено». Скоро становится невозможно начать ни один новый проект. Команды, которые привыкли оценивать свою производительность только по количеству завершенных историй, начинают топтаться на месте. Единственный способ начать работу над новыми опциями – исследовать те проекты, которые до сих пор не прошли проверку. Здесь часто нужны действия, не связанные с разработкой: нужно общаться с клиентами, изучать данные сплит‑тестирования и т. д.

Но очень скоро все учатся делать это. Сначала процесс происходит рывками. Разработчики могут завершить большой этап работы, а затем провести обширное тестирование и проверку. Изыскивая способы повысить производительность, они начинают понимать: если подумать о проверке с самого начала, то снизится общая производительность команды.

Например, стоит ли создавать новую опцию, которая не является объектом эксперимента по сплит‑тестированию? Это может сэкономить немного времени, но позже, во время фазы проверки, потребуется больше времени на тестирование. Та же логика относится к истории, которой разработчик не понимает. По старой системе он просто создавал ее и лишь потом понимал, зачем она нужна. При новой системе становится очевидно, что такое поведение непродуктивно: как можно проверить историю, не имея ясной гипотезы? В IMVU мы тоже с этим сталкивались. Я как‑то наблюдал, как разработчик убеждал провести тестирование идеи своего шефа, который хотел внести в продукт какое‑то незначительное изменение. Разработчик настаивал на том, что новую опцию нужно подвергнуть сплит‑тестированию, как и все остальные. Коллеги его поддержали: казалось совершенно очевидным, что нужно проверять все опции, независимо от того, кто поручил команде их разработку. (Должен признаться, слишком часто этим самым «шефом» был я сам.)

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