Как сильный менеджмент помогает запускать продукты за неделю, растить сильные команды и менять мир (Дмитрий Абрамов)

Дмитрий Абрамов, Chief Product Officer, Skyeng

Всем привет. Меня зовут Дима. Последние два года я работаю в Skyeng. Конкретно сейчас руковожу продуктом в нашем новом бизнес-юните, который называется Edu Skysmart и который запустился во время пандемии. Сегодня я хочу поговорить про менеджмент, потому что последнее время меня особо волнует повышение эффективности обычных продуктовых команд. К сожалению, я понимаю, что менеджмент — одна из самых слабых сторон на рынке продуктов в наше время. С этим надо что-то делать. Почему меня вообще это заинтересовало именно сейчас? Потому что до прошлого года, до того, как мы стартанули новый юнит, в целом и так было все нормально. У Skyeng довольно сильный HR-бренд на рынке продуктов, поэтому найти просто сильных людей, которые знают все основные инструменты, про которые говорят на всяких продуктовых курсах — это не так сложно. Это отлично работает на рынке, который ты сам создаешь. На рынке, где особо нет конкуренции, где нужно просто делать классный продукт довольно быстро. Ты будешь там очень быстро расти. Теперь мы вышли на рынок школьного образования, а он выглядит немножко иначе.

Это примерно годовой бюджет нашего бизнес-юнита. Можно по-разному считать, но примерно полмиллиарда рублей. В обычной среде это очень неплохой бюджет, пока ты не понимаешь, что на твоем рынке есть другой игрок. Например, Сбер. Сбер обещает за год потратить на свой продукт для школ — платформу, которая теперь называется Сбер Образование — 15 миллиардов рублей. При этом это компания, которая не собирается зарабатывать, то есть они делают продукт, за который им кто-нибудь когда-нибудь заплатит, но сейчас у нет таких целей. Это еще ладно, потому что можно сказать: «Это до конца не по дефолту. Медленно». В целом — да, но, когда ты делаешь продукт для школьников, ты конкурируешь не только с игроками на таком же рынке, но и с интересными игроками. Например, с TikTok, который не занимается образованием, но, по сути, это образовательное видео.

Чтобы жить в такой среде, мало просто делать хорошие продукты. К сожалению, чтобы жить в такой среде, вам нужно кратно эффективней работать, чем ваши конкуренты. Даже, наверное, не кратно, а в десятки и сотни раз более эффективно, потому что иначе вас просто задавят ресурсами и ничего вы сделать не сможете. К сожалению, чтобы кратно круче и эффективнее работать, вам мало просто найти сильных людей. Потому что обычно сильный продакт умеет нормально работать с продуктом, считать юнит-экономику. Может быть, он это даже умеет очень классно, но только если он слабый руководитель, то у него нет никакого мультипликатора на команду, которая работает в его подчинении. По сути, management capacity — то, насколько сильный вы менеджер — именно multiply к тем людям, которые работают у вас в команде. Ни один менеджер сам руками не создает продукт. Вы не рисуете дизайн, не пишете код.

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

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

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

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

На данном этапе развития продукта мы считаем, что нам нужно быть супер быстрыми. Для этого надо очень быстро принимать решения.

Второй пункт связан с тем, что мы сейчас находимся на стадии активного поиска product/market fit и каких-то правильных идей, которые должны быть заложены в наши продукты. Для этого мы должны постоянно накапливать знания, потому что чем лучше мы знаем нашего пользователя, наш рынок, наших конкурентов, тем более мы эффективны. Если наши конкуренты не собирают столько данных, сколько мы, значит, мы более эффективны, чем они, если мы их накапливаем и умеем использовать.

Дальше еще одна базовая установка — это то, что мы всегда должны фокусироваться на наших целях. Это может прозвучать слишком банально, потому что всем надо фокусироваться на целях. На самом деле, нет. Есть компании и команды даже в Skyeng, которым не нужно здесь и сейчас прямо всю команду обязательно фокусировать на целях конкретно этого квартала или года. Некоторые компании специально вводят себе какие-то дни самоуправления, 10% на какую-то внешнюю задачу и так далее. У нас есть команда, у которой стратегия звучит сейчас, как осознанный дефокус. У нас ситуация другая. Нам нужно очень эффективно достигать ту цель, которую мы сейчас поставили, поэтому все должно быть на ней сфокусировано.

