Пример: сравнение систем контроля версий
Системы контроля версий со временем записывают изменения в набор файлов. В 2000 году компания CollabNet основала проект Subversion, используемый в качестве системы контроля версий и ревизий программного обеспечения с открытым исходным кодом. Эта система была совместима с системой CVS (Concurrent Versions System, система одновременных версий). В феврале 2004 года появилась подверсия 1.0 (Subversion 1.0), или svn. Использование и свойства svn диктовались технологиями и привычками пользователей. Ядром архитектуры svn явилась концепция централизованного хранилища. Благодаря этому хранилищу пользователи могли контролировать, кто был допущен или не допущен к выполнению изменений.
Годом позже, в 2005 году, появилась система Git. Это также система контроля версий программного обеспечения с открытым исходным кодом. В этой системе делался упор на децентрализованной системе контроля версий, быстродействии целостности данных и поддержке распределенных нелинейных рабочих процессов. В результате каждый разработчик получал полный локальный контроль. В то время как можно было адаптировать централизованный рабочий поток и установить «центральное» хранилище, могли применяться и гибкие процессы. В результате появилась возможность выбора используемой технологии. Несмотря на то что в этом случае увеличивается время «разгона», улучшенные функциональные средства позволяют ускорить выполнение организационных изменений.
Пример: автоматизация ручной инфраструктуры
Большинство используемых решений автоматизации инфраструктуры аналогичны с точки зрения функциональных свойств, даже если отличаются в реализации. Каждый из инструментов может привести как к поощрению, так и к подавлению разных аспектов сотрудничества.
Во многих организациях конфигурирование системы выполняется в ручном режиме. Процесс конфигурирования и обновления документируется с помощью контрольных списков. Пропущенный шаг может привести систему в неопределенное состояние, для выхода из которого потребуются значительные усилия.
Когда Адам Джейкоб разрабатывал программу Chef, он пытался создать решение, которое могло бы использоваться в разных организациях. Программа Chef была разработана таким образом, чтобы поддерживать абстракции, используемые при конфигурировании и менеджменте. При этом был создан язык, который давал программистам возможность с помощью кода определять инфраструктуру и политику.
Создать язык, который позволял бы детально учитывать интересы разработчиков, системных администраторов, инженеров по обеспечению качества и безопасности, довольно сложно. С помощью Chef, а не путем повторного использования терминологии, которая расставляет приоритеты для разных ролей, Джейкоб создал новую терминологию, включающую ресурсы и рецепты.
Весьма важно учитывать инструменты общения, подобные инструментам, рассмотренным в примере про двух скалолазов (см. главу 2). Эти инструменты могут как оказаться полезными, поддержав созданный нами пакт, так и оказать медвежью услугу, сбив нас с правильного пути. Конечно же, все зависит от способа использования каждого инструмента. Если, например, пытаться использовать среду общения с низкой степенью безотлагательности, например электронную почту, в ситуациях, когда требуются немедленные ответы, это приведет к возникновению проблем. Также проблемы появятся, если вы попытаетесь описать что-либо словами в ситуации, когда иллюстрации быстрее и эффективнее передадут суть дела.
И наконец, при выборе инструментов нужно сбалансировать связанность и гибкость. Если же применяется много способов коммуникации, людям придется выполнять множество действий для поиска нужной информации. Эта информация может находиться в сообщении электронной почты, документе Google Doc или на wiki-странице. Также придется искать наиболее эффективный способ передачи информации людям – с помощью мгновенного сообщения, текстового сообщения или получения доступа к рабочему столу пользователя. С другой стороны, при недостатке способов коммуникации также возникнут проблемы. Все мы слышали истории о компаниях, которые по каждому поводу проводят собрания, когда можно проще и быстрее решить возникающие проблемы с помощью электронной почты.
Наш пакт, основанный на всеобщем понимании, будет полезным только в том случае, когда есть традиции или обычаи, на которые можно опираться при выборе наиболее эффективного средства. Но при этом необходимо наличие гибкости, позволяющей выбрать инструмент, который был бы подходящим для выполнения определенной работы.
Аудит экосистемы инструментовПомимо выбора новых инструментов, которые вы можете добавлять в вашу среду, следует проверить состояние экосистемы инструментов. Первый тест для многих инструментов заключается в проверке соответствующей функциональности, существующей в вашей среде. В процессе аудита среды, выполняемого в целях идентификации экосистемы инструментов, выясните информацию о том, кто получает доступ к инструментам, а также об общем использовании инструментов. Также определите, находятся ли несколько инструментов в одной и той же категории и есть ли перекрывающиеся инструменты в вашей среде. Это позволит вам выяснить области потенциального совершенствования, которые могут потребовать дополнительного улучшения или замены инструментов.
Критически важным для эффективного использования инструмента является согласование процессов и желаний отдельных пользователей. Чрезмерный акцент на процессах приводит к высокой цене для отдельных пользователей. Это связано с тем, что им приходится поддерживать сложный контекст, связанный с этими процессами. Подобная деятельность может отвлекать от работы над проектом. Если же процессам уделяется слишком мало внимания, это приводит к отстраненности команды от применяемых инструментов и методов. То же самое касается отдельных сотрудников. При этом потребуется время на коррекцию понимания, слияние работы или проверку наличия дублирующих видов работ. Выполнение подобных базовых операций является ключевым для всех аспектов идентификации и выбора инструментов. Особенно важны они при масштабировании организаций.
Как правило, цель использования инструментов заключается в оказании помощи при создании среды, в которой люди могут концентрироваться на решении реальных проблем. Создание среды подобного рода гарантирует предоставление возможностей по управлению успешной командой, а также требует приложения постоянных усилий. Аудит подобного рода не относится в категории задач, которые можно выполнить один раз, а потом забыть о них. Чтобы создавать и поддерживать эффективную среду, рядовые сотрудники и менеджеры должны использовать проактивный подход.
Устранение инструментовСледует выполнять регулярные обзоры текущих процессов и инструментов, которые позволят убедиться в эффективности их использования. Благодаря отслеживанию технических долгов и долгов, связанных с автоматизацией, можно идентифицировать процессы и инструменты, которые необходимо устранить. В результате предотвращаются ситуации, когда использование инструмента увеличивает объем работ. Также облегчается идентификация и устранение инструментов, выполняющих одни и те же функции. Это позволяет снизить затраты и ликвидировать беспорядок.
Эти обзоры также должны включать выполнение регулярных проверок сотрудников, в ходе которых исследуются базовые истории, которые воздействуют на сотрудников и выполняемую ими работу. Задайте следующие вопросы.
• Что восхищает/расстраивает вас?
• Что способствует пополнению/истощению вашей энергии и мотивации?
• Как вы оцениваете выполняемую работу?
• Какова степень вашего влияния?
• Что мы должны прекратить делать?
• Что мы должны начать делать?
Задавайте эти вопросы только тем людям, которые регулярно используют инструменты для выполнения текущей работы. Решения, принятые в пользу выбора или устранения инструментов, должны основываться на мнении пользователей этих инструментов. Эти решения не должны спускаться сверху людьми, которые не имеют практического опыта работы с этими инструментами.
Улучшения: планирование и оценка изменений
Внедрение изменений требует времени. Независимо от того, идет речь
