[Перевод] Бредовые проекты в разработке16.12.2022 10:32

Впервые я попал в неприятности в «Тиме Хортоне», когда жарил пару дюжин хрустящих пончиков с грецким орехом. «Тим Хортон» — это кафе, которое торгует кофе и пончиками, я работал там году эдак в 2002-м, когда учился в университете.

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

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

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

Я терпеть не мог ИБД и ужасно рад, что окончил университет и пришел в разработку, где мне не приходится делать вид, что я постоянно чем-то занят. Пока идет сборка, я могу почитать Hacker News и ни от кого еще не слышал, что лучше бы мне за это время навести лоск на скобки.
К сожалению, и разработчики не застрахованы от абсурдных задач, от которых, как представляется, никому нет никакого проку. Я в этом убежден, потому что спрашивал многих. Оказывается, можно в два счета найти разработчиков, согласных со следующим утверждением:

Вам приходится выполнять определенную работу, однако вы считаете, что она не имеет смысла и делать ее не нужно.

Об этом и пойдет разговор в сегодняшней статье. Спойлер: ИБД в айти существенно отличается от ИБД в кафе с пончиками. Там речь идет не о том, чтобы заполнить периоды простоя хоть чем-то, а о целых огромных проектах, которые никому не нужны. Рассмотрим несколько примеров.

Происхождение термина

«Бредовая работа: Трактат о распространении бессмысленного труда» — это книга Дэвида Гребера, которая вышла в 2018 году и была посвящена загадочному феномену бессмысленной работы. Книга Гребера включала в частности и интервью с разработчиками. Когда я начал ее читать, то не мог побороть искушение проверить теорию бредовых работ, проведя собственный опрос. Есть ли среди моих знакомых, или на Lobsters, или на Hacker News разработчики, которые заняты бредовой работой?

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

Гранту, выпускнику Стэнфорда, поработавшему в нескольких крупных IT-компаниях, довелось участвовать в бредовом проекте:

«Как-то раз я год отработал на проекте, который считал идиотским, в составе команды из тридцати-сорока людей, не меньше. Было совершенно непонятно, зачем мы всё это делаем. Я поделился своими ощущениями с руководителем, он от меня отмахнулся.
Спустя год проект свернули целиком. Он так и не вышел на публику, если не считать бета-версии с крайней ограниченной функциональностью. Он с треском провалился в том, что касается интереса пользователей и позиций на рынке. Руководитель, который отмахнулся от моих сомнений, покинул команду задолго до того и стал работать над какими-то другими задачами компании».

Разница между подобными бредовыми проектами и моей пончикоцентричной работой в том, что мне-то все-таки нужно было готовить пончики. ИБД никогда не занимала более 10% рабочего времени. Бредовый же проект, если организация достаточно крупная, может загружать полный рабочий день сотрудников целых команд.

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

«Высшему руководству хотелось говорить инвесторам: «Мы используем машинное обучение в процессе принятия решений». Я написал линейную модель, она успешно проводила анализ данных. Но в следующей версии появилась очень сложная модель на основе векторного представления, полученного при помощи деревьев принятия решений с бустингом. Для версионирования модели и наборов данных, а также обслуживания и развертывания требовалась обширная инфраструктура. Одних весов на два гигабайта.
Работа была временами увлекательна — в нашей команде собрались очень способные люди. Но удовлетворения она не приносила».

Есть несколько причин, по которым бесполезная работа может процветать, и потребность везде вворачивать модные словечки вроде «машинное обучение» — определенно одна из них.

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

Классификация бессмысленных задач в разработке

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

Гонка новеньких

Один из этих видов — ИБД, которую поручают свеженанятым сотрудникам или разработчикам на низких должностях. Например, когда люди из отдела контроля качества, логающие баги, которые никто не собирается исправлять.

Фрэнки, разработчик на iOS в компании с офисом в Лос-Анджелесе, считает, что в его бытность стажером контроль качества был нужен только чтобы чем-то его занять:

«Первые несколько месяцев большая часть работы была связана с ручным тестированием сайтов и повторной проверкой багов, которые легко мог бы проверить и разработчик в процессе исправления. Ну и конечно, это настолько иссушало психологически, что я стал искать какие-то способы получить эмоциональную отдачу и стимуляцию хотя бы в нерабочее время».

Винтик в системе

Другая разновидность демотивирующей работы затрагивает людей, работающих в настолько крупных организациях, что, даже если у задач есть определенный смысл, от работников он оказывается скрыт. Фредди убедился в этом на своей шкуре в период работы в Google, где пользовались популярностью футболки «Larry and Sergey«s protobuf moving company» («Компания по перевозкам Protocol Buffers Ларри и Сергея»).

«Проблема с тем, что работники ощущают себя перевозчиками Protocol Buffers — вполне реальная, и иногда из-за этого руки опускаются. У нас столько серверов, которые общаются с другими серверами, которые общаются с еще какими-то серверами, и так далее, что возникает чувство, будто вся твоя работа сводится к перекидыванию протоколов между разными серверами».

Бредовая индустрия?

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

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

