Канбан

Grockit ввела «правило канбан», один из принципов методологии бережливого производства, и стала по-новому устанавливать приоритеты в разработке продукта. В соответствии с новой системой пользовательские истории не считались завершенными до тех пор, пока не позволяли получить подтверждения фактами. Все эти истории можно было отнести к одной из четырех фаз развития: исходные данные, создание, завершающая стадия (опция закончена с технической точки зрения) или «процесс проверки». Прошедшие проверку истории получали статус «мы знаем, что эта история — хорошая идея, и ее нужно сделать в первую очередь». Такая проверка обычно происходила в форме сплит-тестирования, показывающего изменения в поведении потребителей, но иногда включала в себя интервью с пользователями или опросы.

Правило канбан гласит, что в каждой из четырех фаз может находиться только определенное количество историй. По мере того как истории переходят из одной фазы в другую, корзины заполняются. Если корзина заполнена, в нее не положишь еще одну историю. Только после проверки истории ее можно удалить с доски канбан. Если проверка показывает, что история неудачна, соответствующая опция удаляется (см. табл. 1, 2, 3).

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

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

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

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