Следующий пункт мы для себя сформулировали так, что мы должны повышать концентрацию таланта. Концентрация таланта — это термин, который я нагло украл из книжки Netflix. Он говорит о том, что есть несколько возможных подходов к повышению количества ресурсов у вас в команде. Один из них — можно просто нанимать классных людей. У вас будет много людей и какое-то количество таланта. Если вы при этом будете слабых людей постоянно увольнять и оставлять только самых сильных, то общее количество ресурсов у вас снизится, но доля именно таланта среди оставшихся людей сильно повысится. Задача — повышать концентрацию таланта.

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

Следующее из блока «Задаем контекст» — это каскадирование целей. Здесь мы уже переходим в абсолютно предметную область конкретной работы с целями конкретного продукта. Что здесь самое важное? Самое важное — зачем мы с этого начинаем? Потому что далее во всей нашей работе ключевым будет именно прозрачность и связность всей нашей работы всего нашего фреймворка с ключевыми целями, которые должны очень прозрачно каскадироваться на всю команду. У нас есть два уровня каскадирования: совсем большое — более года, и локальное — в этом году. Более года — это наша цель и миссия на пять-десять лет вперед. Это супер амбициозная цель, которую мы себе поставили на пять лет вперед. Дальше каскадируемые из нее цели по годам. Цели по годам не смартованные. Они очень базово описаны, потому что мы планируем методом прогрессивного джипега. Мы не очень хорошо знаем, что будет через пять-десять лет, но мы понимаем примерную картину, и нам важно поставить перед собой супер амбициозную цель. Поэтому мы все каскадируем именно из нее.

Дальше есть цель на год. Цель на год уже абсолютно смартованная. Она у нас выражена конкретно в revenue. Она каскадируется на несколько направлений. По сути, что мы тут начинаем делать? Мы начинаем это все визуализировать. Я использую Miro. Мы в нем рисуем дерево наших целей. Дальше, по сути, все, что я буду показывать — это так или иначе документ, созданный в Miro. Это куски этого документа, где мы можем увидеть всю нашу систему целеполагания, менеджмента наших процессов и так далее.

Здесь можно увидеть, что мы каскадировали revenue по дереву меток. У нас есть два способа монетизации — по каждому свой таргет по выручке. Есть блок про качество продукта — определенные продуктовые метрики. Маркетинговый блок про привлечение пользователей. Дальше они ниже еще каскадируются. Дальше мы с этими подцелями тоже будем работать. Это старт, без которого начинать разрабатывать свою систему управления просто бессмысленно, потому что дальше все, что вы построите, должно быть подогнано именно под те цели, которые у вас сейчас есть. Именно поэтому в одну из базовых установок я записал то, что фреймворк должен постоянно обновляться. Нельзя просто сказать: «Я прочитал в книжке про какой-то фреймворк. Мы просто сделаем, как там, и все». Нет смысла, потому что ситуация постоянно обновляется. Ваш собственный фреймворк — это ваша система управления, которая актуальна именно здесь и сейчас, а не когда-то абстрактно.

После того, как мы сформировали контекст, можно переходить к следующему этапу — это выстраивание орг. структуры. Скорее всего, в тот момент, когда вы работаете в компании, орг. структура уже есть. У вас уже есть какие-то команды, какие-то люди в подчинении, тимлиды, дизайн команды. Может быть матричная структура. Может быть вертикальная. Я не знаю. Что здесь важно понимать? Что орг. структура, если вы сильный менеджер — это ваш инструмент. Это не должно быть навязано извне, вы просто один раз собрались в компании, решили, что у вас структура такая, или это решили ваши HR, топ-менеджеры. Нет, орг. структура — это живой механизм, который позволяет вам правильно управлять достижением ваших целей. Что мы здесь делаем? Во-первых, мы должны идти от дерева целей. Возвращаемся к нашему дереву и ставим вот такие круги на каждую цель.

