Пять аспектов, которые CIO нужно учитывать при внедрении Open Source

Неправильный ввод в строй Open Source-инструмента может вызвать у сотрудников не только его неприятие, но и неприятие изменений в целом. Технический энтузиаст Сет Кенлон делится на портале Enterprisers Project советами, какие моменты нужно учитывать при вводе в эксплуатацию Open Source-продукта.

Вы уже слышали это раньше: Open Source — везде. Он в вашем кармане, компьютере, его можно найти в вашей организации. Наш мир в течение десятилетий полагается на открытые технологии, такие как TCP/IP, DNS, Apache, SSL, TLS и многие другие, но проблема заключается в том, что в основном они рассматриваются как инструменты разработчика. Многие люди не используют эту технологию, если у них нет резервного лицензированного приложения от какого-нибудь известного бренда. И все же глобальная тенденция такова, что общество начинает открывать для себя Open Source. Многие организации расширяют свои горизонты и позволяют независимым проектам играть центральную роль в повседневной работе ИТ-специалистов. У инструментов Open Source есть много преимуществ: основные из них хорошо документированы, но помимо них можно подобрать более специфичные инструменты, если того требует характер проекта.

Пять лучших практик по внедрению Open Source

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

1. Семь раз отмерь, один раз отрежь

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

Затем обходные пути становятся привычным маршрутом. Чтобы проторить его, неудовлетворенные сотрудники потратили время на обучение, и в итоге все обернется тем, что они будут вначале нерешительно, а затем преднамеренно пользоваться альтернативой вашему Open Source-решению. Возможно, вам не терпится развернуть новый инструмент как можно быстрее, но помните: у вас должно быть столько времени на подготовку, сколько вам нужно, потому что как только он вступит в строй — другого шанса настроить все заново у вас уже не будет. Прежде чем приступить к полномасштабному разворачиванию решения, проведите пробный запуск, доверив его внутренней или внешней, но надежной команде тестировщиков. Затем вам предстоит удостовериться, что программа должным образом масштабируется, отвечает требованиям всех заинтересованных сторон и является более гибкой, чем набор имеющихся инструментов. Если день запуска приложения совпадает с вашим отпуском, но вы ощущаете дискомфорт, то вы к нему не готовы. На самом деле это шутка: уходить в отпуск в день запуска программы не рекомендуется.

2. Изучите инструменты сами и научите пользоваться ими других

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

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

3. Позвольте ПО на базе Open Source раскрыть свои сильные стороны

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

Открытое ПО может работать вместе с проприетарными приложениями и инфраструктурой (по крайней мере, если это разрешено проприетарными компонентами), оно также может отлично существовать с фирменным защитным ПО вашей организации. Многие компании сокращают количество проприетарных зависимостей, поэтому Open Source требуется время, чтобы адаптироваться. Это значит, что с его внедрением не нужно торопиться: проведите тщательное тестирование на отказоустойчивость и сыграйте на сильных сторонах архитектуры Open Source.

4. Возьмите на себя ответственность за работу Open Source

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

Это делается не для того, чтобы облегчить работу апстрима, а чтобы придать уверенности вашей организации, что ваш инструмент поддерживается и контролируется и что вы в курсе потребностей ваших людей. Люди не приучены предлагать функции для ПО, потому что в проприетарном софте избыточный энтузиазм не приветствуется. Если вы обратитесь к своим сотрудникам с подобным предложением, это может вызвать у них удивление, недоуменные взгляды, затем по э-почте вы получите ссылки на никогда не существовавшие кнопки. Демонстрируемое ими замешательство — запрос на функцию в скрытой форме, поэтому внимательно следите за своими коллегами. Это не означает, что Open Source превратит вашу организацию в компанию-разработчика ПО, но зато вы взрастите сотрудников, которым комфортно применять те инструменты, которыми они постоянно пользуются, и которые стремятся улучшить их, чтобы они работали еще лучше.

5. Готовьтесь к улучшению

После внедрения Open Source в организации CIO нужно быть готовым к тому, что он вызовет у сотрудников приток энтузиазма. Мотивированные сотрудники, которым нужно сделать свою работу, — это самые изобретательные люди, причем настолько, что ни один Open Source-проект или CIO даже не могут себе представить насколько. Ваши коллеги найдут скрытые возможности, обходные пути, интересные плагины и даже собственные сценарии и рабочие процессы, что стало возможным благодаря тому, что у вашего набора Open Source-инструментов были сняты все ограничения. Что касается роли CIO, то его задача заключается в том, чтобы стимулировать повседневные инновации, помогать им быстро распространяться и даже разбавлять их своими идеями. Этот совет не является откровением, особенно для успешных компаний, поэтому его не стоит игнорировать.

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

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