Yuriy Gavrilov: posts tagged Management

Личный бюджет – open source (actualbudget)

Mon, 19 Jan 2026 20:54:58 +0300

куча разного софта есть, но этот очень похож на YNAB – который кстати удобный, но платный

Пробуйте ...

Мне еще нравится https://ledger-cli.org но это для особо упоротых и командной строки. :)

Управление организационными системами с коалиционным взаимодействием и модели оптимизации иерархических структур

Tue, 06 Jan 2026 00:28:41 +0300

Что то вспомнилось мне, решил посмотреть и дополнить. Как то давно был на лекции Губко, очень интересно рассказывал о фракталах. Оригинал тут есть: https://www.klex.ru/1yt1

М.В. Губко «Управление организационными системами с коалиционным взаимодействием участников» (ИПУ РАН, 2003).

Это научная работа в области теории управления, теории игр и исследования операций. Ниже представлен анализ, краткое содержание, контекстуализация знаниями из смежных областей и некоторые переосмысленные выводы. Болекчейн тоже кстати сегодня сталкивается с некоторым трудностями управления, а проблемы организаций DAO прямо явно про это.

1. Анализ

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

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

Методология: Аппарат кооперативной теории игр (C-ядро, вектор Шепли, решения в угрозах и контругрозах) интегрированный в задачи управления (стимулирование, распределение ресурсов).

2. Краткое содержание по главам

Глава I. Модели коалиционного взаимодействия

Автор проводит ревизию теории кооперативных игр для нужд управления.

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

Глава II. Взаимодействие при полной информации (Стимулирование)

Здесь рассматриваются ситуации, где Центр знает параметры агентов, но агенты могут кооперироваться.

Веерные структуры: В простой структуре (один начальник — много подчиненных) показано, что если технологии позволяют агентам перераспределять работу, они могут «оптимизировать» выполнение плана так, что Центру это безразлично (он получает результат), но агенты выигрывают за счет перераспределения усилий.
Матричные структуры: Рассмотрена проблема двойного подчинения. Доказано, что полная кооперация менеджеров среднего звена (проектов и отделов) часто невозможна без специального согласования интересов с высшим руководством.
Формирование состава: Интересный вывод: агенты могут сами исключать неэффективных участников из системы («увольнять» коллег), перераспределяя их задачи и зарплату между собой, если это выгодно коалиции.

Глава III. Взаимодействие с сообщением информации (Распределение ресурсов)

Рассматривается ситуация, когда Центр не знает истинных потребностей агентов, а агенты подают заявки.

Системы приоритетного распределения ресурсов проанализированы на устойчивость к сговору.
Доказано, что объединение в коалиции невыгодно агентам, если полезность *нетрансферабельна* (нельзя передать выигрыш другому).
При *трансферабельной* полезности (можно передавать деньги/ресурс) найдены условия сбалансированности игры. Показано, что наличие у Центра априорной информации (например, знание, что потребность агента лежит в определенном диапазоне) резко повышает эффективность управления и устойчивость к сговору.

3. Дополнительные знания (контекст)

Чтобы глубже понять работу, стоит добавить знания, которые выходят за рамки текста 2003 года или подразумеваются “между строк”:

Связь с Mechanism Design: Работа Губко лежит в русле мировой теории *Mechanism Design* (Гурвич, Маскин, Майерсон). Однако западная школа чаще фокусируется на *Coalition-Proof Nash Equilibrium* (равновесие, устойчивое к коалициям), в то время как Губко адаптирует понятие C-ядра.
Эффект «Зайца» (Free Rider Problem): В работе мало акцента на поведенческую экономику, но коалиции часто разваливаются не из-за математической невозможности деления выигрыша, а из-за недоверия и желания отдельных участников «проехать зайцем» за счет усилий коллектива.
Блокчейн и DAO: Современные децентрализованные автономные организации (DAO) сталкиваются ровно с теми же проблемами, что описаны в Главе III. Механизмы голосования и распределения токенов часто атакуются именно коалициями пользователей (sybil attacks или сговор «китов»). Математика из этой книги применима к криптоэкономике.
Асимметрия информации: Книга подтверждает фундаментальный закон кибернетики: эффективность управления ограничена степенью информированности Центра. Уменьшение неопределенности (знание диапазонов пиков функций полезности) прямо конвертируется в устойчивость системы.

4. Итог

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

Главное достижение работы — формулировка условий (на свойства целевых функций и механизмов распределения), при которых интересы максимальной коалиции (всех участников) совпадают с интересами Центра. Это состояние называется полной сбалансированностью.

---

5. Рекомендации и переосмысленные выводы

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

Переосмысленные выводы:

Коалиция — не враг, а инструмент: Традиционно считается, что сговор сотрудников — это плохо (коррупция, саботаж). Однако анализ (особенно Глава II) показывает, что коалиция может действовать как *распределенный вычислитель*. Агенты внутри группы могут решать задачи перераспределения нагрузки эффективнее, чем удаленный Центр.
Самоочищение системы: Математически обосновано (Глава II), что устойчивая коалиция стремится избавиться от «балласта» (неэффективных агентов). Центру не всегда нужно проводить аттестации — достаточно создать механизм, где фонд оплаты труда фиксирован на группу, и группа сама вытеснит слабых игроков (при условии трансферабельной полезности).
Прозрачность ограничений: В Главе III показано: если Центр знает хотя бы границы потребностей агентов, он может гарантировать устойчивость. Отсюда вывод — инвестиции в мониторинг и прозрачность данных о ресурсах важнее, чем усложнение формул премирования.

1. Анализ материала и методологии

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

Особенности подхода:

Разделение задач: Автор четко отделяет *дизайн структуры* (кто кому подчиняется) от *дизайна технологии* (кто что делает) и *механизмов управления* (мотивация). Это позволяет свести проблему к задаче дискретной оптимизации на графах.
Секционные функции затрат: Вводится предположение, что затраты менеджера зависят только от того, кем он управляет *непосредственно* (его «секции»).
Однородность: Ключевой математический инструмент — использование однородных функций затрат (свойство самоподобия или масштабируемости). Это согласуется с эмпирическими законами (например, зависимость зарплаты топ-менеджера от размера фирмы по Саймону).

Научная новизна (на момент написания): Получение *аналитических* формул (нижних оценок) для стоимости оптимальной иерархии, что позволяет не перебирать миллионы вариантов, а сразу строить «почти оптимальное» дерево.

2. Краткое содержание по главам

Глава 1. Постановка задачи

Вводится математический аппарат. Иерархия моделируется как ориентированное дерево.

Исполнители имеют «меру» (сложность работы, объем задач).
Менеджеры имеют функцию затрат $c(\mu_1, \dots, \mu_r)$, зависящую от мер подчиненных групп.
Вводятся понятия сужающих (выгодно нанимать помощников, ведет к многоуровневости) и расширяющих (выгодно увольнять промежуточных начальников, ведет к плоской структуре) функций затрат.

Глава 2. Обзор литературы

Автор критически анализирует существующие модели (Бекманн, Вильямсон, Кальво-Веллиц, Раднер).

*Вывод:* Большинство классических экономических моделей рассматривают только симметричные иерархии с фиксированным числом уровней. Подход Губко более гибок, так как ищет оптимальную структуру без ограничений на симметрию.

Глава 3. Оптимальные деревья (Ядро книги)

Здесь содержится главный теоретический результат.

Доказано, что для однородных функций затрат оптимальная иерархия стремится быть однородным деревом. Это значит, что на каждом уровне менеджеры имеют примерно одинаковую норму управляемости (число подчиненных).
Выведена формула нижней оценки затрат $C_L(N)$. Это теоретический минимум расходов, к которому нужно стремиться.
Предложены алгоритмы построения субоптимальных деревьев (Bottom-Up и Top-Down), которые дают результат, очень близкий к идеальному.

Глава 4. Примеры и приложения

Теория применяется к практике:

Сборочное производство: Доказано, что при определенных условиях последовательная сборка (конвейер) экономически выгоднее параллельной.
Обработка информации (приказы): Моделируется процесс, где менеджер детализирует приказ сверху для подчиненных. Анализируется баланс между квалификацией менеджера и степенью его специализации.
Пределы роста фирмы: Исследуется зависимость затрат на управление от размера фирмы ($n$).
- Если степень однородности затрат $\gamma < 1$, фирма может расти бесконечно (эффект масштаба положительный).
- Если $\gamma > 1$, затраты на управление растут быстрее доходов, фирма становится неэффективной при превышении критического размера.

Глава 5. Обобщения

Рассматриваются более сложные случаи: кусочно-однородные функции (скачкообразное изменение затрат) и управление технологическими связями (когда структура подчинения диктуется потоками материалов/информации между цехами).

3. Дополнение новыми знаниями и современный контекст

Книга написана в 2006 году. С позиции сегодняшнего дня (2024+) анализ можно дополнить следующими аспектами:

