gemini://pub.phreedom.club/~kornilovnet/glog/20230318-article.gmi

Когда в 2022 году Twitter уволил половину своих сотрудников, и большинство технологических гигантов последовали его примеру, я не был удивлен. На самом деле, я думаю, что для этих компаний мало что изменится. Проработав в технологическом секторе несколько лет, я пришел к выводу, что большинство людей в технологическом секторе не работают. Я не имею в виду, что мы не работаем много, я имею в виду, что мы почти совсем не работаем. Ничего. Ноль. А когда нам все же удается выполнить какую-то работу, она часто приносит мало пользы компании и ее клиентам. И все это при том, что нам платят такие деньги, о которых некоторые люди даже не мечтают.

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

Я знаю, что мое заявление может показаться немного гиперболическим - как можно постоянно платить людям много за то, что они почти ничего не делают? Конечно, это не может быть правильным! Позвольте мне поделиться некоторыми примерами из собственного опыта.

Пять месяцев назад я был принят на работу в качестве разработчика программного обеспечения в один из самых престижных инвестиционных банков мира. Хотя я предпочитаю работать фрилансером, потому что это связано с реальной работой, мне хотелось иметь немного больше стабильности на некоторое время, поэтому я [решил попробовать] обычную корпоративную работу в сфере технологий. С начала моей работы, пять месяцев назад, я проработал в общей сложности около трех часов (не считая [ни к чему не обязывающие] совещания в Zoom, на которых я присутствовал, не обращая особого внимания).

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

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

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

Это касается не только меня. Все люди, которых я знаю, работающие в сфере технологий, похоже, проходят через то же самое. Один из моих бывших коллег, например, рассказал мне, что на работе он только и делает, что смотрит курсы Coursera. Он подумывает об увольнении после того, как закончится подписка на Coursera, спонсируемая компанией. Другой бывший коллега год назад был принят на работу в качестве специалиста по анализу данных в крупную нефтяную компанию. Она зарабатывает 200 000 фунтов в год. Все, что она делает, это каждую неделю готовит презентацию в PowerPoint, и ей ужасно скучно.

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

Об этом трудно говорить с другими. Кто-то однажды сказал мне, что мое недовольство традиционным рабочим местом в сфере технологий напоминает ему Меган Маркл и принца Гарри, потому что я постоянно жалуюсь на всякую ерунду, несмотря на то, что нахожусь в весьма [благополучной] ситуации. Действительно, для многих людей идея получать много денег за то, чтобы ничего не делать, звучит как воплощение мечты. Однако, хотя мы можем не делать практически никакой реальной работы, нам приходится постоянно делать вид, что мы ее делаем. Это может быть крайне неприятно и выматывает душу. Более того, эта шаткая ситуация не может продолжаться вечно: она похожа на плохо сбалансированный карточный домик. Недавние массовые увольнения и крах SVB уже свидетельствуют о напряжении.

Бизнесмены любят предсказуемость. Им нравится заранее оценивать, сколько будет стоить проект и сколько времени он займет. В некоторых дисциплинах это может быть удивительно сложно. Даже при строительстве физического объекта, например железной дороги, сроки реализации проектов часто значительно превышаются. Например, строительство новейшей железнодорожной линии в Лондоне было отложено на два года за два дня до ее открытия. Представьте себе, насколько хуже ситуация с нематериальными продуктами, такими как программное обеспечение, где трудно точно определить, что требуется для [создания] продукта и даже [понимани]что это [вообще] за продукт.

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

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

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

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

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

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

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

Принципы, лежащие в основе agile-разработки программного обеспечения, заслуживают одобрения и гораздо больше подходят для работы, чем идеи старой школы. Поэтому многие организации стремятся "быть agile". Однако они делают это, принимая "рецепты" agile, которые представляют собой пошаговые инструкции, призванные сделать команду проворной. Самым известным из них является scrum. Принятие рецепта приводит к тому, что компании считают, что они становятся гибкими только благодаря строгому соблюдению набора негибких правил. Эффект оказывается противоположным.

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

Жесткость спринтов также создает другие неэффективности. Например, если новый сотрудник присоединяется к команде в середине спринта, чаще всего ему не поручают никакой работы до начала следующего спринта. Таким образом, из-за [слепого следования этой] методологии новому сотруднику нечем заняться. Кажется, всех это устраивает. Кроме того, если кто-то объявляет, что выполнил поставленную задачу до конца спринта, на практике ему редко поручают новую задачу до начала следующего спринта, оставляя его в полном бездействии, или же ему поручают задачу-филлер, например, "оказать поддержку Джеймсу в выполнении его задачи".

Рецепт agile также управляет повседневной работой, создавая еще больше неэффективности. Например, он предписывает, как часто и как долго команда должна встречаться. Например, в рецепте говорится, что вся команда должна собираться каждый день на короткое совещание, которое называется stand-up meeting. На этом совещании каждый член команды представляет обновленную информацию о текущих задачах и потенциальных препятствиях. Идея собрания заключается в том, чтобы создать своего рода синергию команды, но я никогда не видел, чтобы это [приносило результат]. Вскоре оно превращается в упражнение по [бессмысленному] заполнению коробок. Чаще всего сотрудники используют это время, чтобы рассказать руководителю о том, что они сделали, не общаются и не слушают друг друга. Это работает для менеджера, которому выгодно быть в курсе событий, но не для остальных.

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

