О компании

Компания Clever (далее просто компания или Clever) разрабатывает e-commerce платформу для бизнесов с 2005 года. Целевая аудитория - компании, которые продают лицензии программ. Под капотом интеграция платежных систем, репорты, отчеты по воронкам продаж, и все это в большом монолитном приложении. Если вы покупали Parallels для своего макбука в течение последних пары лет, то вы точно проходили через платежные страницы Clever.

Компания продуктовая, работает чуть больше ста человек. Из них больше половины - разработчики, организованные в команды по направлениям (юнитам). Большинство разработчиков - in-house, но за последний год активно шел найм аутстафферов - я как раз один из таких работников.

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

Как они этого добились, какие процессы выстроили - обо всем этом я расскажу в статье.

Чем занимается тимлид?

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

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

• Собеседования (92%)
• Развитие людей (91%)
• Перформанс ревью людей (85%)
• Декомпозиция и постановка задач (82%)
• Управление техдолгом (77%)
• Повышение качество продукта (72%)
• Кодинг и инженерная работа (67%)
• Код-ревью (64%)
• Выбор технологий в команде (63%)
• Управление зарплатами и грейдами (53%)

В опросе принимали участине в основном тимлиды бэкенд-, фронтенд- и QA-команд. Судя по обязанностям, тимлиды занимаются чаще всего развитием людей и проработкой процессов разработки в команде. Написание кода отметили 67% респондентов. Большинство отметило, что только треть времени рабочего дня занимаются кодингом:

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

А как они работают без тимлидов?

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

Группы архитекторов и QA.

В Clever есть две группы, в которые входя разработчики из разных команд: Architecture Ownership Group (AOG) и Quality Ownership Group (QOG).

Задачи AOG

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

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

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

Задачи QOG

Если участники AOG занимаются правилами, то участники QOG следят за правильным выполнением этих правил в командах, а также:

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

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

Группы AOG и QOG - это возможность сеньорам в Clever не только передвигать задачи на доске из WIP в Done, но и повлиять на проект с архитектурной точки зрения. Таким образом, люди получают возможность отвлечься от повседневных задач, попробовать что-то новое и повысить свои навыки в архитектуре.

Как AOG/QOG облегчат жизнь вашим тимлидам

Организовав группы архитекторов и автоматизаторов из разных команд, вы получите два бонуса:

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

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

Регулярный Town hall для всех

Раз в две недели Clever созывает митинг в Zoom для абсолютно всех сотрудников, где:

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

Сотрудники получают актуальную информацию регулярно, часто и из первых рук. Более того, после того, как руководство поделилось новостями, собрание разбивается на комнаты с каждым С-level менеджером, куда может зайти любой и задать вопросы напрямую. Встречи действительно регулярные, и даже если новостей особо нет, то так и говорят: “новостей нет”. Тем не менее, всегда есть о чем рассказать по поводу выполнения целей квартала - так разработчики, которые трудились последние две недели над своими задачами, видят результаты вклада в общий прогресс. Это возможность увидеть, что твоя команда кого-то блокирует, если по какой-то причине вы не успеваете выполнить свои задачи.

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

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

Как Town hall облегчит жизнь вашим тимлидам

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

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

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

Если что-то можно автоматизировать, то мы будем автоматизировать

Clever следует лучшим практикам автоматизации процессов разработки:

• Тестирование и деплой, CI/CD.
• Повышение качества через peer code review.
• Интеграция инструментов для отслеживания качества: SonarQube, Stylecop, etc.

Эти подходы сокращают время на ревью кода и дисциплинируют разработчиков писать в одном стиле, что дает более быстрое погружение в проект или модуль. Проще понимать код, если он написан в одном стиле со всем остальным в проекте, даже если это монолит на несколько десятков тысяч файлов. О преимуществах CI/CD в интернете можно найти не одну сотню статей - от Gitlab, от RedHat, от SonarCloud - но если кратко, то основные преимущества - это:

• Стабильные сборки,
• Предсказуемые сборки. Мы знаем, какая версия будет отправлена на сервер,
• Автоматическая проверка тестов.

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

