Процесс без вовлечения людей, если только он полностью не автоматизирован, ничего в результате не выработает. Поэтому измеряя процесс вы все-равно измеряете производительность людей, которые в нем участвуют.
Специфика наших процессов состоит в том, что они сфокусированы, и необходимый результат может быть достигнут каждым из сотрудников без необходимости вмешательства кого-либо еще. Поэтому измеряя метрику по такому процессу мы измеряем и производительность каждого сотрудника в отдельности.
Нет, не кажется. Действительно, написание юнит тестов на разной кодовой базе и на разных технологиях может занимать разное время. Поэтому, замеряя производительность каждого сотрудника на еженедельной основе, мы рассматриваем среднюю производительность за 4 последовательные недели (Trailing 4 weeks). И если менеджер видит, что данный конкретный продукт сложен для написания юнит-тестов и поэтому у сотрудника падает производительность, то следующий объем работ сотруднику дадут на простом участке.
По объему кода не оцениваем — у нас используется более сложная метрика: кол-во комитов и % переработанных комитов. Если мы видим, что после сотрудник часто комитит код — это есть хорошо. Но если мы видим, что при этом 50% всех строчек кода что он закомитил в течение 3 месяцев потом перерабатываются — тут уже разбираемся что к чему.
Ну почему же только деньги? У нас есть очень много интересных задач. Например, одна из самых больших команд у нас — это команда, которая занимается разработкой нового функционала для всего нашего портфолио продуктов. А разрабатывать новый функционал любят почти все :) Или, например, оптимизация производительности всех наших продуктов — тоже задача не из простых и очень интересная.
Есть еще очень много сложных инфраструктурных проектов: все наши продукты должны быть докеризованы и установлены в центральный докер-хост, который находится в AWS. Причем докеризуем и Windows-based продукты, а современный Windows-докер хост не очень стабилен, и мы сейчас вносим свой вклад в устранение его нестабильности.
А еще внедрение Continuous Delivery платформы, которая бы поддерживала весь наш «зоопарк» технологий. Ну и так далее. В общем, не соскучишься. Но да — ожидается что сотрудники 40 часов работают.
У нас есть возможность перехода сотрудников между комндами: надоело писать юнит-тесты? Можно попробовать себя в починке багов или автоматизации тестирования. Освоил написание юнит-тестов для одного продукта и данной технологии? У нас есть еще 99 других продутов на других технологиях.
Мы снимаем метрики ежедневно, а анализируем их на еженедельной основе, так что никакой деградации не допускаем.
Мы не отслеживаем когда и откуда сотрудник отработал свои 40 часов. Главное — это качественное достижение поставленной еженедельной цели.
Я, например, освободил себе от совещаний первые половины дней по вторника и четвергам, что дает мне возможность, например, осваивать сноу-борд на местном курорте когда там почти никого нет (ну или заняться какими-то другими личными делами в противоток всему Питеру), а потом, вечером, поработать. Иногда можно и на субботу-вск оставить пару-тройку часов, если не успел в рабочие дни отработать.
И такое тоже часто слышать приходится. Я же говорю — наша культура далеко не всем подходит. И хорошо, вам есть из чего выбрать, так как в этом мире есть огромное количество других IT-компаний.
Мы верим в специализацию. У нас есть команда, сотрудники которой только и делают, что пишут юнит-тесты. Но для всех 100 продуктов из нашего портфолио. Или есть другая команда, которая делает тест-автоматизацию. Или докеризует. Или оптимизирует билды. Или улучшает производительность. Или переносит энвайроменты из датацентров в Амазон. И так далее. Всего у нас таких команд больше 30.
Такая организация команд позволяет нам:
1. Измерять всех сотрудников команды одинаковой метрикой, потому что все они делают одинаковую работу. Например, количество написанных юнит-тестов, кол-во автоматизированных тест-кейсов, количество оптимизированных билдов, и т.д. Конечно, в эту метрику обязательна заложена и составляющего качества этой метрики. Каждая команда имеет четко определенный Output Quality Bar, которого сотрдуники должны придерживаться.
2. Подбирать именно тот уровень персонала, который необходим для данной команды. Например, оптимизация билдов — не простой процесс, поэтому в этой команде работают люди уровня архитектора ($30/час), а вот в Manual Test команде, которая выполняет уже написанные тест-кейсы, работают люди по $10/час, а производительность продуктов улучшают чиф-архитекторы по $50/час.
3. Стандартизировать процессы и используемые инструменты. Например, чтобы внедрить новый процесс написания тест-кейсов на всех 100 продуктах мне достаточно 1 часа — описать его, собрать команду и презентовать. После этого все наши продукты будут получать тест-кейсы которые лучше написаны.
То есть у нас каждая команда имеет простую метрику, которая измеряется на еженедельной основе, и сразу видно кто в команде лучше и хуже всех работает. Мы учимся у лучших и работаем с худшими, при этом постоянно улучшая и упрощая сами процессы, исследуя новые инструменты, которые помогут команде быть эффективнее, и автоматизируя ту часть ручной работы, которую можно автоматизировать.
Как пример — год назад я принял команду, которая писала тест-кейсы. Тогда метрика была 36 тест кейсов на человека в неделю. Сейчас эта команда создает более 90 тест кейсов на человека в неделю, и это еще не предел. При этом было значительно улучшено качество поставляемых тест кейсов.
Как часто вы делаете 1:1 c директами и как часто — скип-левелс? — наш процесс предполагает 2 таких еженедельных совещания с директами и еженедельные погружения в работу какого-либо из «скип-левел».
Как вы организуете процесс обмена информацией между командами, особенно если учесть что они все удаленные? — Исключительно используя хорошо прописанные и отточенные Quality Bars с дэшбордами для отслеживания качества следования им. Ну и JIRA, разумеется.
Какие коммуникационные проблемы (в смысле people/soft-skills problems) чаще всего возникают и как вы их решаете? — чаще всего — это проблема взаимонедопонимания из-за отсутствия протоколов совещаний (meeting minutes) — часто после вербального разговора каждый понимает его результат по-своему. Решаем с помощью внедрения четких процессов и QualityBars, чтобы необходимость в таких разговорах отпадала, и сам процесс отвечал бы на все возникающие вопросы.
мне часто приходится менеджерить вверх и «вбок» — приятно слышать что вы отдаете себе отчет о разных типах управления. А то большинство начинающих управленцев сосредотачиваются только на «управлении вниз» и никогда не выходят на следующий уровень, а начальники их не обучают.
У нас есть отдельный департамент — Продакт Менеджемент — цель которого составлять дорожные карты продуктов, создавать бизнес и технические спецификации.
А дальше мы живем на квартальном планировании: раз в квартал продакт менеджеры выставляют заказ инженерной организации на разработку каких-то улучшений из дорожной карты (которые уже имеют написанные спецификации), или оптимизацию производительности, или какой-то баг-фиксинг, и т.д. Потом идет совместное планирование релизов (согласовываются объем и сроки), а потом инженерная организация все это поставляет.
Я там ниже немного расписал про «ничего не делая». И работы много, и контроль каждые 10 мин, и работы по выходным хватает, и стресс присутствует. Но все-таки меньший чем в энергетической отрасли, так как нет грызни с подставами.
Ну как… я просто про «минусы» не рассказал. У нас далеко не все справляются и остаются, культура все-таки сильно отличается от стандратных IT-компаний. Во-первых, нужно работать 40 часов. Работать-работать — не чатиться с кем-то, не сидеть в соц. сетях, не играть в теннис или пить кофе — а работать. Во-вторых, это обязательное использование тула, который каждые 10 мин тебя фотографирует и берет скриншот. В третьих, это постановка агрессивных целей. Мы апологеты закона Паркинсона: работа занимает ровно столько времени, сколько на нее отводится. Соответственно все наши цели настолько агрессивны, что многие новички пальцем у виска крутят. Например, у нас стандартная цель — это улучшать производительность каждой команды на 25% в квартал.
Мне такая культура по душе, я люблю много работать.
Вот честное слово, я о процессах могу говорить вечно и с огнем в глазах, но для освещения нашего процесса разработки нужна отдельная статья. И даже не одна, а цикл. Каждый менеджер, который присоединяется к нам должен пройти курс, состоящий из шестнадцати 40-минутных вебинаров, которые рассказывают про наши процессы и практики. А потом в каждую команду назначается специально натренерованный коуч (ну никуда от этих англицизмов, извините), который помогает все это внедрять и улучшать.
У нас процесс организован таким образом, что миддл-менеджеры есть только в одной роли — SEM — Software Engineering Managers. Хотя сейчас в связи с быстрым ростом ввели позицию SVP, так что VPoE тоже стали миддл-менеджерами.
В связи с тем, что у нас при росте позиции зарплата растет в 2 раза ($100K for SEM, $200K for VPoE, $400K for SVP), то и ожидания от позиции к позиции сильно отличаются. А промежуточных позиций нет, поэтому перепрыгнуть с позиции SEM на позицию VPoE достаточно сложно, но возможно. Уже есть преценденты.
Специфика наших процессов состоит в том, что они сфокусированы, и необходимый результат может быть достигнут каждым из сотрудников без необходимости вмешательства кого-либо еще. Поэтому измеряя метрику по такому процессу мы измеряем и производительность каждого сотрудника в отдельности.
Мне, например, подходит. А еще подходит 3000 уже работающих через Кроссовер сотрудников.
По объему кода не оцениваем — у нас используется более сложная метрика: кол-во комитов и % переработанных комитов. Если мы видим, что после сотрудник часто комитит код — это есть хорошо. Но если мы видим, что при этом 50% всех строчек кода что он закомитил в течение 3 месяцев потом перерабатываются — тут уже разбираемся что к чему.
Есть еще очень много сложных инфраструктурных проектов: все наши продукты должны быть докеризованы и установлены в центральный докер-хост, который находится в AWS. Причем докеризуем и Windows-based продукты, а современный Windows-докер хост не очень стабилен, и мы сейчас вносим свой вклад в устранение его нестабильности.
А еще внедрение Continuous Delivery платформы, которая бы поддерживала весь наш «зоопарк» технологий. Ну и так далее. В общем, не соскучишься. Но да — ожидается что сотрудники 40 часов работают.
Мы снимаем метрики ежедневно, а анализируем их на еженедельной основе, так что никакой деградации не допускаем.
Я, например, освободил себе от совещаний первые половины дней по вторника и четвергам, что дает мне возможность, например, осваивать сноу-борд на местном курорте когда там почти никого нет (ну или заняться какими-то другими личными делами в противоток всему Питеру), а потом, вечером, поработать. Иногда можно и на субботу-вск оставить пару-тройку часов, если не успел в рабочие дни отработать.
Мы верим в специализацию. У нас есть команда, сотрудники которой только и делают, что пишут юнит-тесты. Но для всех 100 продуктов из нашего портфолио. Или есть другая команда, которая делает тест-автоматизацию. Или докеризует. Или оптимизирует билды. Или улучшает производительность. Или переносит энвайроменты из датацентров в Амазон. И так далее. Всего у нас таких команд больше 30.
Такая организация команд позволяет нам:
1. Измерять всех сотрудников команды одинаковой метрикой, потому что все они делают одинаковую работу. Например, количество написанных юнит-тестов, кол-во автоматизированных тест-кейсов, количество оптимизированных билдов, и т.д. Конечно, в эту метрику обязательна заложена и составляющего качества этой метрики. Каждая команда имеет четко определенный Output Quality Bar, которого сотрдуники должны придерживаться.
2. Подбирать именно тот уровень персонала, который необходим для данной команды. Например, оптимизация билдов — не простой процесс, поэтому в этой команде работают люди уровня архитектора ($30/час), а вот в Manual Test команде, которая выполняет уже написанные тест-кейсы, работают люди по $10/час, а производительность продуктов улучшают чиф-архитекторы по $50/час.
3. Стандартизировать процессы и используемые инструменты. Например, чтобы внедрить новый процесс написания тест-кейсов на всех 100 продуктах мне достаточно 1 часа — описать его, собрать команду и презентовать. После этого все наши продукты будут получать тест-кейсы которые лучше написаны.
То есть у нас каждая команда имеет простую метрику, которая измеряется на еженедельной основе, и сразу видно кто в команде лучше и хуже всех работает. Мы учимся у лучших и работаем с худшими, при этом постоянно улучшая и упрощая сами процессы, исследуя новые инструменты, которые помогут команде быть эффективнее, и автоматизируя ту часть ручной работы, которую можно автоматизировать.
Как пример — год назад я принял команду, которая писала тест-кейсы. Тогда метрика была 36 тест кейсов на человека в неделю. Сейчас эта команда создает более 90 тест кейсов на человека в неделю, и это еще не предел. При этом было значительно улучшено качество поставляемых тест кейсов.
Как вы организуете процесс обмена информацией между командами, особенно если учесть что они все удаленные? — Исключительно используя хорошо прописанные и отточенные Quality Bars с дэшбордами для отслеживания качества следования им. Ну и JIRA, разумеется.
Какие коммуникационные проблемы (в смысле people/soft-skills problems) чаще всего возникают и как вы их решаете? — чаще всего — это проблема взаимонедопонимания из-за отсутствия протоколов совещаний (meeting minutes) — часто после вербального разговора каждый понимает его результат по-своему. Решаем с помощью внедрения четких процессов и QualityBars, чтобы необходимость в таких разговорах отпадала, и сам процесс отвечал бы на все возникающие вопросы.
мне часто приходится менеджерить вверх и «вбок» — приятно слышать что вы отдаете себе отчет о разных типах управления. А то большинство начинающих управленцев сосредотачиваются только на «управлении вниз» и никогда не выходят на следующий уровень, а начальники их не обучают.
У нас есть отдельный департамент — Продакт Менеджемент — цель которого составлять дорожные карты продуктов, создавать бизнес и технические спецификации.
А дальше мы живем на квартальном планировании: раз в квартал продакт менеджеры выставляют заказ инженерной организации на разработку каких-то улучшений из дорожной карты (которые уже имеют написанные спецификации), или оптимизацию производительности, или какой-то баг-фиксинг, и т.д. Потом идет совместное планирование релизов (согласовываются объем и сроки), а потом инженерная организация все это поставляет.
Мне такая культура по душе, я люблю много работать.
У нас процесс организован таким образом, что миддл-менеджеры есть только в одной роли — SEM — Software Engineering Managers. Хотя сейчас в связи с быстрым ростом ввели позицию SVP, так что VPoE тоже стали миддл-менеджерами.
В связи с тем, что у нас при росте позиции зарплата растет в 2 раза ($100K for SEM, $200K for VPoE, $400K for SVP), то и ожидания от позиции к позиции сильно отличаются. А промежуточных позиций нет, поэтому перепрыгнуть с позиции SEM на позицию VPoE достаточно сложно, но возможно. Уже есть преценденты.