Как изменить существующие политики в организации?

Я предполагаю, что организация, желающая провести преобразование DevOps, имеет некоторые проблемы и политики, которые она заинтересована в изменении. Этот интерес может исходить от топ-менеджеров, менеджеров среднего звена или даже снизу вверх. Один из главных факторов, препятствующих этим изменениям, - это заставить других людей принять участие в этих изменениях.

Например, во многих случаях продвижение «новых» идей, таких как Agile, часто терпит неудачу. Люди сопротивляются переменам, и это похоже на стену, которая мешает хорошим вещам происходить. Тем не менее, есть мандат на хорошие вещи, которые должны произойти.

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

Вы должны понимать, что процессы меняют людей, которые следуют за ними. По мере того, как люди учатся, усваивают и совершенствуются в процессе, он меняет способ обучения решению конкретной проблемы. Совокупность сходных процессов усиливает друг друга в мышлении, которое человек использует для решения категории проблем, и в конечном итоге формирует набор ценностей, которые определяют решения и новые решения новых проблем.

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

Чтобы внести изменения, у вас есть следующие два варианта:

1. Привлеките человека, у которого уже будут правильные ценности и мышление, а в лучшем случае - понять процесс, которому нужно следовать без вашей помощи.
2. Привлеките и уполномочьте нового сотрудника, недавно нанятого, нового найма или перевода из другой команды в организации, и обучите его новому процессу, надеясь привить новое мышление, надеясь, что появится новый набор ценностей.

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

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

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

Взломай свою команду

Внесение изменений в вашу организацию сложно. У людей есть привычки, они сопротивляются переменам, и им часто комфортно со статус-кво. Чтобы внести изменения, не в определенном порядке, вот несколько инструментов, которые вы можете использовать.

1. Заставьте других испытать проблему, которую решает DevOps. Много раз преимущества DevOps понимаются только на теоретическом уровне вашей командой. Надеемся, что большинство проблем, возникающих во время развертывания, редко встречается остальной командой разработчиков или руководством. Чтобы это исправить, убедитесь, что вы открыто говорите о проблемах, когда они возникают, и укажите, как эта проблема не возникла бы, если бы команда использовала решение для непрерывной интеграции. Другая возможность - быть уверенным, что вы попросите разработчиков исправить проблемы, вызванные их кодом во время развертывания, а не исправлять их самостоятельно.

2. Найдите лидеров . Люди обычно следуют за лидерами, будь то менеджмент или просто самый популярный / командир в группе. Привлеките к себе этих лидеров, желая перейти к культуре DevOps, и придумайте, каким образом их можно увидеть, используя или пропагандируя лучшие практики.

3. Построй Доверие . Мы более склонны соглашаться с вещами людей после того, как мы уже договорились с ними один или два раза раньше. В идеале, вы можете найти небольшие улучшения, которые можно сделать без изменений в культуре, и развить этот успех. Однако, если это не вариант, задайте им простые вопросы и предложите простые предложения, чтобы они привыкли говорить «да» или соглашаться с вами.

4. Не стыдно повторяться. Повторение работает и, в конце концов, начинает действовать. Когда это возможно, упомяните, как здорово было бы, если бы команда использовала DevOps. Однако это работает только в том случае, если вы впервые создали доверие в своей команде.

5. Сделайте это приятным . Если вам разрешено создавать концептуальное подтверждение вашей ситуации DevOps, используйте симпатичные смайлики и веселые цвета в отчетах и ​​уведомлениях. Отправляйте смешные картинки, когда сборка не удалась. Убедитесь, что вы не раздражаете своими обновлениями.