Производительность должна измеряться в IT не так, как у других. Наглядный кейс — Google

Не расстраивайтесь, если завалили дедлайн — проблемы с эффективностью есть даже у Google. Айтишник под ником Pen Magnet изучил тему и рассказал в своем блоге, почему концепт производительности в программировании работает совсем не так, как в других сферах, и что с этим делать большим IT-компаниям. Bubble перевел заметку блогера и публикует ее с незначительными сокращениями.

В августе 2022 гендиректор Google Сундар Пичаи объявил о проведении спринта простоты в компании. По его словам, это поможет повысить ее эффективность. CEO заявил, что производительность компании не соответствует количеству сотрудников. 

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

Зачем Google вообще повышать эффективность

Квартальные отчеты Google, пишет IT-блогер Pen Magnet, показывают рост выручки на 13%. В прошлом году в том же квартале было 62%. Можно возразить, что прошлогодний показатель был вызван возобновлением работы после пандемии коронавируса и ростом потребительских расходов. Но инвесторов этот аргумент вряд ли устраивает.

Но Google не единственная компания, которая столкнулась с трудностями. К середине августа 2022 Facebook, например, заморозил найм, а в Microsoft сократили количество вакансий.

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

По теме
Кому в Web 3.0 работать хорошо: кто создает новый интернет и неплохо на этом зарабатывает
Кому в Web 3.0 работать хорошо: кто создает новый интернет и неплохо на этом зарабатывает

Что за путь у 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 минут.
По теме
Как научиться кодить и не умереть: 3 способа стать программистом без боли
Как научиться кодить и не умереть: 3 способа стать программистом без боли

Как изменить продуктивность любой компании масштаба 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): главные руководители — большую часть своего времени они проводят в поездках, стратегических встречах, вечеринках и/или встречах, которые имеют минимальное влияние на работу на уровне цеха. Они гибки в запуске новых вещей, но неэффективны в ситуациях, когда все идет гладко. Нижестоящие сотрудники уже выполняют их приказы.

По теме
Что должен знать junior тестировщик перед первым собеседованием
Что должен знать junior тестировщик перед первым собеседованием

O (N): DevOps, дизайнеры UX, тестировщики. Во времена гибкой разработки развертывание — сердце каждого проекта. DevOps контролирует все важные переключатели. Но их автоматизация гарантирует, что результаты появятся в предстоящих циклах. Несмотря на все достижения в более умных инструментах дизайна пользовательского интерфейса, дизайнерам UX/UI все еще приходится создавать прототипы в пропорции элементов пользовательского интерфейса.

Все типы тестовых случаев пропорциональны вариантам использования/ функциональным единицам, поэтому работа тестировщиков также попадает в корзину O (N).

O (N log N): Архитекторы. Их работа очень важна для качества кода. Даже после того, как дизайн готов, их взаимодействие оказывает значительное влияние на качество продукта и решения о внедрении.

O (N^X): Основные разработчики. Чем лучше они понимают свою работу, тем лучше становится продукт. Допущенная ими ошибка в одном символе может незаметно распространиться по всему SDLC и привести к миллионам убытков. Разработчики — это те, кто вносит или устраняет тысячи будущих ошибок, попыток рефакторинга и регрессии. 

Что в итоге

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

article widget img
«‎‎Главная ошибка собеса — подгонять ответы»‎. Рекрутеры рассказали о найме в IT
Откуда берутся IT-рекрутеры, с какими трудностями они сталкиваются в попытках закрыть позиции и какие ошибки сами совершают на интервью — полезно знать перед тем, как искать работу.
Телеграм-канал про Образо­вание, карьеру и жизнь в IT
Телеграм-канал про Образо­вание, карьеру и жизнь в IT

Читайте по теме

nerd head nerd letter

Мир содрогнулся, когда узнал, что читают разработчики по ночам...

Ничего криминального — только полезная еженедельная рассылка от Bubble. Тренды в айти, лайфхаки и советы экспертов.

Подписывайся!

Ты — котик! Проверяй почту
Нам нужен настоящий адрес эл. почты
Спецпредложения
Курсы со скидками для пользователей Bubble
Выбрать курс
Освоить за выходные
Экспресс-курсы программирования
Выбрать курс
Баг пофиксил
Курсы для QA-инженеров
Выбрать курс
Звездочка к резюме
Курсы по карьерному росту
Выбрать курс
Реклама на Bubble
Реклама на Bubble
Подписывайся на Bubble в соцсетях
Подписывайся на BUBBLE в социальных сетях
Телеграм-канал про Образование, карьеру и жизнь в IT
Только полезный контент и ничего лишнего.