Как автоматизация облегчит жизнь вашим тимлидам

Про необходимость автоматизации, DevOps, CI/CD к 2023 году не сказал только ленивый. По оценке некоторых экспертов, рост производительности может достигать более 50%, если компания внедрит DevOps практики. Clever стремится автоматизировать действительно все, что возможно, а не только разработку.

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

Правила кодинга и дисциплина разработки

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

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

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

• При коммите номер задачи должен быть в сообщении. Иначе - реджект коммита.
• Ветка в Git должна называться так же, как и номер задачи. Иначе - не запушишь ветку.
• Статус CI отражены в Jira. Ревьюер задачи видит, что тесты не прошли.
• В Jira в определенные статусы переводить могут люди с определенной ролью. Перевести в колонку Done задачу разработчик не может технически, а не только по процедурам.

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

Как кодекс разработчика облегчит жизнь вашим тимлидам

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

Тестируют тоже разработчики

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

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

Автотесты повышают надежность системы и сокращают ручной труд. На данный момент в проекте более 15 тысяч тестов - это очень много даже для большой монолитной системы. Багфиксы сопровождают тестами на найденную ошибку. Если разработчик говорит, что нужно больше времени на задачу, так как он пишет тесты, то менеджер только скажет “спасибо” за это. Руководство Clever понимает пользу от автотестов и крайне рекомендует своим разработчикам их писать.

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

По данным исследования Stackoverflow.com за 2022 - 58% разработчиков из 34 тысяч опрошенных пишут автотесты. Несмотря на то, что уважаемые люди в книгах и со сцен конференций говорят о важности и пользе тестов, статистика гласит, что пока еще не все разработчики их пишут.

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

(с) Р. Мартин

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

Как автотесты облегчат жизнь вашим тимлидам

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

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

Самостоятельные команды из миддлов и сеньоров

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

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

• нужно ли расширяться, так как объем задач вырос,
• кого нанимать, кто сможет провести собеседование,
• финальное решение брать человека или нет - за продакт менеджером.

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

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

Новичкам команда назначает buddy

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

Как высокий уровень сеньорности команды облегчит жизнь вашим тимлидам

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

Компания пользуется аутстаффингом

Outstaffing is a type of remote recruiting model in which a vendor provides a specialist or a group of professionals for a client’s project during the contract term. The client can administer and manage a “rented” team or specialist.

Аутстаффинг - это возможность быстро нанимать людей, быстро укомплектовывать команды недостающими компетенциями, а в случае ошибки выбора или ненадобности в работе - так же быстро отказываться от услуг конкретного специалиста. Согласно результатам опросов, 92% IT-компаний пользуются услугами аутсорсинга и аутстаффинга, и это позволяет им сократить расходы на персонал вплоть до 70%. По оценкам экспертов Gallup, замена работника в штате может обойтись в стоимость до двух его годовых окладов. Согласно исследованию, при средней ежегодной зарплате в 50 000$ компания размером 100 человек может тратить до 2.6 млн долларов в год только на найм людей в результате текучки кадров.

Как аутстаффинг облегчит жизнь вашим тимлидам

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

Scrum-матсер помогает с performance review и ретроспективами

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

Сам процесс оценки выглядит как часовой митинг, на котором коллеги делятся комментариями по трем пунктам:

• Что хорошо - keep doing,
• Что стоит улучшить - should be improved,
• Что может обернуться проблемой - potential.

Вещи, которые негативно влияют на перформанс человека, записывают в категорию “Potential”, не придавая ей явно негативную окраску. Здесь отмечают, что человек должен начать делать, чтобы улучшить свою производительность. Каждый сотрудник получает оценку перформанса через 3 месяца после начала работы в команде, через полгода, через год и затем каждый год. Таким образом, он получает фидбек от всей команды часто и регулярно.

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

Как scrum-мастер облегчит жизнь вашим тимлидам

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

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

За регулярный релиз отвечают архитекторы