Цифровизация и AI: В моделях Губко функция затрат менеджера $c(\mu)$ — это «черный ящик», зависящий от человеческих когнитивных способностей. Сегодня внедрение AI и ERP-систем меняет эту функцию. IT-системы увеличивают норму управляемости (снижают затраты на контроль), что делает иерархии более плоскими (расширяющий эффект).
Сетевые структуры и Agile: Книга фокусируется на *древовидных* иерархиях. Современный менеджмент часто использует матричные или сетевые структуры (двойное подчинение, кросс-функциональные команды). Модель Губко считает такие связи «дорогими» и неоптимальными, но в условиях высокой неопределенности (VUCA-мир) гибкость сети может окупать излишние затраты на коммуникацию, чего статические модели не учитывают.
Человеческий фактор: Модель предполагает *анонимность* менеджеров (все менеджеры одного уровня одинаковы). В реальности «звездный» менеджер может эффективно управлять 20 людьми, а слабый — только 3. Современный HR-анализ требует ввода индивидуальных коэффициентов в функцию затрат.
Трансакционные издержки: В главе про сборочное производство неявно затрагивается тема трансакционных издержек (Коуз). Современные платформенные экономики (Uber, маркетплейсы) показывают, что алгоритм может заменить целые слои иерархии, сводя функцию затрат менеджера к нулю или константе (стоимость сервера).

4. Итог, рекомендации и переосмысленные выводы

Итог

Книга М.В. Губко — мощное математическое доказательство того, почему классические пирамидальные структуры (где у каждого начальника 5-7 подчиненных) так устойчивы и распространены. Это не просто традиция, это математический оптимум для широкого класса функций затрат, обладающих свойством масштабируемости.

Практические рекомендации (на основе моделей книги):

Правило «7 ± 2» имеет математическое обоснование: Если работа менеджеров однотипна (однородная функция затрат), то норма управляемости должна быть одинаковой по всей иерархии. Если у вас в одном отделе начальник руководит 2 людьми, а в соседнем таком же — 15, ваша структура математически неэффективна. Нужно перебалансировать нагрузку.
Диагностика предела роста: Оцените, как растут зарплаты и расходы на управление при росте отдела.
- Если расходы на управление растут быстрее, чем линейно (степень $\gamma > 1$), вашу организацию нельзя масштабировать простым добавлением людей — она «схлопнется» под весом бюрократии.
- Решение:* Либо дробить компанию на независимые юниты (рыночные отношения внутри фирмы), либо внедрять IT (менять саму функцию $c(\mu)$, снижая $\gamma$).
При слияниях и поглощениях: Используйте алгоритм «Bottom-Up» (снизу-вверх). Сначала объединяйте мелкие подразделения в кластеры, потом кластеры в департаменты. Это дешевле, чем пытаться натянуть новую структуру сверху.
Квалификация vs Специализация: В главе 4 показано, что при низкой квалификации управленцев выгоднее делать структуру более многоуровневой (узкая норма управляемости). Если вы нанимаете дорогих профи, делайте структуру более плоской. Это математически обоснованный трейд-офф.

Переосмысленные выводы (Insight):

Иерархия — это компрессор информации. Главный вывод из главы 4.3: смысл иерархии не во власти, а в сжатии информации при передаче снизу вверх и детализации приказов сверху вниз. Оптимальная структура — это оптимальный алгоритм сжатия данных. Если данные не сжимаются (каждый чих сотрудника требует внимания гендиректора), иерархия парализуется.
Симметрия — признак здоровья. Теоретически доказано, что для выпуклых функций затрат оптимальное дерево стремится к симметрии. Сильные перекосы («флюсы») в оргструктуре — верный признак неэффективности расходов.
Цена контроля. Стоимость иерархии — это цена, которую мы платим за невозможность одного человека управлять всем сразу. Главная задача организационного дизайна — не «красиво нарисовать квадратики», а минимизировать эту цену через подбор такой нормы управляемости $r$, при которой производная затрат равна нулю. Для большинства стандартных задач это $r \approx 5..9$.

Свой Heroku: запустил Dokku дома и накатил новогоднего :)

Thu, 01 Jan 2026 22:59:46 +0300

Мы привыкли, что для развертывания веб-приложений нужно платить за VPS или разбираться в дебрях Kubernetes. Но если у вас есть домашний сервер (в моем случае — Asustor), вы можете создать свою собственную PaaS-платформу (Platform as a Service), которая работает по принципу *“git push — и готово”*.

Сегодня я расскажу, как настроить Dokku через Portainer, запустить веселое Python-приложение к Новому 2026 году и поделюсь лайфхаками по оптимизации сборки и масштабированию.

Часть 1. Фундамент: Запуск Dokku в Portainer

Dokku — это Docker-контейнер, который управляет другими Docker-контейнерами. Чтобы он заработал на NAS, его нужно правильно запустить. Я использовал Portainer Stack.

Docker Compose конфигурация

Вот рабочий `docker-compose.yml`, который решает главную проблему — доступность приложений из локальной сети.

# version: '3.2'
services:
  agent:
    image: dokku/dokku:${VERSION}
    pid: host.  # ⚠️ важно для работы на NAS
    network_mode: bridge # ⚠️ важно для работы на NAS
    environment:
      DOKKU_HOSTNAME: ${DOKKU_HOSTNAME}
      DOKKU_HOST_ROOT: ${DOKKU_HOST_ROOT}
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ${VOLUME_PATH:-/var/lib/dokku}:/mnt/dokku
    ports:
      - "3022:22" # ⚠️ важно для работы через ssh и что бы не конфликтовал с 22 
      - "80:80"    # Внешний порт 80 -> порт 80 внутри контейнера Dokku
      - "443:443"

Нюансы сети:
Чтобы обращаться к приложениям по красивым домегам типа `my-app.dokku.datahub.mother`, я настроил AdGuard Home в качестве локального DNS-сервера (фильтры получил бонусом – где-то 20% это всякие счетчики, ужас:). Добавил правило Rewrite: `*.dokku.datahub.mother` → `192.168.0.20` (IP моего NAS). Теперь все поддомены (приложения) автоматически ведут на Dokku.

Также для удобства я настроил `~/.ssh/config` на ноутбуке, чтобы не вводить порты вручную:

Host dokku.datahub.mother
  HostName 192.168.0.20
  Port 3022
  User dokku

ну и ключ сам так можно добавить

echo "ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ" | dokku ssh-keys:add dokku

Часть 2. Приложение “my-first-app”: Новогоднее гадание

Для теста я написал простое Flask-приложение, которое рассчитывает ваш возраст в наступающем 2026 году.

Код приложения (`app.py`)

from flask import Flask, request

app = Flask(__name__)

@app.route('/')
def home():
    return """
    <h1>Приветствую в игре Нового 2026 года! 🎉</h1>
    <p>Это веселая интерактивная игра в честь Нового года. Угадай свой возраст на 1 января 2026!</p>
    <p>Введи свой год рождения:</p>
    <form action="/result" method="get">
        <input type="number" name="birth_year" min="1900" max="2025" required>
        <button type="submit">Угадать возраст на Новогодний 2026!</button>
    </form>
    """

@app.route('/result')
def result():
    birth_year = request.args.get('birth_year')
    if not birth_year or not birth_year.isdigit():
        return "Ошибка: введи корректный год рождения!"
    
    birth_year = int(birth_year)
    age_in_2026 = 2026 - birth_year
    return f"""
    <h2>Результат: 🎇</h2>
    <p>В 2026 году тебе будет {age_in_2026} лет!</p>
    <p>Счастливого Нового 2026 года! Пусть все твои желания сбудутся!</p>
    <a href="/">Играть снова</a>
    """

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Подготовка к деплою

Чтобы Dokku понял, как запускать это чудо, нужны два файла в корне проекта:

`requirements.txt` (зависимости):

Flask==2.3.2
gunicorn==20.1.0
Werkzeug==2.3.3

`Procfile` (команда запуска):

web: gunicorn app:app --bind 0.0.0.0:5000

`.python-version` (опционально, явная версия Python):

3.11.14

Процесс деплоя

Все делается через Git, как на “взрослых” платформах:

Создаем приложение на сервере:

ssh dokku@dokku.datahub.mother apps:create my-first-app

Отправляем код:

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

Если вы до этого еще что-то деплоили, то лучше проверить куда гит смотрит

git remote -v

ну и поменяем еще не верное

git remote remove dokku

git init
    git add .
    git commit -m "Happy New Year 2026 version"
    git remote add dokku dokku@dokku.datahub.mother:my-first-app
    git push dokku master

После пуша Dokku сам скачает Python, установит Flask и запустит Gunicorn. Через минуту-две приложение доступно по адресу `http://my-first-app.dokku.datahub.mother`.

Еще нужно домен установить

ssh dokku@dokku.datahub.mother domains:set my-first-app my-first-app.dokku.datahub.mother

или можно сразу глобально его установить:

ssh dokku@dokku.datahub.mother domains:set-global dokku.datahub.mother
# но тогда придется удалить ручную привязку 
ssh dokku@dokku.datahub.mother domains:clear my-first-app

# не забыть перебрать nginx ( на всякий случай ) 
ssh dokku@dokku.datahub.mother proxy:build-config my-first-app

Сертификат сгенерировать

ssh dokku@dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

и проверить порты

ssh dokku@dokku.datahub.mother ports:report my-first-app

если порты не корректные, то можно их установить так:

ssh dokku@dokku.datahub.mother ports:set my-first-app http:80:5000 https:443:5000

Часть 3. Уровень PRO: Скорость (uv) и Marimo

Аппетит приходит во время еды. После простого Flask-приложения я решил развернуть что-то посерьезнее — Data Science ноутбук на Marimo, и столкнулся с реальными сложностями и особенностями. Для примера брал их дело ноутбук https://marimo.app

1. Ускорение сборки с `uv`

Стандартный `pip` устанавливает пакеты медленно. Если проект большой, деплой может висеть минутами.
Я перешел на uv — новый менеджер пакетов на Rust.

