Когда речь заходит о ценностях компании, первая мысль у обычного разработчика (и не только разработчика) будет примерно такой: «Ну какие ценности? Пусть маркетологи об этом на своих презентациях говорят». А вторая: «Лучше бы задачи принимали быстрее, раз столько свободного времени».

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

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

Когда я пришел в «Курсон» младшим фронтенд-разработчиком и мне сообщили, что у компании есть корпоративные ценности и с ними нужно ознакомиться, я приуныл. Подумал: сейчас меня заставят их вызубрить, потом я смирюсь, надену галстук и стану как те люди, что ходят по городу по двое и с улыбкой спрашивают прохожих: «Veritye li vy v boga?»

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

Подробнее об этом ниже. Но сперва немного теории.

Теория

На мой вопрос, зачем компании вообще нужны ценности, наш генеральный директор Борис Халимовский ответил так: 

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

С теорией все.

(Не)много скепсиса

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

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

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

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

Далее я пройдусь по каждому из принципов в «Курсоне» и посмотрю на их реализацию в жизни.

«Приоритизировать гибкость»

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

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

В качестве одной из основных ценностей гибкость заявлена и у нас. А вот ее реализация.

• Гибридный график работы (часть рабочей недели в офисе, часть – удалено) согласован по умолчанию, так что люди сами определяют, в какие дни они работают удаленно, а в какие – в офисе. Никаких табличек с учетом этих дней не ведется. Конечно, могут быть исключения, когда необходимо присутствовать на какой-либо встрече очно, но для разработчиков это редкость. Тимлид фронтендеров сформулировал это просто: 

Сотрудник решает сам, где ему работать. Если он принял решение работать удаленно, против никто не будет. Главное – руководителю и команде не забыть сказать. 

• При желании можно полностью перейти на удаленку (и обратно). Кто-то работает удаленно с первого же дня работы; другие переходят на такой режим с течением времени. А еще можно уйти на удаленку на несколько месяцев, чтобы перезимовать в другой стране. Этой возможностью я с удовольствием воспользовался и уехал из Москвы до весны. Сейчас, зимой 2022 года, команда «Курсона» раскидана по разным часовым поясам – от Валенсии до Челябинска. С такой распределенностью команды связано гибкое начало рабочего дня – с 7 до 11 утра по московскому времени. 

• Для учета рабочего времени в офисе используется СКД, для удаленки – ручная отметка о начале и окончании рабочего дня во внутренней ERP-системе. Эта вещь немного раздражает, но об этом ниже.

• Под гибридный график были адаптированы все рабочие процессы: большинство встреч (даже не у разработчиков) были переведены в онлайн-формат; карты для покера планирования были заменены на бот в Slack и т.д.

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

И все же есть пара оговорок:

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

• Полной свободы, когда ты работаешь не один, все же не бывает: ты зависишь от команды, а команда – от тебя. Слово снова тимлиду фронтендеров: 

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

«Работаем командой, не по одиночке»

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

А если серьезно, то тут речь в первую очередь о том, что задачи в компании не просто спускаются руководителем, а формулируются с учетом мнения разработчиков, причем право голоса есть у каждого. Подразумевается, что сотрудник высказывает мнение, поскольку чувствует личную ответственность за проект. Как говорит тимлид бэкенд-разработчиков, «свои проекты надо защищать».

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

Регламент стараются сделать ненавязчивым: не надо писать заявок, предложений и прочей корпоративной корреспонденции. Если мне нужно перекрасить кнопочку, но я столкнулся с непреодолимой проблемой, с вопросом об этом можно очень быстро дойти до ВП и генерального. Впрочем, это мой взгляд, а я разработчик. Менеджерам и руководителям может быть сложнее. К тому же, определенные рамки все равно подразумеваются, и это, по словам гендира, нужно самим разработчикам. Ему слово:

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

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

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

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

«Лучше работать эффективно, чем много»

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

