Управление разработкой в «горизонтальных» компаниях: расшифровка онлайн-встречи. Часть 2

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи «Управление разработкой в «горизонтальных» компаниях», где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан. 

Сегодня публикуем вторую и последнюю часть митапа: это вопросы «из зала», которые задали слушатели гостям. Пост получился объемным, поэтому, если не хотите читать, то посмотреть видео можно ниже (запустится сразу с нужного момента — там, где закончилась первая часть).

Гости

• Сергей Кононенко, CTO в Райффайзенбанке

• Никита Прудников, CTO в Mindbox

• Михаил Юматов, руководитель разработки в Циан

• Ведущий: Алексей Рыбак, CTO «Везёт».

Темы второй части

• Чем leadership внутри «плоской» команды отличается от менеджмента?

• Как в «горизонтальной» структуре решаются вопросы безопасности? 

• Какие плюсы от «открытых» зарплат в Mindbox?

• Как команда соблюдает technical excellence?

• Как в «горизонтальных» компаниях шарятся ресурсы?

• Есть ли у вас и как устроен Performance Review?   

Чем leadership внутри «плоской» команды отличается от менеджмента. Как решаются вопросы безопасности. Technical excellence. Решение конфликтов

Алексей Рыбак: Давайте сейчас перейдем к вопросам из зала. Я начну зачитывать те вопросы, которые есть в текстовом чате. Первый вопрос был от Димы Кушникова. Сергей, а чем leadership внутри команды отличается от менеджмента?

Сергей Кононенко: Менеджмент — command and control. Command and control никто из этих троих людей, которые входят у нас в leadership team, не занимается.

Алексей Рыбак: Понял. Следующий вопрос тоже от Дмитрия. Банковское обслуживание — довольно регулируемая индустрия. Наверняка есть огромное количество требований, которые необходимо соблюдать, чтобы регулярно проходить аудит безопасности? Что случилось с политикой безопасности в процессе трансформации?

Сергей Кононенко: Ничего не случилось, они все с нами. Аудиты есть не только по безопасности, есть много других аудитов, которые мы регулярно проводим: как внутренние, так и внешние, так и групповые из Raiffeisen Group. 

Алексей Рыбак: Следующий вопрос был тоже от Дмитрия. Сергей, кто и как контролирует, что команда соблюдает договоренности, technical excellence? Как происходит изменение требований technical excellence?

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

Алексей Рыбак: Хорошо, следующий вопрос. По-видимому, уже всем. Вопрос от Вадима Назарова. Отличный, кстати вопрос. Как организуется решение конфликтов, если платформенной команде в рамках своего проекта требуются какие-то доработки от продуктовых команд, а у продуктов тоже свой бэклог?

Сергей Кононенко: Мне, наверное, проще всего ответить. У нас нет платформенных команд, которым нужны какие-то особенные доработки. Платформенные команды выставляют definition of done, что значит — разработка на их платформе. Если этот definition of done под продуктовые команды не соблюден, то их инкремент просто не принимается в платформу.

Алексей Рыбак: Понятно. Никита, как у вас?

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

Алексей Рыбак: То есть через какую-то специальную встречу, где происходит какая-то договоренность. Хорошо, тогда такой вопрос. Во всех liberated структурах есть всегда такой стиль, когда ты, с одной стороны… короче, вежливое «нет», вежливое постоянное «нет». Структура позволит это сделать, но в случае, если постоянно идет отказ: «Да, но не сейчас. Нет времени, слушай, такой важный проект. Да, техдолг, но не сейчас», — и постоянно, постоянно откладывается. Что произойдет? Встречаемся: «Слушай, не могу, не можем». 

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

Алексей Рыбак: У тебя есть платформенная команда, которая переходит с одной версии API или базы данных на другую. И логику надо переписать, потому что тот SQL, который я написал, или тот API, который я использую, новым софтом не поддерживается. Я должен переписать достаточно важный кусок. Я не хочу его трогать, оно поломает дофига всего. Я объяснил это продакту, который говорит: «Не-не-не, вы вчера сломали что-то. И в прошлом месяце что-то сломали. Нет, сейчас мы делать не будет, потому что у нас очень важные планы, бла-бла-бла…»

Никита Прудников: Да, я понял, могу ответить.

