[Перевод] Время «рок-звёзд»: когда разработка ПО основывалась на талантах и креативности07.07.2023 17:32

Впервые за 5 лет в отпуске на Гватемале. Заканчиваю эту статью

В качестве саундтрека для этого поста я выбрал песню Torn Натали Имбрульи.

Какие статьи у нас выходили после «Куда подевались все хакеры?» Самое масштабное из того, что помню — это прекрасная серия Software and its Discontents за авторством Келлана, в которой он постарался ответить на вопрос «Почему сегодня все так недовольны ПО?»

Мне та серия очень понравилась, но при этом я чувствовал, что она не раскрывает всеобъемлющий контекст, стоящий за всеми описанными в ней мрачными чувствами: «Разработка прикладного ПО больше не является игрой талантов и креативщиков. Теперь это превращённая в коммерческий товар муть с прописанными правилами для её создания». Эти правила описывают игру, которая: а) не вызывает у большинства участников интереса и мотивации, b) больше основана на управлении рисками (страхе), чем на максимизации результата (надежде) и с)… похоже, на деле не особо работает? Если же ты вдруг отклоняешься от этих правил, то на тебя все начинают кричать, называя незрелым или несерьёзным.

Рынок труда очень медленно поспевал за этой тенденцией, поэтому какое-то время вознаграждение и общая концепция соответствовали уровню креативщиков/профессионалов, а работа и её результаты оказывались консервативными и управленческими. В итоге по стоимости программное обеспечение можно было сравнить с Тейлор Свифт в музыкальной индустрии, а по качеству с «неизвестным студийным музыкантом».

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

В этой статье я опишу, что подразумеваю под индустрией «креативщиков/талантов», докажу, что уход от этой модели сделал для всех сферу ПО более плачевной, и что, возможно, нам нужно пересмотреть формирующий этот переход сценарий, хотя бы отчасти.

В 2009 году я купил эту книгу, потому что когда ты начинал работать с кодовой базой, у неё был стиль. Это можно было сравнить с «почерком кода». Теперь же у нас есть black и gofmt

А в них есть «дух»?!

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

Один из этих вариантов оказывается явно лучше: не существует формулы для создания успешной гранж-команды. У некоторых групп есть особый «дух», который вызывает отклик у белых подростков, массово скупающих CD этих групп. При этом другие коллективы тоже могут играть на инструментах и произносить слова, но будут лишены той самой магии, и молодёжь их отвергнет. Поэтому большинство успешных гранж-бэндов возникали не в результате планомерного набора и слаживания участников, а выискивались в естественной среде.

Вот фрагмент из очень известного эпизода Reply All, где музыкант встречается с крутым продюсером, который прослушал его демо. Лучше, конечно, этот фрагмент послушать, но я также привёл его текстовую версию. Обратите внимание на образ жизни и ценности разных действующих лиц, как для них выглядит «работа», и как забавно, что эти два человека вообще встретились и смогли стать компаньонами:

Суть в том, что в ПО всё было зачастую также. В 2009 году вас, ещё студента выпускного курса, могли доставить в Сан-Франциско на собеседование в Facebook1, поселить в отеле, кормить, и всё потому, что вы умели программировать. Вы чувствовали себя крутым, особенно если последние два года провели в библиотеках за разбором различных сторонних проектов. Но при этом вас также ошеломлял и озадачивал тот факт, что компания готова тратить столько денег только чтобы понять, обладаете ли вы необходимой ей магией.

Вот важные ингредиенты для создания индустрии талантов/креативщиков:

