Взгляд на управление: Нет инструкций для инженерии

Лет 5 хотел написать этот пост и всё ещё не до конца понимаю, почему его надо писать — на мой взгляд эти вещи очевидны.

Но я также не понимаю некоторых явлений из рабочей практики и теории, например.

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

Конечно, написано много книг с наборами конкретных практик в духе «Как я был Engineering Manager» или «Как мы в Google делаем менеджмент», но это не теории — это наборы практик для частных случаев — для разумного применения этих практик надо иметь в голове соответствующую теорию.

Почему в управление творческими коллективами постоянно протекают практики из управления регламентированными коллективами? От попыток зафиксировать норму выработки до использования velocity команды как KPI. От попыток загрузить 100% времени инженера, до (неявного) требования подписываться кровью под каждой эстимацией. Не говоря уже об отказе в самостоятельном принятии решений, навязывании жёсткого расписания и работы в офисе.

Оба вопроса, конечно, риторические.

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

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

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

Далее

Взгляд на управление: Что почитать, когда и почему

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

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

Весь прошлый год я эти книги читал, но, вопреки обычаю, рецензии не писал:

• С моей скоростью подготовки публикаций обзор 9 книг занял бы целый месяц.
• Все книги топовые — много читателей, большие рейтинги, куча обзоров в интернете — нет смысла повторяться.
• Книги имеют формат учебников и/или агиток. Писать рецензии на заведомо хорошие учебники смысла нет.

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

Итак, приступим.

Далее

Саммари презентации GPT-5 без маркетинговой мишуры

1. Сеть стала, в среднем, немного (на проценты) умнее.
2. В некоторых аспектах сеть стала значительно умнее (на десятки процентов).
3. В некоторых аспектах сеть стала немного глупее(!).
4. API стало дешевле, или нет, — смотря как вы его используете.
5. OpenAI сознательно вводят людей в заблуждение по поводу способностей новой модели — смотрите скрины.

=> Мировой лидер в LLM начал вязнуть в болоте, скорее всего за ним последуют все остальные.

Когда у вас всё хорошо и вы совершаете очередной прорыв, вы не мухлюете с картинками.

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

Близится фаза «разочарования» из цикла хайпа.

В связи с этим напомню о своём прогнозе о будущем ИИ — пока сбывается.

Добавлю вот ещё что.

Далее

Платёжные системы запрещают игры

Прошу прощения за желтизну заголовка, к сожалению всё так и есть.

То что пока запрещают не все игры, или не те игры, в которые играете именно вы, не означает, что через год не запретят ваш любимый шутан, потому что он «не соответствует ценностям» любовницы/любовника зам-зама какого-нибудь MonopolyPayCard.

Давайте я расскажу:

• Что случилось.
• Что я думаю по этому поводу.
• Что я хочу посоветовать тем, кто занимается подобной ерундой.

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

Далее

Взгляд на управление: Цикл проверки гипотез

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

Иногда мы делаем предположения в явном виде:

Если перекрасить вывеску в красный и подсветить, посещаемость ресторана в вечернее время увеличится на 10%.

иногда — в неявном:

У меня будет самый крутой парк развлечений на Луне с блэкджеком и инопланетянками.

но, рискну предположить, что вообще без предположений не обходится никогда.

Эти предположения мы называем гипотезами.

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

Этот цикл крутится вечно, пока существует продукт и является частным случаем цикла обратной связи.

Существует огромное количество литературы об этом цикле, его запуске и прочих нюансах. Лучшие практики собраны в наборы на любой вкус: от заумной системной инженерии до Lean Startup и Agile. Сам цикл называется, наверное, десятками аббревиатур: PDCA, OODA, DMAIC, 8D — не счесть их — каждый уважающий себя гуру-консультант с книгой добавляет новую.

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

Но кроме самого факта запуска важно и что конкретно вы в этом цикле делаете.

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

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

Далее