#люди Наконец-то к теме, с которой все началось. Итак берем | Человек и машина

#люди

Наконец-то к теме, с которой все началось.

Итак берем какую-то стратегическую проблему, из нее берем тактическую проблему - что-то, что можно измерить. Если вы работаете в платформенной/инфраструктурной команде, то лучшая метрика - либо масштаб, либо расходы, либо “возможность” (дать техническую возможность для бизнеса делать Х). В непродуктовых командах, инженеры чаще всего сами обозначают проблемы и способы их решения. И чем серьезнее проблема, тем серьезнее способ.

Тут стоит сделать небольшую отсылку на пару постов назад и вновь процитировать Генриха Альтшуллера: “Система идеальна, когда ее нет, а ее функция выполняется.” Казалось бы, что может быть лучше для предприятия, чем использовать уже существующие инструменты и системы для решения новых задач?

В этом и есть одна из первых серьезных проблем: нельзя получить повышение, просто взяв уже существующее и натянув на него проблему (Как вы думаете, почему у Google так много мессенджеров?) . Карьеристы это прекрасно понимают. Бизнес это прекрасно понимает. И бизнес, чтобы блокировать злоупотребление креативным подходом, имеет при себе штат инженеров-“дедов”, которые задают каверзные вопросы: “А почему не хотите использовать Y? А чем вас не устраивает Z?” Карьеристу нужно найти такую (дополнительную) проблему, что не может решиться уже существующей системой. Из чего растут ноги второй серьезной проблемы: если такой проблемы нет, ее нередко придумывают!

Помните тот стикер-пародию O’Rly “Solving imaginary scaling problems”? Приблизительно так это и работает.

Третья проблема - большие проекты не подтверждают и не проверяют умение инженера работать с несколькими командами. По факту, инженеру достаточно заручиться поддержкой своего менеджера (или менеджера своего менеджера), который выделит ему необходимое количество людей. Несложно договориться с людьми, которых тебе “выдали”, согласитесь?

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

Отсюда четвертая проблема: не всегда можно проверить “честность” этих метрик, и более того - берутся только те метрики, что изменились в плюс. Многие знают гигантскую историю Dropbox о том, как они построили свои ЦОДы и уехали из AWS, сэкономив миллионы миллиардов. Есть и обратные истории, как компании залетали в AWS, точно так же экономя миллиарды миллионов. Мы не знаем, нельзя ли было добиться того же эффекта внутренними оптимизациями (мой опыт эксплуатации собственных инфраструктур и облаков подтверждает, что чаще всего можно).

И пятая, в продолжение: учитывая сроки планирования, разработки, имплементации и запуска проекта, мы не можем знать наверняка, что все вложенные силы и инвестиции отбились. А значит мы не знаем, можно ли было направить столько ума и таланта на что-то более весомое и полезное для предприятия.

---

Выводов из этого поста делать не стоит. В конце концов, благодаря инициативным кадрам the Big Tech задает тренды индустрии, выпускает свои проекты в Open Source и дает компаниям меньшего размера выходить на больше рынков и объемов подготовленными. Цитируя своего приятеля: “Все, что сейчас решается в FAANG, будет решаться и в других компаниях через несколько лет.”

С другой стороны, не все общеизвестные системы появились на свет из-за карьерных аппетитов их изобретателей. Сысоев хотел ускорить Apache; Миловидов вряд ли придумал ClickHouse ради бесплатной ипотеки от Яндекса (хотя кто знает?); Роб Пайк явно сидел достаточно высоко в Google, когда придумывал Golang; Гвидо ван Россум решил “ускорить” Python, потому ему наскучила пенсия, и в Microsoft ему сказали взять себе любой проект по душе.

Даже если из ста проектов только один принесет реальную пользу - разве это плохо?