Вместо `requirements.txt` я использовал `pyproject.toml` и `uv.lock`. Dokku (благодаря современным buildpacks) увидел `uv.lock` и переключился на быстрый режим. Время сборки сократилось в разы.

2. Ловушка масштабирования (Scaling)

Marimo — это stateful приложение (хранит состояние в памяти). Flask, который мы делали выше — stateless.

Когда я задеплоил Marimo, Dokku по умолчанию все было хорошо, но потом я решил масштабировать его и сделал так

ssh dokku@dokku.datahub.mother ps:scale my-marimo-app web=3

далее Dokku запустил 3 копии контейнера (`web=3`).
Начался хаос:

Интерфейс открывался.
При нажатии кнопок вылетала ошибка `Invalid server token`.

Почему? Браузер загружал страницу с *Контейнера 1*, а WebSocket-запрос улетал в *Контейнер 2*, который ничего не знал про мою сессию.

Решение:
Для интерактивных приложений (Streamlit, Marimo, Jupyter) всегда принудительно ставьте одну реплику:
Ну ли придется делать липкие сессии на nginx или еще что-то.

ssh dokku.datahub.mother ps:scale my-marimo-app web=1 # все вернуло в рабочее состояние.

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

Вот так можно установить лимиты или повысить их:

ssh dokku.datahub.mother resource:limit my-marimo-app --memory 2G --cpu 2

3. SSL в локальной сети

Браузеры блокируют микрофон и иногда WebSockets на HTTP-сайтах. Для локальной сети Let’s Encrypt не сработает (нет публичного IP), ну и его чуть сложнее запускать.
Я решил вопрос генерацией самоподписанного сертификата одной командой Dokku:

ssh dokku.datahub.mother certs:generate my-first-app my-first-app.dokku.datahub.mother

Браузер ругается, но приложение работает полноценно.

Еще я прогнал стресс тесты

ab -n 10000 -k -c 2000 ...

Много они не показали, решением было подкрутить nginx, настроить кеш ssl, горизонтальное масштабирование не приносило больших результатов. я упирался в ограничения клиента при тестах нагрузки.

Итог

Dokku на домашнем сервере — это отличный инструмент.

Для простых API (Flask/FastAPI): Работает “из коробки” идеально.
Для сложных задач: Использование `uv` делает работу комфортной, а понимание разницы между *Stateless* и *Stateful* приложениями спасает от занудных ошибок и отладки.

Теперь my-first-app готово предсказывать возраст всем гостям на Новый год, а сервер готов к новым экспериментам! 🎄 Пожалуй оставлю его для будущих экспериментов. Прижился как-то быстро. Кстати у Dokku есть коммерческая PRO версия, а точнее не версия, а полноценный UI с кнопочками и стоит он 900$. https://dokku.com/docs/enterprise/pro/

Пора чего-нибудь накатить новогоднего еще :)

Bar is sooooooooo high – Platform Takes The Pain

Fri, 24 Oct 2025 00:49:24 +0300

Часть 1: “Bar is sooooooooo high” – https://nekrolm.github.io/blog.html

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

Учим английские выражения и их значение в контексте статьи, любопытно

`Bar is sooooooooo high`: “Планка неимоверно высока”. Означает, что требования для повышения (промоушена) настолько завышены, что достичь их практически невозможно, даже если ты уже выполняешь работу на следующем уровне. Это создает ощущение бега на месте.
`RSU (Restricted Stock Units)`: Акции компании, которые выдаются сотруднику, но он получает их не сразу, а по частям в течение нескольких лет. Это способ удержания ценных кадров. Автор отказался от ~£100k, не дождавшись очередного получения акций.
`FAANG`: Акроним для гигантов технологической индустрии: Facebook (теперь Meta), Amazon, Apple, Netflix, Google. Символ престижной и высокооплачиваемой работы в IT.
`Return-to-office`: “Возвращение в офис”. Политика компании, обязывающая сотрудников работать из офиса определенное количество дней в неделю.
`Oncall`: “Дежурство”. Период, когда инженер должен быть доступен 24/7 для решения экстренных проблем с продакшн-системами. В статье это источник огромного стресса из-за сложности системы и широкого круга обязанностей.
`Leadership Principles`: “Принципы лидерства”. 16 “заповедей” Amazon, которые должны направлять поведение сотрудников. Автор иронично использует их, чтобы показать, как в реальности они превращаются в инструменты бюрократии и давления.
`Receive shouldertaps`: “Получать ‘похлопывания по плечу’”. Метафора, означающая постоянные отвлечения, прерывания и запросы от коллег и менеджеров, которые мешают сосредоточиться на основной задаче.
`Let’s keep rollout aside`: “Давайте пока не будем думать о раскатке”. Фраза менеджера, которая говорит о том, что процесс релиза настолько сложный, долгий (от месяца до года) и рискованный, что его даже не пытаются планировать и оценивать.
`Customer Obsession`: “Одержимость клиентом”. Один из принципов лидерства. В статье показана его гипертрофированная форма, когда нужно реагировать даже на падение одного запроса из миллиона.
`Correction-of-errors document (COE)`: Документ с разбором ошибок. Его написание и защита перед высшим руководством — крайне неприятная процедура после любого сбоя.
`Bar Rising`: “Поднятие планки”. Процесс ревью и “прожарки” на митингах, где любая идея подвергается шквалу критики и сомнений, что ведет к выработке синдрома самозванца. пс: у кого-то “паяльники” рабочий инструмент, а у матерых компаний “градусники для мяса”. 🤣 Что поделать, идут дальше, контролируют степень “прожарки” в виде ежедневных опросов, что бы не подгорало.
`Ownership`, `Operational Excellence`: Другие принципы лидерства, которые на практике означают, что дежурный инженер несет полную ответственность за гигантскую и запутанную систему.
`In pain`: “Страдает”. Эмоционально окрашенный термин для описания клиента с проблемой, используемый для создания срочности.
`Disagree and Commute`: “Не согласен, но езди в офис”. Ироничная переделка принципа `Disagree and Commit` (“Не согласен, но поддерживай решение”). Отражает отношение к принудительному возвращению в офис.
`GenAI`: Генеративный Искусственный Интеллект. Автор описывает неадекватную истерию вокруг этой темы в компании.
`Bellow benchmarks`: “Ниже эталонных показателей”. Результат анонимных опросов удовлетворенности, который показывает, что команда недовольна, и приводит к игре в “мафию” — поиску виноватых.

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

Футбол кстати вовлекает 40% населения, а количество зрителей финала чемпионата может достигать 1,5 млрд. человек.

Стоимость бренда UFC – 4 млрд$, но цифра уже устарела, 11 дек. 2024 г. — $10 миллиардов, — Глава UFC оценил, а в августе этого года Paramount приобрела права на трансляцию UFC за $7,7 млрд. Сейчас оценка где-то 11млрд. За один просмотр выручка c трансляции одного боя может достигать 180$ млн.

А вот Люк как запомнился, “Он говорил на языке страсти, а не KPI”

Ну вы все уже знаете. 81 сервис пострадал, +800 компаний где-то, даже медиум лежал.

Облака, белогривые лошадки,
Облака, что вы мчитесь без оглядки
Не смотрите вы пожалуйста свысока,
А по небу прокатите нас облака... Трям! Здравствуйте!»))

Рецепт выгорания от Amazon или почему “планка так высока”

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

Причина кроется в самой культуре, парадоксальным образом описанной через знаменитые `Leadership Principles` Amazon. Принцип `Insist on Highest Standards` (“Настаивайте на высочайших стандартах”) на практике превращается в бюрократическую “прожарку” (`Bar Rising`), где любая инициатива тонет в бесконечных согласованиях и документах. Чтобы выпустить даже небольшое изменение, нужно “просмотреть все варианты будущего”, как Доктор Стрэндж, и защитить свое решение перед армией сомневающихся.

Вершиной этой культуры становится процесс релиза. Фраза менеджера `Let’s keep rollout aside` говорит сама за себя: раскатка изменений в продукте, через который проходит 30% интернет-трафика, — это настолько болезненный и непредсказуемый процесс, что его предпочитают даже не обсуждать. Проект, сделанный за 2 недели, может добираться до пользователей полтора года. Как пишет автор, это лучший рецепт для выгорания: “Заставьте программистов писать код, не дайте им увидеть результат и при этом дергайте их в разные стороны”.

Эти “подергивания” (`shouldertaps`) — еще один гвоздь в крышку гроба мотивации. Дежурства (`oncall`) превращают инженера в универсального солдата, который должен ориентироваться в сотнях дашбордов, десятках видов логов и нести `Ownership` за все, что происходит. При этом `Customer Obsession` доходит до абсурда: приходится разбираться с падением одного запроса из миллиона, потому что клиент `in pain`.

На фоне этого — постоянные увольнения, принудительное “возвращение в офис” (`Disagree and Commute`) и неадекватная `GenAI`-истерия. В итоге “планка” (`bar is so high`) для карьерного роста оказывается не стимулом, а стеной, о которую разбиваются амбиции. Это история о том, как система, созданная для минимизации рисков в огромном масштабе, начинает пожирать человеческий ресурс, превращая талантливых инженеров в выгоревших статистов.

Стихотворение в стиле АЙ да Пушкина :) 🤖

Три года в царстве AWS,
Где каждый день — суровый стресс.
Прощай, гигант, твой дом высок,
Но дух мой страждет и продрог.