Как вы можете видеть, большая часть работы в области технологий включает в себя "метаработу", которая направлена на планирование или обсуждение фактической работы: Сначала вы говорите о работе, которую будете делать, затем вы говорите о ней каждый день в течение двух недель по мере ее выполнения (поскольку задачи действительно раздуты, это требует большого количества притворства), затем вы демонстрируете результат своей работы, затем вы коллективно размышляете над ним. Очень часто мета-работа - это почти единственная работа, которую вы делаете, поскольку 15-минутные обсуждения и сессии планирования занимают больше времени, чем выполнение самих раздутых задач. Однажды я присутствовал на совещании по планированию, на котором в течение 20 минут обсуждалось, стоит ли включать задачу в следующий спринт или нет. Задачу можно было выполнить за пять минут.

Повседневная неэффективность, которую вносит рецепт agile, усугубляет раздувание задач. Во-первых, мета-работа отнимает у людей время. Однажды я спросил знакомого юриста, который очень занят, проводит ли он ежедневные совещания с коллегами. Он ответил мне: "Нет. Мы слишком заняты для этого. Мы не можем позволить себе постоянно встречаться, чтобы наверстать упущенное, ведь у нас есть важные дела". Он был удивлен, узнав, что мы занимаемся этим в технологической сфере. Но постоянная мета-работа также убивает производительность, прерывая [деятельность] сотрудников. Например, когда перед кодером стоит сложная задача, иногда лучшим решением будет провести пару дней, обдумывая ее или проводя исследования в сосредоточенном, свободном режиме. Это не помогает, если приходится постоянно прерывать работу, чтобы говорить о работе и уведомлять всех о том, что вы делаете на каждом шагу.

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

Оспаривание рецепта agile воспринимается как ересь. Например, однажды я сказал, что не уверен, что все эти повторяющиеся встречи, чтобы наверстать упущенное, являются лучшим использованием нашего времени. Мне ответили: "Ну, в этой компании нам нравится работать в команде. А [вам]?"

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

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

Например, всего несколько недель назад одна компания обратилась ко мне за советом, как использовать ChatGPT в своей бухгалтерской программе. Они сказали, что это связано с тем, что они пытаются привлечь финансирование, и инвесторам не понравится, если они не будут использовать ChatGPT для [чего-либо]. В своей книге я привел множество примеров подобного явления в контексте ИИ.

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

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

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

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

Более того, преимущества многих технологических проектов неосязаемы. Если вы обещаете создать "механизм анализа на основе искусственного интеллекта", бизнесменам трудно понять отдачу от инвестиций. Вы можете приблизительно измерить результат работы парикмахера по количеству стрижек, но как измерить ценность проекта по науке о данных или аналитике?

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

Эти факторы в совокупности помогли технологическим компаниям стать невероятно раздутыми без последствий. Если вы еще не видели, то, возможно, захотите посмотреть это видео под названием "Один день из жизни сотрудника Twitter".

Название этой статьи говорит о том, что я почти никогда не работал, будучи занятым в сфере технологий. Но это не значит, что я никогда не работал. На самом деле, я очень много работал и был частью удивительно продуктивных команд, которые создавали первоклассные продукты в рекордные сроки (и клиенты их любили). Дело в том, что это не происходило в традиционной среде, то есть при полной занятости в средней или крупной технологической компании. Только работая фрилансером или в стартапах на ранних стадиях, я наблюдал продуктивную работу в сфере технологий. Я хотел бы поделиться тем, почему, на мой взгляд, это произошло, поскольку надеюсь, что некоторые из этих особенностей можно перенести на более широкую технологическую индустрию.

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

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

Это резко контрастирует с тем, как обстоят дела в мире традиционного технологического предприятия, где сотрудники слишком часто сосредоточены на выполнении поставленных задач в отведенные сроки, не задаваясь вопросом об их ценности для бизнеса и следуя методологии до буквы. В книге "Парадокс глупости" Матс Альвессон и Андре Спайсер описывают этот феномен, говоря: "Вы избегаете слишком много думать о том, что именно вы делаете, почему вы это делаете, и о потенциальных последствиях. Вы надеетесь избежать наказаний и многих забот, которые могут возникнуть в результате отступления. Вы избегаете бремени, связанного с необходимостью слишком много думать и расстраивать других, задавая сложные вопросы".

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

Один мой технический друг сказал мне сегодня: "Я не уверен, должен ли я быть доволен тем, что [заработал] столько денег и так мало [работал]. Это действительно ловушка, поскольку в наш век кризиса стоимости жизни иметь доступ к такой сумме сбережений кажется [важным]. Но разве я не должна стремиться улучшить свои навыки для будущего?". Боясь сменить работу, она цепляется за свою нынешнюю, где ей много платят, она мало делает и мало учится. Так обстоит дело со многими техническими работниками. Если вы один из них, я советую вам как можно скорее искать новую работу: я слышал, что есть много компаний, которые хотят создавать реальные вещи, но с трудом находят талантливых [специалистов].

I’ve been employed in tech for years, but I’ve almost never worked

Я работаю в сфере технологий уже много лет, но я почти никогда не работал

Раздувание задач

Как рецепт agile убивает продуктивность

Как шумиха разрушает мотивацию

Почему это так часто происходит в технологиях?

Как выглядит по-настоящему гибкая командная работа?