Флориан, разработчик ПО из компании с офисом в Мюнхене, ранее создававший технические решения для рекламного бизнеса, немного подустал от людей, которые называют работу в этой области бесполезной:

«Считаете, что всё, связанное с рекламой — мусор? Пожалуйста. Думаете, что побуждать людей чаще видеть рекламу, приспосабливая ее к их вкусам, нехорошо и неэтично? Не стану вас разубеждать. Но одну из самых классных работ, которые у меня были, я нашел именно в рекламном секторе IT».

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

Зомби-проекты

Оставляя в стороне разговоры о том, что Twitter можно было бы создать за выходные, разработка ПО — ресурсозатратное дело. Именно поэтому меня поразили выводы, к которым Гребер пришел в своей книге. Он писал: «Огромное количество людей проводит дни за работой, которую втайне считает недостойной выполнения». А кто лучше осведомлен о сути работы, чем человек, который ей занимается?

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

«У нас не было ни пользователей, ни особого стремления ими обзавестись. Эти люди сами не знали, кому пытаются угодить».

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

«Из этого проекта я узнал всё о карго-культе. Вот, Netflix использует микросервисы, значит нам тоже надо! Я пришел к ним со знанием React Native, а ушел со знанием Elixir, так что с точки зрения навыков расклад был неплохой. Заодно усвоил, как нельзя управлять компанией.
Еще благодаря этой работе я понял, что технологии и бизнес-кейс — две независимые сущности. Можно выстроить крепкий бизнес-кейс и преуспеть даже с никудышным стеком, и обратная ситуация тоже возможна. Если выбирать, лучше иметь хороший бизнес-кейс — от пользователей зависит очень многое».

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

Невозвратные затраты

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

memorysluice с Hacker News полагает, что подобный протест против невозвратных издержек часто встречается в обреченных проектах:

«Когда я устроился на новую работу; человек, который меня нанял, вот уже четыре года делал для заказчика веб-приложение «нового поколения», и до прода этому приложению было еще далеко.
Проработав на этом месте две недели, я посмотрел на начальника и сказал ему, что из этого проекта ничего не выйдет и нужно отправить его в утиль. Получил ответ в духе «издеваешься, что ли, это вопрос нескольких миллионов долларов». С тех пор прошло два года, к выходу в прод приложение по-прежнему не готово».

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

Проекты — любимчики начальства

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

«Все и каждый, кто этим занимался, прекрасно понимал: мы переводим деньги Джеффа впустую и нет ни малейшего шанса, что кто-то купит эту штуку».

Можно ли отнести этот случай к бессмысленным проектам, сказать трудно. Возможно, Fire Phone изначально задумывался как пробный продукт, и Безос понимал, что, скорее всего, он не станет успешным, но доносить до сотрудников это не стал из опасения их демотивировать?

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

«Мы брали в работу один продукт за другим, и каждый из них неизменно рекламировался — и покупателям, и разработчикам, которых ставили на проект — как самая обалденная штука в истории человечества. Сперва серверы для Java-приложений, затем среды разработки, BPM, разработка, управляемая моделями, сервис-ориентированная архитектура, сервис-ориентированная архитектура: дубль два, сервис-ориентированная архитектура: дубль три…
Каждые полгода в отделе развития и инноваций происходили масштабные перестановки. Предыдущего старшего вице-президента увольняли или смещали из-за отсутствия результатов, на его месте возникал новый и знакомил нас со своим грандиозным планом и архитектурой предприятия для новой обалденной штуки.
Штуки никогда не выстреливали. Мы избавлялись от них и брались за следующую штуку, которая тоже не выстрелит. Проект объявлялся провальным спустя полгода или год. Мы отправляли в утиль то, над чем работали — и во что вкладывали душу — и начинали по новой».

Сначала Грегори нравилась его работа: оставалось много времени на самообразование, и программа наставничества была организована отлично. Но в конце концов, бессмысленность всего происходящего стала сказываться на его состоянии.

Может показаться, что работать над проектом, который никогда не выйдет на публику и не обретет пользователей (либо их будет раз-два и обчелся), очень даже неплохо — расписание щадящее, можно между делом подтянуть какие-нибудь навыки. Но Грегори на своем опыте узнал, что это может сильно выматывать.

«Мою работу раз за разом отправляли на свалку. Да и что это вообще была за работа? Попробуй на словах объяснить, чем занимаешься, кому-нибудь со стороны — другу, челну семьи или пусть даже такому же программисту из другой компании — ничего не выйдет».

Другой разработчик по имени Марсель также считает обреченные проекты тяжелой ношей.

«Никогда еще мне не приходилось работать в команде с такими апатичными настроениями. В какой-то момент я понял: да ведь мой начальник плевать на всё это хотел. Да и начальник моего начальника тоже. Я целый месяц отчитывался на стендапах одним и тем же, и всем было наплевать. Просто мучение какое-то!»

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

«Вы ведь даже не живете в своей собственной лжи. По большей части, вы и в чужой лжи не живете. Ваша работа больше напоминает расстегнутую ширинку у начальника: ее все видят, но благоразумно предпочитают не привлекать к ней внимания».

© Habrahabr.ru