• Она должна иметь высокую ценность, как индустрия профессионального спорта, музыки или кино. Крупные победы должны быть реально крупными.
• Невозможность «искусственного» воспроизведения успеха. У нас даже есть телешоу, нацеленное на взращивание поп-звёзд (American Idol). И хотя многие его участники уже имели некоторую карьеру в сфере музыки, по факту пока на выходе получилась всего одна успешная звезда (Келли Кларксон, самая первая победительница шоу). В подобной индустрии должна присутствовать определённая тайна, скрывающая, кто же окажется носителем того самого «духа».
• «Дух» должен иметь большое значение. Именно здесь, на мой взгляд, сфера технологий свернула не туда. В ней должен присутствовать множитель силы для формирования исключительных талантов. Кендрик Ламар, будучи Кендриком Ламаром, должен производить соответствующие своему уровню творения. Думаю, технологическая индустрия убедила нас, что если бы мы написали Lisp как Пол Грэхем, то смогли бы проложить себе путь к богатству. Но, как оказалось, гораздо проще убедить себя, что ты являешься техногением, создающим инновационные продукты, чем фактически таким гением быть. Очень немногие фирмы действительно добились весомой отдачи и прибыли, вкладывая средства в гениальных специалистов: для большинства путь наименьшего сопротивления заключался в принятии шика и блеска «технологической компании», акцентировании затрат на инженерном отделе и ведении финансовой игры.

Помните, когда мы писали подобные книги о языках программирования? Для молодёжи подскажу — это иллюстрация из Why’s poignant guide to Ruby. А ещё помните историю, когда чудной любитель автогонок из Дании использовал язык из 1995 года, чтобы написать фреймворк, и люди его работу одобрили?

Хорошо, но зачем об этом говорить?

Потому что хоть в анализе, проведённом Келланом в Software and its Discontents, и нет ничего плохого, на мой взгляд большинство утверждаемых им диагнозов вполне излечиваются командами, которые следуют принципам (и создают реальность) «пребывания в индустрии креатива». Тем не менее мы с ним, пожалуй, никогда в этом вопросе не согласимся, поскольку он в какой-то степени изобрёл концепцию Choose Boring Technology (выбирай скучную технологию), а я по большей части отстаиваю отказ от сформированных правил игры, возвращение к старой концепции творческого подхода и стремлению делать всё интересным.2

В своих статьях он приводит четыре основных пункта:

• услуги талантливых специалистов в технологической сфере неуклонно дорожают;
• взрыв в сложности разработки ПО;
• достичь успеха становится всё труднее, и современные стартапы уже «утратили то магическое чувство»;
• конфликты из-за изменений в ожиданиях определённых условий труда.

Разберём их. Если вы выработаете внутри себя модель «креативного подхода», то справитесь с худшими из них.

▍ Услуги талантливых специалистов неуклонно дорожают

Во-первых: нанимайте меньше людей. Не нанимайте новых сотрудников, пока не возникнет крайней необходимости. Примерно через 5–7 лет работы инженеры начинают пафосно заявлять, что: «Лучше вообще не писать код. Каждая строка стоит дорого и требует обслуживания». Это абсолютная правда, но я хочу, чтобы вы понимали — с операционной точки зрения затраты на найм нового сотрудника будут по меньшей мере соответствовать обслуживанию сервиса объёмом 200К строк.

Когда компания Facebook приобрела WhatsApp, в команде мессенджера было всего 35 инженеров. Отчасти им удавалось обходиться столь небольшим штатом, потому что они не играли по писаным сценариям. И хотя вы вряд ли сможете пойти на такую крайность, но, следуя высказанной выше рекомендации, я вас всё же спрошу: «Считаете ли вы, что SNL (Saturday Night Live, телепередача «Субботним вечером в прямом эфире») добилась бы большего, найми они 400 дополнительных писателей? А если бы компания HBO привлекла к проекту «Игра престолов» ещё 15 исполнительных продюсеров?

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

В качестве примера приведу экосистему пруда: представьте, что там живут черепахи, рыбы, бактерии и водоросли. Это культура вашей компании. Если вы увеличите объём этого пруда на 5%, взяв жидкость из другого пруда (с другими бактериями, рыбой и водорослями), то итоговый водоём в течение нескольких недель будет вполне соответствовать изначальному пруду, но с бо́льшим объёмом воды. Если же вы решите увеличить его объём на 40%, то привнесённая фауна может начать доминировать, и итоговый пруд уже станет неузнаваем.

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

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