Каждые две недели Clever выпускает новую версию продукта, какой бы состав задач не был подготовлен: что готово, то и деплоим. Огромную монолитную систему деплоит один из участников группы AOG. Релиз проходит по стратегии “Blue-green deployment”. Большинство этапов релиза автоматизированы, но некоторую часть пока что приходится выполнять вручную. Процесс релиза выглядит так:

1. В понедельник создают ветку новой версии продукта на основе development, где уже лежат замердженные фичи и багфиксы.
2. Во вторник в начале дня часть продакшн-серверов обновляются. Проверяют, что система не упала сразу после наката.
3. В среду команды тестируют на новых серверах свои фичи: ведут мониторинг системы или проходятся по тесткейсам с тестовыми данными. По завершению тестирования задачи в Jira маркируют соответствующим лейблом.
4. После того, как все задачи были протестированы и помечены лейблом в Jira, релиз-менеджер переключает балансировщик на сервера с новой версией и затем обновляет оставшуюся часть серверов.

Процедура релиза описана в документации и доступна всем сотрудникам компании. Такая стратегия дает несколько преимуществ:

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

Как релизы от AOG облегчат жизнь вашим тимлидам

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

Documentation first

Clever обеспечивает прозрачность процессов тем, что всё-всё-всё описано в документации. Эта база знаний доступна любому работнику с доменной учеткой. В документации описаны:

• Кто мы, что мы, зачем мы работаем.
• Ссылки на диаграммы и доски в Miro с роадмапом продукта. Планы, цели и задачи всегда перед глазами.
• Какое бы правило ни было принято в Clever, оно будет закреплено в документации вместе с тем, как правило решает поставленную проблему.
• Структура компании в виде матрицы - кто в какой команде работает, чем занимаются. В ней упомянуты и аутстафф-сотрудники. Так ускоряется коммуникация между командами, каждый знает, к кому в случае какого вопроса обращаться.
• Любое изменение в коде должно быть в рамках определенной задачи в Jira.
• Задачи в Jira - такая же проектная документация. В задачах описаны критерии приемки, бэкграунд задачи, взаимосвязи с другими задачами и прочая полезная информация, которая может пригодиться исполнителю.
• Любой митинг создается с аджендой - это тоже своего рода документация, зачем организатор встречи планирует собрать людей. Исходя из адженды, участники понимают, к каким вопросам стоит подготовиться и что “принести” на митинг.
• Часто во время митинга пишут заметки, чтобы затем положить их в документацию команды.
• После любой встречи должен быть какой-то результат: новые задачи с требованиями, комментарии с Jira с принятыми решениями, редко - изменения в процессах. Результаты разговоров не остаются в головах его участников.

Упор на документацию хоть и требует дополнительных затрат, но в долгосрочной перспективе экономит время и силы. Нет необходимости повторять одно и то же, нет риска забыть важную информацию. Согласно результатам исследования McKinsey, в среднем работник тратит около 20% своего времени на поиск нужной информации. Автоматизированные базы знаний могут сократить общее время на поиск информации до 35%. Согласно опросу stackoverflow за 2022 год, 34% разработчиков тратят до часа в день на поиск информации, а 17% - до двух часов. О преимуществах баз знаний подробно можно почитать тут.

Автоматизированная база знаний Clever помогает:

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

Как документация облегчит жизнь вашим тимлидам

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

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

Митинги с ажендой и экшн-айтемами

У Clever есть два неписанных правила:

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

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

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

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

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

Как адженда облегчит жизнь вашим тимлидам

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

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

Code ownership и мотивация

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

Highly engaged teams are 14% to 18% more productive than low engagement teams, on average.

(c) gallup

Мотивация и привязанность к результатам работы были объектом исследований Дэна Ариели, в youtube можно найти видео The IKEA effect, объясняющее так называемый “Эффект IKEA”.

“Эффект IKEA” - это когда покупатели начинают больше любить то, что приобрели, если они приняли бОльшее участие, чем просто купить товар. Мебель IKEA нужно собирать самому. Покупатели больше вовлекаются в процесс приобретения и сильнее привязываются к результатам, если собрали сами стол и стулья. Попробуй сказать, что собранный стул кривоват - тебе не поздоровится. Дэн Ариели для подтверждения теории проводил несколько экспериментов, результаты двух из них я хотел бы привести здесь.

