Developer productivity - Part I В большой компании часто сложно понять насколько эффективно работает организация. Конечно можно ориентироваться на разные финансовые показатели, включая Cost to Income Ratio, но у них есть две особенности: они очень общие и сложно понять вклад отдельных частей организации, а также они сильно запаздывают во времени. Поэтому менеджеры высокого уровня обычно желают получить более эффективный инструмент. Когда я думал над этим, то понял, что мне удобнее сначала построить модельку и сузить область размышлений. Я взял модель Run-Change-Disrupt - Run - это операционные процессы того, как мы делаем business as usual  - Change - это те процессы, которые направлены на изменение ситуации: создание новых продуктов, развитие существующих продуктов  - Disrupt -это процессы, связанные с внутренними стартапами, новым бизнес-моделям и трансформациями Для системных улучшений мы должны работать в каждой области, но сегодня я хотел сфокусироваться на Change. Причем если компания является продуктовой, а не сервисной, то в свою очередь продуктовый процесс тоже разделяется на две части  - Do the right things - это часть про бизнес и процесс discovery  - Do the things right - это часть про разработку и процесс delivery Причем сегодня я хотел обсудить часть delivery, где мне кажется, что обычно практикуют два дуальных подхода к повышению эффективности поставки ценности. 1) Bottom-up - улучшение процессов команд на местах силами линейных менеджеров. Дальше улучшение общих процессов подразделения силами middle менеджеров. Общий драйв к лучшему от топ-менеджеров. Для такого подхода в компаниях часто используются инсутрменты для статистического управления процессами. Этот подход напоминает то, как работает микроэкономическая теория для отдельного предприятия на рынке. То есть руководитель каждой команды сам отвечает за то, чтобы она эффективно работала в условиях спроса и предложения на рынке, внутренних процессов команды, цепочки взаимосвязей с другими командами и так далее. 2) Top-down - улучшение процессов за счет изменения глобальных параметров системы:  - Создание PaaS и большого количества платформенных команд  - Выделение функции SRE и системная работа над надежностью  - QA-стратегия, где фокус на автоматизации  - Data-стратегия и переход к DWH к Data Mesh - Активное использование AI к месту и нет Для таких больших изменений топ-менеджент обычно хочет понимать централизованный эффект, а также в идеале хочет уметь его моделировать. Это чем-то напоминает макроэкономическую теорию и роль государства в ней, которое может влиять на рынок через ставку рефинансирования, налоги, гостраты и так далее. Модели для сбора "макроэкономической статистики" по delivery часто у компаний нет, если не считать отдельные показатели с микроэкономического уровня, которые впрямую нельзя сравнивать и зачастую агрегировать. Но зачастую хотелось бы иметь показатель developer productivity и уметь на него влиять в положительную сторону. Продолжение в постах: 2 и 3 #Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership