Привет! На связи Дмитрий Сарычев, менеджер проектов компании «Флант». Сегодня я расскажу о системе ценностей «Фланта», которую мы создали для услуги DaaS (DevOps-as-a-Service) и которая позволяет приходить к единому решению при разных мнениях.

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

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

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

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

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

Команда — наш главный ресурс и главная ценность

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

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

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

• К каждому сотруднику прикрепляем наставника — опытного инженера, который помогает погружаться в задачи. Наставники могут периодически меняться.

• Задачи назначаем с постепенным ростом уровня сложности. 

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

• Обсуждаем, что получилось не лучшим образом, и подсказываем, как это улучшить.

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

Все это можно свести к такому набору принципов:

• Каждый имеет право на ошибку. Например, если DevOps-инженер не протестировал код и это привело к проблеме, его не будут ругать. В этом случае ему объясняется, как нужно делать, чтобы не допускать эту ошибку снова. Наш подход — думать о том, чтобы ошибка не повторялась, а не искать виноватых.

• Знать всё — невозможно. Вопросы — это хорошо. Даже если они кажутся простыми. В первый месяц работы наши новые члены команды задают много вопросов опытным инженерам. Так мы видим, что человек заинтересован в работе и старается разобрать каждый аспект задачи. 

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

Сотрудничество с клиентом всегда должно быть win-win

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

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

Нагрузка на команду должна распределяться равномерно

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

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

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

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

Мы не обманываем команду, клиентов и партнеров

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

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

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

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

Планирование должно быть совместным и прозрачным

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

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

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

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

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

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

Мы не используем секретных практик. Инструменты, с которыми мы приходим на проект, можно использовать и без нас, а по всем вопросам мы всегда консультируем клиента. Практически все, что мы используем, это Open Source-решения. 

Мы должны понимать цели, которые важны для бизнеса клиента

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

• рост бизнес-показателей;

• стабильность работы продукта;

• развитие продукта.

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

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

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

Мы постоянно улучшаем процессы

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

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

Мы работаем в команде, а не по одиночке

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

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

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

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

Мы — не команда клиента. Мы — команда «Фланта» со своими управлением, ценностями и процессами

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

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

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

Наши клиенты — наши коллеги. Мы работаем с клиентом сообща ради единого дела

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

Вместо заключения

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

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

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

P. S.

Читайте также в нашем блоге:

• Наш опыт интеграции внешних DevOps-команд в команды клиента: этапы, процессы, трудности, неочевидные нюансы

• 15 лет «Фланта»: переход от сервисной компании к продуктовой, покупка внешнего продукта, вера в Open Source

• Большая перемена: как за 3 года мы пересмотрели управление проектами во «Фланте»