С чего начать
Вариант 1: эксперимент в 6 недель
Не обязательно менять все процессы сразу. Если компания не готова к глобальному изменению, проведите эксперимент длительностью в 6 недель. Вот из чего он состоит:
-
Сформируйте проект, достаточно значимый для компании, который реально закончить за 6 недель. Будьте пессимистичны и добавьте немного времени на первый раз.
-
Заберите на проект одного дизайнера и одного разработчика. Добейтесь гарантии, что никто не будет их отвлекать во время эксперимента.
-
Вместо голосования просто презентуйте команде проект. Важно сделать полноценную презентацию, со всеми ингредиентами, упомянутыми ранее. Познакомьте их с методом, договоритесь, что они сами обнаруживают и создают задачи.
-
Организуйте для команды единое рабочее место (реальную комнату или чат).
-
Мотивируйте команду быстро добиться готовности первого участка.
На этом этапе не стоит тратить силы на карту участков или подробные отчёты о прогрессе. Наверняка вы заметите прогресс уже потому, что отдали в работу хорошо сформированный проект, защитили команду от отвлекающих факторов и предоставили им свободу принятия решений.
Используйте успех как аргумент для более полномасштабного внедрения.
Вариант 2: сначала только формирование
Иногда нет возможности получить команду на 6 недель. Тогда можно начать внедрение, ограничившись первым этапом — формированием проекта. Воспользуйтесь методом Shape Up, чтобы сформировать проект, затем презентуйте его и пустите по принятому в вашей компании процессу (даже если это означает напихать задачи в бэклог, как в шреддер).
Качественно сформированный проект может убедить коллег попробовать и другие практики.
Вариант 3: сначала только циклы
Ещё можно начать работать циклами. Команды, которые привыкли к двухнедельным спринтам, испытают облегчение, избавившись от постоянного планирования и получив возможность «поймать волну».
Результат важнее плана
Прокачайте свои навыки достижения результата прежде, чем навыки формирования и исследования. У вас может быть лучшая в мире идея, но она не имеет смысла, если вы не можете превратить её в реализованный проект. Дайте команде почувствовать, что она может доводить дело до конца, и уже потом можно заниматься улучшением исходных материалов.
Результат важнее всего
Часто страшно давать командам свободу решать, что делать по проекту. Что если они неграмотно распорядятся временем? Что если дизайнер или разработчик окажутся в какой-то момент без задач?
Чтобы преодолеть этот барьер, обратите внимание не на микро-уровень, а на макро. Спросите себя — если проект будет успешно завершён в течение 6 недель, будет ли это означать, что мы всё сделали правильно? Если проект завершается, цели достигаются и у команды есть ощщущение прогресса — является ли это успехом? Если да, то не нужно управлять каждым часом каждого работника. Результат важнее всего.