Что ещё можно сделать для внедрения принципов креативной индустрии:

• Подумайте о колокации (colocation) серверов, вместо их размещения в облаке. Так поступили в Squarespace, Twitter, Basecamp и в Stack Exchange. Этот вариант не просто возможен, но ещё и зачастую оказывается намного дешевле.
• На начальных порах можете даже следовать модели «pets, not cattle».* Не попадитесь в западню создания никчёмной вариации Heroku и вашего продукта.
• Делайте stateful-деплои, хотя бы в качестве дополнительного уровня поверх stateless. Если ваш рабочий поток основан на Docker, который клонируется из свежего образа, подумайте о хостинге надёжного сборочного сервера, который будет выполнять git pull. Фред Хеберт рассказывает о том, как компании, в которых он работал, утрачивали функциональность и гибкость, так их и не восстановив (мне такое тоже знакомо), во имя удаления stateful-деплоев и перехода от BEAM к Go + Docker (следуем сценарию, «выбираем скучный вариант»).

*«pets, not cattle» — принцип разработки, противоположный по значению принципу «cattle, not pets», дословно означающему «скот, а не домашние питомцы». Смысл последнего в создании инфраструктуры или сервисов таким образом, чтобы их можно было изменять/удалять/обслуживать с минимальным участием человека — по аналогии с ухаживанием за скотом в противоположность уходу за домашними питомцами, требующими большего внимания и участия.

Обо всём об этом по отдельности можно написать целые статьи, рассказав о множестве подвохов и приведя объективные свидетельства. Но я думаю, что этот пост и так получается довольно длинным, так что остальное опущу.

▍ Взрыв в сложности разработки ПО

Ненавижу слово сложность (комплексность). В нашей индустрии нет единого определения для этого понятия. Обычно оно означает «фигню, которая мне не нравится». К счастью, Келлан даёт более точную формулировку:

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

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

Но на этом не обязательно останавливаться. Поступая вразрез с правилами, проявите креативность:

• Действительно ли каждой компании нужна целая команда фултайм-сотрудников для поддержки клиента React, который будет связан с дополнительной серверной инфраструктурой отрисовки плюс содержать в своей системе сборки и в каталоге node_modules больше инженерных нюансов, чем было во всей среде выполнения Flash? Подумайте об использовании htmx, серверных шаблонов или LiveView.
• Действительно ли вам нужны микросервисы? Kubernetes? Terraform? Представьте, что на дворе снова 2011 год и разверните JAR или бинарники, сохраняйте и поддерживайте монолитную структуру. Dropbox, YouTube, Instagram, Facebook Blue App, Shopify — все эти сервисы преимущественно монолитны и возникли до современной Эпохи мучений (в оригинале Misery Era, — прим. пер.).
• Можете ли вы использовать технологию, обеспечивающую более эффективное масштабирование, чем Ruby, Python или Node? Я могу написать об этих инструментах много, но пообщайтесь с любым инженером, работавшим с гигантскими базами кода в этих стеках. В них происходят печальные вещи, которые не встретишь, например, в JVM. В другой своей статье я говорил: «Вы создали и оптимизировали среду так, чтобы ваши инженеры-основатели смогли реализовать готовый продукт в течение 7 месяцев, но ценой тому оказались повторяющиеся проблемы, с которыми тем же инженерам придётся разбираться в течение последующих 7 лет».

Часть моего негодования в адрес BEAM и LiveView объясняется необходимостью избавления от очень большого числа взаимосвязей. Эти инструменты осваивать нелегко, но после некоторого изучения они открывают для вас невероятно широкие возможности

▍ Достичь успеха становится всё труднее, и стартапы утрачивают «то магическое чувство»

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