Алексей Рыбак: Ну, привет! А когда? Вы встретились, сказали: «Встретимся через две недели и поговорим». За две недели произошло еще что-то, через две недели тоже. Вот такой сценарий. Дальше?

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

Алексей Рыбак: Кто влезет в бизнес-логику? Платформенная команда влезет в бизнес-логику, перепишет какие-то вызовы, платформу?

Никита Прудников: В том числе она может так сделать, конечно.

Алексей Рыбак: Я понял. У вас были такие кейсы? В реальности были такие ситуации или нет? Как они разрешались?

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

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

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

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

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

Никита Прудников: Может быть, но я не могу вспомнить пример такой задачи, если честно. Из-за того, что очень близко коммуникация… С одной стороны, всё привязано к бизнесу, и мы обучаем архитекторов мыслить от бизнеса. То есть нам не нужны рефакторинги в воздухе, они всегда замотивированы чем-то. И спустя годы архитекторы могут объяснить продукту, зачем им это нужно, потому что они работают с продуктом в одной команде постоянно и занимаются приоритезацией части роадмэпа.

Алексей Рыбак: Хорошо. Михаил, у вас конфликты тоже решаются больше на более ранней стадии общения? Или можешь вспомнить какие-то примеры, когда они выплеснулись куда-то, не смогли решить?

Михаил Юматов: Бывают ситуации, когда команда платформы не может договориться с продуктовой командой. В этом случае они подключают меня или это может дойти до уровня CTO, где мы можем разрешить этот конфликт. И это либо укладывается в квартальное планирование, если это какие-то большие истории, которые затрагивают много продуктовых команд, и нужно разрезать весь этот проект продуктовым командам плюс платформе. Либо это какие-то небольшие истории в рамках квартала. И, соответственно, либо продуктовые команды самостоятельно договариваются вместе с платформой, либо не договариваются и эскалируют выше. И мы уже вместе принимаем решения.  

Открытые зарплаты: какие от них плюсы. Рыночные зарплаты, воронка кандидатов. Описание задач 

Алексей Рыбак: Ясно, спасибо. Никита, к тебе вопросы. Два вопроса. Первый вопрос от Димы Кушникова. Какие плюсы вы получаете от открытых зарплат?

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

Алексей Рыбак: Да, но, с другой стороны, появляется в том числе и определенное давление отрицательного характера, которое никуда не деть, а так бы его могло бы и не быть.

Никита Прудников: А какого отрицательного давления?

Алексей Рыбак: Например, произошла какая-то ошибка или необходимо удержать сотрудника. И закрытые зарплаты позволяют сделать определенный дисбаланс. Но поскольку он не является открытым, то он не оказывает никакого отрицательного…

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

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

Алексей Рыбак: То есть ты думаешь, что настолько все привыкают, в том числе к такого рода культуре, что и уже уходить некуда? Ты это имеешь в виду?

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

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

И мы сейчас с HR, с каким-то таким вещами занимаемся. Возможно, восприму твой совет про один на один, что надо реструктурировать в этом месте. То есть такая проблема есть.

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

Алексей Рыбак: Разные бывают ситуации, особенно когда большие коллективы. Такой еще вопрос, перекликается с одним из последних, по-моему, вопросов. А как часто вы делаете рыночный обзор зарплат? И есть ли у вас процесс, который оценивает, произошел ли gap up? Или люди скромно работают, а потом в какой-то момент им поступает предложение и они находятся в ситуации, когда: «Блин, нифига себе. Это почему у нас…»

Никита Прудников: Ну, gap большой. Но это то, про что я рассказал.

Алексей Рыбак: Вопрос был довольно прямой: рыночные ли у вас зарплаты? Я здесь развернул: как часто у вас происходит такого рода ревью? Что из себя представляет этот процесс?

Никита Прудников: Ревью обычно происходит с точки зрения вакансий. Я и еще ряд людей, мы занимаемся интерированием вакансий на HeadHunter. И нам, естественно, с учетом того, что полностью открыты зарплаты внутри компании, этот гэп понятен. То есть у нас есть какая-то вилка на HH, к нам приходят какие-то люди по воронке…

Алексей Рыбак: Прости, Никита, не понял. Как он вам понятен? С HeadHunter вы взяли эту информацию?

