Я тимлид в IT команде и я люблю читать. 5 лет назад я прочитал Фредерика Лалу «Открывая организации будущего». Потом Патти МакКорд «Сильнейшие. Бизнес по правилам Netflix». Потом еще 5 книг около менеджмента. И каждая книга меняла меня. Но с каждой новой я все более критично относился к предыдущим. Я всегда делал заметки с главными идеями книг и пробовал их в своих командах. В итоге в голове смешались мысли из всех источников. Горе от ума, если можно так сказать. Ничего не знать или знать много, но не структурировано - это практически одно и то же для меня.
Месяц назад я выписал подходы из всех источников себе на whiteboard. И пропустил их все через призму своего восприятия. Выделил общее, разное и тут готов вам рассказать про своё приключение. Считай, мета-анализ главных посылов из книг про управление командами.
О себе
2 года я работал ML/CV-инженером, 3 года - тимлидом ML/CV команды. В то время я активно участвовал в российских конференциях по ML - от DataStart до OpenTalks. Моя специализация была довольно глубока. Но наша команда росла, административных задач становилось больше и глубокая специализация терялась. Сейчас я знаю про всё современное, но поверхностно - мало практики. Последние 2 года я побывал в роли менеджера доставки продукта, техлида в проектной команде, руководителя отдела разработки, автора корпоративной культуры, а местами ощущал себя в роли менеджера проекта. Можно спорить, хорошо это или плохо - пробовать много ролей без глубокого погружения. Но это данность и сегодня я здесь. Тем не менее, у всех этих ролей есть общее - работа с командой. Разного размера, разной специализации, разной сплоченности.
В итоге, у меня не большой, но достаточный опыт, чтобы говорить про управление командой. Многие идеи из книг я пробовал в своих командах. У нас выделено достаточно автономии - это позволяло быстро пробовать и внедрять идеи. О них я тоже расскажу.
Ограничения
Читай “дисклеймер”. Наша команда - молодые заряженные IT-специалисты. Многие развивались в нашей компании сразу после универа. Мы много исследуем, тянемся к инновациям и работаем где-то между продуктами и проектами. Мы предпочитаем офисную работу, общение на “ты” и отсутствие дресс-кода. Мы не любим бюрократию. У нас есть отделы разработки ПО, продаж, РП, маркетинга, HR, сборки оборудования. Нас 40 человек. Год назад мы еще могли назваться стартапом, а сегодня нет. Мы поставляем решение для мониторинга дорожного трафика, поиска инцидентов, оптимизации светофоров. У нас B2G и сейчас мы выделяем отдел R&D для поиска новых ниш.
Всё выше - набор стекляшек в калейдоскопе, через которые я смотрю на книги.
Я понимаю и принимаю, что для других команд в другой стране или другое время мой опыт или опыт авторов книг может быть нерелевантен. Прошу и тебя принять это.
Сегодня оставим токсичность за бортом и помечтаем, что из описанного подошло бы твоей команде. Приветствую обмен опытом и советы, куда стоит покопать глубже. Дальше основная часть.
Подход
В приключении поучаствовали книги:
Том ДеМарко «Deadline: роман об управлении проектами»
Патрик Ленсиони «Пять пороков команды»
Фредерик Лалу «Открывая организации будущего»
Патти МакКорд «Сильнейшие. Бизнес по правилам Netflix»
Дж. Рейнвотер «Как пасти котов»
Лорейн Грабс-Уэст «Сотрудники на всю жизнь»
Да, эти книги не об одном и том же, но часть мыслей сильно пересекается. Или просто подаются под разным соусом. Еще хотел добавить в список Крис Восс «Договориться не проблема». Опыт из неё интересен в разрезе решения конфликтов. В книге описано, как слушать собеседника и находить его истинные обиды и желания. В остальном не очень релевантно. Поэтому здесь без неё, но рекомендую. В планах прочесть «Все начальники делают это» Брюса Тулгана и «Высокоэффективный менеджмент» Эндрю Гроува. После дополню доску, которой делюсь с вами.
Три шага:
Читая книги, я выписывал важные идеи. Не в блокнот с тесьмой красивым почерком, как в кино. Бардак из этих заметок лежит у меня в избранном Телеграма. Перечитывать книги накануне я не стал. Но для освежения в памяти на некоторые книги я нагуглил а-ля “основные идеи книги XXX”. Особенно свежи в памяти почему-то «Deadline: роман об управлении проектами» и «Пять пороков команды». Вспомнив всё, я кратко оформил идеи в стикеры whiteboard. Ссылка
Но я буду и скрины кидать. Вот так выглядела доска с описанными мыслями 6 книг. Каждый цвет - одна книга:
На стикеры я добавил небольшое описание и разместил их на доске, выделив идеи разных книг разными цветами. Каждую идею я постарался отнести к одной из сфер:
Найм сотрудников
Атмосфера в команде
Развитие команды
Рабочие встречи
Индивидуальный подход
Роль лидера
Обратная связь и коммуникации
Мотивация кнутом или давлением
Мотивация через вдохновение, цели и информацию
Управление рисками
Избегание лишней работы
Ответственность, принятие решений и делегирование
Конфликты
Я потратил неделю, выделяя разные сферы. Итерации приводили меня к вариантам с 7-20 сферами. Их можно выделять более академично или дробить сильнее с привязкой к практике. Но в итоге сошелся на вышеописанных тринадцати. Тут имхо - я выбрал оптимальный вариант для себя. Вот так выглядит итог:
Все идеи я кластеризовал по сферам из пункта 2. Если можно было подвести суть под один знаменатель, то я делал это. Иначе - отмечал для себя противоречия. Если противоречия были, то я копал глубже и пытался найти их причины. В итоге же выбирал для себя то направление, которые ближе по опыту.
Теперь рассмотрим идеи авторов отдельно по всем сферам. Для удобства в каждой сфере сделал блоки кратко и подробно.
Найм сотрудников
Кратко: Развивайте бренд, нанимайте приятных людей.
Подробно
Тут выбивается только Netflix с идеей набора лучших сотрудников. Насколько я помню из книги, под “лучшими” понималась эффективность сотрудника. Можно предположить, что это включает в себя и софт-скиллы, умение работать в команде. Тем не менее, Netflix набирает только опытных, зарекомендовавших себя специалистов на лучшие зарплаты.
Общее - нужен крутой бренд компании, чтобы кандидаты хотели у вас работать. Эту часть IT-компании закрывают с успехом - печенюхи, релакс-комната, кухня, отсутствие дресс-кода и неформальное общение. Я бы даже сказал, что эта тема устарела и сегодня картина развернулась на 180. Сегодня наличие плюшек считается нормой и не вызывает эмоций. А вот отсутствие - сразу вызывает негативное отношение. Подробно часть про бренд рассмотрена в книге Лорейн Грабс-Уэст.
Другое общее - нужно нанимать приятных людей. Тут я согласен. Мы часто берем сотрудников, которых обучаем сами. Поэтому для нас в первую очередь важно умение учиться, добросовестность и в целом первое впечатление. За 4 года у нас было 40+ наймов. Из них с таким подходом нам не подошли 4-8 (я дед и не выпил таблетки для памяти) человек. Можно по-разному оценивать, много это или мало. Но не, кто остался, стали хорошей эффективной частью компании.
Атмосфера в команде
Кратко: Развивайте доверие в команде. Поощряйте неформальное общение. Само собой это не случится.
Подробно:
Прописная истина - в команде важно доверие, личные отношения, настроение. Но что делать для достижения этих целей? Тут уже становится интереснее. Особенно в контексте IT-разработчиков. Само собой всё не придет. Нужно по-честному выделять время.
В книгах предлагается много подходов:
Для новичков выделяется ментор, помогающий сориентироваться в команде.
Собираются неформальные встречи, чтобы кратко поговорить про личные интересы.
Создается инструмент для обратной связи коллегам.
Проводятся тимбилдинги. Нужно смотреть на тимбилдинг, релевантный именно вашей команде.
Культура компании выстраивается так, чтобы люди не боялись критики, а критика была обоснованной.
Сюрпризы, дни рождения, чаепития и прочие мелочи.
И много другого. Наша компания использует практически всё из этого. За стенами офиса большая часть команды - друзья. Мы ходим на дни рождения друг друга, в бильярд и просто тусить.
Из сложностей - после окончания проекта дать команде работать дальше вместе не всегда возможно. Какая-то ротация всё равно происходит. Можно ли достичь варианта, когда уже все со всеми поработают и любая собранная команда будет эффективна? Сомневаюсь.
Однако, в этом списке отсутствует важный пункт про традиции и ритуалы команды, которые также объединяют команду. Возможно это было в какой-то из книг и я просто забыл. Тем не менее, считаю важным упомянуть его.
Развитие сотрудников
Кратко: Развитие команды и сотрудников нужно постоянно. Выясните потребности команды и с заботой помогите.
Подробно:
Тонкой красной нитью написано - развиваться нужно постоянно и требовать это от сотрудников. Но нужно делать это с заботой. А самое главное - чувствовать, чего же хочет команда. А затем давать возможность и свободу перемен.
Что для этого предлагают:
Составляются матрицы компетенций. Да, отдельная история про их объективность и постоянную актуализацию. Мы их используем и не сказал бы, что очень довольны.
На их основании составляются карты развития сотрудников. У себя не пробовали, не знаю.
Покупаются книги, оплачиваются курсы.
Проводятся встречи 1 на 1. Полезно, легко, можно погуглить. Я использую метод бутерброда - хвалим, даём критику, заканчиваем позитивно.
Постоянное улучшение процессов на основе пожеланий команды
Командные обучения. Тоже аккуратно, чтобы не уйти в карго-культ. Нужно отталкиваться от пожеланий и готовности команды.
Мне не близок беспощадный подход Netflix и Дж. Рейнвотер «Как пасти котов». И я не согласен, что безупречность/элегантность решения всегда лучший путь. Не всегда мы влияем на сроки. Не ко всем решениям нужно быть столь требовательным. Но в общем случае соглашусь.
Причем тут годовое планирование? Оно непосредственно влияет на планы развития команд. Горизонт более квартала полон неопределенности. Например, не стоит планировать карту развития компетенций разработчика на год вперед. Через квартал вы можете начать писать на Go. Можно ставить общие цели компании на год, но не стоит планировать глубоко. Вы потратите время, а через квартал всё перепишете. Особенно это актуально в IT-компаниях, где конкуренты, рынок, технологии меняются по щелчку (не Таноса, но путь в IT - сама неотвратимость).
Говорят, что у кого-то планирование на год вперед работает. Иногда это удача, а иногда особенность специфики компании. Например, если вы B2G, то иногда (никакой политики) в чем-то можно быть уверенным.
Патти МакКорд из Netflix говорит, что эффективная сегодня команда не обязательно будет эффективной завтра. И я согласен. Нельзя давать команде закостенеть в текущих процессах и инструментах.
Рабочие встречи
Кратко: Не плодите встречи
Подробно
Всего два тикета. Но чёрт возьми, да! Зачем плодить постоянные встречи, отнимающие время. Всё просто - если нужны периодические встречи, то делайте раз в неделю, не чаще. Иные встречи согласуйте в чатике со своей командой.
С другой стороны - общаться и делиться опытом нужно для поддержания атмосферы в команде и снижения бас-фактора. Просто не переусердствуйте.
Индивидуальный подход
Кратко: Подходите к каждому индивидуально, будьте терпеливы, помогайте раскрыться.
Подробно:
Вспомните, у вас в команде наверняка есть интроверт, которому можно дать сложную интересную задачу и он сделает её элегантно и быстрее всех. А если дать неинтересную - то он будет неосознанно, но саботировать процесс разработки. Или например, сангвиник, готовый взяться за любую задачу и всегда можно быть уверенным, что задача будет выполнена в ожидаемое время - не медленно и не быстро.
Такие коллеги бывают. И особенно ценно, когда знаешь, как с ними работать. Не бывает универсального солдата, кто делал бы всё быстро и правильно. Есть люди, к которым нужен свой подход.
Можете тут почитать про породы программистов из Дж. Рейнвотер «Как пасти котов». Довольно интересно, часть даже помогла мне.
Иногда думаю, что этим пунктом можно просто закрыть все дебаты про управление командой. Почти всегда нужен личный подход. А если он не используется, то можно попробовать и это даст увеличение продуктивности.
Но всё же я считаю, что индивидуальный подход занимает много времени и это, скорее, пряная специя для улучшения вкуса. В небольших количествах будет полезно любой команде.
Роль лидера
Кратко: Будьте близки к команде территориально, иерархично, эмоционально, интеллектуально
Подробно:
Лидер и руководитель - роли, часто совмещенные в одном человеке. Но не всегда это так. А если не так, то сигнал ли это, что у нас проблемы? Не всегда. Но важно, чтобы лидер команды и руководитель двигались в одном направлении. Один говорит, куда идти, другой - мотивирует команду идти туда вместе.
И все мысли из книг примерно об одном. Помогайте команде, будьте рядом, не отдаляйтесь от специфики, не бойтесь делегировать, не бойтесь показать слабость (аккуратно). Неустаревающая иллюстрация:
Обратная связь и коммуникации
Кратко: Поощряйте честность и дайте механизм для систематической обратной связи.
Подробно
Безусловная честность - один из принципов в корпоративной культуре нашей компании. Важно не стесняться говорить про успехи. И важно не сглаживать углы сложностей - это позволит команде ясно видеть, когда нужно объединиться. И замотивирует.
Обратная связь - это тоже столп для процессов коммуникаций. Мы проповедуем ОСВК - обратную связь высокого качества. Важно отметить старания человека, даже если цель не достигнута. А критику стоит давать объективно, безэмоционально. Желательно сразу с предложением решения проблемы.
У нас в компании для обратной связи в основном используются Ретроспективы. Там мы можем отметить, что было круто, а что не понравилось за прошлый период. Важно, что негативное можно писать анонимно. Ретроспективы могут быть для крупных отделов, всей компании или отдельных команд. Можно использовать Трекеры задач, чтобы после выполнения давать обратную связь членам команды.
Хорошее выполнение задач считается нормой - за него редко хвалят. А как только выбился из сроков - сразу идет давление. Не забывайте хотя бы изредка хвалить за сдачу задач в срок.
Отдельно нужно отметить возможность горизонтального общения. Это важно и удобно, но только когда команда понимает, как эту свободу использовать. Горизонтальное общение может отвлекать или приводить к выполнению странных задач.
Мотивация кнутом или давлением
Кратко: Угрозы, злоба и сильное давление сверху - это плохо. Давление и требовательность внутри команды - хорошо. Слабое редкое давление сверху может краткосрочно помочь.
Подробно:
Вот тут у меня были основные сложности и противоречия, которые я нёс в себе от книги к книге. Но похоже смог провести черту. Для этого нужно разделять давление по 3 параметрам - направление, сила, частота.
По направлению. Давление снаружи команды от руководства - это плохо. А давление изнутри (требовательность членов команды друг к другу) - это хорошо.
По силе. Излишнее давление снаружи точно плохо. Излишняя требовательность внутри команды может сыграть по разному. Но в целом лучше не переусердствовать
По частоте. Редкое слабое давление снаружи и сверхурочная работа могут помочь команде сконцентрироваться. Если делать это часто - эффект пропадет и демотивирует.
Мы в компании не поощряем сверхурочные переработки. Но раз в году бывают периоды, когда без этого не обойтись. Забавно, что части команды остаться поработать было даже в кайф. Однажды, 2 разработчика оставались ночевать у нас в офисе. И не припомню плохих отзывов про этот опыт. Наоборот - было понимание причин и воодушевление. Но это раз в год. Было бы чаще - никто бы не порадовался.
Интересное предположение из Deadline - команды без жестких сроков заканчивают быстрее. Тут на моей практике согласиться сложно. Срок нужен, но можно использовать его в своих интересах. Например через Objectives and Key Results ставить мотивирующий команду срок. Или ставить их нежестко, определяя период.
Том ДеМарко подсвечивает, что иногда бороться с давлением сверху очень сложно. Иногда невозможно. И здесь появляется единственный пример, когда практика избегания конфликта оправдана. Попробуйте его разрешить пару раз. Но если сверху злюка/тиран, то нужно искать другие пути решения. Прочитайте роман Тома ДеМарко - там интересный пример решения этой ситуации - там выделили 2 команды. Одна решала задачи так, как просило руководство - с бюрократией, ненужными обучениями, плохими процессами. А вторая по-настоящему двигалась к цели. Если итог такого эксперимента не изменит ситуацию, то надежды и правда нет.
В командах разработки требовательность членов команды друг к другу мы развиваем с помощью ретроспектив, код-ревью, матриц компетенций, встреч 1 на 1.
Ну и что тоже важно - если ты, как лидер и руководитель, единственный, кто пытается соблюдать сроки, справедливость и порядок, то это тревожный звоночек. Нужно исследовать атмосферу и мотивацию команды.
Мотивация через вдохновение, цели и информацию
Кратко: Честно информируйте команду о состоянии дел. Вдохновляйте сильными целями. Составьте и продвигайте вдохновляющую корпоративную культуру. Всё это мотивирует.
Подробно:
В пункте про обратную связь уже было упоминание безусловной честности. Здесь это тоже важно. Когда руководство честно говорит, что у компании проблемы (без обвинений и лишних эмоций), это может мотивировать команду. Безусловная честность предполагает и исключение сокрытия информации. Если вы инициируйте проект - расскажите команде, кто заказчик, сколько заплатят компании и почему мы хотим с ним работать.
Также можно мотивировать сильными целями. Например, OKR (Objectives and Key Results) мотивирует больше, чем SMART. Важно поставить цель выше, чем вас могло бы удовлетворить. Например, решение нужно через полгода, а по OKR можно попробовать сделать за 3 месяца. Но тут есть ловушка. OKR очевидно работает лучше для компаний, старающихся делать инновационные продукты. Цель “сделать ChatGPT первыми в мире” мотивирует бесконечно. Тут нужно подобрать свой подход и смотреть, работает ли.
Ну и корпоративная культура - её нужно оформлять, делать вдохновляющей и плотно всех знакомить. Это лучше, чем свод бюрократических правил. Например, мы взяли для себя большую часть принципов из корпоративной культуры Netflix - они мотивируют. Важно, что недостаточно оформить презентацию с культурой и показывать её новичкам. Культура должны отражаться в процессах, принятии решений и в целом все дела должны соответствовать словам. Иначе, культура - просто фикция, ширма.
Отдельно отмечу, что быстрый доступ к информации о работе команды в трекере задач тоже важен. Человеку важно иметь возможность увидеть, на какой стадии сейчас работа команды.
Управление рисками
Кратко: уделите внимание рискам
Подробно:
Пока не могу понять, управление рисками правда так всемогуще или нет. Про риски я читал десяток статей и наша компания проходила обучение. Однозначно, выписывание рисков - это очень полезно. Мы можем найти критический путь задач, лучше оценить сроки, понять стейкхолдеров и составить план Б. И мы это используем. Отдельно отмечу, что простой матрицы вероятности рисков недостаточно. Для каждого риска стоит расписать силу влияния, вероятность, причину, способ избегания, реакцию в случае происшествия и ответственного. Но достаточно ли этого для управления проектом?
Избегание лишней работы
Кратко: Не отвлекайте по мелочи и не давайте отвлечь вас. Старайтесь решить задачу самым простым способом.
Подробно:
Такая маленькая мысль, но такая важная. Я видел ситуации, когда прибегает менеджер другого проекта и говорит - нужно срочно раскопать старую могилу. И никакого контекста о приоритетах других задач у него нет. А разработчик простой человек - берет и переключается. Ну раз срочно. Конечно, частично это следствие излишней свободы и горизонтального общения. И именно поэтому каждый из нас должен думать о том, что же он сейчас делает. Такие отвлечения “выбьют из состояния потока” молодежь. А те, кто постарше, расфокусируются.
Ну и вопрос про самый простой и эффективный путь. Руководитель может написать задачу на разработчика с описанием примерного пути решения. И разработчик строго ему следует. Хотя именно он, конечный исполнитель, часто видит, где можно пойти другим путём и сделать быстрее. Поэтому к планированию задач нужно привлекать конечного исполнителя. А членам команды нужно быть смелыми предлагать свои пути решения.
Ответственность, принятие решений и делегирование
Кратко: Не бойтесь ответственности. Делегируйте задачи и доверяйте коллегам. Дайте больше свободы.
Подробно:
Ответственность - это и страх, и возможность. С одной стороны у тебя есть свобода принять решение, с другой - ты отвечаешь за него. Нужно поощрять взятие ответственности на себя членами вашей команды. Если за решениями всегда идут к вам - это плохо. Если вас просто информируют о принятом решении - это хорошо. Показателем тут может быть тип вопроса, с которым к вам приходят. Если возможный ответ - да/нет, то скорее всего человек попробовал разобраться и предлагает своё решение. А вопрос, требующий развернутого большого ответа, не очень.
Принимая любое решение, вы никогда не найдете безрисковый вариант. Риск - это данность. Именно это одна из причин, почему в командах сложно добиться согласия каждого. Донесите это до команды. Не всегда решениями будут довольны все - и это нормально.
Компания никогда не станет инновационной и сильной, если люди боятся риска и ответственности.
Желание брать ответственность следует за доверием в команде и способностью решать конфликты. Обратите внимание на иерархию пороков в 5 пороках команды. Не разобравшись с пороками внизу по иерархии будет невероятно сложно бороться с пороками сверху.
А вот пункт про измерение метрик, как альтернативы контроля излишней свободы, я пока не могу разделить. Говорят, это ведёт к следованию за метриками, а не за целями компании. Мы пока не пробовали измерять эффективность труда. Считаю, что хороший тимлид всегда заметит западение эффективности работы.
Конфликты
Кратко: Конфликты важны и нужны. Их решение - точка роста. Настройте в команде выявление конфликтов и их спокойное разумное разрешение.
Подробно:
Я слышал, как знакомые жалуются на конфликтную команду. Представляю, сколько там возможностей роста, если эффективно подойти к решению. Но стоит признать, что культура решения конфликтов - это непросто. Основные правила - быть спокойным, не избегать конфликта, аргументировать своё мнение, уважать чужое и допускать свою неправоту
Есть особенность, связанная с размером команды. Конфликт в большой команде неизбежно превращается в священную войну, которую невозможно модерировать. Лучше попробовать собрать меньшую команду для решения конфликта. Например, выделив делегатов от разных мнений.
Важно донести до команды, что все тут на одной стороне, а на другой стороне только лишь задача, проект, проблема. И не нужно расстраиваться, когда выбирают решение, с которым вы не согласны. Согласие всех - либо недостижимый идеал, либо признак незаинтересованности членов команды. И тут разделить бывает сложно.
Очень интересной считаю мысль про фасилитатора, которая проскакивает в нескольких книгах. Можно пригласить незаинтересованное лицо для помощи в решении конфликта.
Итог
Опишу через метафору - ощущение, что мы строим новую дорогу. И опыт каждого автора - это песочная подушка, которая позволит безопасно класть дорогу дальше. Или новые 100 метров асфальта, которые непосредственно ведут нас вперёд. А иногда - вообще новое направление проезда. В итоге всё вместе приведет нас в пункт назначения. Или не приведёт:
В конце концов самое важное - это уровень автономии на принятие решения в вашей команде. Не всегда вам разрешат общаться на “ты”, обсуждать цели компании или менять корпоративную культуру. Но это я отвлёкся.
Одни авторы смотрят на принципы управления командой сильно сверху, другие - с приложением к своим задачам. А например, Патрик Ленсиони вообще постулирует связь между ними. Если не обеспечить взаимодоверие в команде, то это снизит желание брать ответственность, а потом приведет к безразличию к результатам.
В целом я думал, что противоречий между идеями авторов будет больше, когда приступал к этой авантюре. Можно отметить, что есть небольшие отличия в градациях подходов - где-то жестче (Netflix), где-то мягче (Открывая организации будущего). А тут место для шутки - одни столпы рынка, а кто-то сходу назовёт бирюзовых?
Замечу, что некоторые идеи выглядят излишне радикальными. Например - собирать метрики разработки. Разработчики умные, они хакнут ваши метрики и будут двигаться не к целям компании, а к достижению метрик. Особенно если привязать метрики к финансовому поощрению. Хотите этого? Но это, скорее, исключение из правил. В остальном идеи одной книги как бы смотрят с другого угла на идеи других. Это даёт понимание, что входные данные очень важны. Оттолкнувшись от того, что есть, можно пробовать, экспериментировать и искать лучшее для себя.
Стоит ли в таком случае читать многообразие литературы? Конечно, да. Книги были написаны в разное время и прилагались к разным командам и частям бизнеса - это интересно и даёт опыт работы в разных командах. Но всё равно книги имеют общую стезю. Дописываю этот абзац и спокойно иду спать. Зная, что индивидуальный подход важен, градации существуют, но общий тренд всё же один. Буду признателен, если поделитесь идеями из других книг в комментариях. Интересно, как всё это сочетается вместе.
Выражаю благодарность за ревью коллегам - Александру и Константину. Отдельно - корпоративному консультанту по управлению проектами, Семеновой Дарье.