Чтоб строчку кода в мир пустить,
Трактат надобно сочинить.
На том совете господа
Тебя осудят без труда.

“А точно ль цель сия верна?
Вся ль сложность вами учтена?”
Идёт полгода, год второй,
А код твой спит, еще не в строй.

Дежурства мрак, клиент “in pain”,
И кашель рвёт грудину мне.
И планка та, что так горда,
Лишь множит горе и года.

Оставлю акций бренный звон,
Покину сей хрустальный трон.
Свободным быть — вот мой удел,
Прощай, Amazon, я улетел.

Часть 2: О статье про Spotify (“Platform Takes The Pain”)

Эта статья, основанная на подкасте corecursive.com, рассказывает о внутренней трансформации Spotify на пути от хаотичного стартапа в стадии гиперроста до зрелой технологической компании. Это история о том, как им удалось навести порядок, не убив свою знаменитую культуру автономии.

Суть и смысл статьи

Основная идея — Spotify столкнулся с проблемой масштабирования. Их культура полной автономии команд, где каждая сама отвечала за свой конвейер сборки и доставки (CI/CD), привела к хаосу: более 300 команд использовали 200+ разных, небезопасных версий CI-системы Jenkins. Перед выходом на IPO аудиторы указали на это как на серьезный риск.

Компании нужно было за 6 месяцев стандартизировать CI, но как это сделать, не нарушив главный принцип — автономию инженеров, которые не хотели, чтобы им что-то навязывали “сверху”?

Решением стала смена парадигмы в работе платформенных команд под лозунгом `Platform Takes The Pain` (“Платформа забирает боль на себя”).

Устройство, культура и особенности Spotify

Культура “старого” Spotify (до трансформации):
- Хорошо:
  - Полная автономия: Команды (`squads`) были абсолютно независимы, что давало им чувство сопричастности и ускоряло принятие решений в малом масштабе.
  - Сильная идентичность: У каждой команды была своя “комната” (`squad room`), оформленная в уникальном стиле, что создавало сильную командную связь.
  - Скорость и гениальные инженеры: В компании были “звёзды” (“employee number 10”), которые могли писать код день и ночь и знали всё об инфраструктуре.
- Не очень:
  - Хаос и фрагментация: Более 200 CI-систем — яркий пример. Это приводило к дублированию работы и уязвимостям.
  - “Rumor Driven Development” (“Разработка, основанная на слухах”): Чтобы что-то узнать, нужно было “похлопать по плечу” нужного человека. Не было единого источника информации, что замедляло новичков и приводило к созданию костылей.
  - Проблемы с онбордингом: Новичку требовалось более 60 дней, чтобы сделать свои первые 10 Pull Request.
  - Хрупкость: Если ключевой инженер уходил в отпуск, система могла остаться без поддержки.

Трансформация и новая культура:
- Мантра `Platform Takes the Pain`: Платформенные команды перестали быть просто создателями инструментов “в стол”. Они стали сервис-провайдером для внутренних клиентов — других команд разработчиков. Их новой задачей стало не просто создать инструмент, а взять на себя ответственность за его внедрение (`adoption`). Они приходили в команды и помогали им мигрировать, забирая на себя самую нудную и сложную работу.
- `Backstage` — решение проблемы “слухов”: Чтобы победить `Rumor Driven Development`, Spotify создали единый портал для разработчиков — `Backstage` engineering.atspotify.com.
  - Устройство: Это центральный каталог, где можно найти информацию о любом сервисе, его владельце, документации, API и дежурном инженере.
  - Главная особенность: `Backstage` построен на плагинах. Это значит, что центральная команда не стала “бутылочным горлышком”. Любая команда может написать свой плагин для `Backstage`, чтобы добавить нужную ей функциональность. Это гениальное решение, которое централизует информацию, но децентрализует владение и развитие платформы.
- Переосмысление автономии: В Spotify поняли, что автономия ради автономии бессмысленна. Настоящая цель автономии — влияние (`impact`). Если команда автономна, но изолирована и ее работа не приносит пользы, это плохая автономия. Новые стандарты и инструменты вроде `Backstage` не убили автономию, а, наоборот, дали командам больше влияния, убрав рутину и упростив взаимодействие.

*На Backstage кстати можно строить порталы IDP https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/

Чем Spotify отличается от других (например, от Amazon из первой статьи)?

Аспект	Amazon (согласно статье)	Spotify (согласно статье)
Процесс	Процесс — это цель. Бюрократия и избегание рисков приводят к параличу. Релизы длятся годами.	Процесс — это средство. Цель — скорость итераций. Узкие места (bottlenecks) активно устраняются.
Автономия	Индивидуальная ответственность (`Ownership`), которая часто превращается в поиск виноватого.	Командная автономия, нацеленная на результат (`impact`). Баланс между свободой и общими стандартами.
Платформа	Не описано, но похоже на набор сложных инструментов, за которые ты сам несешь ответственность.	Платформа как сервис (`Platform takes the pain`). Платформенные команды — помощники, а не надзиратели.
Культура	Top-down (сверху-вниз). Жесткие принципы, которые могут использоваться для давления. Страх ошибки.	Bottom-up (снизу-вверх). Культура эволюционировала в ответ на реальные проблемы. Поощрение экспериментов и “быстрых провалов”.
Информация	Скрыта в тысячах репозиториев и устаревших вики. Огромный контекст, который невозможно удержать.	Централизована и доступна через `Backstage`. Прозрачность — один из ключевых принципов.

Итоги

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

Основные выводы:

Платформа должна служить разработчикам, а не диктовать им условия. Модель `Platform Takes The Pain` — это то, чему стоит поучиться многим компаниям.
Централизуйте информацию, а не контроль. Инструмент вроде `Backstage` с плагинной архитектурой — мощное решение для сохранения скорости и автономии в большом масштабе.
Культура не высечена в камне. Она должна адаптироваться к размеру и задачам компании. Spotify смогли переосмыслить “автономию”, привязав её к реальному влиянию на продукт.

Для компаний, стремящихся к росту, опыт Spotify

sciencedirect.com — это дорожная карта по построению эффективной и при этом человечной инженерной организации. А для инженеров, выбирающих место работы, это маркер здоровой культуры: ищите компании, которые борются с трением, а не создают его. Как говорится, если в компании есть свой `Backstage` — это хороший знак. Если же там “let’s keep rollout aside” — возможно, стоит бежать.

Если коротко – оригинал по ссылке выше

В статье анализируется организационная модель Spotify, которая позволяет предоставлять высокую степень автономии сотням команд разработчиков (называемых «сквадами», или `squads`) и при этом эффективно координировать их работу в масштабах всей компании.

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

Однако эта свобода существует в рамках так называемых «благоприятствующих ограничений» (`enabling constraints`). Эти ограничения — не приказы сверху, а скорее общие правила и инструменты, которые помогают командам работать слаженно, не создавая хаоса. Исследование основано на ретроспективах с командами, интервью с менеджерами и анализе внутренних данных Spotify.

Основные рекомендации и стратегии, применяемые в Spotify

Для достижения баланса между автономией и согласованностью Spotify использует несколько ключевых стратегий:

Выравнивание (Alignment) вместо контроля: Вместо того чтобы указывать командам, *что* и *как* делать, компания создает условия для естественной синхронизации.
- `TechRadar` (Технологический радар): Это централизованный, но коллективно управляемый список одобренных технологий, языков программирования и фреймворков. Команды не могут использовать абсолютно любую технологию, что упрощает поддержку, обмен инженерами и совместную работу над кодом.
- Запросы на комментарии (`RFCs – Requests for Comments`): Для крупных изменений, затрагивающих несколько команд, используется формальный процесс RFC. Это позволяет собрать обратную связь и достичь консенсуса до начала реализации.
- «Золотые пути» (`Golden Paths`): Это готовые шаблоны и руководства для выполнения стандартных задач (например, создание нового микросервиса). Это снижает когнитивную нагрузку на инженеров и обеспечивает единообразие.

Управление общей кодовой базой:
- «Слабое владение кодом» (`Weak Code Ownership`): У каждого компонента кода есть команда-владелец, но любая другая команда может предлагать изменения через пул-реквесты (`Pull Requests`). Команда-владелец обязана рассмотреть эти изменения. Это предотвращает возникновение «узких мест» и поощряет коллективную ответственность за продукт.
- Самостоятельное управление зависимостями: Команды могут договариваться между собой и передавать владение кодовыми репозиториями, чтобы уменьшить зависимости и ускорить свою работу.

Сетевые структуры и обмен знаниями: Компания активно развивает горизонтальные связи, минуя формальную иерархию.
- Гильдии (`Guilds`): Это добровольные сообщества по интересам (например, гильдия веб-разработчиков или гильдия по качеству). Они служат для обмена знаниями, выработки лучших практик и решения общих проблем.
- Культура взаимопомощи и внутренние инструменты: Использование корпоративного Slack и внутреннего аналога Stack Overflow поощряет открытый обмен информацией. Репутация инженера или команды отчасти зависит от их готовности помогать другим.
- «Встраивание» (`Embedding`): Практика временного (до трех месяцев) «одалживания» инженеров между командами. Это помогает быстро передавать экспертизу, решать проблемы с зависимостями и укреплять социальные связи.

Что выходит?

