Когда компания Грега Беснера CultureIQ еще делала свои первые шаги, он стал привлекать ее сотрудников – а на тот момент их насчитывалось всего несколько человек – к пешим походам. Помимо укрепления доверия и формирования более тесных взаимоотношений с коллегами, эти мероприятия преследовали и другую цель — определение базовых ценностей, на основе которых будет выстраиваться культура компании по мере ее роста.

Культура песен у костра

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

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

«Я был одним из первых инвесторов в Zappos, и рост числа работников организации с 70 до 5 тыс. происходил на моих глазах, – отметил Беснер. (Zappos.com — интернет-магазин обуви, который превратился в хрестоматийный пример правильной и успешной корпоративной культуры, «помешанной» на качестве обслуживания клиентов. — Прим. ред.) – Внимание, уделяемое культуре и ее влиянию на сотрудников, сыграло очень важную роль. Я приобрел богатый опыт использования культуры руководителем для усиления вовлеченности, поднятия морального духа, формирования бренда, определения показателей эффективности: хорошую и устойчивую организацию невозможно построить, не имея культурных основ».

«Упор на культуру способен усилить любую компанию, независимо от отрасли, размеров и занимаемой ею доли рынка, – добавил Крието Тамура, вице-президент по маркетингу компании Treasure Data, названной Forbes одним из лучших провайдеров облачных сервисов. – Причем никаких дорогостоящих вложений для этого не требуется».

Бесплатная культура

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

«Сдержанность Хиро [Хиронобу Йошикава, соучредитель компании] стала отличным примером для всех остальных, – подчеркнул Тамура. – Он выступает за отделение критики и комментариев от их авторов и стремится к тому, чтобы все были услышаны и пользовались уважением. И мы все стараемся поступать точно так же. Ориентация на сдержанность и автономность, еще одна базовая ценность Treasure Data, уходит своими корнями в философию движения с открытым кодом. Работа над проектами или фрагментами кода, которые представляются глобальной аудитории и подвергаются комментариям и критике со стороны других технических специалистов по всему миру, – лучший пример этих двух культурных принципов. Кроме того, это способствует усилению разнообразия. Мы убеждены в том, что написание программного обеспечения с открытым кодом – один из лучших способов вовлечения разработчиков и повышения интереса со стороны сообщества. Широкое поле деятельности открывается и для разного рода одиночек и непризнанных, которые в полном объеме могут принять участие в работе этой массовой сети взаимодействия. Ощущение расширения индивидуальных возможностей ни с чем не сравнимо, не менее интересно наблюдать и за публичными спорами, развернувшимися вокруг вашего кода».

Празднование успехов

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

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

Как убедиться в том, что проектируемые вами программы и сервисы не перестанут и в будущем соответствовать нуждам клиентов и потребителей? Если этот вопрос для вашей организации актуален, вероятно, вам нужен инженер по надежности систем (systems reliability engineer, SRE). К данной категории относятся инженеры-программисты, отвечающие за надежную и безотказную работу приложений как в ближайшем будущем, так и в долгосрочной перспективе, с учетом требуемой масштабируемости.

«Иногда их называют инженерами по надежности сайтов или инженерами по надежности сервисов, но в любом случае эта роль неразрывно связана с концепцией DevOps, которая завоевывает все большие симпатии ИТ-служб, – указал проповедник DevOps и специалист компании VictorOps по инцидентам Джейсон Хэнд. – Чаще всего такие люди востребованы в организациях, занимающихся облачными сервисами, SaaS, PaaS и IaaS. Они должны обеспечивать функционирование своих сервисов в течение 24 часов 7 дней в неделю и 365 дней в году. Организациям, которым важна надежность, безотказность и устойчивость, SRE необходим как воздух, ведь каждая минута простоя оборачивается серьезными потерями».

Кто такой SRE?

Чем занимаются SRE? Иногда они представляют собой некий гибрид разработчика и системного администратора, ведающего одновременно написанием нового программного кода и обеспечением бесперебойной работы программных сред и приложений.

«На многих предпритиях есть как те инженерные команды, которые отвечают за клиентские приложения, так и те, что занимаются базовыми системами. Но есть и SRE, взаимодействующие с этими командами на протяжении всего жизненного цикла разработки программного обеспечения, чтобы разработчики не забыли о масштабируемости и безотказности функционирования, которым в перспективе будет отводиться особая роль, – отметил Хэнд. – Это особенно важно на этапе проектирования и первоначальной разработки, поскольку гарантирует работу создаваемых решений не только сейчас, но и через полгода, год и через два года. Если мы не хотим, чтобы какую-то часть кода пришлось переписывать, то должны убедиться в том, что учтены все будущие потребности».

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