Что здесь такое? Здесь просто имена ответственных за эти цели. Если вы понимаете, что такое целеполагание, то должны понимать, что цель не просто должна смартована, у нее должен быть конкретный ответственный. По сути, орг. структура идет именно от формы этого дерева и от достижения этих целей. Орг. структура должна отвечать на вопрос: как это дерево целей разбивается на вашу команду? Поставили эти кружочки, записали туда имена. Если за какие-то метрики не нашлись ответственные, вы начинаете их искать, формируя орг. структуру.

Дальше вы начинаете рисовать первую версию вашего дерева подчинения, вашей орг. структуры. Этот документ — это драфт орг. структуры моего направления, который я рисовал где-то несколько месяцев назад. Несколько месяцев назад я его рисовал, потому что, как я сказал, орг. структура — это живой инструмент. Ситуация меняется, вы регулярно можете ее пересматривать. Что тут важно? Тут важно увидеть, что тут куча всего. Это не просто стандартное дерево ваших людей, в котором указано: кто кому подчиняется и так далее. Здесь гораздо больше всего. Сейчас мы не будет проходить прям все, потому что это живая, настоящая орг. структура нашего департамента.

Что здесь важно понимать? Во-первых, здесь не только люди. Это драфт, это рабочая версия, поэтому здесь есть очень много всего. Красными помечены мои прямые подчиненные, а зелеными — проекты, которые я веду. Почему это так? Почему на одном уровне у меня люди и проекты? Потому что по факту, если вы именно руководитель, то для вас руководство человеком и самостоятельное ведение какого-то проекта — это похожего рода нагрузка. Нужно всегда отслеживать, чтобы под одним руководителем не было прямых подчиненных или прямых проектов слишком много. Считается хорошим — шесть-восемь. Если у вас 10-12 — это уже перегрузка.

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

Поэтому мы рисуем эту оргструктуру, а дальше идем на наши базовые установки и проверяем подходит ли она или нет. Например, базовая установка — быстро принимать решения. Значит, должна быть низкая связность команду. Я иду и проверяю, насколько отдельно каждая команда может принимать решения. Есть ли там зависимости по KPI, есть ли там зависимости по тому, над чему они работают — по продукту, по коду, по дизайну одних и тех же страниц и так далее. Есть ли какие-то ситуации, когда команды должны конфликтовать. Этого быть не должно.

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

Фокус на целях юнита — четкая привязка KPI к нашим целям. Я проверяю, что я четко могу понять, какие KPI будут у этого человека. Если на орг. структуре такая ситуация, что человек вроде делает что-то полезно, но отвечает чуть-чуть за это, чуть-чуть за это, чуть-чуть за это, то это плохая орг. структура. Ее надо поменять, чтобы у человека был конкретный фокус на конкретные подметрики из дерева целей.

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

Постоянно развивать фреймворк. Казалось бы, причем здесь орг. структура? На самом деле, все просто. Если вы хотите что-то делать, то вам нужно знать, что вы это собираетесь сделать, оформить это как проект, взять за него ответственного. Поэтому у меня на орг. структуре — это именно развитие нашего управленческого фреймворка. Проверили — орг. структура подходит. После этого мы будем еще регулярно ее проверять. У меня раз в месяц стоит слот времени в календаре, когда я проверяю орг. структуру. Вдруг ситуация поменялась, и она больше не актуальна. Едем дальше.

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

У нас появилась орг. структура. У нас появились классные ребята в команде. К сожалению, этого мало. Следующий шаг построения нашего фреймворка — это налаживание регулярного менеджмента в нашей команде. В первую очередь это разные процессы, встречи и какие-то рутины. Во-первых, регулярные рутины всего юнита. Тут я иду сверху вниз, начиная от всего продактового направления и даже всего бизнес-юнита. Понятно, что мы идем от целей, поэтому раз в квартал мы формулируем цели на квартал. Мы делаем планирование этого квартала. Это стадия, когда мы просто сформулировали цель, проверили, что она от годовой цели хорошо каскадируется, написали планы, построили какие-то предварительные roadmap, проработали с командой, провели какую-то декомпозицию.

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

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