Кроме того, талантливый специалист, нанятый вами в качестве «свободного художника», будет и более вдохновлён, и заразит своим вдохновением других участников команды. Любимая статья генерального директора Ramp, Эрика Глимана — Amp it up!. В ней приводится много различных идей, среди которых ключевая: «Поддерживайте высокий уровень энергии!» Один участник команды из 50 реально вдохновлённых инженеров, которым, как в случае с WhatsApp, принадлежит весь продукт и стек, будет работать эффективнее (и чувствовать себя счастливее), чем аналогичный участник команды из 50 разработчиков на React, которым принадлежит 3 страницы.

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

Скажу так. Некоторые индустрии невозможно превратить в надёжные прибыльные фабрики: необходимо искать таланты в естественной среде и нельзя создавать «товары» искусственно и при этом надёжно. В начале статьи я привёл пример с гранжем, но больше мне нравится пример контент-войн между HBO, Disney и Netflix.

Дело в том, что HBO и Disney в течение десятилетий являлись королями индустрии контента. У них есть налаженные конвейеры производства качественных продуктов, которые любят люди. Они знают, что необходимо платить кучке отчаянных чудаков в Лос-Анджелесе и делать странные ставки, опираясь на внутреннее чутьё. Вот история из жизни HBO, рассказывающая о том, как компания чуть не потеряла крупнейшее телешоу десятилетия, которым руководил увольняемый ими человек:

Среди них можно назвать продюсера Кэролин Штраусс. Несмотря на то, что она создавала для HBO один хит за другим, в 2008 году ей указали на дверь. С её слов, причиной послужило то, что она упустила сериал «Безумцы», в результате чего через несколько месяцев была уволена. Уходя, она сказала: «Я работаю над одним шоу, которое мне бы хотелось довести до конца. Это сериал про драконов». На что руководство ей ответило: «Ты этого хочешь? Без проблем. Мы это устроим». И они устроили. В итоге Кэролин Штраусс стала ведущим продюсером самой успешной драмы HBO за всю историю — «Игра престолов».

Всё это очень человеческие процессы. Платформа Netflix стала новичком в кинобизнесе, причём ориентированным на технологии. Поэтому когда они занялись программированием, то постарались выстроить свою концепцию за счёт сбора и аналитики данных. «Данные говорят, что новые подписчики забрасывают просмотр сериала после двух сезонов, значит надо снимать не более двух сезонов». Кроме того, в таком случае проще привлекать в Лос-Анджелесе людей из сферы развлечений.

И они проигрывают в этом своём решении. Как оказалось, людей больше интересуют фильмы Marvel, «Андор» и «Репетиция», чем кино на $200 миллионов со знаменитостями, которое никто не смотрит, или неуклюжая аллегория про расизм с Уиллом Смитом в главной роли.

Забавно, но у меня есть подруга, которая работала в Disney Animation во время съёмок «Холодного сердца», и она как-то между делом сказала, что многие участники проекта были убеждены в том, что это будет проходняк. В этой игре невозможно прогнозировать успех.

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

Сноски

1. Прим. ред: владеющая им Meta запрещена в России как экстремистская.

2. В его (и свою) защиту скажу, что постулаты Choose Boring Technology (когда вы читаете статьи) содержат дисклеймеры и звёздочки, которые делают их практически неоспоримыми. Это можно рассматривать как аргумент против определённого вида «разработки, ориентированной на новизну». Такие заявления никогда открыто не говорят, что: «Ты должен притупить свою инженерную чувствительность». И в своей статье про недовольство индустрией ПО Келлан пишет: «Как для ведущего инженера, для вас поднятие качества принятия решений наверняка станет самой важной задачей, идущей за построением самой команды». Поэтому вряд ли он хочет, чтобы люди под словами «Выбирайте скучную технологию!» в контексте предварительного запуска B2B-системы подразумевали, что «Мы будем использовать Kubernetes и микросервисы, потому как все их используют».

Также можете почитать и другие мои статьи, где отражено аналогичное понимание. По тем же причинам я добавляю кучу похожих дисклеймеров в конце своего поста Against Boring. Концепция Choose Boring стала реакцией на реальную проблему.

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

Выиграй телескоп и другие призы в космическом квизе от RUVDS. Поехали?

© Habrahabr.ru