Мы не можем заставить людей согласиться на использование конкретного инструмента
В небольших организациях можно попытаться получить согласие у каждого человека на использование (или отказ от применения) какого-либо инструмента. Более того, в маленьких стартапах эта методика окажется успешной. Но по мере «разбухания» команды и организации это будет все труднее и труднее. После достижения определенного размера и уровня сложности вряд ли целесообразно налаживание обратной связи с каждым человеком, использующим тот или иной инструмент, не говоря уже о получении согласия на использование данного инструмента.
Как только вы поняли, что достичь единодушного согласия на использование инструмента не представляется возможным, можете переходить к поиску решения, имеющего смысл для большинства вариантов использования. Вполне возможно, что вы захотите идентифицировать людей, использующих инструменты ежедневно. Для таких людей есть смысл в оптимизации потребностей и вариантов использования. Не имеет смысла уделять особое внимание людям, которые используют инструмент эпизодически. Возможно, стоит сформировать группу из нескольких тестеров, которая вероятно представляет большинство общих вариантов использования инструмента. Можно также позволить людям стать бета-тестерами, чтобы помочь оценить возможные решения.
Многие инженеры и техники не хотят каких-либо перемен. Как правило, они выступают против внедрения новых инструментов не потому, что не испытывают каких-либо проблем, а потому, что просто к ним привыкли. Разработайте структурированный способ осуществления обратной связи, позволяющий высказать мнение об используемых инструментах. Благодаря такой связи вы сможете установить, как часто пользователи сталкиваются с проблемами, а также идентифицировать сами проблемы. И не забывайте о том, что те, кто громче всех жалуется на проблемы, не обязательно выражают мнение большинства.
В то время как гибкость, безусловно, важна, в некоторых областях имеет смысл располагать инструментами, которые не обговариваются в рамках команды или организации. Например, если имеются инструменты, которые позволяют поддерживать SOX, PCI либо другой уровень соответствия, имеет смысл настаивать на том, чтобы все, кто работает в этой области, использовали данные инструменты. Вероятно, есть смысл свести набор необходимых инструментов к минимуму, хотя, безусловно, есть области, в которых использование таких инструментов оправданно.
Мы решили принять технологию X (или отказаться от нее), но люди не хотят ее использовать (или отказаться от нее)
Степень открытости людей, использующих новый инструмент в работе, во многом зависит от процесса, в котором был выбран этот конкретный инструмент. Если у вас сложилась ситуация, когда было принято решение «сверху вниз», возможно, менеджером, который имеет меньший опыт работы с данным инструментом или рабочим потоком, чем обычные сотрудники, это может послужить весьма веской причиной для отказа от применения инструмента. Чтобы избежать появления подобных ситуаций, исследуйте проблемы, которые вы пытаетесь решить. Также поработайте с людьми, которые будут часто использовать этот инструмент, как описано ранее. Как отмечено выше, возможно, придется пройти длинный путь, прежде чем подобные ситуации перестанут возникать.
Обратите внимание на то, как изменяется стиль общения и как откатить эти изменения обратно. Представьте, что компьютеры сотрудников управляются централизованно, из точки, в которой изменения программного обеспечения могут выполняться ИТ-персоналом удаленно. В одно прекрасное утро люди приходят на работу и видят, что был установлен новый компонент программного обеспечения. Причем это было сделано без объяснения функций этого компонента и, что более важно, без сообщения о цели этого изменения. В подобной ситуации сотрудники, скорее всего, будут сопротивляться изменениям, даже если они полезны.
Проинформируйте людей заранее о предстоящих изменениях набора инструментов, которые повлияют на них. Дайте им возможность поучаствовать в процессе изменений. Вы можете обнаружить, что люди, которые, по вашему мнению, даже не знают, как работать с инструментом, имеют свое, и весьма неплохое, мнение об этом инструменте. Как только будут приняты решения, сообщайте об этом заранее, задолго до внедрения изменений. Дайте людям больше времени для перехода к использованию нового инструмента. Либо дайте им возможность привыкнуть обходиться без инструмента, от которого вы собираетесь отказаться. Объясните, что именно изменилось, как был сделан выбор. Дайте людям знать, как они смогут связаться с вами или сообщить о возникших проблемах.
Описанная в разделе методика относится как к добавлению новых инструментов, так и к отказу от существующих. Эти изменения приобретут необратимый характер и станут полезными при наличии достаточного уровня общения и эмпатии в организации.
Часть V. Масштабирование
Глава 14. Масштабирование: критические точки
Эта глава посвящена способам выявления и преодоления трудностей, возникающих на основных этапах жизненного цикла организаций. На первый взгляд может показаться, что проще все свести к идее «корпоративных devops-практик», как обычно поступают многие, когда идет речь о методологиях devops, которые не используются в стартапах и небольших компаниях. Но это было бы слишком просто, хотя подобные devops-практики и включают некоторые специфичные для корпораций моменты, которые будут рассмотрены в настоящей главе. Гораздо лучше было бы описать процесс изменения компании с течением времени, будь то рост и развитие стартапа или разделение крупной организации на две отдельные компании. С помощью масштабирования описываются эволюция, рост и продвижение организации как единого объекта на всех этапах ее жизненного цикла.
Знакомство с масштабированиемДовольно сложно предугадать тот момент, когда в команде, отделе или организации необходимо внедрять те или иные изменения. Поскольку эти изменения порой неочевидны, весьма полезными будут некоторые советы по их внедрению.
Если мы рассматриваем прогресс в качестве составной части разнородного ландшафта, который либо способствует, либо мешает будущим начинаниям, это поможет нам планировать, выполнять и корректировать текущее состояние с учетом предварительно поставленных целей. Эти цели могут достигаться как постепенными, но управляемыми действиями, так и динамическими скачками. Опыт обычно подсказывает, когда и как следует менять направление прогресса, а также то, какие стратегии нужно применять в тех или иных средах.
В этой главе освещаются причины возникновения проблем, возникающих в процессе масштабирования организаций. Кроме того, вниманию читателя предлагается детальное рассмотрение взаимодействия между тремя рассмотренными ранее столпами эффективных devops-практик и различными разновидностями проблем, возникающих в процессе масштабирования. В продолжение темы предыдущих глав будут рассмотрены некоторые неправильные представления и общие вопросы, возникающие в процессе устранения проблем.
Рассмотрение корпоративных devops-практикНе существует «корпоративных devops-практик», предусматривающих использование уникальных инструментов и методик, которые применялись бы исключительно в компаниях, в которых работает большое количество сотрудников. Также не существует единого определения успеха, позволяющего получить однозначный результат, к которому стремятся все компании и организации. Чтобы успешно внедрять изменения, нужно превратить организацию в удобный для применения и сбалансированный инструмент, обладающий необходимой степенью гибкости.
Как в крупных компаниях, так и в небольших организациях необходимым условием для выработки силы, баланса и оперативности является devops-пакт. Культура сотрудничества и близости способствует укреплению «слабых связей» и более оперативному распространению информации внутри компании. Крупные организации отличаются друг от друга способами применения принципов, а не самими принципами.
Многие полагают,