Масштабируемая автономия возможна и эффективна. Модель Spotify доказывает, что можно предоставить командам значительную свободу даже в очень крупной организации. Ключ к успеху — в способности команд к самоорганизации, сотрудничеству и коллективному принятию решений.
Автономия требует ответственности и согласованности. Свобода не работает без «благоприятствующих ограничений». Именно эти рамки позволяют всей системе оставаться управляемой и двигаться в одном направлении.
Основные барьеры для автономии не всегда связаны с менеджментом. Главными препятствиями являются технические и организационные зависимости между командами, недостаточная зрелость самих команд (неумение управлять своими процессами) и нехватка нужных компетенций.
Существует «цепь автономии». Производительность всей системы ограничена ее самым медленным и наименее автономным звеном. Проблемы одной команды быстро становятся проблемами для многих других, которые от нее зависят.
Главный вызов — поддержание модели при росте. По мере роста компании поддерживать культуру автономии и эффективные горизонтальные связи становится все сложнее. Это требует постоянных усилий и адаптации существующих практик.

Open Source порталы разработки и что такое IDP

Wed, 24 Sep 2025 23:12:48 +0300

На рынке внутренних порталов разработчика существует один явный лидер в категории open source — Backstage. Большинство других популярных решений, таких как Port, являются коммерческими (SaaS) продуктами, хотя они и могут предлагать open source компоненты для интеграции https://internaldeveloperplatform.org/developer-portals/port/

Поэтому основной фокус в open source сегменте приходится именно на Backstage, который был создан в Spotify и позже передан в Cloud Native Computing Foundation (CNCF).

Ключевое решение: Backstage

Backstage — это не готовый продукт, а фреймворк для создания собственного портала разработчика https://cloudomation.com/cloudomation-blog/5-internal-developer-portals-and-what-software-engineers-say-about-them/. Это его главное преимущество и одновременно главный недостаток. Он предоставляет базовые строительные блоки и архитектуру, на основе которых компании могут построить портал, идеально соответствующий их процессам и инструментам.

Кстати очень интересная статья про порталы, платформы и их различия.

Картинка от портала Cortex – ну прям огонь сайт у них https://www.cortex.io.

Cloudomation Guide – Building Internal Developer Platforms.pdf есть еще гайд обобщенный. А основная концепция конечно тут https://internaldeveloperplatform.org

Основные компоненты Backstage:

Software Catalog: Единый реестр для всех программных активов компании (микросервисы, библиотеки, веб-сайты, ML-модели и т.д.). Позволяет централизовать метаданные, информацию о владельцах, зависимостях и состоянии.
Software Templates (Scaffolder): Инструмент для создания новых проектов по заранее подготовленным шаблонам. Это стандартизирует первоначальную настройку сервисов, CI/CD пайплайнов, репозиториев и т.д.
TechDocs: Решение для создания, поддержки и отображения технической документации по принципу “docs-as-code”, когда документация хранится вместе с кодом.
Плагины: Экосистема Backstage строится вокруг плагинов. Существует огромное количество готовых плагинов для интеграции с AWS, Kubernetes, GitHub, CI/CD системами, системами мониторинга и многими другими. Если нужного плагина нет, его можно разработать самостоятельно.

Сравнение подходов: Build vs. Buy

Поскольку настоящий open source конкурент у Backstage практически отсутствует, наиболее корректно сравнить его не с другим open source решением, а с подходом использования коммерческих SaaS-платформ, ярким представителем которых является Port.

Port** — это коммерческий продукт, который предлагает готовый к использованию портал. Его философия заключается в гибкой модели данных на основе “blueprints” (шаблонов сущностей) и взаимосвязей между ними. Port позволяет быстро агрегировать данные из различных источников и построить каталог без необходимости развертывания и поддержки сложной инфраструктуры 10-best-internal-developer-portals-to-consider. Хотя ядро продукта закрыто, его интеграции и экспортеры данных являются открытыми [internaldeveloperplatform.org](https://internaldeveloperplatform.org/developer-portals/port/).

Сравнительная таблица: Backstage vs. Коммерческие IDP (на примере Port)

Критерий	Backstage (Open Source)	Коммерческие решения типа Port (SaaS)
Модель лицензирования	Open Source (Apache 2.0). Бесплатно.	Коммерческая (SaaS). Платная подписка.
Философия / Подход	Фреймворк для создания портала. “Построй свой дом”.	Готовый продукт для настройки портала. “Купи и настрой квартиру”.
Сложность внедрения	Высокая. Требуется разработка, развертывание и поддержка. Есть кривая обучения [cloudomation.com](https://cloudomation.com/cloudomation-blog/5-internal-developer-portals-and-what-software-engineers-say-about-them/).	Низкая / Средняя. Быстрый старт, не требует своей инфраструктуры.
Требования к команде	Нужна выделенная команда платформенных инженеров для разработки и поддержки портала.	Может управляться одним или несколькими DevOps-инженерами. Не требует навыков фронтенд-разработки.
Гибкость и кастомизация	Максимальная. Можно изменить и доработать абсолютно все, создать уникальные плагины и логику.	Высокая, но ограничена возможностями платформы. Кастомизация интерфейса и логики возможна в рамках, заданных вендором.
Инфраструктура	Требует собственной инфраструктуры для хостинга (обычно Kubernetes), базы данных, CI/CD для самого портала.	Не требует. Хостится и управляется вендором.
Экосистема и интеграции	Огромная, управляемая сообществом. Большое количество open source плагинов.	Управляется вендором. Интеграции создаются вендором, но часто есть открытые API и экспортеры данных.
Общая стоимость владения (TCO)	Скрытая и высокая. Лицензия бесплатна, но основные затраты — это зарплаты команды разработки и поддержки, а также стоимость инфраструктуры.	Прозрачная и предсказуемая. Основные затраты — стоимость подписки.
Поддержка	Сообщество (Slack, GitHub Issues).	Коммерческая поддержка от вендора (SLA, выделенный менеджер).

Выбор между open source фреймворком вроде `Backstage` и коммерческим продуктом — это классический выбор между “Build” (создавать) и “Buy” (покупать).

`Backstage` — это стратегическая инвестиция. Это мощное решение для крупных или технологически зрелых компаний, у которых уже есть выделенная платформенная команда и которые готовы вкладывать ресурсы в создание идеально подогнанного под себя инструмента. `Backstage` дает полный контроль, избавляет от зависимости от вендора (vendor lock-in) и позволяет решать уникальные задачи, которые не могут покрыть коробочные продукты.

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

Руководство

Создание внутренних платформ для разработчиков: лучшие практики, инструменты и стратегические выводы для технических лидов

***

Кратко о чем все это?

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

Независимо от того, оцениваете ли вы готовые платформы или создаете собственное решение, этот документ предлагает ценные сведения и тщательно подобранные ресурсы, которые помогут вам эффективно пройти путь внедрения IDP.

Основные тезисы:

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

***

Содержание

Что такое IDP?
Зачем нужны IDP?
Как работают IDP?
Обоснование необходимости IDP для бизнеса
Лучшие практики для создания IDP
Инструменты платформенной инженерии для создания IDP
3 проблемы при создании IDP
Ресурсы

1. Что такое IDP?

Внутренние платформы для разработчиков (IDP) лежат в основе дисциплины платформенной инженерии (Platform Engineering).

Пояснение:
Внутренняя платформа для разработчиков — это, по сути, продукт, предназначенный для разработчиков внутри организации. Она предоставляет им доступ по принципу самообслуживания к технической инфраструктуре и рабочим процессам, таким как конвейеры развертывания или облачные ресурсы. пост на dev.to. Ключевая идея — относиться к своей внутренней платформе как к продукту, а к разработчикам — как к клиентам. еще пост с dev.to. Это позволяет им не ждать выполнения заявок в отдел эксплуатации и не нести полную ответственность за инфраструктуру, как в модели «you build it, you run it».

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

Понимание внутренних платформ для разработчиков

На схеме ниже показаны ключевые концепции, лежащие в основе IDP.

Подходы «Инфраструктура как код» (As-Code Approaches): Акцент на автоматизацию и документирование через код.
«Золотые пути» (Golden Paths): Предоставление заранее определенных, проверенных и поддерживаемых путей для выполнения типовых задач (например, создание нового сервиса, развертывание в среде). Разработчики могут легко следовать этим путям, будучи уверенными в результате.
Самообслуживание (Self-Service): Позволяет разработчикам самостоятельно использовать платформу без необходимости обращаться в другие команды.
Управление как продуктом (Managed like a product): У платформы есть свой жизненный цикл выпуска, владелец продукта и дорожная карта развития.
Инженеры платформы (Platform Engineers): Создают и поддерживают IDP, фокусируясь на ценности для разработчиков.
Разработчики ПО (Software Developers): Основные пользователи, которые взаимодействуют с IDP.

Функции IDP

IDP предоставляют функции, которые являются центральными в повседневной работе разработчиков программного обеспечения.

Это лишь примеры функций, которые может иметь IDP. Каждая IDP уникальна для организации, которая ее использует. Часто они создаются с нуля или сильно кастомизируются под нужды компании.

2. Зачем нужны IDP?

По мере усложнения процесса поставки ПО организации сталкиваются с фрагментированными практиками DevOps, несогласованными рабочими процессами и операционной неэффективностью. От разработчиков ожидают, что они будут управлять инфраструктурой, конвейерами CI/CD, политиками безопасности и мониторингом, что часто приводит к когнитивной перегрузке и снижению производительности. Именно здесь на помощь приходят платформенная инженерия и IDP.

Раскрывая мощь IDP

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

3. Как работают IDP?

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

Фронтенд IDP
Бэкенд IDP
Множество других инструментов, интегрированных с IDP

Фронтенд: Пользовательский интерфейс для доступа разработчиков к IDP. Часто это внутренний портал разработчика (Internal Developer Portal).
Бэкенд: Управляет интеграцией и автоматизацией с другими инструментами. Эту роль часто выполняет оркестратор платформы.
Интегрированные инструменты: Различные инструменты, которые работают с IDP для выполнения ключевых процессов (CI/CD, мониторинг, безопасность и т.д.).

Архитектура

Следующая диаграмма архитектуры, основанная на модели CNOE (Cloud Native Operational Excellence), дает более детальное представление.

Ранее писал про Rainbond китайский, там немного другой акцент, но их архитектура тоже интересная, а так как это опенсорс, то можно свой такой запилить, но переводить придется :)

В этой диаграмме «Портал разработчика» (`Developer Portal`) является фронтендом IDP. Компонент «Оркестрация рабочих процессов» (`Workflow Orchestration`) будет бэкендом.

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

Ключевая функциональность IDP

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

Таким образом, бэкенд IDP, как правило, должен быть сильным в двух типах функциональности: №1 Интеграция и №2 Автоматизация.

Интеграция: Объединение разнообразных инструментов и сервисов в единую систему.
Автоматизация: Связывание и оркестрация существующих конвейеров автоматизации.

4. Обоснование необходимости IDP для бизнеса

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

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

Вот как можно обосновать необходимость IDP, обращаясь к четырем ключевым проблемам руководителей: Масштаб, Затраты, Риски и Управление.

1. Масштаб: Предоставление организации возможности двигаться быстрее

Проблема руководителя: Как мы можем масштабировать наши инженерные команды и поставку ПО без узких мест?
Обоснование IDP: IDP повышает производительность, абстрагируя повторяющиеся, низкоценные задачи. Она дает командам приложений возможность самостоятельно обслуживать инфраструктуру, CI/CD, тестирование и развертывание стандартизированным и безопасным способом.
Бизнес-результаты:
- Повышение скорости работы команд приложений и организации в целом.
- Быстрая доставка большей бизнес-ценности, поскольку команда разработки может сосредоточиться на коде.
- Возможность масштабирования без линейного увеличения найма DevOps-инженеров.
Как это сделать: Оцените, сколько времени команды приложений тратят на борьбу с инфраструктурой и инструментами развертывания, и сколько — на работу над своим основным приложением. Используйте эти данные, чтобы обосновать необходимость IDP и показать, как она может высвободить время для основной задачи, что напрямую влияет на бизнес-ценность. Визуализируйте это, чтобы подчеркнуть, каким объемом инфраструктуры приходится управлять командам приложений, и сравните это с тем, как это могло бы выглядеть.

*(В оригинальном документе здесь показаны два слайда из презентации PlatformCon23, представляющие “текущее состояние” и “будущее состояние”. Текущее состояние показывает, как команда из 50 разработчиков приложений вынуждена вручную взаимодействовать с разрозненным набором инструментов. Будущее состояние показывает, как команда платформы предоставляет единый, унифицированный слой, который абстрагирует эту сложность, позволяя командам приложений работать более эффективно.)*

Обратите внимание сколько кубиков вверху, а сколько внизу. В России кстати очень быстро вырывается вперед разработка на фреймворках streamlit, они почти ничего не делают повторно, если развернули хоть раз его с авторизацией и ипишками – в основном только ui колбасят. Но часто такие инициативы не вырастают сильно, их обычно давят в зародыше, так как они не соответствуют общему формату и не хотят делать все остальные кубики или не умеют – в общем похожи они на shadow it. Но если же им каким, то образом это удалось, то потом их не остановить и придя к ним через год, можно увидел второй прод, полностью зеркальный :) и сделал его кто-то один вечерами.