«Роль SRE эволюционировала с учетом интересов двух этих разнородных групп, – подчеркнул Хэнд. – Зачастую противоречия между ними приходится устранять, даже если хотят они одного и того же: приложений, программного обеспечения и сервисов, отличающихся легкостью управления, а также высоким уровнем готовности, устойчивости и масштабируемости».

Дипломатия

Как разъясняет в своем блоге инженер по надежности компании Atlassian Патрик Хилл, SRE выступает посредником «в вековой борьбе между командами разработки и эксплуатации», разрешая споры о том, «что и когда можно запускать».

«Основная проблема заключается в следующем, – пояснил Хилл. – Разработчики хотят предлагать новые функции массам и радоваться достигнутому. Специалисты по обслуживанию, со своей стороны, желают убедиться в том, что эти функции ничего не нарушают. Исторически между ними ведется непримиримая борьба, в которой эксплуатирующие подразделения пытаются по возможности тормозить выпуск всего нового, а разработчики ищут способы обойти воздвигаемые на их пути барьеры».

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

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

Этимология названия

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

«Для небольших организаций, у которых нет необходимых ресурсов, чтобы нанять специального SRE, неплохой временной мерой станет обучение уже имеющегося сотрудника процессам и процедурам, которые нужны при выполнении обязанностей системного администратора и повышения квалификации при использовании Chef, Ansible, Puppet и других инструментов автоматизации, – считает директор по набору ИТ-персонала кадрового агентства Mondo Стивен Зафарино. – Поскольку SRE требуют высоких зарплат, некоторые клиенты могут предложить профессиональную разработку кому-то из уже имеющихся у них сотрудников. Другой вариант – поискать фрилансера или консультанта, который даст нужный совет или примет участие в работе над конкретным проектом».

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

«Сегодня соответствующую зону ответственности зачастую разделяют между собой другие специалисты ИТ-службы – инженеры DevOps, программисты и системные администраторы, – подчеркнул Зафарино. – Открытые вакансии SRE заполнили лишь несколько наших клиентов. Но по мере интеграции концепции DevOps и принятия ее принципов спрос на SRE будет расти, а роль эта начнет принимать все более определенные очертания».

В сатирической заметке, опубликованной недавно в журнале New Yorker, стереотип удаленного работника вызывает улыбку – взъерошенный, не понимающий, где находится, забывший, когда последний раз общался с людьми, и вот уже много дней не снимающий своей вечной пижамы. Он привык по любому поводу обращаться за помощью по телефону 911. Есть ли в нарисованном портрете зерно истины? Новое исследование, проведенное специалистами Future Workplace и Polycom, полностью развеивает стереотип, согласно которому удаленные работники представляются ленивыми, асоциальными и непродуктивными.

Отчет «Человеческое лицо удаленного работника» был составлен по итогам опроса 25 234 сотрудников из 12 стран: США, Канады, Бразилии, Японии, Великобритании, Индии, Сингапура, Германии, России, Франции, Австралии и Китая. При этом 55% опрошенных занимают руководящие должности, 58% в той или иной мере несут за кого-то ответственность или заботятся о ком-то, а 68% являются родителями. Исследование показало, что на самом деле удаленные работники готовы сопереживать, желают общаться и поднимают телефонную трубку даже чаще, чем их работающие в офисе коллеги.

Разрушение стереотипов

«Несмотря на бытующее представление об оторванности удаленных работников от остальной части коллектива, исследование показывает, что они даже более общительны и стараются наладить прочные взаимоотношения с коллегами, – отметила партнер Future Workplace Жанна Майстер. – Новые инструменты, поддерживающие коммуникации и взаимодействие, побуждают работников отвечать на звонки, изыскивать время для личных контактов и формировать длительные отношения. Об этих позитивных аспектах удаленной работы упоминают довольно редко».

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

Большая часть исследования была посвящена оценке преимуществ удаленной работы, к которым относятся: лучший баланс работы и личной жизни, усиление вовлеченности, повышение лояльности и снижение текучести персонала, увеличение производительности труда. 70% респондентов отметили улучшение сбалансированности работы и личной жизни, 63% – повышение производительности труда, 38% – расширение возможностей в части заботы о детях. При этом определенные выгоды получают не только работники, но и работодатели.

«Одно из главных преимуществ для работодателей заключается в получении глобального доступа к талантам, и это очень важно, – подчеркнула Майстер. – Это стратегический путь к управлению вашим бизнесом! Некоторые предприятия, с которыми мне довелось работать, сообщали о многомиллионной экономии на офисных площадях, хозяйственных расходах, электроэнергии и других затратах. Так что удаленная работа интересна не только сотрудникам».

