Философия DevOps

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

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

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

Мы не можем заставить людей согласиться на использование конкретного инструмента

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

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

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

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

Мы решили принять технологию X (или отказаться от нее), но люди не хотят ее использовать (или отказаться от нее)

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