2. Затраты: Оптимизация за счет масштабирования и повторного использования

Проблема руководителя: Как нам контролировать растущие расходы на облако и инженерию?
Обоснование IDP: Платформенная инженерия сокращает дублирование усилий и консолидирует управление инфраструктурой. IDP способствует экономически эффективному масштабированию, обеспечивая прозрачность и контроль на протяжении всего жизненного цикла ПО. Централизация позволяет совместно использовать ресурсы, проактивно отслеживать затраты и автоматически высвобождать неиспользуемые активы (например, тестовые среды).
Бизнес-результаты:
- Улучшенная прозрачность и предсказуемость затрат.
- Снижение общей стоимости владения (TCO) за счет оптимизации ресурсов.
- Большая рентабельность инвестиций (ROI) в облачную инфраструктуру.
Важный момент: Команды платформы могут отслеживать метрики использования и отключать неиспользуемые среды.

3. Риски: Сокращение точек отказа и операционных угроз

Проблема руководителя: Какие риски угрожают нашей способности поставлять продукт надежно и безопасно?
Обоснование IDP: IDP минимизирует операционные риски и риски безопасности путем стандартизации процессов по всем направлениям — конвейеры CI/CD, развертывание, наблюдаемость (observability), оповещения и аутентификация.
Бизнес-результаты:
- Снижение риска сбоев в продакшене.
- Централизация ключевых сервисов, таких как развертывание, управление идентификацией и логирование.
- Принудительное применение политик безопасности и соответствия на уровне платформы.
Примеры устраняемых рисков:
- Задержки в поставке из-за нестабильных конвейеров.
- Утечки данных из-за неверно настроенных систем аутентификации.
- Непрохождение аудита из-за несогласованного логирования или дрифта соответствия требованиям.

4. Управление (Governance): Обеспечение согласованности и соответствия требованиям в масштабе

Проблема руководителя: Как нам поддерживать контроль, не замедляя команды?
Обоснование IDP: С IDP управление становится встроенным. От шаблонов до API, команды платформы могут кодировать стандарты и лучшие практики непосредственно в опыт разработчика.
Бизнес-результаты:
- Проактивное управление и применение политик.
- Улучшенная аудитопригодность и соответствие нормативным требованиям.
- Формирование культуры инженерного совершенства.

Подкрепление доводов данными

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

Итоговые мысли: Что не дает спать руководителям?

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

Скорость выхода на рынок (Speed to market): Сможем ли мы поставлять продукт быстрее конкурентов?
Надежность: Выдержат ли наши системы нагрузку?
Безопасность и соответствие требованиям (Security & Compliance): Уязвимы ли мы для взломов или аудитов?
Масштабируемость: Сможем ли мы расти, не теряя контроля?

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

5. Лучшие практики для создания IDP

Этот раздел основан на идеях, вдохновленных видео Виктора Фарчича «От нуля до полностью работающей платформы для разработчиков за 5 шагов!». Он описывает не столько шаги, сколько ключевые возможности, которые должна иметь IDP, чтобы быть полезной.

5 ключевых возможностей IDP (по версии Виктора Фарчича):

API
Управление состоянием (State management)
Одноразовые действия / Рабочие процессы (One-shot actions / Workflows)
RBAC и Политики (RBAC & Policies)
Пользовательские интерфейсы (опционально)

Наш взгляд на ключевые возможности (немного измененный и дополненный):

API: Программный интерфейс для взаимодействия с платформой.
Пользовательские интерфейсы (не опционально): Удобный способ для разработчиков взаимодействовать с платформой.
Автоматизация: Включает как одноразовые действия (например, запуск сборки), так и управление состоянием (например, поддержание среды в нужном состоянии).
Ограничения (Constraints): Политики, управление доступом на основе ролей (RBAC) и т.д.
Документация и обнаруживаемость (Discoverability): Возможность легко находить сервисы, их владельцев и документацию.

Как это поможет мне построить платформу?

Если вы подумаете о проблемах, с которыми вы недавно сталкивались как инженер платформы или DevOps-инженер, вы, вероятно, сможете соотнести их с одной из описанных возможностей.

Некоторые примеры:

Если у вас проблемы с простоями инстансов или случайными высокими затратами из-за оставленных облачных ресурсов, у вас недостаточные возможности по управлению состоянием.
Если у вас проблемы с тем, что у инженеров-программистов нет доступа к нужной им инфраструктуре, или с тем, что младшие инженеры вмешиваются в развертывания, в которые им не следует вмешиваться, вы плохо управляете ограничениями.
Если ваши разработчики не могут самостоятельно запустить систему на основе feature-ветки или запустить сборку и тест для определенного коммита, вам нужно взглянуть на ваши возможности автоматизации одноразовых действий.
Если ваши инженеры-программисты просто не используют предоставляемые вами API и сервисы, вам, вероятно, следует взглянуть на предоставляемые вами пользовательские интерфейсы или проверить, обнаруживаемы / документированы ли ваши сервисы.

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

6. Инструменты платформенной инженерии для создания IDP

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

Категоризация инструментов и компонентов

Мы классифицируем эти инструменты, используя «референсную архитектуру», популяризированную `platformengineering.org`. Эта структура разбивает экосистему на пять основных компонентов, известных как «плоскости» (`planes`):

Плоскость управления разработчика (`Developer Control Plane`): Все компоненты, через которые разработчики взаимодействуют с платформой. Обычно включает GUI/порталы, контроль версий, облачные среды разработки (CDE), а также стандарты конфигурации, которые разработчики поддерживают сами.
Плоскость интеграции и доставки (`Integration & Delivery Plane`): Здесь происходит вся автоматизация. Инструменты CI/CD, автоматизация инфраструктуры и другие оркестраторы платформы обычно являются частью этой плоскости.
Плоскость мониторинга и логирования (`Monitoring & Logging Plane`): Как следует из названия, здесь находятся все инструменты наблюдаемости (observability).
Плоскость безопасности (`Security Plane`): Управление секретами, инструменты политик и другие инструменты безопасности.
Плоскость ресурсов (`Resource Plane`): Вычислительные ресурсы и хранилища.

