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

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

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

---

Что такое agile-коуч и зачем он нужен?

Виктор Климов

Я работаю agile-коучем, а раньше был программистом. В Sidenis я чуть больше семи лет. У меня был долгий путь от джуниора до сеньор java-разработчика. Почти на протяжении всего этого пути я еще попутно был скрам-мастером. И понял, что люди должны заниматься тем, что у них получается лучше всего. Поэтому перешел на agile-коучинг. Общаться с людьми у меня получается лучше, нежели программировать.

— И как давно ты это понял?

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

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

— Agile-коуч — звучит экзотично. Расскажи что конкретно ты делаешь?

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

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



— Может быть расскажешь конкретную историю, где команды делают что-то, что ты считаешь неправильным, а ты приходишь и помогаешь исправить?

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

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

---

Какие продукты делает Sidenis

— Когда ты пришел, компании уже было много лет?

Она намного старше. Компания существует более 20 лет. На протяжении всего этого времени она оказывает услуги по разработке ИТ решений для страхового и перестраховочного бизнеса. Наши основные заказчики — это большие корпорации, такие как SwissRe или Allianz. Они занимают лидирующие позиции в области перестрахования и страхования.

У нас есть в офисы в четырех городах. В Санкт-Петербурге, там больше всего людей. Есть офис в Томске, Калининграде и Цюрихе. В Цюрихе сосредоточена в основном бизнес-часть, в Санкт-Петербурге, Томске и Калининграде — центры разработки.



— Я так понимаю, компанию создали специально, чтобы работать со SwissRe?

SwissRe наш самый крупный и давний партнер. Но это только часть бизнеса, у нас есть и другие заказчики, и свои собственные продукты. Например, сервис онлайн-страхования RiskMarket. Сервис интегрирован с ИТ системами страховых компаний и позволяет искать страховки с лучшими условиями по актуальным тарифам. Сиденис является ИТ партнером Ooniq — платформы социального страхования, основанной на блокчейне.

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

— У вас больше собственных проектов или проектов для других компаний?

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

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

---

Структура компании и работа между часовыми поясами

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

Да, мы растем. Растет портфель заказов от текущих партнеров, появляются новые заказчики, да и разработка собственных продуктов также требует больше ресурсов. Сейчас у нас в компании во всех четырех офисах больше 200 человек — около 140 в Питере, около 50 в Томске, 15 в Калининграде и примерно 20 человек в Цюрихе.  У нас интернациональная команда. Есть люди из России, Швейцарии, Германии, Австрии, Франции, Китая и других стран.



— В чем была логика такого распределения по городам? Между Томском и Петербургом далеко, разные часовые пояса. Наверное, неудобно.

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

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

— У вас сотрудники работают только в офисах или есть удаленные?

Только в офисах. Есть возможность один день в неделю работать удаленно из дома, но в основном — работа идет в офисе. Когда мы находим сотрудников в других городах, мы им предлагаем переезд в Питер, Калининград или Томск. Так сложилось исторически. У нас никогда не было удаленных сотрудников.

— Как люди распределены по командам?

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

— Как проходит работа — от принятия заказа до сдачи продукта заказчику?

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

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

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

— На собрания и переговоры уходит много времени?

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



— Ты считаешь, разработчикам это действительно нужно — знать, как работают другие?

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

---

Специфика заказчика и список запрещенных технологий

— Можешь рассказать про особенности и специфику работы со страховой корпорацией?

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

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

— Расскажешь про этот список?

Преимущественно ведется Java-разработка, и несколько проектов на .NET, но в целом сильно меньше. То есть, точно разрешены Java 8 и .NET, RabbitMQ для передачи данных. В принципе, это покрывает большинство нужд промышленной разработки, но мир растет и развивается

Например, нам был нужен фреймворк Spring для Java, но он был запрещен. Разрешали только Java Enterprise Edition. Нам удалось доказать, что это для нас важно и нужно, что это ускоряет разработку.

Во фронтенде у нас разрешены Angular 6, JavaScript c React и TypeScript.



— Для чего нужен список технологий?

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

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

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

— Есть технологии, которые вы хотели бы применить, но не можете?

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

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

---

Найм в компании без разрекламированного бренда

— Где вы ищете людей?

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

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

— Как проводите собеседование?

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

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

Спрашиваем более глубокие теоретические вопросы, чтобы понять, с каким опытом человек к нам пришел.

— Не кажется, что теорией можно отсеять и хорошего разработчика? Все же гуглится.

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

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

— Есть черта, из-за которой вы точно откажете кандидату?

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

— Если разработчик гениален, но не знает английского — все равно не возьмете?

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

— Через продакта.

Всегда работать через продакта не очень эффективно. А при использовании скрама практически невозможно.

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

— Как много времени проходит от заявки кандидата до оффера?

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

— Человек попадает в компанию. Что дальше?

У нас есть welcome-тренинг. Там все рассказывается про компанию, как мы живем и работаем. Человека знакомят с офисом, людьми и проектами, а дальше ответственность за то, как он вольется в коллектив, лежит на команде.

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

— Что вообще привлекает людей идти к вам работать?

Я бы сказал печеньки…

— Печеньками никого не удивишь.

…но у нас фрукты!

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

---

Жизнь внутри, виртуальные счета и время на саморазвитие

— Чем вы мотивируете и поощряете сотрудников?

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

Такой же виртуальный счет есть на каждого отдельного человека. Его можно тратить на улучшение рабочего места, фитнесс, образование, конференции, книжки.

— А как боретесь с выгоранием?

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

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

Зачастую не сильно заметно, что человек выгорел. Он по-прежнему ходит на работу, но его ничего не интересует. И если это уже случилось, значит что-то пошло не так. Это надо обсуждать с каждым отдельно и решать, что конкретно сделать. Я знаю одного человека, который решил эту проблему переводом на другой проект. У него появилась мотивация работать из-за смены деятельности, задачи приносили больше радости.



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

— А сами рабочие задачи интересные?

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