Никита Прудников: Мы делаем вилку на HeadHunter в вакансии, и к нам в воронку приходят какие-то люди. У нас нон-стоп конвейер собеседований. У меня каждый день примерно по одному собеседованию C#, лидов, я участвую.

Алексей Рыбак: Правильно я понимаю, что вы собираете это с потока входящих?

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

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

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

Алексей Рыбак: Хорошо. У тебя есть понимание, какая текучка внутри компании?

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

Алексей Рыбак: То есть 2%? Если 50 человек…

Никита Прудников: Я тут боюсь обмануть, честно тебе скажу. Просто я сейчас что-то из памяти вспоминаю. Кажется, оценка такая.

Алексей Рыбак: В любом случае это какие-то части. Давай двинемся дальше. Был еще вопрос, тоже, Никита, тебе. У нас минута Mindbox. Вадим Назаров спрашивает. Чем занимаются архитектор? Есть ли он? Кто ему ставит задачи? Кому подчиняется? Взаимодействует ли он с командой?

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

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

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

Алексей Рыбак: Понял. Никита, спасибо большое. У нас есть первый смелый. Спасибо большое, Георгий. Поднял руку, оказался на панели среди спикеров. Георгий, у вас вопрос. Прошу вас. Только включите, пожалуйста, микрофон.

Георгий: Всем привет. Во-первых, спасибо, Алексей, за такое мероприятие, интересно послушать, как бывает у людей. У меня вопрос к ребятам, к коллегам. Много было сказано по поводу задач. А кто занимается описанием задач? Участвуете ли вы в этом? Насколько глубоко описываются у вас задачи?

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

Алексей Рыбак: Спасибо большое. Кто хочет ответить из вас?

Сергей Кононенко: Давайте я отвечу. Задачи прорабатываются внутри команды. Если задача не имеет понятного acceptance-критерия, то есть критерия, по которому мы поймем, что задача сделана, то, скорее всего, она будет сделана не сразу, не очень качественно, и у нас будут сюрпризы. Поэтому, пока команда не поймет, что они понимают, что нужно сделать, скорее всего, задача в работу не пойдет.

Алексей Рыбак: В связи с этим у меня вопрос. Это искусство — описывать задачи, в том числе это искусство… Мы это всегда называли PRD, спеки – не важно. Спеки — более технический текст, PRD — более продуктовый. Там идет взаимодействие с дизайнером, там идет взаимодействие, может быть, не с одним продактом. Продакт, если будет описывать задачу, зашьется. Дизайнер не всегда готов описывать. UX-человек, если есть отдельный UX-специалист или UX-дизайнер, то он, может быть, каких-то аспектов продуктовых не знает. То есть это всегда магия.

Два вопроса в связи с этим. Как добиться того, чтобы не умерли все эти люди в процессе описания, потому что иначе это будет бесконечно. И кто все-таки это делает? Кто это делает и как добиваемся того, что это не занимает бесконечное время?

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

Алексей Рыбак: Давай представим себе, что мы члены команды, а ты продакт. Ты принес идею, которая вообще никаким образом не описана, просто ее на словах принес. И дальше все остальные сели и сказали… Появилась некоторая задача, которая должна быть описана. Но это же часть бэклога, получается, описать такую-то задачу?

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

Алексей Рыбак: Спасибо, Сергей. Михаил, ты включал микрофон, видимо, хотел что-то ответить.

Михаил Юматов: У нас все опять же зависит от команды. Где-то, может быть, в наиболее сложной предметной области есть project-менеджер, который берет какую-то идею сырой от продакта и описывает уже более детально. И с этим детальным описанием уже выходит к команде разработки, где вся команда ревьюит это дело.

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

Как решаются вопросы безопасности

Алексей Рыбак: Следующий вопрос был… Уже вопросы из Youtube пошли. Вопросы безопасности как решаются в ваших структурах? Я так полагаю, что так или иначе вопросы безопасности идут через платформенные команды. И они есть как в Mindbox, так и в Циане. 

А есть ли платформенные команды все-таки у вас, Сергей? И вопросы безопасности каким макаром решаются? Потому что команда собралась и сама решила, как делать — с точки зрения безопасности это не самый лучший set up.

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

