Что там думает McKinsey и Сережа о продуктивности и эффективности команд в 2025 году?Ледяные майские праздники в России продолжаются, а у нас сегодня необычный формат привычной субботней рубрики #сережазаваспочитал . Ведь мы не просто переводим интересный материал, сегодня мы рассуждаем о материале. На глаза попалась статья McKinsey самап которой дали ребята из Future of Work (кстати классный канал, подписываемся). Собственно синопсис в том, что маки проанализировали 1700 неких команд в 75 организациях (здесь сразу важный нюанс, ни что такое “команда”, ни в каких конкретно организациях проводился рисерч не понятно, но фабула предполагает, что речь идет о +- типовых продуктовых командах в неких цифровых индустриях). И собственно наши дорогие коллеги задаются вопросом о том, что же влияет на эффективность этих самых команд?В итоге, они выделили три измерения, на которых строится ответ: 1. Delivery Predictability. Здесь от базы вроде “какой объем мы запланировали vs какой объем заделиверили” до более интересных материй типа автономности команд (и здесь мы маков горячо поддерживаем, настоятельно рекомендуем нашим клиентам, у которых строим производственные процессы, уметь отслеживать “индекс автнономности” каждой команды. Считается элементарно, берете бэкдэйтом бэклог за последние полгода и считаете процент задач, в которые команде нужно было привлекать кого-то извне больше, чем на 10% всего объема трудозатрат по задаче. А дальше уже можно задаваться вопросом насколько автономными команды должны быть (что, по большому счету, всегда производная от доступных денег, т.к. у любой автономности есть цена) 2. Value realization. Здесь очень правильный заголовок замазан в куче лозунгов. То есть если коротко, реально суперважно считать, принесенную и упущенную ценность от работы команд. Нельзя держать команды, у которых нет целей и связи между их бэклогами и влиянием на эти цели. Точнее можно, если деньги, ну совсем некуда девать. Но у маков здесь пространный месседж о том, что вообще супер важно не проектное финансирование, а командное, и прям одна строчка про некий Product-level planning. 3. Team engagement. Здесь кстати классный микс из очевидных штук вроде уровня вовлеченности и удовлетворенности, до более интересный вроде нормальной функционально-ролевой модели (натурально, в каждом первом проекте вокруг производственных процессов мы видим кучу сложностей из за размытых и супер неочевидных границ ответственности внутри команд), а еще классная штука это индекс “автоматизации рутинных задач”.Детальки по каждому измерению можно почитать в отчете, но вот чего мне не хватило, так это истории с постоянным анализом потерь и простоев. Всем нашим клиентам мы стараемся донести одну простую истину: рост эффективности продуктовых команд напрямую связан с тем, насколько ее лидеры отслеживают потери, простои и любую иную неэффективность на системной уровне. У всех команд есть “полезное время” (пишем код, рисуем дизайн и тд) и “бесполезное время” (ждем кого-то извне, нам поднимают стенд, данные не готовы и тд). Так вот ежемесячное отслеживание, классификация и устранение причин “бесполезного времени”, на мой вкус, является самым действенным методом в работе с эффективностью любых команд. Требует кучу дисциплины, внимания, и желания руководителей делать тот самый deep dive, но с точки зрения удельной пользы - лучшее, что мы видели.В общем спасибо дружочками, что тему поисследовали, есть о чем пошуршать всем любителям измерять эффективности всех форм, цветов и размеров )P.S. PDF’ка исследования в первом комментарии, не благодарите )
пишем README и документируйте код — через месяц вы сами сможете разобраться в своём решении 
тестируем предобработку и edge-cases, a.k.a"что произойдёт, если на вход подать нули или пропущенные значения?" 
замеряем производительность — время выполнения, потребление памяти, узкие места итд. 
продумываем план продакшена, или же"как модель будет развёрнута, как обрабатывать ошибки, есть ли механизм отката?"Hint2: особое внимание стоит уделить интерпретируемости моделей