Пример: Создание внутренней платформы для разработчиков

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

Плоскость управления разработчика

№1 Портал разработчика (`Developer Portal`)

Почему это важно: Внутренние порталы разработчиков служат единым интерфейсом и позволяют разработчикам, командам и инженерам-менеджерам обнаруживать сервисы, отслеживать владение, применять стандарты и улучшать программное обеспечение.
Инструменты для рассмотрения:
- Backstage: Популярный open-source фреймворк для создания порталов разработчиков, созданный Spotify.
- Port: Платформа для создания внутреннего портала разработчика с no-code подходом, что облегчает быстрый старт.
- Cortex: Корпоративный внутренний портал разработчика, созданный для ускорения пути к инженерному совершенству. [cloudomation.com](https://cloudomation.com/cloudomation-blog/5-internal-developer-portals-and-what-software-engineers-say-about-them/)
- Atlassian Compass: Компонентный каталог для отслеживания компонентов и команд, которые за ними стоят.

№2 Облачные среды разработки (`Cloud Development Environments, CDEs`)

Почему это важно: CDE — это удаленные среды разработки, размещенные в облаке или локально. CDE позволяют разработчикам работать в согласованных, стандартизированных средах, что устраняет проблемы «у меня на машине все работает».
Инструменты для рассмотрения:
- Gitpod: Позволяет запускать безопасные, контекстно-насыщенные среды для разработчиков в корпоративном масштабе.
- Coder: Предоставляет безопасные среды разработки для разработчиков и их агентов.

Плоскость интеграции и доставки

№1 Конвейер CI (`CI Pipeline`)

Почему это важно: Автоматизирует проверку кода, тестирование и обеспечивает более быстрые циклы обратной связи.
Инструменты для рассмотрения:
- GitHub Actions: Нативный CI для GitHub с настраиваемыми рабочими процессами.
- CircleCI: Высокомасштабируемый CI с поддержкой расширенного параллелизма.
- Buildkite: CI, ориентированный на разработчиков, с масштабируемой инфраструктурой.

№2 Конвейер CD (`CD Pipeline`)

Почему это важно: Конвейеры CD автоматизируют безопасное, повторяемое развертывание программного обеспечения.
Инструменты для рассмотрения:
- Argo CD: GitOps-ориентированная доставка для Kubernetes.
- Flux: Контроллер GitOps для Kubernetes.
- Octopus Deploy: Подходит для мультиоблачных и локальных (on-prem) сред.

№3 Оркестратор платформы (`Platform Orchestrator`)

Почему это важно: Инструменты оркестрации предоставляют логику для связывания рабочих процессов между различными инструментами и сервисами.
Инструменты для рассмотрения:
- Humanitec: Оркестратор платформы, предоставляющий динамические среды. Является лидером рынка IDP. [internaldeveloperplatform.org](https://internaldeveloperplatform.org/)
- Собственные решения/фреймворки: Многие команды используют общие инструменты, такие как Argo Workflows или пишут собственные скрипты на Python/Go для объединения своих процессов.

Плоскость мониторинга и логирования

№1 Наблюдаемость (`Observability`)

Почему это важно: Инструменты наблюдаемости обеспечивают видимость состояния, производительности и надежности приложений и инфраструктуры.
Инструменты для рассмотрения:
- Prometheus: Набор инструментов для мониторинга и оповещения, особенно для Kubernetes.
- Grafana: Инструмент для создания дашбордов, часто используемый в паре с Prometheus.
- Datadog: Облачный мониторинг и аналитика.

Плоскость безопасности

№1 Менеджер секретов (`Secret Manager`)

Почему это важно: Менеджеры секретов безопасно хранят и распространяют учетные данные, ключи API и другие конфиденциальные данные.
Инструменты для рассмотрения:**
- HashiCorp Vault: Ведущее в отрасли решение для управления секретами.
- AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: Решения от крупных облачных провайдеров.
- Sealed Secrets (Bitnami): Шифрует секреты для Kubernetes.

Вывод: Строительные блоки, а не список покупок

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

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

7. 3 проблемы при создании IDP

Этот раздел основан на идеях Гая Менахема (Guy Menahem), архитектора решений в Amazon.

Проблема 1: Попытаться поймать всех зайцев одним выстрелом

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

Проблема 2: Оценка затрат на создание и эксплуатацию

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

Проблема 3: Создание и управление каталогом программного обеспечения

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

Наш взгляд

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

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

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

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

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

8. Ресурсы и ссылки

Сообщества

Reddit – https://www.reddit.com/r/platform_engineering
Platformers – https://platformers.community

Рассылки

https://platformweekly.com

Ранее еще писал немного на другую тему, но про разработку и стандарты апишек,интересно, мало у кого они есть, выглядят вот так: https://gavrilov.info/all/analiz-zalando-restful-api-and-event-guidelines/

Growth Engineering: Искусство взрывного роста компании через код

Sun, 06 Apr 2025 10:58:04 +0300

На основе: https://newsletter.pragmaticengineer.com/p/what-is-growth-engineering

Что такое Growth Engineering?

В современном мире технологического бизнеса, где конкуренция ощущается на каждом шагу, компании постоянно ищут способы взрывного роста. На стыке разработки продукта и маркетинга возникла область, получившая название Growth Engineering. Это не просто написание кода – это стратегическое применение инженерных навыков для максимизации прибыли компании, оптимизируя каждый этап взаимодействия с пользователем. Алексей Комиссарук, бывший руководитель Growth Engineering в MasterClass, говорит об этом просто: “Growth Engineering – это написание кода, который помогает компании зарабатывать больше денег”.

Зачем компаниям Growth-инженеры?

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

Growth-инженеры особенно востребованы в компаниях, осуществляющих продажи потребителям или работающих по модели SaaS, на этапе Series B и далее. Именно тогда компания имеет достаточно трафика и ресурсов, чтобы проводить A/B-тесты и инвестировать в команду, которая будет заниматься исключительно вопросами роста.

Чем занимаются Growth-инженеры? Три ключевых направления

Работа Growth-инженера лежит в трёх основных плоскостях:

Работа, непосредственно влияющая на бизнес:** Это сердце Growth Engineering. Здесь Growth-инженеры, вооружившись A/B-тестами и аналитическими инструментами, оптимизируют ключевые бизнес-метрики. Примеры задач:
- Оптимизация воронки регистрации:** Снижение барьеров для новых пользователей, упрощение форм, добавление социальных логинов, улучшение онбординга.
- Персонализация рекомендаций:** Разработка алгоритмов, которые предлагают пользователям наиболее релевантный контент или продукты, повышая вовлеченность и вероятность покупки.
- A/B-тестирование цен и пакетов услуг:** Проверка различных ценовых стратегий для максимизации дохода, включая тестирование скидок, пробных периодов и различных комбинаций функций в платных планах.
- Оптимизация рекламных посадочных страниц:** Создание и A/B-тестирование целевых страниц, адаптированных к конкретным рекламным кампаниям, чтобы повысить конверсию посетителей в лиды или клиентов.
Предоставление возможностей для роста:** Задача Growth-инженера – расширить возможности команды маркетинга и других специалистов, предоставив им инструменты, которые позволяют самостоятельно реализовывать идеи и экспериментировать без постоянного участия разработчиков. Это включает в себя:
- Интеграцию с платформами автоматизации маркетинга (например, HubSpot, Marketo), автоматизируя e-mail маркетинг и работу с пользователями.
- Создание инструментов для работы с CDP (Customer Data Platform) для сегментации пользователей, таргетинга и персонализированных предложений.
- Настройку систем атрибуции для отслеживания источников трафика и оценки эффективности маркетинговых каналов, позволяя максимально точно определять ROI (Return on Investment) маркетинговых активностей.
Работа с платформой:** Чтобы команда Growth могла двигаться максимально быстро, необходима надежная платформа, включающая в себя:
- Микросервисную архитектуру, позволяющую командам независимо развертывать эксперименты и избегать конфликтов.
- Создание инструментов для автоматической интеграции с маркетинговыми платформами, упрощающими процесс подключения новых сервисов.
- Централизованные системы ведения логов и аналитики, обеспечивающие доступ ко всем необходимым данным для мониторинга и анализа результатов экспериментов.
- Централизованную A/B платформу, которая позволяет удобно проводить и анализировать результаты экспериментов.

Почему Growth-инженеры работают быстрее, чем Product-инженеры?

Ключевое различие между Growth и Product Engineering кроется в философии и подходе к работе. Product-инженеры *разрабатывают*, чтобы создать продукт. Growth-инженеры *разрабатывают*, чтобы учиться. Growth Engineer быстрее принимает решения, потому что их цель – проверять гипотезы, а не создавать идеальный продукт сразу. Они быстрее оптимизируют свою работу, чтобы можно было проводить как можно больше экспериментов.

Представьте себе строительство. Product Engineering – это возведение небоскреба: основательно, долговечно, но требует огромного количества времени и ресурсов. Growth Engineering – это скорее установка палатки: быстро, дешево и легко. Палатка не предназначена для жизни на века, но она позволяет быстро проверить, подходит ли это место для более основательного строительства.

Пример из практики: Masterclass и ценовые планы

В Masterclass команда Growth Engineering столкнулась с необходимостью протестировать новую модель ценообразования. Разработка полноценного многоуровневого решения заняла бы месяцы и потребовала привлечения множества команд. Вместо этого, Growth-инженеры реализовали “фейковую дверь” – показали пользователям страницу с различными тарифными планами, которые на тот момент еще не были реализованы. Анализ данных показал, что переход на новую модель ценообразования может значительно увеличить доход компании. Это позволило убедить руководство инвестировать в полноценную разработку.

Инструменты Growth-инженера: Технологический стек

Для эффективной работы Growth-инженеру необходим обширный набор инструментов, охватывающих разработку, аналитику и автоматизацию маркетинга:

Языки программирования:** Python, JavaScript, TypeScript и другие, в зависимости от специфики проекта.
Feature Flags:** LaunchDarkly, Optimizely – для быстрого включения и выключения функциональности и проведения A/B-тестов.
Продуктовая аналитика:** Amplitude, Mixpanel – для отслеживания поведения пользователей и оценки эффективности изменений.
Экспериментальные платформы:** AB Tasty, VWO – для автоматизации A/B-тестирования и анализа результатов.
Системы мониторинга и алертинга:** Datadog, Grafana, Prometheus – для оперативного выявления проблем и оповещения о критических ситуациях.
Платформы автоматизации маркетинга:** HubSpot, Marketo, Iterable – для автоматизации коммуникаций с пользователями и персонализации маркетинговых кампаний.
CDP (Customer Data Platform):** Segment, mParticle – для управления данными о клиентах и создания персонализированных предложений.

Кто такой Growth-инженер: Необходимые навыки и качества

Чтобы преуспеть в Growth Engineering, необходимо обладать не только техническими навыками, но и определенным складом ума:

Любознательность:** Желание постоянно учиться новому, исследовать и экспериментировать. Умение смотреть на все глазами пользователя и анализировать причины тех или иных действий.
“Строительство ради обучения”:** Готовность быстро прототипировать, проводить эксперименты и учиться на ошибках.
“Мастер на все руки”:** Обширный набор навыков, позволяющий решать задачи, лежащие на стыке разработки, аналитики и маркетинга.
Аналитическое мышление:** Умение анализировать данные, выявлять тренды и делать обоснованные выводы.

Организация команды Growth: Где размещаются Growth-инженеры?

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

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

Стать Growth-инженером: Путь к карьерному росту

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

В заключение

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

Методы приоритизации задач

Wed, 26 Mar 2025 18:49:34 +0300

Методы приоритизации задач: как эффективно управлять временем

Картинку стащил из паблика

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

---

1. Матрица Эйзенхауэра

Принцип: Задачи делятся на четыре категории по критериям срочности и важности:

Срочные и важные (Do): требуют немедленного выполнения (например, кризисные ситуации).
Важные, но не срочные (Schedule): планируются на будущее (стратегические цели, саморазвитие).
Срочные, но не важные (Delegate): можно делегировать (рутинные задачи, ответы на письма).
Несрочные и неважные (Delete): устраняются (бесцельный скроллинг соцсетей).

Пример:

Do: Срочный отчет для клиента.
Schedule: Планирование квартальной стратегии.
Delegate: Ответы на стандартные запросы через ассистента.
Delete: Просмотр развлекательных видео в рабочее время.

---

2. Time Blocking (Временные блоки)

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

Пример расписания на понедельник:

|Время|Задача|

|-----------|---------------------------|

|9:00–11:00|Глубокая работа (написание статьи).|

|11:00–12:00|Встречи с командой.|

|13:00–14:00|Обработка срочных задач.|

Совет: Используйте буферные периоды между блоками для переключения контекста.

---

3. Метод 3-3-3

Принцип: День делится на три части:

3 часа на глубокую работу (сложные проекты).
3 часа на выполнение срочных, но менее важных задач.
3 часа на рутинные дела (проверка почты, административные задачи).

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

---

4. ABCDE-метод

Принцип: Задачи ранжируются от A (наивысший приоритет) до E (можно исключить):

A: Последствия невыполнения критичны (например, оплата счетов).
B: Важно, но не срочно (планирование отпуска).
C: Желательно, но не обязательно (оптимизация процессов).
D: Можно делегировать (подготовка документов).
E: Исключить (устаревшие задачи).

---

5. Moscow-метод

Принцип: Задачи сортируются по категориям:

Must have: Без этого проект провалится (основной функционал).
Should have: Важно, но не критично (дополнительные фичи).
Could have: Желательные улучшения (улучшение UI).
Won’t have: Откладывается на будущее.

Пример для разработки приложения:

Must have: Регистрация пользователей.
Should have: Интеграция с соцсетями.
Could have: Анимированные переходы.

---

6. Принцип Парето (80/20)

Принцип: 20% усилий дают 80% результата. Фокусируйтесь на задачах с максимальной отдачей.

Пример:

20% клиентов приносят 80% прибыли → Уделяйте им больше внимания.
20% функций продукта определяют его успех → Сначала реализуйте их.

---

Итоговые рекомендации

Комбинируйте методы: Используйте матрицу Эйзенхауэра для ежедневной приоритизации и Time Blocking для планирования.
Регулярно пересматривайте задачи: Удаляйте или делегируйте то, что потеряло актуальность.
Избегайте перфекционизма: Согласно принципу Парето, иногда «достаточно хорошо» лучше, чем «идеально».

---

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

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

🔗 Подробнее: [scottcaputo.com](https://scottcaputo.com)

Web3 project management tools

Thu, 30 May 2024 11:42:15 +0300

Интересные аппки

https://www.alchemy.com/best/dao-project-management-tools

https://dework.xyz/

Закончил продуктовое обучение

Tue, 13 Feb 2024 20:02:18 +0300

Все было 🤘

Scrum is a cancer

Mon, 28 Aug 2023 00:08:06 +0300

Хм...

Yuriy Gavrilov: posts tagged Management

Личный бюджет – open source (actualbudget)

Управление организационными системами с коалиционным взаимодействием и модели оптимизации иерархических структур

1. Анализ

2. Краткое содержание по главам

Глава I. Модели коалиционного взаимодействия

Глава II. Взаимодействие при полной информации (Стимулирование)

Глава III. Взаимодействие с сообщением информации (Распределение ресурсов)

3. Дополнительные знания (контекст)

4. Итог

5. Рекомендации и переосмысленные выводы

Переосмысленные выводы:

Рекомендации для проектирования систем управления:

1. Анализ материала и методологии

2. Краткое содержание по главам

Глава 1. Постановка задачи

Глава 2. Обзор литературы

Глава 3. Оптимальные деревья (Ядро книги)

Глава 4. Примеры и приложения

Глава 5. Обобщения

3. Дополнение новыми знаниями и современный контекст

4. Итог, рекомендации и переосмысленные выводы

Итог

Практические рекомендации (на основе моделей книги):

Переосмысленные выводы (Insight):

Свой Heroku: запустил Dokku дома и накатил новогоднего :)

Часть 1. Фундамент: Запуск Dokku в Portainer

Docker Compose конфигурация

Часть 2. Приложение “my-first-app”: Новогоднее гадание

Код приложения (`app.py`)

Подготовка к деплою

Процесс деплоя

Часть 3. Уровень PRO: Скорость (uv) и Marimo

1. Ускорение сборки с `uv`

2. Ловушка масштабирования (Scaling)

3. SSL в локальной сети

Итог

Bar is sooooooooo high – Platform Takes The Pain

Часть 1: “Bar is sooooooooo high” – https://nekrolm.github.io/blog.html

Учим английские выражения и их значение в контексте статьи, любопытно

Рецепт выгорания от Amazon или почему “планка так высока”

Стихотворение в стиле АЙ да Пушкина :) 🤖

Часть 2: О статье про Spotify (“Platform Takes The Pain”)

Суть и смысл статьи

Устройство, культура и особенности Spotify

Чем Spotify отличается от других (например, от Amazon из первой статьи)?

Итоги

Если коротко – оригинал по ссылке выше

Основные рекомендации и стратегии, применяемые в Spotify

Что выходит?

Open Source порталы разработки и что такое IDP

Ключевое решение: Backstage

Сравнение подходов: Build vs. Buy

Сравнительная таблица: Backstage vs. Коммерческие IDP (на примере Port)

Рекомендации

Руководство

Создание внутренних платформ для разработчиков: лучшие практики, инструменты и стратегические выводы для технических лидов

Кратко о чем все это?

Содержание

1. Что такое IDP?

Понимание внутренних платформ для разработчиков

Функции IDP

2. Зачем нужны IDP?

Раскрывая мощь IDP

3. Как работают IDP?

Архитектура

Ключевая функциональность IDP

4. Обоснование необходимости IDP для бизнеса

1. Масштаб: Предоставление организации возможности двигаться быстрее

2. Затраты: Оптимизация за счет масштабирования и повторного использования

3. Риски: Сокращение точек отказа и операционных угроз

4. Управление (Governance): Обеспечение согласованности и соответствия требованиям в масштабе

Подкрепление доводов данными

5. Лучшие практики для создания IDP

Как это поможет мне построить платформу?

6. Инструменты платформенной инженерии для создания IDP

Категоризация инструментов и компонентов

Пример: Создание внутренней платформы для разработчиков

Плоскость управления разработчика

Плоскость интеграции и доставки