То есть подпроцессы, которые происходят в каждой конкретной команде, тоже должны быть хотя бы в каком-то базовом виде описаны, чтобы вы на общей схеме могли провалиться и посмотреть, как там в команде идут дела, как там устроен процесс. Почему это важно? Потому что чем более сложный у вас продукт, тем более сложная у вас система и тем важнее уметь быстро заонбордить новичка, перевести человека из отдела в отдел, чтобы он мог разобраться. Эта прозрачная информация о том, как все устроено, в этом помогает. Естественно, описание конкретных подпроцессов делают конкретные тимлиды в конкретных командах. Они могут быть, как угодно. Это самый просто пример. У нас есть отдел ресерча — там четыре этапа. Все понятно. У какой-нибудь разработки внутри может быть какой-нибудь свой процесс и так далее. Самое главное, чтобы это все было описано и визуализировано в одном месте.

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

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

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

Дальше есть ключевые дашборды. Ключевые дашборды — это главный инструмент оперативного знания о том, что происходит в бизнес-юните здесь и сейчас. У нас это просто большие Excel с деревом наших меток и план-фактом по каждой метрике на недельной основе. Почему это Excel, а не какой-нибудь BITool? Хотя мы используем их табло, их даш (00:29:00) и прочие другие инструменты. В Excel можно довольно быстро все тюнить и менять формат этого всего представления. Самое главное, что в Excel можно потом создать новый лист, а старый лист заархивировать. Всегда, если нам понадобится провести какую-то ретроспективу, мы сможем просто к нему вернуться. Там никогда в жизни не изменятся данные, потому что там они просто цифрами введены. Это более устойчиво.

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

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

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

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

По сути, мы берем наши базовые установки и начинаем их декомпозировать на какие-то абсолютные мелочи. Есть мелочи, которые понятны для всех. Всем понятно, откуда они взялись. У меня любимый пример — это то, что у нас один из пользователей — это учитель школы. Учителя в школе — это взрослые люди за 50 лет. Они не умеют скролить. Поэтому мы внедрили принцип, что каждый дизайн, который должен увидеть учитель, должен быть сначала проверен, что в нем необязательно скролить, чтобы получить ценность. Это не те принципы, которые у любого в компании должны быть. Мы историческим путем поняли, что нам это нужно. Поэтому записали это в принципы.

По сути, у нас принципы, как завещал Рэй Далио… Можете прочитать его книжку. Он подробно рассказывает, почему они нужны. Здесь три примера. На самом деле, принципов очень много. У нас есть общая страничка, доступная всем, где есть этот реестр наших принципов. Любой член команды, придя в нее, может зайти туда, прочитать эти принципы и понять, как ему здесь принимать решения.

Что у нас получилось в итоге? В итоге у нас получилась целая система. Во-первых, она состоит из базовых установок и каскада целей — такого контекста, в котором работают все наши люди из команды. Во-вторых, там есть люди. У них есть роли, критерии, по которым они подходят или не подходят на свою позицию. У нас есть описанная и нарисованная орг. структура, которая всем доступна. Она была каскадирована именно от наших целей и идеально подходит в этот момент для этих целей. Дальше выстроили процессы — какие-то встречи, регулярные рутины, ретроспективы для того, чтобы пересматривать наш фреймворк и так далее. У нас есть цели артефактов — шаблоны документов, дашборды с цифрами, реестры знаний, форматы записи этих знаний. Опять же это доступно всем в команде, чтобы быстро иметь возможность найти любое знание или записать новое. У нас есть принципы, которые позволяют любому члену команды, особенно любому тимлиду, быстро принимать решения на базе всего большого управленческого фреймворка, который системно выстраивается, обновляется, дорабатывается и так далее. Любой тимлид, придя в нашу команду, ознакомившись с этим фреймворком, может компетентно, грамотно принимать любые решения.

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