В проектах используется много информационных и физических материалов, неизбежно возникает беспорядок. Как говорят физики, увеличивается энтропия. Как следствие, на поиск уходит время, возникает путаница и ошибки. Не допускать беспорядка — это фантастика, а вот регулярно наводить порядок вполне возможно. На практике организуют наведение порядка либо однократно, либо регулярно.
Беспорядок порождает проблемы
Проект выполняется группой людей, командой проекта. В процессе создаются документы, программный код, закупаются ресурсы. Что-то идет в дело, но может быть плохо организовано. А какие-то материалы больше не пригодятся.
Ненужные вещи. К ним относятся устаревшие версии документов, промежуточные записи, старые куски программного кода, избыточное сырье и материалы.
Хаотичная организация. Полезные документы могут храниться в электронной почте, общем чате, облачном хранилище, в распечатанном виде на столе. Программный код может храниться в разных ветках репозитория или без такового как совокупность разрозненных файлов.
Беспорядок бывает полезным до определенной степени. Но с ростом его объема возникают проблемы:
- Увеличиваются затраты на поиск нужной вещи;
- Увеличиваются затраты на хранение;
- Что-то теряется или повреждается из-за ненадлежащего хранения;
- Возникает путаница и рассогласованность в материалах проектах;
- Нарастает раздражение в команде.
Если беспорядок начинает приносить явные неудобства, то решение очевидно — беспорядок нужно снижать.
Как решают проблему в Тойоте
В 2005-2007 годах я вел в несколько проектов в компании Toyota Motor. В последний рабочий день перед Новым Годом в Toyota проводится интересный ритуал — «Kara-kara day» (за наименование не ручаюсь на 100%, мог забыть).
В этот день все сотрудники наводят порядок на рабочих местах. Разбирают рабочие столы, выбрасывают ненужные документы, полезные документы отправлять в архив или аккуратно раскладывают по стеллажам. Когда с физическим беспорядком покончено, приступают к виртуальным хранилищам: электронной почте, сетевым папкам и т.п.
В результате на новогодние каникулы сотрудники уходят с почти идеальным порядком на рабочих местах. И по возвращении приступают к работе с большим удовлетворением без вот этих вот мыслей «О боже, что за бардак, как не хочется работать…».
В этом ритуале участвуют все сотрудники Toyota — как из операционных подразделений, так и из проектной деятельности. Я тоже использую эту практику и не только в проектах. Правда, в бытовой сфере практика больше напоминает «Kara-kara week», т.к. за год накапливается слишком много хлама.
Как решают проблему в классических проектах
В классических проектах штатно предусмотрено регулярное наведение порядка. На примере Руководства к Своду знаний по управлению проектами (PMI PMBoK) видно, что по завершении каждой фазы проекта должен исполняться процесс «Завершение проекта или фазы». На схеме процесс входит в группу «Процессы закрытия».
При выполнении этого процесса руководитель проекта наводит порядок в материалах, передает документы и результаты принимающей стороне, извлекает уроки из опыта.
Чтобы не забыть что-то важное, удобно использовать для проверки чек-листы. Вот пример чек-листа для последней фазы проекта.
Извлечение уроков — это, своего рода, наведение порядка в голове. Команда проекта собирается вместе, осмысляет пройденный путь, принимает решения, что можно сделать лучше на следующей фазе проекта.
Как решают проблему в аджайл-проектах
В проектах с высокой неопределенностью используются целые семейства практик под зонтиком «agile». В каждой практике свой подход к поддержанию порядка. Общим является тот факт, что порядок поддерживать в аджайл-проектах нужно чаще. Сама природа этих проектов такова, что способствует более быстрому накоплению хаоса.
Например, в Экстремальном Программировании (XP) есть практика «рефакторинга» программного кода. По сути своей, это наведение порядка в алгоритме без изменения его функциональности. Код упрощается, комментируется, снижается его связность с другими функциями. Аккуратный код проще впоследствии использовать, пересматривать, расширять.
В Скраме есть несколько мероприятий, предназначенных для наведения порядка.
Уточнение бэклога (Product backlog refinement, PBR). Владелец продукта вместе с командой разработки пересматривает состав бэклога и буквально наводит в нем порядок. Крупные требования разбиваются на более мелкие. Неудачные формулировки требований переписываются. Владелец переосмысляет ценность тех или иных требований. Так бэклог становится более пригодным к дальнейшей разработке и упрощается планирование итераций.
Обзор спринта используется для наведения порядка в понимании продукта. Потенциальные пользователи продукта и приглашенные эксперты дают обратную связь по итогам демонстрации инкремента продукта. Так у Владельца продукта и команды разработки уточняется понимание потребностей пользователей, а также того функционала, который должен быть разработан в продукте.
Ретроспектива. На ретроспективном обзоре прошедшей итерации команда наводит порядок в своих инженерных процессах и способах внутрикомандного взаимодействия. На ретро принимаются решения о начале использования автотестов, непрерывной интеграции и других практик для поддержки качества продукта в условиях турбулентности требований.
Здесь же команда отказывается от неудачных практик взаимодействия: неуважительного обращения друг с другом, унижающей критики, трусливого замалчивания проблем. Эволюционно, с течением времени, процесс сотрудничества становится все более отлаженным. Так команда удерживает энтропию под контролем.
В сухом остатке
Наведение порядка поддерживает нормальную работу в проекте. По ходу проекта создаваемый продукт растет в объеме и сложности, но регулярные мероприятия удерживают беспорядок под контролем. Порядок можно наводить:
- в определенные периоды времени как в Toyota Motor
- в конце каждой фазы классического проекта
- в гибких проектах во время специальных ритуалов
