Когда в 2022 году Twitter уволил половину своих сотрудников, и большинство технологических гигантов последовали его примеру, я не удивился. На самом деле, я думаю, мало что изменится для этих компаний. Проработав много лет в технологическом секторе, я пришел к выводу, что большинство людей в технологическом секторе не работают. Я не имею в виду, что мы мало работаем; Я имею в виду, что мы почти не работаем. Ничего. Пшик. И когда нам все-таки удается выполнить какую-то работу, это часто приносит небольшую добавленную стоимость компании и ее клиентам. И все это при выплате суммы денег, о которой некоторые люди даже не мечтают.
То, что сейчас происходит в сфере технологий, может быть одной из величайших рыночных неэффективностей — или даже обмана — в истории. Я пишу эту статью, потому что думаю, что посторонние заслуживают знать, что на самом деле происходит в этой области.
Я знаю, что мое утверждение может показаться немного преувеличенным — как можно постоянно платить много денег людям, которые почти ничего не делают? Конечно, это не может быть правильно! Что ж, позвольте мне поделиться некоторыми примерами из моего собственного опыта.
Пять месяцев назад меня наняли разработчиком программного обеспечения в один из самых престижных инвестиционных банков мира. Хотя я предпочитаю работать фрилансером, потому что это связано с реальной работой, на какое-то время я хотел иметь немного больше стабильности, поэтому я дал шанс обычной работе в сфере корпоративных технологий. С начала моей работы, пять месяцев назад, я проработал в общей сложности около трех часов (не считая нецелевых встреч в Zoom, которые я посещал, не обращая особого внимания).
Когда я впервые пришел в компанию, я была в восторге. Однако с тех пор, как я присоединился, они давали мне только задачи, которые было чрезвычайно легко выполнить всего за несколько минут, но выделяя на них дни или даже недели. Сначала я хотел ускорить процесс. Я искренне хотел создать классный продукт, поэтому связался с несколькими людьми из компании, чтобы задать вопросы о предполагаемых пользователях, их потребностях и о том, как наш продукт их удовлетворит. Но вскоре мне несколько раз ясно дали понять, что я не должен этого делать. Один человек сказал мне: «Я не хочу говорить вам, чтобы вы не задавали слишком много вопросов, но…», и она фактически сказала мне не задавать слишком много вопросов.
Вскоре я понял, что проект был раздут, и большинство людей притворялись, что работают. И я также понял, что это работа, для которой меня наняли, моя работа заключалась в том, чтобы притворяться. Если бы это был единственный раз, когда это случилось со мной, я бы счел это аномалией. К сожалению, так было почти со всеми техническими работами, которые у меня были в течение многих лет.
Возьмем, к примеру, мою предыдущую работу в сфере технологий, когда меня наняли дата-инженером в одну из крупнейших в мире телекоммуникационных компаний. За полтора года, что я у них работал, был только один двухнедельный период, когда я работал на полную мощность. Кроме этого, я почти ничего не делал оставшиеся 18 месяцев. Помимо этих двух продуктивных недель, большая часть моей работы заключалась в посещении не относящихся к делу совещаний, выполнении небольших задач, чтобы сделать вид, что сломанный продукт работает хорошо, и даже получить фальшивые результаты. Это казалось этическим компромиссом и было скучно. Я работал всего полчаса в неделю или около того, если не считать нецелевых совещаний.
Я мог бы продолжить и рассказать множество других подобных личных историй, но суть вы поняли.
Это не только я. Кажется, все мои знакомые, работающие в сфере технологий, проходят через то же самое. Один из моих бывших коллег, например, сказал мне, что все, что он делает на работе, это смотрит курсы Coursera. Он подумывает об уходе после того, как закончится подписка на Coursera, спонсируемая компанией. Еще одна бывшая коллега год назад была принята на работу специалистом по данным в крупную нефтяную компанию. Она зарабатывает 200 000 фунтов в год. Все, что она делает, это каждую неделю готовит презентацию в PowerPoint, и ей ужасно скучно.
Еще один мой друг был нанят два года назад в качестве аналитика в один из самых важных инвестиционных банков мира (да, именно в этот). Процесс собеседования для такой работы — один из самых сложных, которые вы можете себе представить — головоломки, дифференциальные уравнения, графовые алгоритмы. Сначала он был очень взволнован, думая, что будет создавать передовые технологии. Однако, хотя люди всегда кажутся занятыми со стороны, на самом деле он почти ничего не делает и ужасно скучает, но ему хорошо платят.
Трудно говорить об этом с другими. Кто-то однажды сказал мне, что мое разочарование традиционными рабочими процессами в технологиях напомнило ему о Меган Маркл и принце Гарри, потому что я продолжал жаловаться на вещи, несмотря на то, что находился в очень благоприятной ситуации. Действительно, для многих людей мысль о том, что им много платят за то, чтобы ничего не делают, звучит как сбывшаяся мечта. Однако, хотя мы можем и не выполнять почти никакой реальной работы, нам приходится постоянно притворяться, что мы ее делаем. Это может быть очень разочаровывающим и истощающим душу. Более того, эта шаткая ситуация не может длиться вечно; это как плохо сбалансированный карточный домик. С недавними массовыми увольнениями и крахом SVB признаки напряжения уже есть.
Давайте подробнее рассмотрим, что происходит в сфере технологий и почему технари в итоге так мало работают.
Раздувание задач
Бизнесмены любят предсказуемость. Им нравится заранее оценивать, сколько будет стоить проект и сколько времени это займет. В некоторых дисциплинах это может быть удивительно сложно. Даже при строительстве физической вещи, такой как железная дорога, проекты часто значительно превышают объемы. Например, последняя железнодорожная ветка Лондона была сдана с опозданием на два года и два дня. Представьте, насколько хуже обстоит дело с нематериальными продуктами, такими как программное обеспечение, когда трудно точно определить, что требуется для доставки продукта и даже что это за продукт.
Так, в начале 2000-х годов в технологиях стала по-настоящему популярной философия под названием Agile, которая стремилась улучшить процесс разработки программного обеспечения. В Agile программное обеспечение разрабатывается за очень короткие циклы, всего за две недели, и между циклами проверяется результат и пересматриваются цели.
Каждые пару недель команда собирается, чтобы спланировать задачи на следующий цикл. Но на этом этапе планирования происходит что-то действительно странное: стало стандартной практикой сильно преувеличивать усилия, необходимые для выполнения задачи, что мы называем раздуванием задач. На совещаниях по планированию все, кто работает, менеджеры и другие заинтересованные стороны согласны с тем, что выполнение каждой задачи занимает аномально большое количество часов и требует аномально большого количества сотрудников.
Мы проанализируем причины раздувания задач через минуту, но позвольте мне привести пару примеров, чтобы вы могли увидеть масштабы проблемы.
Одной из моих недавних задач в инвестиционном банке было проанализировать, для чего можно использовать пару шаблонов программного кода, предоставленных Microsoft. Любой, кто знаком с разработкой программного обеспечения, сможет сделать это максимум за пару часов. Однако на нашем заседании по планированию было коллективно сочтено, что эта задача требует много дней и работы двух человек. Сложность задач в этой компании определяется голосованием, и в данном случае коллективный разум решил, что задача относительно сложная. Я проголосовал за то, что это было легко, что не соответствовало мнению большинства. Когда они спросили об этом, я признал, что, возможно, это все-таки сложнее, чем я думал. В таких ситуациях трудно не согласиться, потому что кажется, что вы идете против коллективного разума команды. Кроме того, когда вы замечаете, что каждая отдельная задача раздута таким образом, и никто ничего не говорит, вы не хотите бросать вызов системе. Поскольку эта задача была поручена двоим из нас, в итоге мы разделили ее на две еще более простые части, по одной для каждой. Я закончил свою часть за несколько минут и сделал вид, что это заняло гораздо больше времени.
В следующем цикле мне дали задание написать абзац, обобщающий результаты предыдущего задания. Я проголосовал за сложность 1, самую низкую из возможных, так как это было 10-минутное задание. Однако мои коллеги не согласились — они проголосовали за то, что моя задача сложнее, чем кажется, и достойна нескольких дней работы.
Также принято разбивать простую задачу на дюжину частей, а затем определять, что каждая подзадача черезвычайно сложна. Например, у нас была задача решить, какой программный инструмент использовать для определенного приложения. У нас был список необходимых функций и четыре инструмента-кандидата, поэтому нам нужно было выяснить, какой из инструментов охватывает больше необходимых функций. Мне это показалось простой задачей, которая могла бы занять у одного человека пару дней, даже если бы все было сделано очень тщательно. Но задача была разбита на четыре разных подзадачи для индивидуального изучения каждого из четырех инструментов-кандидатов. Каждой из этих четырех подзадач было назначено многодневное окно для выполнения двумя сотрудниками.
Если бы мне пришлось угадывать, я бы сказал, что фактор раздутия не менее 10х является нормой. Но 50х или даже 100х не редкость. Так как практике раздувания задач следуют почти повсеместно, планка того, что технический сотрудник должен делать со своим временем, была коллективно снижена.
Что вызывает это раздутие? Заманчиво стать циничным и подумать, что это крупный заговор, который помогает ленивым сотрудникам не работать и позволяет компаниям завышать цены для своих клиентов. Но я думаю, что, хотя в этом и есть доля правды, есть более глубокие причины. Давайте посмотрим.
Как Agile-рецепт убивают производительность
Принципы гибкой разработки программного обеспечения заслуживают похвалы и гораздо больше подходят для работы, чем идеи старой школы. Поэтому многие организации стремились быть «гибкими». Тем не менее, достигали они этого, принимая гибкий «рецепт», который представляет собой пошаговые инструкции, призванные сделать команду гибкой. Самый известный из них — Скрам. Принятие рецепта просто приводит к галочке и заставляет компании верить, что они стали гибкими просто в силу строго соблюдения набора негибких правил. Эффект противоположный.
Мы уже говорили об одном из этих жестких правил: работа должна быть разделена на четко определенные циклы, обычно называемые спринтами, и что мы должны попытаться предсказать сложность задач, чтобы убедиться, что они укладываются в спринт. Эта структура поощряет раздувание задач — сотрудники хотят выполнять обещания, которые они дают в течение спринта, поэтому в конечном итоге они раздувают задачи, чтобы быть уверенными, что выполнят их в течение спринта. Таким образом, производительность приносится в жертву предсказуемости.
Жесткость спринтов также приводит к другим недостаткам. Например, если новый сотрудник присоединяется к команде в середине спринта, чаще всего ему не назначают никакой работы до начала следующего спринта. Так что, слава методике, новому работнику нечего делать. Кажется, все соглашаются с этим. Кроме того, если кто-то объявляет, что он выполнил назначенную задачу до конца спринта, на практике ему редко назначают новую задачу до начала следующего цикла, оставляя его полностью бездействующим, или ему назначают вспомогательную задачу, например, «оказать поддержку Джеймсу в его задаче».
Agile-рецепт также управляют повседневной работой, создавая еще большую неэффективность. Например, в нем точно указано, как часто команда должна встречаться и как долго. В рецепте, например, говорится, что вся команда должна собираться каждый день для краткого обсуждения, называемого стендап-совещанием. На этой встрече каждый член команды сообщает о текущих задачах и потенциальных проблемах. Идея стендапа состоит в том, чтобы создать своего рода командную синергию, но я никогда не видел, чтобы это происходило. Вскоре это становится упражнением для галочки. Чаще всего сотрудники используют это время, чтобы рассказать менеджеру о том, что они сделали, и не общаются и не слушают друг друга. Это работает для менеджера, который получает выгоду от новой информации, но не для всех остальных.
Некоторые версии Agile-рецепта также требуют, чтобы сотрудники проводили «демонстрацию» после завершения каждой задачи, в которой они демонстрируют всем остальным членам команды, что они сделали. А также в конце спринта все члены команды участвуют в длительной совместной сессии по саморефлексии, на которой каждый рассказывает обо всем, что было сделано.
Как видите, большая часть работы в сфере технологий связана с «мета-работой», которая направлена на планирование или обсуждение фактической работы: сначала вы говорите о работе, которую будете выполнять, затем говорите о ней каждый день в течение двух недель (поскольку задачи действительно раздутые, это требует много притворства), потом демонстрируете результат своей работы, потом коллективно размышляешь над ним. Очень часто мета-работа — это почти единственная работа, которую вы выполняете, поскольку 15-минутные разборы и планирование занимают больше времени, чем выполнение самих раздутых задач. Однажды я присутствовал на совещании по планированию, на котором в течение 20 минут обсуждалось, следует ли включать задачу в следующий спринт или нет. С задачей можно было справиться за пять минут.
Я пошутил, что причина, по которой Facebook* стал Мета*, заключается в том, что все его сотрудники делают «мета работу».
Повседневная неэффективность, вызванная Agile-рецептом, усугубляет раздувание задач. Во-первых, метаработа в конечном итоге отнимает у людей время. Однажды я спросил у очень занятого друга-адвоката, проводит ли он ежедневные встречи с коллегами. Он сказал мне: «Нет. Мы слишком заняты для этого. Мы не можем позволить себе постоянно встречаться и общаться, так как у нас есть важные дела». Он был удивлен, услышав, что мы делаем это в технологиях. Но постоянная мета-работа также убивает производительность, прерывая рабочий поток сотрудников. Например, когда перед программистом стоит сложная задача, иногда лучшее решение — потратить пару дней на размышления над ней или на целенаправленное, свободное исследование. Постоянные перерывы, чтобы говорить о работе и уведомление всех о том, что вы делаете на каждом этапе пути, совсем не помогает этому.
К сожалению, Agile стал культом; некоторые даже называют это религией. Если вы предполагаете, что методология может быть причиной непродуктивности, ее сторонники делают новую ставку и говорят, что это потому, что вы недостаточно строго следовали рецепту или неправильно его поняли (они могут нанять Agile-консультанта, чтобы помочь). Один из моих друзей насмешливо говорил, что Agile похож на коммунизм: причина того, что он никогда не работал, в том, что его никогда не применяли правильно.
Ставить под сомнение Agile-рецепт считается ересью. Например, однажды я предположил, что не уверен, что все повторяющиеся встречи
Ставить под сомнение Agile-рецепт считается ересью. Например, однажды я сказал, что не уверен, что все повторяющиеся встречи для обсуждения дел были лучшим использованием нашего времени. Мне сказали: «Ну, в этой компании нам нравится работать в команде. Не так ли?»
Повсеместное внедрение гибких рецептов подорвало работу технических специалистов. Никто не заинтересован в том, чтобы работать на полную мощность или держать продукт и клиента в качестве главного приоритета. Вместо этого главной целью сотрудников становится соблюдение методологии. Аминь.
Как хайп разрушает мотивацию
В мире технологий процветает хайп. Когда появляется новая технология, люди проявляют чрезмерный энтузиазм и хотят применять ее повсюду — мы видели это с большими данными, искусственным интеллектом, наукой о данных, блокчейном, ChatGPT и так далее. Я видел, как компании нанимали до 70 человек для создания продукта с целью следовать тренду, не определяя, что продукт будет делать и захотят ли его клиенты.
Всего несколько недель назад, например, одна компания обратилась ко мне за советом о том, как они могут использовать ChatGPT в своей бухгалтерской программе. Они сказали, что это потому, что они пытались привлечь финансирование, и инвесторам не понравилось бы, если бы они не использовали ChatGPT для чего-то. Я задокументировал множество примеров этого явления из области ИИ в своей книге.
Этот подход «телега впереди лошади» заставляет компании разбавлять команды для создания ненужных продуктов. Я думаю, что это еще одна важная причина раздувания задач и огромного свободного времени, о которых я упоминал выше, поскольку технари сильно демотивируются, когда не видят смысла в своей работе. Один из моих друзей потерял всякий интерес к своей работе, когда в его команду наняли еще пять человек, потому что топ-менеджер счел эту тему модной, хотя они прекрасно справлялись с нагрузкой. Расширение команды разложило работу на слишком большое количество работнчиков, поэтому начался сезон раздувания задач.
В некоторых случаях сотрудники вскоре понимают, что продукт, над которым они работают, никогда не будет использоваться реальными клиентами, поскольку он никогда не отвечал потребностям клиента — он просто следовал прихоти. Но им все еще нужно создать продукт. В таких случаях зачем усердно работать вместо того, чтобы раздувать задачи и использовать время для чего-то более значимого, например, для поиска следующей работы, стрижки газона или, возможно, для написания этой статьи?
Однажды я присоединился к команде, чтобы создать продукт, который должен был помочь специалистам по данным в организации. Поскольку я много лет работал специалистом по данным, я был немного удивлен, увидев пользовательский интерфейс продукта, который, казалось, не отражал того, как на самом деле работают специалисты по данным. Я спросил об этом и узнал, что они даже не опросили специалистов по данным в организации, чтобы узнать, что им нужно — они слепо создали команду и начали разработку продукта, потому что он казался модным. Когда я продолжил разговор, старший менеджер сказал мне: «Мы решили не разговаривать с пользователями; сначала мы создадим продукт, который, по нашему мнению, им подходит, и посмотрим, что они думают». Он назвал это «fail fast approach», но я думал, что это подход «fail for sure». Представьте себе уровень мотивации и продуктивности в этой команде.
Почему это так часто происходит в технологиях?
Технологии — не единственный сектор, пронизанный непроизводительностью. Я уверен, что некоторые люди возразят, что то, что я сказал до сих пор, затрагивает и другие отрасли. Тем не менее, я думаю, что некоторые характеристики технологии делают ее особенно склонной к раздуванию задач и непродуктивности. Думаю, одна из причин этого в том, что деловые люди плохо понимают техническую работу. Так что если технари говорят лицу, принимающему решения, что чтение шаблонного кода занимает неделю, а не более реалистичных 30 минут, лицо это, скорее всего, в это поверит. Гораздо сложнее, скажем, парикмахеру сделать вид, что стрижка кого-то занимает дни, потому что каждый уже стригся раньше и примерно понимает, что это такое.
Более того, выгоды от многих технологических проектов неосязаемы. Если вы обещаете создать «механизм анализа данных на основе искусственного интеллекта», бизнесменам будет трудно понять окупаемость инвестиций. Вы можете грубо измерить производительность парикмахера с точки зрения количества стрижек, но как вы измерите ценность Data Science проекта или аналитики?
Принятие гибких рецептов также помогает скрыть проблему, поскольку создает иллюзию гибкости и иллюзию командной работы. Если посмотреть на это со стороны, команда кажется продуктивной, потому что каждые пару недель выполняются новые задачи и совместно планируются другие задачи. Также кажется, что здесь много командной работы, так как все постоянно встречаются.
В совокупности эти факторы помогли технологическим компаниям невероятно раздуться без каких-либо последствий. Если вы еще этого не сделали, вы можете посмотреть это видео под названием «Один день из жизни сотрудника Twitter».
Как выглядит по-настоящему гибкая командная работа?
Название этой статьи говорит о том, что я почти никогда не работал по найму в сфере технологий. Но это не значит, что я никогда не работал. На самом деле, я очень много работал и был частью удивительно продуктивных команд, которые выпускали первоклассные продукты в рекордно короткие сроки (и клиентам они нравились). Дело в том, что этого не происходило в традиционной среде, то есть при полной занятости в средней или крупной технологической компании. Только когда я работал фрилансером или в стартапах на ранней стадии, я был свидетелем продуктивной технической работы. Я хотел бы поделиться, почему я думаю, что это произошло, поскольку я надеюсь, что некоторые функции могут быть экспортированы в более широкую технологическую отрасль.
Наиболее распространенная характеристика, которую я вижу в действительно продуктивной технической работе, заключается в том, что люди, участвующие в ней, ставят создание правильного продукта превыше всего остального. Они строят его небольшими циклами и проверяют сделанное, и это следует философии Agile, но не ограничивают себя строгим Agile-рецептом. Иногда они заимствуют некоторые элементы Agile-рецепта, но только потому, что это помогает им создавать правильный продукт. Например, они проводят повторяющиеся встречи только в том случае, если для них есть веское обоснование. И вместо того, чтобы позволить методологии диктовать каждое взаимодействие, они проводят импровизированные встречи по мере необходимости, даже с уведомлением за пять минут, и все это во имя улучшения продукта.
Кроме того, в компании, которая ставит во главу угла создание правильного продукта и обслуживание клиентов, сотрудники категорически отказываются создавать что-то, что они считают неадекватным, только потому, что начальник сказал, что это хорошая идея. Например, в стартапе, в котором я работал, два разработчика и технический директор однажды сильно поругались в офисе по поводу аспектов продукта, и один из них закончился слезами и всем остальным. Я знаю, что это может быть слишком, но это показывает, что все они страстно заботились о продукте, а не просто выполняли поставленные задачи.
Это резко контрастирует с тем, как все работает в мире традиционной технологической компании, в которой сотрудники слишком часто сосредотачиваются на выполнении своих задач в соответствии с запросом в отведенное время, не подвергая сомнению свою ценность для бизнеса и следуя методологии до буквы. В книге «Парадокс глупости» Матс Алвессон и Андре Спайсер описывают этот феномен, говоря: «Вы не хотите слишком много думать о том, что именно вы делаете, почему вы это делаете и о возможных последствиях. Вы надеетесь избежать наказаний и многих забот, которые могут возникнуть из-за отклонения от плана. Вы уклоняетесь от необходимости слишком много думать и расстраивать других, задавая трудные вопросы».
Мне кажется, что большинство технологических компаний оптимизируют не то. Они оптимизируются для соблюдения методологий, внедрения модных технологий, получения оценки в миллиард долларов и так далее, но они забыли о своих клиентах. Однако думать о клиентах — вот что делает бизнес успешным, а команду — по-настоящему продуктивной.
Одна мой друг-технарь сказала мне сегодня: «Я не уверена, должна ли я радоваться тому, что получаю так много денег и так мало стараюсь. На самом деле это ловушка, так как в наш век кризиса стоимости жизни мне уже начинает казаться легким получать такую сумму. Но разве я не должен стремиться улучшить свои навыки для будущего?» Боясь сменить работу, она цепляется за свою нынешнюю работу, где ей много платят, где она очень мало делает и очень мало учится. Так обстоит дело со многими техническими работниками. Если вы один из них, я призываю вас как можно скорее искать новую работу. Я слышал, что есть много компаний, которые хотят создавать настоящие вещи, но изо всех сил пытаются найти технические таланты.