Всем привет, меня зовут Андрей и я Project Manager. И на этом канале я снимаю видео про менеджмент, технологии и психологию. И сегодня я хочу с вами обсудить большую часть своей жизни, а именно работу проектным менеджером. Вот сегодня обсудим с вами вообще, кто такой Project Manager, зачем он существует внутри команды, какие обязанности он выполняет, с какими инструментами он работает, какие артефакты он создает. То есть мы сегодня с вами ответим на огромное количество вопросов.
Это... Видео признано быть для вас такой точкой входа в мир проектного менеджмента в IT, поэтому даже если вы ничего не знаете, это будет идеальный для вас кейс, когда вы сейчас придете, прослушаете это видео до конца и вы получите такой roadmap, скелет, архитектуру знаний, куда в будущем вы сможете уже складывать знания из других видео. Моя главная задача дать вам вот эту вот архитектуру, а сами знания вы сможете добывать потом в других ресурсах и просто складывать.
уже существующую систему таким образом все следующие знания у вас будут усваиваться лучше вы будете понимать взаимосвязь всех элементов этой большой системы и как обычно ребят ставьте лайки подписывайтесь на этот канал оставляйте комментарии таким образом я смогу понять что это видео для вас интересно так как это видео первое в этой линейке про проектный менеджмент я буду очень сильно благодарен вашей обратной связи если какие-то из существующих тем для вас уже понятны Найти необходимый вам таймстемп в описании к этому видео и перейти к необходимой для вас, наиболее интересной для вас части этого видео. Но для чистоты эксперимента я бы посоветовал вам смотреть от начала до конца. Таким способом вы сможете получить более фундаментальные и структурированные знания. Ну что, ребят, будет интересно, поэтому поехали. Субтитры сделал DimaTorzok Что такое проект?
И для этого мы пойдем с вами в самую главную книжку любого проектного менеджера, это Pm. В Pm у нас есть следующее описание. Проект это предпринятие с определенными датами начала и завершения, предпринятое для создания продукта, услуги, соответственно с заданными ресурсами и требованиями. То есть изначально мы с вами видим три составляющих внутри проекта. Это ограничения, дедлайны, это цель, что мы непосредственно хотим делать и ресурсы, с помощью которых мы будем это...
производить и теперь хочу поделиться с вами одной ментальной моделью которая мне помогла в свое время достаточно лучше понять что такое проект поймите что проект это не что иное как фикция его не существует в реальности ни одного проекта не существует реальность он существует только в головах у стейкхолдеров как результат проекта мы можем получить конечно что-то физическое здание какой-то продукт или услугу но при этом сама сущность проекта она существует только в головах у всех членов команды и компаний, которые будут работать над этим проектом. Соответственно, роль проектного менеджера здесь часто, во-первых, понимать, что находится в голове у разных стейлхолдеров проекта и нормализировать понимание о том, что необходимо сделать, в какие сроки, с какими ресурсами на едином уровне. Соответственно, поймите, что вы часто будете работать с информацией, информационными потоками и формализировать их в виде каких-то артефактов, документов, диаграмм и всему подобное.
И чисто как такой мыслительный эксперимент, давайте представим с вами жираф. Я думаю, каждый из вас сейчас представил себе животное, ходящее на четырех лапах, с длинной шеей, черно-желтого окраса. Но при этом, если я начну задавать вам вопросов больше, а что этот жираф сейчас делает, когда вы представили, а какое у него соотношение ног к...
шея и вот подобные вопросы в глубину скорее всего кажется что мы все с вами поняли и представили жирафа по-разному собственно эта проблема коренится в том что вербальный язык он не идеальный и часто люди могут называть одни и те же вещи разными вещами или назвать одну и тоже к примеру как в нашем случае животное но при этом иметь совершенно разное представление того что должно быть сделано в конечном итоге так как вербальный язык не идеален собственно нам необходимо понимать что что вообще другие люди думают и понимают касаемо этого проекта и формализировать это в виде документов, всяких картинок, графиков, чартов и многого всего другого. Об инструментах формализации этих знаний в физический мир мы поговорим немножко дальше в этом видео. Теперь давайте поговорим о составляющих проекта, потому что чем лучше и точнее вы понимаете, что такое ваш проект, из чего он состоит, тем вероятнее вы его успешно закроете, потому что подготовка, как известно, это половина... нашего успеха соответственно любой наш проект состоит из трех вещей первая цель что мы соответственно хотим произвести какую услугу или продукт второе это ресурсы какими ресурсами мы обладаем туда могут входить человеческие ресурсы специализация возможно какие-то там купленные программы к примеру у меня сейчас есть проект снять этот видео на youtube у меня есть купленный пример про и собственно в этом проекте эта программа будет тоже ресурс то есть нам необходимо собрать как можно больше информации о допустимых для нас ресурсах и третья часть это непосредственно ограничения ограничения бывают разными это могут быть временные ограничения к примеру дедлайна это могут быть функциональные ограничения на то что мы не можем использовать к примеру код из открытых источников, то есть open source код, потому что у нас с точки зрения безопасности стоит такое условие. То есть требования могут быть разные, и ограничения могут быть, как я уже сказал, временные, функциональные и нефункциональные, но о них мы поговорим немножко позже.
Теперь давайте поговорим о жизненном цикле проекта, об этапах жизни любого проекта, потому что наша с вами работа как проектного менеджера будет сильно отличаться в зависимости от... от того, на какой стадии сейчас находится наш проект. Также стоит понимать, что проекты фрактальны. То есть это означает, что внутри одного большого проекта может быть куча маленьких, и наоборот, этот проект может быть частью чего-то наибольшего, такого грандиозного и над проектом, над этим всем.
Все проекты проходят 5 основных стадий. Первая это инициализация, когда мы вообще понимаем, что нам необходимо сделать, формализируем понимание и готовимся к тому, чтобы что-то произвести. Вторая стадия это стадия планирования, когда мы собрали уже всю информацию и сейчас можем понимать, что мы будем делать, как мы будем делать, в какой последовательности и искать какие-то взаимосвязи.
К примеру, мы можем уже на этой стадии понимать, какие у нас возможно будут риски, составлять риск митигейшн планы и многое другое. То есть на этой стадии мы уже процессим всю информацию, которую мы на стадии инициализации собрали и из этой информации собираем какой-то план наших будущих действий. Третья стадия. это стадия выполнения собственно здесь у нас не так много мы собственно выполняем и наша задача следить за качеством продукта и за technical solution то есть технической точки зрения как именно хорошо или плохо мы будем выполнять поставленную перед нами задачу четвертая стадия это мониторинг то есть мы уже что-то произвели и мы можем наблюдать за тем что мы именно сделали то есть мы смотрим на качество на качество процесса на вообще исполняет ли то что мы сделали функции ради которых мы этот продукт создали и многое другое. То есть на этой стадии мы мониторим как и процесс создания, так и результат нашей работы, так и процессы, которые нас приводят к этому результату.
Ну и последняя, пятая стадия это завершение. Внутри этой стадии мы с вами будем проводить все, что нам необходимо для завершения проекта. Уведомлять необходимых стейкхолдеров, проводить презентации, к примеру, релизить продукт на какое-то окружение для нас, на какие-то сервера, к примеру. Вот. И собирать информацию информацию о том что мы сделали как мы делали что у нас получилось что мы можем сделать лучше в будущем и что какие ошибки мы можем не допустить наших будущих проектов теперь погнали к более интересному контенту поговорим с вами о том что такое методологии управления проектами соответственно я вам сейчас рассказал про 5 основных стадий и стоит понимать что в зависимости от выбранного вами инструмента и системы с помощью которой вы будете вести ваш проект эти стадии могут они могут быть длинными и идти последовательно они могут быть маленькими такими оперативными и собственно у всех этих инструментов есть одно всеобщее понимание что это не серебряные пули вы выбираете методологию выполнения проекта в зависимости от условий которые вы собрали там на стадии инициализации в самом начале проекта сейчас я не буду вдаваться в подробности фреймворков очень много и полезных инструментов них уйма возможно предоставлю статью с описанием этого всего в описании к этому видео а пока что стоит понимать что существует две самых распределить распространенных системы управления проектами это waterfall и agile то есть гибкие методологии в скобочках давайте напишем скрам потому что именно скром это одна из самых популярных систем из семейства гибких методологии управления проектами и так waterfall собственно waterfall это самая старая и самая популярная модель управления работы с проектами тут все просто мы из названия можем понять что waterfall это водопад соответственно каждая стадия у нас идет друг за дружкой они изначально планируется мы точно понимаем что сначала мы планируем пишем спеки дизайне утверждаем после этого программируем тестируем деплоем и проверяем то есть каждая стадия у нас идет друг за дружкой и мы не возвращаемся на прошлую стать таким образом мы будем точно понимать в какой промежуток времени на каком качестве а проекта и где именно внутри этого проекта мы будем сейчас находиться с помощью waterfall а созданы большие проекты к примеру такие как я не знаю ядерная бомба государственные планы то есть большое количество проектов в виде там самолетов технологий раньше были созданы с помощью этой методологии управления проектами но наш мир меняется он динамически появляются больше новой информации мы хотим подстраиваться под рынок потому что все может поменяться просто в одночасье поэтому люди придумали такую систему управления проектами, как Scrum.
Соответственно, мы долго шли к тому, что мы хотим быть более гибче и не планировать там проект на следующий год или два, а мыслить более мелкими периодами, такими себе итерациями. Agile пропагандирует за собой итеративное улучшение создания продукта. То есть мы уменьшаем наши циклы поставки до маленьких объемов, к примеру, это неделя или два. Собственно, внутри скрама это называется спринты.
Соответственно, в конце каждого спринта мы должны предоставить какой-то рабочий функционал. То есть это будет итеративное улучшение в скобочках increment. Собственно, что-то новое, что мы принесли в наш продукт. Соответственно, мы будем так частями двигаться и предоставлять после каждых двух недель уже что-то рабочее.
И таким образом наслаивать на наш продукт, сервис или услугу, неважно, какой-то новый. новое value какое-то новое значение соответственно у нас сильно уменьшается цикл разработки и если вдруг нам в будущем что-то захочется поправить мы просто в следующем спринте можем переписать эти требования или или их переделать и нам не надо будет как случае с waterfall мы уже никогда не вернемся на прошлую стадию потому что слишком много уже работы сделаны и слишком много взаимосвязи между объектами внутри системы уже было создано На более высоких уровнях вашего профессионализма вы будете использовать не какую-то определенную модель управления проектом, а скорее всего это будет смесь. Так как я уже сказал, это не серебряная пуля, и чтобы успешно закрыть проект вовремя в срок, и чтобы все были довольны, вы будете просто выдергивать необходимые вам инструменты из разных методологий и сами создавать свою уникальную, подходящую под этот проект, эту команду и этих людей.
Теперь, когда мы с вами обсудили, собственно, что такое проект, как проект разрабатывается, давайте теперь поговорим, собственно, о самой должности проектного менеджера. Проектный менеджер, aka PM, это должность саппорта внутри команды. То есть я хочу сделать на этом акцент. Если вы думаете, что вы станете управленцем, будете управлять программистами, тестировщиками, дизайнерами, и вот будете просто все говорить, они будут что-то делать, а вы будете почивать на лаврах, Это неправда и в принципе можете закрывать это видео и уходить, потому что на самом-то деле должность PM это должность помощника, это человек, который буквально является множителем продуктивности.
То есть поймите, что с PM, представьте, что вы в компьютерной игре, у вас есть какая-то команда, есть сильные персонажи, вот PM это такой саппорт, он делает всех этих персонажей еще сильнее, чем они были бы без него. И с моей точки зрения это самое... тяжелая и эмоциональная работа из всех, которыми мне приходилось заниматься, при этом параллельно одна из самых прекрасных.
Собственно, давайте поговорим сначала, почему одна из самых тяжелых. Потому что часто вы не будете видеть физических результатов вашего труда. Если вы программист, вы написали что-то, у вас есть код, вы понимаете, что вот вы что-то сделали.
Вы дизайнер, вы что-то нарисовали. У вас всегда есть физическое отображение вашей работы. У проектного менеджера с этим все очень сложно, потому что... результатов много, и они все организуют один проект, и тебе сложно ассоциировать этот проект с самим собой, что вот это то, что ты сделал, и оно работает вот так. Плюс ко всему на это накладывается еще такой, знаете, цикл обратной связи от всех людей, что у нас на постсоветском пространстве института менеджмента нет, и все люди думают, что менеджеры это люди, которые отдыхают, а вот пока все остальные работают, это не так.
Ко всему прочему, если вы уже работали На реальных проектах вы можете понять, что когда все идет хорошо, все думают, что так и надо, что ну вот мы так классно, круто все вместе работаем, и работа проекта здесь не замечается. При этом, если все плохо, понятное дело, что виноват проект, который не может устроить процессы. И вот из-за того, что когда все хорошо, типа все молодцы, все хорошо, а когда все плохо, виноват проект, это часто отражается достаточно большим эмоциональным следом на душе проектного менеджера.
Часто пиемы забывают слово «я» и остается только слово «мы», потому что мы говорим о том, что мы что-то вместе сделали, мы с командой. И это, в принципе, правильно, но просто об этом нужно понимать, что это сложно эмоционально, но при этом это очень круто. Представьте, что вы теперь будете работать с огромным количеством людей. Вы сможете видеть и управлять процессом, который больше.
вас соответственно то что вы раньше могли сделать как один там программист теперь вы сможете делать куда большие и более амбициозные проекты и видеть всю структуру взаимосвязи внутри вашего проекта как и логическую так и эмоционально вы сможете работать с большим количеством людей узнавать то какие они специалисты как они работают в работе и вот люди это то что будет вас травить внутри этого процесса потому что люди все разные несмотря даже на проекты каждый для вас проект даже один и тот же будет уникальным, потому что его будут делать разные люди. В разные периоды проекта проектный менеджер будет как и таким стражем порядка, так и борцом с пожарами, огнетушителем таким, так и космонавтом, который будет запускать продукты в космос. Список задач у проектного менеджера сильно разнится от проекта, команды, выбранной методологии работы и стадии этого проекта.
Но задач будет всегда очень много. что, знаете, если вы работаете программистом, у вас закончился список задач на этот спринт в бэклоге, и вы такие, ну, пойду, поковыряю технический долг, потому что задач больше прям таких насущных нет. То с точки зрения проектного менеджера у вас всегда будет большая куча задач, и у вас всегда будет бесконечный бэклог, который вы периодически будете переприоритализировать.
Задачи проектного менеджера делятся на две таких категории. Первая это стратегические, это те задачи, которые задают будущее движение проекта. Например, вот.
анализ и сбор первичных требований у стейкхолдеров, это сбор и планирование рисков, которые у нас, возможно, во время проекта произойдут, это утверждение сроков и управление, собственно, самим проектом. Так и тактические, которые будут помогать вашей команде решать такие стоперы, какие-то проблемы, которые встретились на вашем пути, это и написание спецификаций, мониторинг проекта, менеджмент, ожидания. ожиданий стейкхолдеров основных и все прочее.
Также теперь давайте поговорим с вами о работе проектного менеджера на разных стадиях проекта. Стоит понимать, что ваша работа, она будет сильно разниться в зависимости от стадии проекта, потому что на разных стадиях для проекта важны разные вещи. К примеру, как я говорил, на стадии... вы будете выявлять первичные требования, риски, работать со стейхолдерами, собирать команду и собирать как можно больше информации о том, что вы будете делать.
На стадии планирования вы уже будете собирать команду, понимать кто вам необходим. для реализации этого проекта искать возможно каких-то партнеров выбирать инструмент с помощью которого вы будете вести этот проект создавать процессы коммуникации и обмена задач внутри проекта и многое многое другое во время выполнения проекта вы будете общаться с разработчиками будете устранять проблемы и стопперы на их пути общаться со стейкхолдерами дописывать и уточнять требования задач всегда во время выполнения будет очень много параллельно с этим вы будете мониторить ваш проект наблюдать за качеством производства за то что вы успеваете укладывайте сроки за то что ресурсы у вас есть и они никуда не исчезают будете смотреть на наступление рисков и если что на них реагировать и все что связано с улучшением процесса то есть вы будете генерировать какие-то гипотезы изменять ваш рабочий процесс и смотреть на результаты этого рабочего процесса ну и завершение проекта будете подводить итоги смотреть на ваш процесс и создавать какие-то презентации для ваших Теперь давайте поговорим про инструменты проектного менеджера, то есть то, с чем вы будете работать. Они фундаментально делятся на три категории, по крайней мере так и делю я.
Первая это эмоциональный, вторая это программный и третья теоретически. Первая категория это эмоциональный-софт стилей. Так как любой проект состоит в первую очередь из людей, то важно с этими людьми уметь продуктивно работать, как в прямом, так и в переносном смысле.
Вам необходимо проявлять эмпатию. уметь убеждать быть лидером и многое-многое другое соответственно все эти стилы у нас проходят и лежат в категории эмоциональной программные тут уже навыки по работе с какими-то программами например для коммуникации это может быть дискорд слэг или айсеки у неважно skype все что угодно это фреймворке и программы для управления с собственно проектами это может быть ноушен это может быть джиро этому может быть Trello и куча других. И, собственно, хранение информации это Confluence, Google Drive и тот же Notion.
В зависимости от программы вам необходимо уметь этой программой продуктивно пользоваться, чтобы доставлять, во-первых, вашу информацию с одной головы в другую, теряя как можно меньше информации, и делать это быстро и продуктивно. И третья категория это теоретические знания. До новых встреч!
Входят ваши навыки в менеджменте, соответственно, в инструменте, то, что вы знаете, best practice в ведении проектов. Какие инструменты вы можете использовать с точки зрения, к примеру, мониторинга проекта, как вы можете собирать риски. как вы можете планировать, как вы можете оценивать ваши задачи. И вот весь этот поток информации, он лежит как раз в теоретической категории. Плюс ко всему туда же входят знания о домене и рынке, потому что если вы, к примеру, прошел...
умеете работать с людьми плохо разбираетесь в менеджменте но при этом у вас есть знания о домене о рынке в котором вы будете про собственно создавать проект то вы точно также можете сравнительно успешно завершить этот проект но стоит понимать что все из этих стадий важны и наиболее из них важны это эмоциональные и теоретически и теперь давайте поговорим о бизнес-процессах которые проходят внутри проекта любой проект он состоит из людей как мы уже успели понять ранее а а все люди это живые существа. Соответственно, проект, он на самом деле тоже живой, он эволюционирует и внутри него есть, как и у любого живого организма, какие-либо процессы. И тут мы подходим к одному очень важному правилу в мире проектного менеджмента, чтобы чем-то управлять, вы должны это понимать.
То есть, если вы хотите управлять дизайнерами, вы должны понимать процесс разработки дизайна. Если вы хотите управлять продуктами, вы должны в идеале понимать продакт менеджмент процесс. Если вы управляете программистами, вы должны понимать, как...
программисты работают что такое сейси что такое deployment что такое сервера и вообще что они делают внутри своей работы сейчас вам покажу небольшой пример бизнес процессов которые происходят в принципе в любом проекте и вашу роль как проектного менеджера в них итак поехали первая группа процессов это процессы работы с требованиями это requirements management и requirements development собственно requirements development это процесс создания требований вы собираете знания разрабатываете из них требования, которые должны быть произведены. И requirements management это распределение этих требований в максимально продуктивном виде, чтобы каждый из стейкхолдеров получал необх��димую для него информацию. Вторая категория это процессы планирования проекта.
Project planning, project monitoring and control и risk management. Собственно, в project planning туда входит бизнес практики и best practice о планировании проекта, как мы будем добить это наше. на стадии, что во время каждой стадии мы будем делать. Второй бизнес-процесс Project Monitoring and Control, как нам следить за успеваемостью выполнения нашего проекта. Третье, это риск-менеджмент, и, собственно, в риск-менеджменте мы будем собирать все необходимые риски, смотреть, как они будут аффектить наш продукт или проект, и как мы, собственно, с этими рисками будем работать в случае их наступления или ненаступления.
Процессы тестирования, это verification и validation. Если мы говорим про verification, это тестирование. то что наш продукт собственно сделан точно таким же каким мы его и хотели сделать то есть мы проверяем качество а процесс валидающим это процесс валидации того что вообще наша идея то что мы сделали решает поставленные при ней сдачи то есть к примеру у нас есть ложка мы произвели ложку и допустим представим что ложка у нас необычная а выгнутая и есть и неудобно процесс верификации покажет нам изначально такую же ложку которую мы хотели произвести это что у нас получилось мы посмотрим они обе выгнуты значит все окей мы произвели то что мы хотели с надлежащим качеством а теперь представим что мы эту же ложку валидируем и мы начинаем с помощью этой ложки есть мы понимаем что совершенно все неудобные процесс валидации это не проходит именно для этого нам нужны два процесса верификации и валидации и третья часть это процесс and product quality assurance это более глобальный процесс уже наблюдением за производством и за соблюдением процессов как таковых четвертая часть это процессы связанные с технологической частью процесса то есть это продукт интегрейшн интеграция нашего продукта в существующие environment клиента к примеру второй это technical solution это архитектура проекта из каких частей он состоит как они между собой работают насколько это все безопасно и третье это configuration management с точки зрения какие у нас есть сервера как эта инфраструктура между собой работает насколько у них безопасный обмен данными и многое многое В будущем вам необходимо будет разобраться с каждым из этих бизнес-процессов, с best practice внутри каждого из этих бизнес-процессов, но вы будете в них разбираться понемногу. Есть также более сложные бизнес-процессы, которые уже говорят об управлении организациями и о том, чтобы вот этот процесс создания проектов множить и качество этого процесса большого соблюдалось.
Но об этом мы поговорим с вами уже в следующих видео. Как я говорил в самом начале, одно из самых важных. деталей работы проекта.
У менеджера будет формализация информации и создание из этого каких-то физических артефактов и документов. Документов этих будет много и давайте сейчас с вами обсудим, какие самые часто встречающиеся артефакты и документы вы будете создавать или будете вместе с нами. с ними работать. Project Charter это главный документ, такая главная страница вашего проекта.
Там есть ссылки на требования, на риск менеджмент план, на кто вообще этот проект делает, когда его будет делать, то есть это такая сводная информация. со всех документов ссылками на все остальные документы в идеале чтобы какой-то человек разобрался вашем проекте вам достаточно передать этот продукт чартер и он поймет ну 80 процентов необходимой ему информации technical requirement или техническое задание собственно это самый частый инструмент с помощью которого вы будете передавать знания о том что необходимо что-то сделать какому-то человеку то есть это будет либо дизайнер либо тестировщик либо программист соответственно с требованием будете сталкиваться очень часто и и прописывать, что вам необходимо сделать, как вы будете проверять, что это сделано, и когда это должно быть сделано. Бэклог это приоритеризированный и оцененный с точки зрения времени или стори-поинтов, если вы используете скрам, список задач. Риск-менеджмент-план это план рисков, которые могут возникнуть в пределах нашего проекта, плюс мы описываем, во-первых, как этот риск может заэффектить нас, насколько высокая вероятность того, что этот риск сработает, и что мы будем делать в случае...
его наступление какой риск митинге чем экшен мы будем выбирать резал со взыкаст ему интервью то есть это результаты общения с заказчиком с нашими потребителями этот документ есть только в основном в продуктовых компаниях которые уже вышли на рынок у которых уже есть клиенты и обычно этот документ отдаст вам проток чтобы вы и ваша команда смогла более лучше понимать ваших клиентов и соответственно для которых вы будете разрабатывать тот или иной проект или услугу демо дэй презентейшн собственно презентации внутри которой вы будете говорить с вашими стейкхолдерами об основных показателях проекта, об успеваемости, ресурсах, команде, проблемах и о том, что вы, собственно, произвели за этот промежуток времени. Testing reports это, собственно, отчеты о тестировании. Их будет огромное множество, начиная от прогрессионных и смоук тестов, заканчивая просто acceptance тестингом ваших билдов.
Соответственно, они будут выглядеть вот так. Там будет задачка или commit от программиста в кодбейс. Кодбейс. И, соответственно, выполнена она, не выполнена, или там есть баги, баги критические, не критические, то есть вся информация об ошибках внутри вашего продукта будет храниться в тестинг-отчетах.
Это всего лишь небольшая, но одна из самых главных таких, знаете, категорий артефактов, с которыми вы будете сталкиваться. Фух, видео получилось достаточно большим и объемным, но при этом я, мне кажется, хорошо закрыл большинство вопросов, которые связаны с проектным менеджментом. Что такое проектный менеджмент, что такое проект, кто...
кто такой PM, какие артефакты есть у PM, какие есть бизнес-процессы внутри проекта и многое-многое другое. То есть я надеюсь, что свое обещание, дав вам структуру знаний, как это все вообще между собой работает, какие есть процессы и прочее, я вам дал, а в будущем вы будете складывать все уже новые знания об этом в пределах этой структуры. Знания будут усваиваться лучше, вы будете получать больше взаимосвязей какого-то знания с другими знаниями, которые уже будут храниться в вашей голове.
голове. А пока что я очень сильно вас прошу дать мне обратную связь в виде лайка, комментария, подписки к этому каналу, чтобы я понимал, что мне необходимо дальше продолжать делать подобные видео. Всем большое спасибо за ваше внимание и всем пока-пока!