• Главный принцип – команды сами подбирают темпы, в которых они могут работать, не накапливая технический долг или переутомление. Владелец продукта делает прогнозы на основе этой скорости, а не наоборот. Иными словами, на открытии спринта наши тимлиды сообщают, сколько стори поинтов их команды готовы сейчас на себя взять. Решают именно они.

• Сотрудники постоянно учатся. Это касается не только прокачки хард-скиллов, но и саморазвития. Для развития первых компания купила подписку на онлайн-курсы для айтишников (тогда я подумал: «Подсаживают на крючок благодарности, хитрецы»); практически ежедневно практикуется парное программирование (более опытный – менее опытный разработчик); а чтобы джуны быстрее развивались, а сеньоры и мидлы не скучали, кто-то недавно предложил всем отправиться на CodeWars. Для саморазвития же у нас заведены группы по желаемым скиллам: тем, кто, например, хотел подтянуть английский, оплатили преподавателей одной хорошо известной онлайн-школы. Впрочем, не знаю, всем ли это нужно. Но обязаловки нет. Так что не уверен, что продолжу состоять в какой-либо из групп через полгода.

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

• Для работающих здесь долгое время это очевидно, но новички не сразу привыкают: по любому вопросу нужно сразу же обращаться к коллегам. Подскажут и помогут: с кодом, декомпозицией, инструментами. Сложности или ошибки – это не страшно, их принято признавать и проговаривать вслух. Рефлексия помогает всей команде не наступать на прежние грабли в будущем. Мне, как младшему разработчику, особо утешительно слышать вопросы, нет ли у меня проблем с задачами и не нужна ли помощь. А если нужна, то получать ее в виде совета или в формате парного программирования.

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

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

• Еще приветствуется использование техники Pomodoro, а готовые инструменты для тайм-трекинга есть в Jira и PhpStorm. Задумка такая – это помогает не только дать понять тимлидам, какой задачей ты сейчас занимаешься и не закопался ли с ней, но и дают готовые рамки для рефлексии: если превысил лимит, то почему; в чем были сложности; как команда и компания могут тебе помочь.

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

«Работа должна приносить удовольствие»

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

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

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

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

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

В общем, как-то так:

Отдельно про вежливость

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

Из уже упоминавшегося исследования PwC следует, что в России для работников характерны скромность и принижение собственных заслуг, тогда как «доминантное поведение» социально допустимо только для начальства. Кроме того, я согласен с распространенным мнением, что в нашей стране (шире – в русскоязычном сегменте интернета) сложилась весьма суровая культура критики, которая многими воспринимается как должное, но шокирует представителей тех стран, для которых резкость и категоричность в суждениях не характерны.

С последствиями этого мои коллеги сталкивались на практике, когда в команду приходили новички и боялись объяснять свои решения во время парного программирования или созвонов в Slack. Кажется, они представляли себе процесс примерно так:

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

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

А теперь о проблемах

Все описанное выше звучит хорошо, но и проблем достаточно – как теоретических, так и прикладных.

1. Как быть с масштабированием? Да, кое-что удалось реализовать сейчас, но нас не так много. Это работает для – условно – 50 человек. Но если нас станет 500? А если придет сразу много новичков? Мы попробовали предусмотреть решение, изменив процесс онбординга (см. выше рассказ о менторстве для вновь пришедших сотрудников), но как это будет работать на длинной дистанции, покажет лишь время – вот и проверим курсоновскую гибкость и принципы совершенствования процессов. Кстати, если у вас есть соображения на этот счет или примеры удачных решений, будем благодарны, если поделитесь.

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

3. Основные формулировки звучат абстрактно, но, кажется, с этим ничего не поделать. Идеология всегда абстрактна. Беда в том, что из-за этого может случиться недопонимание. Например, «лучше работать эффективно, чем много» порой переводится как «лучше закрыть побольше задач, сидя до ночи, тогда я буду считаться эффективным работником» или «надо, чтобы было больше сделано, значит, надо больше работать». Это часть российской культуры: переработки социально одобряются. Так что приходится постоянно объясняться и совершенствовать формулировки.