Рабочее место будущего

«Возможность работать удаленно и гибкие условия – один из важных факторов при найме, особенно для молодых работников, – отметил директор компании Polycom по маркетингу Джим Крюгер. – При формировании рабочего места будущего необходимо обеспечить гибкость корпоративных политик, такая гибкость становится ключевым конкурентным преимуществом при найме. Она помогает заполучить лучшие таланты, привлечь и удержать молодые кадры, особенно в условиях, когда идет сегментация рынка. Сегодня в организациях начинают понимать перспективность такого подхода: 73% опрошенных нами компаний предлагают гибкие условия труда. Думаю, что делается это именно для привлечения нового поколения работников, выходящих на рынок труда».

Рост сопереживания

Исследование продемонстрировало, что новые технологии совместной работы усиливают способность сотрудников к сопереживанию и помогают им выстраивать отношения с коллегами. Об этом сообщили 98% опрошенных. Около половины отметили, что благодаря видеоконференциям лучше узнали коллег лично. А две трети респондентов заявили, что их «любимый» сотрудник работает в другом месте.

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

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

Хотя принципы скорой (agile) разработки изначально были предложены создателями программного обеспечения, сегодня они применимы практически в любой сфере. В их основе лежат сотрудничество, открытые коммуникации, доверие и независимость, эффективность и непрерывная выдача результатов. Все это способно сформировать долгосрочный позитивный эффект почти в каждой структурной части вашей организации. На прошедшей недавно в Вашингтоне конференции Agile Alliance 2015 старший консультант компании Industrial Logic Тим Оттингер изложил шесть принципов концепции скорой разработки, которые можно использовать фактически повсеместно.

Помните: иногда работа выглядит не так, как вы привыкли

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

«Работа заключается в том, чтобы думать, а не стучать по клавишам, — указал Оттингер. – Мозговые штурмы, обсуждение и даже простое пребывание вместе с членами команды – все это часть работы. Иногда самые удачные идеи и решения приходят в голову не во время многочасового написания кода, а во время прогулки. Нужно считать не время, в течение которого пальцы бьют по клавишам, а время, когда остаются в игре».

Формируйте ценности как можно раньше и как можно чаще

Скорая разработка подразумевает предоставление заинтересованным лицам ценностей на ранней стадии и довольно часто состоит из простой последовательности шагов: планирование, разработка, улучшение, тестирование и выпуск. Затем все повторяется снова. Ключевым условием является выполнение всего перечисленного за достаточно короткий промежуток времени (так называемый спринт), после чего последовательные изменения вносятся по результатам полученных отзывов.

«ВременнЫе ограничения скорого подхода снижают вероятность аварий, ошибок, выбора неверного направления и прочих проблем, – подчеркнул Оттингер. – Рамки сужаются. Будучи разработчиками, мы не знаем достоверно, что на самом деле нравится людям в нашем продукте и как они собираются его использовать, потому что у людей в голове свои тараканы и люди постоянно меняют свое мнение. Нужно преподнести им какой-либо вариант как можно раньше, чтобы у них была возможность сказать 'да', 'нет' или 'почти'. На протяжении нескольких месяцев вы постоянно разочаровываете заказчиков ради того, чтобы в конечном итоге сделать их счастливыми».

Делите все на части — пусть даже со стороны это напоминает хаос

Если ваша команда завалена несметным количеством объемных проектов, необходимо упорядочить их. Разделяйте работу на составные части, которые могут быть реализованы в рамках спринта. Повторяйте это до тех пор, пока все задачи не будут разбиты и распределены с учетом ресурсов каждой команды, с тем чтобы ими можно было управлять. Все это требует интенсивного предварительного планирования – нужно убедиться в том, что задачи бизнеса правильно определены и сформулированы.

Иногда вы будете получать примерно такие указания: «А добавьте-ка сюда интернет-магазин». И здесь возникает целый ряд вопросов. Насколько объемна такая задача? Какие операции будут выполняться в результате ее решения? Как все это должно выглядеть? Как будет использоваться? Задайте соответствующие вопросы, а затем разбейте ответы на более мелкие составляющие. В том-то и состоит мощь хаоса. Со стороны кажется, что ничего не происходит (в силу большого числа составляющих) , хотя сделать предстоит очень много, но группы специалистов различного профиля обладают всеми компетенциями, необходимыми для выполнения этой работы.

Акцентируйте внимание на новых возможностях, а не на скорости. Скорость придет

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

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

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

Будьте готовы к вечному совершенствованию

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

Учитывайте эмпирический характер скорых методов

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