Алексей Рыбак: У меня в связи с этим следующий вопрос. Во-первых, резюме. Достаточно мощная служба безопасности, автоматизация процесса деплоя таким образом, чтобы происходили почти все проверки автоматически.

Ревью. Означает ли это, что это какой-то процесс фоновый, или означает ли это, что каждый коммит должен пройти ревью безопасника?

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

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

Сергей Кононенко: Chaos Monkey?

Никита Прудников: Я думаю, скорее, пентест ты имеешь в виду.

Алексей Рыбак: Больше пентест, но нормальный пентест, когда никто не предупрежден.

Сергей Кононенко: Пентесты и BCP практикуем обязательно. Но совсем без предупреждений мы не можем, потому что банк работает 24/7. Вы, извините, приедете на заправку, а у нас пентест, и вы не сможете заплатить карточкой.

Алексей Рыбак: Почему пентест приведет к тому, что я не могу заплатить карточкой.

Сергей Кононенко: А мало ли, пенетрейшн удастся, и система упадет.

Алексей Рыбак: Ах, в этом смысле. Хорошо. Давайте дальше, про безопасность сообразили.

Как в «горизонтальных» компаниях шарятся ресурсы. Performance Review. Как техлиды оценивают разработчиков не из своего стека

Алексей Рыбак: Михаилу вопрос. Как вы шарите ресурсы между командами, если шарите?

Михаил Юматов: Ресурсы — это люди, наверное? Если люди, то стараемся этого не делать. Вот такой ответ. Иногда такое бывает, но это ад и для команд, и для человека.

Алексей Рыбак: Использует ли кто-то таймшиты? Если нет, то почему? Я не знаю, что такое таймшиты. Видимо, какая-то диаграмма или какое-то расписание?

Михаил Юматов: Это, видимо, отчетность по времени, как я понимаю.

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

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

Практика — заставлять людей писать, сколько времени они чем занимались, порочная. Мы стараемся этого не делать, конечно.

Алексей Рыбак: Кто-нибудь еще хочет ответить?

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

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

Алексей Рыбак: Хорошо. Ребята, еще быстрый вопрос всем. Просто давайте «да» или «нет». Есть ли у вас performance review? Никита?

Никита Прудников: Все сложно. Что ты подразумеваешь под performance review?

Алексей Рыбак: Performance review — это когда у тебя есть процесс, когда ты оцениваешь работу каждого человека в отдельности.

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

Алексей Рыбак: Если он не завел эту карточку?

Никита Прудников: Если он работает как работает, в смысле нет вопросов с точки зрения стейкхолдера и других чуваков, то регулярного performance review нет. Если есть вопросики, тогда да, поехали. То есть — on demand.

Алексей Рыбак: Сергей, как у вас?

Сергей Кононенко: Есть performance review команды. У команды есть performance-цели. И раз в год команда оценивается, и от этого зависит, получит команда бонус или не получит команда бонус.

Алексей Рыбак: Раз в год и всей командой?

Сергей Кононенко: Да.

Алексей Рыбак: Понял, спасибо. Как у вас, Михаил?

Михаил Юматов: Есть — как оценка вовлеченности команды. Но это, скорее, больше про здоровье команды. И конкретного сотрудника тоже в том числе.

Алексей Рыбак: То есть у конкретного сотрудника есть performance review?

Михаил Юматов: Да.

Алексей Рыбак: Раз в какое время?

Михаил Юматов: Если говорить про какой-то общий процесс, то это может быть раз в полгода или год. Но на регулярной основе — с лидом на one-to-one — это постоянный процесс скорее.

Алексей Рыбак: Окей, то есть он такой… Процесс performance review, если этот процесс, то у него есть определенный таймлайн, подготовка, заранее известные сроки, сколько раз в год. У кого-то один раз, у кого-то четыре раза. Хорошо, ладно.

Алексей Рыбак: Давайте двинемся дальше. Опять два вопроса Никите. Как техлиды оценивают технический уровень разработчиков не из своего стека?

Никита Прудников: У нас практически full stack. Просто из-за специфики компании… У нас нет мобильной разработки, у нас очень ограниченный фронт, по сути, ограниченный облачной админкой нашего продукта. И очень много бэка. И большой проблемы с тем, что человек не разбирается в соседнем стеке, нет. Нам буквально только-только потребовались фронтенд-heavy истории. И в одной из команд появился выделенный фронтенд-лидер, который формулирует архитектуру фронта и все такое. И есть точка экспертизы и с точки зрения другого стека. Тут большой проблемы нет: ни в тех командах, где нет фронта, ни в той команде, где есть фронт. А с ним самим работаем совместно.