4. По ценностям могут быть разногласия. Позиция у руководства примерно такая: если ценность не подходит сотруднику, то никто не пытается его или ее перевоспитать, если противоречие не мешает работе; разнообразие мнений – это хорошо, а формулировка ценностей – это не результат, а процесс. Но всегда ли получится соблюдать этот баланс, я не знаю.

5. Подпункты заявленных ценностей могут пересекаться, это иногда путает и отбивает желание вникать. Так что формулировки надо уточнять всем вместе (см. пункты 2 и 3).

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

7. Наконец, главное: как оценить эффективность, реальную пользу ценностей? А не лучше ли без них? Может быть, нужны какие-то объективные метрики, а не только субъективные отзывы разработчиков? На этот вопрос ответа пока нет. 

   Пока что менеджмент просто ведет мониторинг самочувствия сотрудников. Раз в месяц бот Polly в Slack предлагает нам пройти опрос о своем опыте в «Курсоне», основанный на практиках компании Crisp. Еще в рамках квартальных перформанс-ревью не только руководители оценивают сотрудников, но и сотрудники своих руководителей – вплоть до генерального директора.

Бонус для тех, кто думает, как сформулировать или внедрить ценности

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

Вопрос: «Как вообще придумываются ценности? Дадите списать?»

Ответ: «Ценности не нужно придумывать. Их нужно выявлять». 

Если команда сплоченная, а у компании есть цель, то ценности более или менее очевидны: это те принципы, которые отличают этот коллектив от остальных. Так что начать формулировать просто: нужно спросить себя, в чем эти отличия.

Также можно просто опросить команду. Только не спрашивать напрямую, какие должны быть у компании ценности (мало кто сразу поймет, о чем речь), а выяснить, почему сотрудники работают именно тут, а не где-то еще. Что им здесь нравится и отсутствию чего они радуются?

Этого достаточно, чтобы появились первые идеи, но важно вовремя остановиться. Есть разные методологии, но практически все они рекомендуют ограничиваться 3–5 пунктами. Каждая из ценностей может быть выражена словом, фразой или даже прописана в подпунктах – главное, чтобы все было понятно именно вашей команде.

До того, как беретесь за выявление ценностей, стоит посмотреть на примеры других компаний: Google, Kellog’s, 3M и любимый пример – Hewlett-Packard. Этой теме также посвящено большое количество книг, но, чтобы начать, читать их вовсе не обязательно.

Процесс займет несколько итераций, прежде чем вы остановитесь на варианте, который устроит всех. Чем раньше начнете, тем лучше.

Вопрос: «Почему в ценностях не упоминается сфера деятельности?»

Ответ: «Ценности связаны с командой, а сферы могут меняться».

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

Вопрос: «А нужно ли прописывать в ценностях пользу обществу?»

Ответ: «Можно, но очень осторожно».

Это было одной из наших ценностей в первой итерации, но мы убрали этот пункт по простой причине: от абстрактного желания приносить пользу никому не лучше. Много кто искренне желает помочь бездомным и ветеранам, остановить загрязнение окружающей среды или изобрести лечение от рака, но мало кто делает конкретные шаги. Лучше на 100% отдаться одному направлению и повлиять на мир, чем хвататься за все и сразу, но лишь номинально. Конечно, вы можете прописать пункт о пользе обществу, но сделайте это так, чтобы команде было ясно, как именно вы собираетесь эту пользу приносить.

Заключение

В том, как реализуются ценности компании в «Курсоне», есть и преимущества, и сложности. 

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

Сложности – в том, что многое еще нужно реализовать на практике, чтобы ощутить результат. А еще в том, что мы не знаем, как это будет масштабироваться, нужен ли контроль начала рабочего дня (в нынешнем виде он нас не слишком устраивает), где границы в свободе выбора проекта (и может ли их в принципе не быть). Да и скепсис не во всем преодолен. Если у вас есть удачные примеры решений подобных проблем, пишите.

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

Так что не прощаемся.