Эксперимент 1. Негативная мотивация

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

Цель. Выяснить, сколько людей дойдут до нулевой оплаты.

Результат. В группе 1, где собранный конструткор убирали, почти все доходили до конца - было 11 попыток. Во второй группе, где конструктор пересобирали каждый раз, в среднем было сделано 7 попыток.

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

Эксперимент 2. Позитивная мотивация

Эксперимент. Испытуемые собирают оригами двумя способами: с инструкцией и расчерченными линиями (А) и без инструкций, но с линиями и фото готового результата (Б). После сборки испытуемым предлагают купить фигуру.

Цель. Посмотреть, сколько в среднем испытуемые готовы заплатить за результат своего труда в разных группах.

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

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

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

Как поддержка code ownership облегчит жизнь вашим тимлидам

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

Любая ли компания может обойтись без тимлидов?

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

Долгие обсуждения

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

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

История 1. Фигурные скобки

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

// .. some code
if (someCondition)
    DoSomethingImportant();
// .. also some code

А хотелось, чтобы стало так:

// .. some code
if (someCondition)
{
    DoSomethingImportant();
}
// .. also some code

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

История 2. Код-ревью в Gitlab, а не в Jira

Компания установила правило, что код-ревью должно проходить в Jira. Все комментарии к коду, которые один разработчик хочет оставить другому, он должен писать в соответствующей секции в Jira с указанием класса и номера строки. В репозитории Gitlab оставлять такие комментарии гораздо удобнее и замечания более наглядные. Когда я подключился к команде, я удивился код-ревью в Jira и предложил перейти в GitLab. Мои коллеги согласились, что подход неудобный, но объяснили, что так руководство Clever хочет достигнуть бОльшей прозрачности всей системы и код-ревью - в том числе. Лишь спустя полтора года архитекторы выпустили обновление правил, по которым теперь ревью кода мы должны делать в Gitlab.

Высокий бас-фактор

Bus factor (also known as truck factor, bus number, lottery fac- tor, etc.) was defined by Coplien as the minimal number of the developers that would have to be hit by a bus before the project is stalled

Басфактор системы обусловлен скорее сложным монолитом, чем процессами компании. Тем не менее, он присутствует. Например, если ни один участник AOG не сможет сделать релиз вовремя, то никто не сможет - процесс сложный, задействовано много этапов. Я наблюдал системы, где релиз в продакшн - это всего лишь один мердж-реквест из сэндбокса в мастер ветку в Git. С этим справится любой. Здесь же коллега, который тоже захотел присоединиться к AOG, делал все этапы релиза под пристальным наблюдением других 5 раз, прежде чем делать это самостоятельно.

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

А куда расти?

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

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

Рисковый найм

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

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

Заключение

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

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

• Собеседования (92%)
• Развитие людей (91%)
• Перформанс ревью людей (85%) ✔️ только фидбеки, процесс уже настроен
• Декомпозиция и постановка задач (82%)
• Управление техдолгом (77%) ✔️
• Повышение качество продукта (72%) ✔️
• Кодинг и инженерная работа (67%)
• Код-ревью (64%) ✔️ не один тимлид делает ревью
• Выбор технологий в команде (63%) ✔️
• Управление зарплатами и грейдами (53%)

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

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

Дополнительные источники

Исследования

• Исследование разработчиков 2022. Kolesa
• Hiring. Gallup
• Engagement. Gallup
• Статистика аутстаффинга и аутсорсинга

Статьи

• Быть тимлидом, а не казаться. Habr
• Outstaffing
• Эффект IKEA
• Мотивация в Agile

Выступления и доклады

• Егор Бугаенко о качестве продукта и скорости разработки
• Егор Бугаенко. “TDD вверх ногами”
• Егор Бугаенко. “Тестировщик ошибается только один раз”