Не расстраивайтесь, если завалили дедлайн — проблемы с эффективностью есть даже у Google. Айтишник под ником Pen Magnet изучил тему и рассказал в своем блоге, почему концепт производительности в программировании работает совсем не так, как в других сферах, и что с этим делать большим IT-компаниям. Bubble перевел заметку блогера и публикует ее с незначительными сокращениями.
В августе 2022 гендиректор Google Сундар Пичаи объявил о проведении спринта простоты в компании. По его словам, это поможет повысить ее эффективность. CEO заявил, что производительность компании не соответствует количеству сотрудников.
— Помогите мне создать культуру, которая больше ориентирована на миссию, больше сосредоточена на наших продуктах, больше ориентирована на клиента. Мы должны подумать о том, как свести к минимуму отвлекающие факторы и действительно поднять планку качества продукции и производительности, — сказал он.
Зачем Google вообще повышать эффективность
Квартальные отчеты Google, пишет IT-блогер Pen Magnet, показывают рост выручки на 13%. В прошлом году в том же квартале было 62%. Можно возразить, что прошлогодний показатель был вызван возобновлением работы после пандемии коронавируса и ростом потребительских расходов. Но инвесторов этот аргумент вряд ли устраивает.
Но Google не единственная компания, которая столкнулась с трудностями. К середине августа 2022 Facebook, например, заморозил найм, а в Microsoft сократили количество вакансий.
Концепция продажа рекламы Google и Facebook, основанная на использовании пользовательских данных, устарела. Слабые показатели постковидного периода в сочетании с непредсказуемой геополитикой говорят о том, что FAAMG и IT-компании второй ступени могут пострадать первыми.
Что за путь у Amazon
Amazon относится к своим сотрудникам, как к роботам. В результате компания регулярно страдает от высокой текучки кадров и плохой репутации в отрасли. Тем не менее, именно поэтому Amazon редко теряет прибыль из-за снижения производительности труда. Но Google — это не Amazon.
Google во времен Ларри Пейджа и Сергея Брина основал культуру открытости, которой сегодня пользуется IT-индустрия. В Силиконовой долине внутренняя демократия и прозрачность Google считались граничащими с анархией.
Прежде чем говорить о возможном плане действий Google, давайте проанализируем продуктивность программирования в целом.
К чему сводится продуктивность программиста
Когда дело доходит до производительности, квартальные и годовые цифры ничего не значат для крупных компаний. У них есть планы на десять лет вперед. Если что-то пошло не так, это, скорее всего, связано с чьим-то неверным решением пятилетней давности.
Если вы хотите провести в компании масштабные изменения, вам нужно очень внимательно отнестись к тому, как вы измеряете успех. Необходимо четкое разделение групп, команд и ролей в сочетании с надежными матрицами, чтобы:
- исполнители получали награду;
- среднячков поощрали и мотивировали расти;
- неэффективным сотрудникам помогали или, в худшем случае, перевоспитывали их.
Почему продуктивность в программировании — странное понятие
Производительность — это количество работы, выполненной в единицу времени. Время — деньги. И это не просто поговорка, а экономический факт. Чем больше времени специалист работает, тем больше ему платят. Чем дольше работает проект, тем дороже он становится.
Все экономические матрицы вознаграждают производительность. При равенстве всех факторов производительность — единственный естественный путь, с помощью которого нация увеличивает свой ВВП. Однако в тот момент, когда вы применяете тот же принцип производительности в программировании, результат становится непредсказуемым. Компьютер — это устройство, которое автоматизирует работу. Но его возможности полностью зависят от программы, которую он получает от своего хозяина — программиста.
Сегодня умная программа на обычном ПК может обработать миллиард записей за несколько часов. Но для ее создания требуется умный программист и правильная инфраструктура. Плюс значительное количество времени, потраченное на обучение, проектирование, кодинг, тестирование и итерации. В программировании, в отличие от заводов и сферы обслуживания, производительность далеко не линейна. Среднестатистические программисты пишут код каждый день, но не закрывают все задачи к концу спринта. С другой стороны, опытные программисты днями не занимаются кодом, но часто к концу спринта предоставляют полностью работоспособные решения.
Продуктивность в программировании достигается правильным выполнением действий с первого раза, а это зависит от:
- способности программиста — его владения основами информатики;
- моментов продуктивных вспышек, через которые он проходит, чтобы разработать решение, их частоты и продолжительности.
В каждой компании в какой-то момент измерение производительности становится котом Шредингера. Нужно думать об измерениях производительности на макроуровне. Amazon с их подходом к менеджменту справились с этим, хотя и большой кровью. Компания с такой же культурой работы, как у Google, тоже может справиться, если захочет.
Что на самом деле значит падение производительности в Google
Когда Google говорит, что его сотрудники непродуктивны, это не означает, что они не могут выполнить определенный объем работы за отведенное время. Это значит, что с увеличением времени они не могут приумножить отдачу от своей работы.
Но как это исправить?
- Анализировать. Сотрудники, отвечающие за выпуск продуктов, могут собирать больше фидбека от конечных пользователей. Кроме того, нужно постоянно отслеживать взаимодействия с продуктом, даже редкие.
- Использовать готовые решения. следуйте принципам DRY и SOLID, тестируйте, автоматизируйте. Используйте генерацию кода для шаблонов. Если что-то уже существует, не изобретайте это снова.
- Создавать capabilities, которые создают фичи. В среднем программисты создают N функций за N часов. Опытные программисты создают одну capability за N часов, что позволяет обычным программистам создавать бесконечное количество фич.
- Работайте над полезными идеями. Вместо того, чтобы работать над алгоритмом по поиском изображений поверхности Марса, работайте над алгоритмом по поиску изображений на YouTube. Это проще применить на практике и может пригодиться большему количеству людей.
- Избегайте задач, которые можно измерить только с помощью линейности времени. Пример такого подхода: если задачу можно выполнить за N минут, M экземпляров одних и тех же задач будут стоить M*N минут.
Как изменить продуктивность любой компании масштаба Google с помощью Big O нотации
Есть совершенно другая парадигма измерения производительности программиста, ее можно применить и к другим профессиям. Парадигма может быть выражена в терминах известной Big O нотации. Google (или любая компания такого же масштаба) может использовать следующий подход:
- классифицировать организационные роли и определить их функции времени и воздействия. Например, функция зависимости времени от влияния chief experience officer имеет сложность O (log N), то есть если генеральный директор увеличивает свое рабочее время в восемь раз, результат увеличивается всего в три раза;
- нанести на график влияние каждого сотрудника со временем на оси X и влиянием на оси Y;
- чтобы сделать бизнес-цели важными в уравнении производительности, нужно ввести множитель для значений по оси Y. (примеры значений: инновации = 10, полезность = 7, поддержка = 5);
- сравнить баллы сотрудников по схожим категориям (разработчики против разработчиков, CXO против CXO и т. д.), а затем посмотрите, лидирует ли кто-то из сотрудников или отстает. Так можно легко помочь неэффективным и наградить отличников.
Пример Big O категоризации
Каждый оценивает роли по-разному, и вы можете по-своему классифицировать сотрудников Google. Вот один из вариантов:
O (1) < O (log n) < O (n) < O (n log n) < O (n ^ x)
где все основания логарифмов <n.
O (1): персонал по работе с клиентами — их рабочее время минимально влияет на прибыльность компании или даже на удовлетворенность клиентов.
O (log N): главные руководители — большую часть своего времени они проводят в поездках, стратегических встречах, вечеринках и/или встречах, которые имеют минимальное влияние на работу на уровне цеха. Они гибки в запуске новых вещей, но неэффективны в ситуациях, когда все идет гладко. Нижестоящие сотрудники уже выполняют их приказы.
O (N): DevOps, дизайнеры UX, тестировщики. Во времена гибкой разработки развертывание — сердце каждого проекта. DevOps контролирует все важные переключатели. Но их автоматизация гарантирует, что результаты появятся в предстоящих циклах. Несмотря на все достижения в более умных инструментах дизайна пользовательского интерфейса, дизайнерам UX/UI все еще приходится создавать прототипы в пропорции элементов пользовательского интерфейса.
Все типы тестовых случаев пропорциональны вариантам использования/ функциональным единицам, поэтому работа тестировщиков также попадает в корзину O (N).
O (N log N): Архитекторы. Их работа очень важна для качества кода. Даже после того, как дизайн готов, их взаимодействие оказывает значительное влияние на качество продукта и решения о внедрении.
O (N^X): Основные разработчики. Чем лучше они понимают свою работу, тем лучше становится продукт. Допущенная ими ошибка в одном символе может незаметно распространиться по всему SDLC и привести к миллионам убытков. Разработчики — это те, кто вносит или устраняет тысячи будущих ошибок, попыток рефакторинга и регрессии.
Что в итоге
Проблема Google, по мнению блогера, в том, что он уже находится на пределе либеральных возможностей управления персоналом. С таким базовым уровнем он может идти только по пути Amazon. Любая попытка переопределить измерение людей неизбежно приведет к эмоциональному ущербу для всей организации.