Алексей Рыбак: И следующий еще был вопрос, тоже, Никита, тебе. Про T-shape. В процессе работы компании возникает специалист с уникальным набором навыков. Как и надо ли это как-то выравнивать с рынком?

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

Мне кажется, с этой точки зрения сильно помогают как раз открытые зарплаты. Просто из-за того, что мы не можем сформулировать суперформальные критерии, что такой человек с таким набором навыков стоит вот столько. Это случается органически, потому что этот человек работает в команде с другими людьми. И по сути — вопрос в ценности. То есть насколько этот конкретный T-shaped ценен для команды и компании. Это и элайнится с зарплатой в итоге.

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

Сторипоинты. Системы премирования, мотивационные схемы. Перерасход людей

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

Никита Прудников: У нас нет сторипоинтов. У нас пулятся карточки одинакового размера.

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

Никита Прудников: Это уже команда внутри делает. Скрам-мастер изобретает любой удобный ему процесс с командой, как ему удобнее ставить себе совместно с PO на следующую каденцию. Но обычно они ориентируются: «Мы прикинули, вот сколько карточек. Обычно мы столько делаем».

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

Алексей Рыбак: Михаил, Сергей, у вас есть сторипоинты?

Сергей Кононенко: Есть, работаем по классике. То есть команда, planning poker, все дела.

Алексей Рыбак: Какие есть варианты сторипоинтов? Сколько: 1 – 2, 1 – 5, 1 – 48?

Сергей Кононенко: Обычно это исправленное Фибоначчи, то есть: 1, 2, 3, 5, 8, 10, 20.

Алексей Рыбак: Мы когда-то давным-давно, более десяти лет назад, когда пробовали, степени двойки использовали. Короче, что-то тоже похожее.

Сергей Кононенко: Можно использовать все что угодно, главное, чтобы команде было комфортно квантифицировать свой got feeling — сделаем или не сделаем, много или мало.

Алексей Рыбак: Понял. Что у вас, Михаил? Сторипоинты есть?

Михаил Юматов: Нет, у нас сторипоинтов нет, у нас часы обычные.

Алексей Рыбак: Окей, вопрос от Коли Крапивного. Что происходит, если при текущих приоритетах бизнеса какая-то команда оказывается перегружена, какая-то недогружена? Есть ли процесс ребалансировки? Если есть, то как часто за последний год менялись составы команд в связи с изменением нагрузки?

Сергей Кононенко: Мне, наверное, проще всего ответить. Никакой ребалансировки нет, потому что каждая команда — отдельная структура, которая живет в своих реалиях.

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

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

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

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

Второй подход такой, что у меня есть мой персональный план в зависимости от того, какой на меня фидбэк или еще что-то и какой у меня грейд, назовем это так. Это какая-то часть. И еще есть какая-то часть командная. Как у вас?

Сергей Кононенко: У нас есть определенный бюджет, который из всех переменных складывается. И он по определенным формулам раскидывается по командам. Внутри команд — это история, связанная с грейдами.

Алексей Рыбак: Понял. Михаил, как у вас?

Михаил Юматов: У нас, кроме повышения в рамках роста между грейдами или внутри грейда, нет никаких премий.

Алексей Рыбак: А как у вас в Mindbox, Никита?

Никита Прудников: Профшаринг.

Алексей Рыбак: Не понимаю, разъясни, пожалуйста. 

Никита Прудников: Часть прибыли компании распределяется среди команд. Там тоже формула непростая: частично мы учитываем выручку продуктов или иногда рост выручки, если мы понимаем. 

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

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

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

Запускаем новый продукт и говорим: «Ладно, мы продуктовая компания, нам нужна микрокоманда вокруг этого продукта. Кто нам для нее нужен? Очевидно, нам нужен тот человек, который будет делать фронт. Если мы делаем при этом какое-то мобильное приложение, значит, нам нужен и iOS, и Android. Нам нужен бэк, обязательно нам нужен QA, QA на все. Одного QA на такое количество людей мало. Ой, bus factor, давай по два. Ой, раз два, давай еще добавим QA». В результате команда разрастается.

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

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

Алексей Рыбак: Но все-таки…

Никита Прудников: Я, кстати, соглашусь, у нас похожая история. В смысле, мы стараемся…

Алексей Рыбак: Но iOS разработка и бэкенд — совсем разные.

Сергей Кононенко: Да-да-да, все правильно, поэтому у нас команды, которые прямо совсем full stack, допустим R-Mobile какой-нибудь, банковское приложение клиентское, там, пожалуйста — и Java, и Scala, и Kotlin, и iOS, и базы данных, и DB2 — чего там только нет. Но в момент один собирается по одному одному человеку из каждой экспертизы. А до конца года у них цель, чтобы каждый освоил еще две экспертизы.

Алексей Рыбак: Понятно. Михаил, что-нибудь можете добавить?

Михаил Юматов: Я немножко прослушал сам вопрос. Цель собрать команду, подсосать откуда или что?

Алексей Рыбак: Нет. Когда мы делаем новые направления, бывают команды, которые выпускают консюмерные продукты не в каком-то стриме большом, а например, игры делает или какие-то социальные приложения. Делают какие-то небольшие кусочки, эксперименты. И, когда запускается программа, команда, у которой есть мобильная история, веб-история, то у тебя появляется сразу же определенное количество мобильщиков, фронтендеров, QA. И команда сразу становится достаточно большой. Хотя кажется, что для того, чтобы выполнить такой проект, его можно было бы подмешать к какой-то другой команде, более большой, или нужно было бы выделять целую отдельную команду?

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

Да, действительно есть проблемы с тем, что, условно, разработчик iOS, он умеет только iOS. Есть у нас — и мы поощряем это – ребята, которые развиваются из С# во фронт, с фронта — в Python, с Python в C#, и так далее. Но это, наверное, такие кандидаты, которых нужно как раз рассматривать для того, чтобы не раздувать ее.

Алексей Рыбак: Георгий снова тянет руку. Георгий, еще раз вас включу, и, наверное, это будет последний вопрос.

Георгий: Да, у меня есть еще два небольших вопроса. Первое — насколько, как у CTO в организациях, ваши возможности ограничены? Что вы можете сделать, что нет? Какие-то есть у вас ограничения или нет? 

И второй вопрос — про команды. Есть у вас удаленные команды? Вы нанимаете только русскоговорящих или у вас есть иностранцы? Есть ли какие-то ограничения с этой стороны?

Никита Прудников: Кто готов ответить? Давайте я. Ограничение роли CTO. Учитывая специфику организации, в принципе, инициировать я могу любое решение, но оно должно быть мотивировано про пользу. Иначе будут несчастливые люди, процессы вето и дальше эскалация, если захочется через всю цепочку вето пройти до совета директоров или до голосования акционеров, если надо. Так любое решение могу принять, какое необходимо, главное, чтобы оно было мотивировано пользой. И главное — уведомить про это решение людей, на которых оно повлияет. Если они окей с ним, то все, принято.

А про удаленные команды — у нас сейчас нет. Нет опыта, и нет команд удаленных, вся локация в офисе.

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

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

Алексей Рыбак: Русскоговорящая?

Михаил Юматов: Да.

Алексей Рыбак: Окей, мультиязычных команд нет. Ещё быстрый вопрос. Ребята, когда последний раз писали код? Из YouTube вопрос.

Никита Прудников: Вчера.

Михаил Юматов: Сегодня. Но я должен оговориться, что это просто какие-то автоматизации своих…

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

Еще раз спасибо огромное всем, кто поучаствовал, гостям. Тема нашего митапа была «Управление разработкой в «горизонтальных» компаниях». Сегодня у нас в гостях были Никита Прудников из Mindbox, Михаил Юматов из Циан и Сергей Кононенко из Раффайзенбанка. Спасибо вам большое.

Если у вас остались вопросы, то можете задать их прямо под этим постом. 

У нашего сообщества есть Фейсбук-группа «Управление и разработка крупных IT-проектов» и канал @feedmeto с интересными публикациями из корпоративных (преимущественно забугорных) техноблогов, и канал автора @rybakalexey про управление разработкой в продуктовых компаниях.