декомпозиция что это в бизнесе

Разделяй и властвуй. Что такое декомпозиция цели и как ей правильно пользоваться

Что значит декомпозиция

Что такое декомпозиция? Декомпозиция ― это разделение большого объекта на маленькие части.

Работу декомпозиции можно показать на примере подготовки танцевального номера. Хореограф не может просто показать танец и ждать, что танцоры его сразу же запомнят и повторят. Это невозможно. Чтобы танец запомнился, хореограф делит его на комбинации (небольшие танцевальные кусочки). Каждая комбинация, в свою очередь, делится на отдельные движения. И вот, вся танцевальная команда сначала учит движения, затем всю комбинацию и потом пробует всё это под музыку. Как только комбинация освоена, команда переходит к следующей. В итоге получается целый танец.

Метод декомпозиции можно применять где угодно. Любую цель можно разделить на несколько мелких задач и значительно облегчить процесс её выполнения.

Для чего нужна декомпозиция целей

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

Упростить задачу, чтобы избежать прокрастинации. Прокрастинация ― это проблема многих современных людей, ведь вокруг много развлекательного контента, интересных дел, из-за которых никак не хочется переходить к сложным задачам. Однако, если большую цель разделить на несколько маленьких, взяться за неё будет не так сложно. Например, представьте, что вам нужно написать книгу страниц на 300. Как взяться за такое дело? Поставьте себе цель каждый день писать по 1 странице. Согласитесь, это выглядит не так уж пугающе.

Оценить осуществимость цели. Когда вы будете разделять задачу на части, вы можете увидеть сложности, которые были незаметны. Из-за этих сложностей реализация цели может быть под угрозой.

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

Принципы постановки цели и задач

Чтобы правильно поставить цель или задачу, нужно придерживаться нескольких принципов.

Методику правильной постановки целей назвали SMART, по первым буквам принципов. Итак, правильная цель/задача должна быть:

S — конкретной (Specific). Задача не должна быть выражена абстрактными формулировками. Например, вы готовите вечеринку ко дню рождения. Один из пунктов вы назвали «Подготовить помещение к вечеринке». Из такой формулировки точно непонятно, что нужно делать. Куда точнее, будут звучать формулировки «Сервировать стол», «Оформить фотозону», «Сделать фруктовую нарезку»;

M — измеримой (Measurable). У вас обязательно должна быть возможность посчитать результат. Например, вы решили заниматься спортом. Вы хотите делать некоторое количество шагов в день. Чтобы цель была поставлена правильно, укажите, сколько точно шагов вы должны сделать в день, например 10 тыс.;

A — реально достижимой (Achievable). «Хочу быть президентом!» ― говорите вы. Хороша цель, но достижима ли она? Если вы уже участвуете в политических проектах и известны в этих кругах, это ещё возможно. А если вы решили это неожиданно и хотите за пару лет добиться такого положения, скорее всего, у вас ничего не получится;

R — значимой (Relevant). При декомпозиции цели важно, чтобы задача была не слишком маленькой. В результате вы должны получать ощутимые изменения;

T — ограниченной по времени (Time bound). При планировании обязательно устанавливайте сроки каждой задачи, иначе продвижение к цели может сильно затянуться.

Ещё подробнее об этой теме вы можете прочитать в нашем блоге в статье SMART-система, или как поставить правильную цель.

Виды декомпозиции

Декомпозиция задачи бывает:

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

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

Этот подход плох тем, что при выполнении одной задачи не получается рабочий функционал. Команде бэкенда нужно ждать, пока их дело закончит фронтент. Если декомпозиция проекта применяется в рамках бизнеса, будет трудно показывать продвижение к цели заказчикам, да и самим выполненная задача не будет давать удовлетворение, так как её нельзя «потрогать». Из-за этого недостатка горизонтальную декомпозицию используют редко.

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

Если снова вернуться к нашему примеру, результатом выполненной задачи является готовый функционал: он прошёл все стадии (бэкенд, фронтенд, базы данных). Теперь новый продукт можно проанализировать, протестировать, показать заказчику и получить фидбек.

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

Выучить 20 000 слов.

Вы понимаете, что таким образом язык не изучается. Вы изучаете каждый из представленных пунктов одновременно. Вы берёте тему, изучаете в её рамках слова, сразу же пытаетесь их произносить и писать. Используя новые слова, вы пытаетесь складывать предложения, параллельно изучая грамматику. А это уже вертикальный подход. Поэтому специалисты советуют использовать именно его.

Недостатки декомпозиции

У метода декомпозиции есть несколько недостатков, которые стоит учитывать:

Метод не учитывает форс-мажоры. Внешние факторы (социальные, экономические, малая продуктивность исполнителей) могут внести значительные изменения в идеально продуманный план.

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

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

Декомпозиция процесса: как делать схемы онлайн

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

Чаще всего для декомпозиции задач используют метод интеллект-карт. К слову, о Mindmap, правилах и сервисах для их создания мы говорили в статье в нашем блоге.

Итак, визуализировать цель и декомпозировать её вам помогут следующие сервисы.

Miro ― интерактивная доска для удалённой совместной работы. Внутри сервиса есть возможность текстового, голосового или видеочата. Все действия на доске можно просматривать в реальном времени. Чтобы видеть, что показывает ваш собеседник, в приложении есть функция отслеживания курсора.

В Miro можно использовать различные медиа-файлы: картинки, PDF-файлы, документы из Google Drive и YouTube-видео. На доске можно строить схемы, выделять важные мысли маркерами, лепить стикеры.

Lucidspark ― это тоже виртуальная доска, прямой конкурент Miro. Вообще, это часть целого семейства программ: Lucidspark, LucidChart, Lucidchart Cloud Insights. Все эти сервисы синхронизируются, благодаря чему работа с сервисами даёт больше возможностей. LucidChart отвечает за создание схем и диаграмм, которые можно потом перенести на интерактивную доску. Lucidchart Cloud Insights — сервис для автоматического выстраивания архитектуры, схем и диаграмм с помощью уже имеющихся данных из AWS, GCP и Microsoft Azure. Кроме функционала, который есть в Miro, в Lucidspark есть интеграция с Jira, Slack, сервисами из Google Workspace и другими, а также корпоративный уровень безопасности документов и рабочих пространств.

Draw.io — это более простой инструмент, в отличие от первых двух. Это сервис для создания диаграмм, блок-схем, интеллект-карт и т. п. Однако в нём можно использовать документ совместно с другими пользователями, что также превращает этот инструмент в интерактивную доску. Только не хватает чата. Огромным плюсом программы является десктопная версия, которая поддерживается на операционных системах Windows, MacOS и Linux.

MindMeister — инструмент, похожий на Draw.io. Он ориентирован на создание интеллект-карт и схем, однако возможность совместной работы над документом позволяет разрабатывать этапы любых действий, например продаж. Есть множество шаблонов на все случаи жизни.

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

Источник

Декомпозиция как элемент управления продажами и определения KPI

Бизнесу многому стоит учиться у спорта. Особенно декомпозиции.

Тому, как победы на чемпионатах мира, Олимпиадах раскладываются до уровня конкретных ежедневных упражнений.

Я сам через это проходил.Во время учебы в школе с 5 по 11 класс я профессионально занимался легкой атлетикой.

И абсолютно каждый легкоатлет, в не зависимости от того, насколько он титулованный (даже если ты Усейн Болт) каждую тренировку выполняет комплекс специальных упражнений, который направлен на отработку техники бега. Повторюсь, это делают все, от мала до велика.

В бизнесе часто подобными вещами пренебрегают.

Цитата из книги «Откровенно. Автобиография Андре Агасси».

«Папа говорит, что если я отобью 2500 мячей за день, то за неделю это будет уже 17 500 мячей, а к концу года — около миллиона. Отец верит в математику. Он говорит, что цифры не могут врать. Ребенок, отбивший за год миллион мячей, станет непобедимым».

7-летний Андре Агасси тренировался с отцом на заднем дворе своего дома. У него стояла специальная теннисная пушка, которая подавала мячи, а он должен был учиться их отбивать.

Тоже самое можно переложить например на работу менеджеров по продажам и сформировать простую рекомендацию, которая повысит мастерство и как результат объем продаж.

Пример №1: если работа менеджера связана с активным звонками, то за основу должна быть взята норма звонков в день.Это базовый и обязательный показатель, которым не имеет право пренебрегать ни один из менеджеров. Не важно новичок ли он или ведущий менеджер. Просто у каждого это норма будет своя.

Пример №2: если кол-во продаж менеджера зависит от того, насколько он эффективно ведет свою базу и не забывает про клиентов, четко знает о чем говорить с клиентом и что предлагать и как продвигать его по воронке продаж, то обязательным условием является ведение CRM-системы и поддержание ее в актуальном состоянии. Именно CRM будет подсказывать и помогать менеджеру продавать больше и лучше.Тогда за правило должен быть взят показатель актуальности базы данных в CRM и качество ее ведения. Чтобы абсолютно каждый менеджер в течении рабочего дня выделял время для того, чтобы актуализировать ситуацию произошедшую за день. Запланировать свои следующие шаги, поставить задачи на завтрашний день и т.д.

Источник

Декомпозиция. Как разобрать огромный проект на понятные сегменты для предварительной оценки

Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?

Если вам достался жирненький проект, вопросы примерно такие же — какой круг задач предстоит, и как их предварительно оценить. Декомпозиция — крутой способ разложить всё по полочкам и прикинуть объём работ, заложить резервы на трудные блоки и докопаться до неприятных задач со звездочкой. Как это сделать, мы уже рассказывали в одном из обучающих видео. А для любителей вдумчивого чтения мы преобразовали его в крутую статью.

Уровни декомпозиции

Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!

1 уровень. Крупные блоки или компоненты

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

2 уровень. Страницы сайта или экраны мобильного приложения

В случае с блоком «мобильное приложение», как на схеме выше, разбиваем его на экраны. Но как узнать, что вы учли все-все-все возможные экраны? Для проверки полноты берите в расчёт сценарии использования — это даст понимание, какие задачи юзеры будут решать в приложении (или на сайте) и каким примерно образом они это будут делать.

Для e-commerce основной сценарий — продавать, а путь пользователя в нём выглядит так: каталог → список товаров → карточка товара и так далее.

Есть соблазн написать в смете только сценарий использования и его оценку (скажем, сценарий покупки товара или сценарий заказа такси) — ну, ведь понятно же, что там внутри. Нет, непонятно, и есть большой риск потерять множество шагов, поскольку такие сценарии большие, и их крайне сложно адекватно оценить целиком.

Когда сценарий раскладывается на экраны, шансов ошибиться становится меньше. Но помните, что каждый сценарий стоит проверять на связанность — достаточно ли вам вот этих экранов, чтобы этот сценарий сбылся?

У нас есть маркетплейс — магазин, куда другие производители могут загружать свои товары. Сценарии, лежащие на поверхности: загрузка своих товаров (загрузка и описание, разделы каталога и вот это вот всё), покупка товара (шаги покупателя на пути к цели), обработка заказа (как будут распределяться деньги, как будет получать свою долю маркетплейс и так далее). Если всё это не расписать подробно, можно запросто упустить кучу нюансов.

Будет ещё легче, если вы выделите ключевые роли на проекте (пользователь, администратор интернет-магазина и т. д.), у каждой из которых есть свой сценарий, а у каждого сценария — свой набор экранов. И тогда проверить полноту экранов ещё проще — достаточно посмотреть, связан и выполняется ли сценарий конкретной роли по ним.

3 уровень. Содержание экранов

В общем случае у вас на экранах могут быть какие-то вкладки либо какие-то блоки — грубо, вложенные экраны. Например, страница корзины/оформления заказа — здесь всегда есть блок товаров со своим сценарием (добавить-убавить-очистить), а еще блоки доставки, оплаты, авторизации, бонусной системы и так далее. Бывают ситуации, когда эти блоки также разбивают на экраны по шагам. Зависит от решения, принятого по итогам аналитики — бывает, что удобнее их всё-таки «слить» воедино.

Задача менеджера, когда он добрался до такого экрана, — посмотреть, из чего тот состоит. Бывает, экран легко разбить на блоки, бывает — сложно. Яркий пример сложной разбивки — калькуляторы: по ним чаще всего неочевидно, что происходит и как процесс расчёта делить на шаги.

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

Откуда эта хрень на странице?!

Итак, вы добрались до какого-то блока или страницы. Самое время задать себе вопрос «Откуда это на странице?!». Но проджекты, аналитики и аккаунт-менеджеры (и даже заказчики) вот тут часто-часто ленятся — «подумаем об этом потом».

Например, аналитик сказал: «это мы как-нибудь на коде решим», а потом на планинге сидят 4 умных человека, смотрят друг на друга и спрашивают: «кто это придумал, что это за маразм?!». Такая ситуация — явный признак, что где-то недоработали раньше. Бывает, конечно, что принятие какого-то решения действительно откладывается, но это должно быть осознанно и где-то зафиксировано.

Чем меньше вы понимаете в момент «Откуда это на странице!?», тем больше у вас должен быть зазор в смете. И когда к вам приходит клиент и говорит «а почему тут такой большой зазор?!», у вас должен быть готовый ответ — потому что вы не понимаете, как работает то, то и это (лучше — фиксированный перечень конкретных вопросов), и что эти вопросы вы будете выяснять вместе с ним позже.

Итак, какими могут быть варианты, откуда берутся данные на странице?

Вариант 1. Хардкод

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

Вариант 2. Включаемая область

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

Вариант 3. Из админки (из базы данных)

Итак, мы знаем, что какие-то данные выбираются из базы данных. Тогда нам нужно понимать, из какой сущности и из какого поля. Примеры сущностей в интернет-магазине: «товар», «раздел», «пользователь», «заказ» — то есть то, что состоит из каких-то полей. Поля — например, «цена».

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

Например, это формула

Когда информация хранится в базе, но ее нужно как-то определенным образом модифицировать, появляется понятие «формула». Одна из самых опасных вещей, которую менеджеры часто пропускают.

Когда вам аналитик говорит «ну там это как-то считается» — навострите ушки, впереди точно будет затык. Математики не понимают программистов и считают что, их формулу достаточно переписать и следом «просто» запрограммировать — делов-то. Но когда клиента начинаешь спрашивать о формуле, часто слышишь что-то вроде «ой, она у нас там в excel», или «механика пока непонятна», или вообще «ну скопируйте вон с того сайта».

Видите формулу — копайте глубже. У неё внутри есть коэффициенты — а откуда берутся эти коэффициенты? Добро пожаловать в новый виток расследования «Откуда эта хрень на странице!?».

Вот из-за этого о формулах никто не любит думать:)

В зависимости от используемой технологии бывает, что часть данных хранится в файлах. Может показаться, что это какая-то сущность или поле сущности, но это всё-таки ФАЙЛ.

Очень часто файлы в самой базе данных не хранятся, чтобы не «раздувать» её. Из-за этого работа с ними организована иначе. В случае банального каталога товаров файлом может быть фотография у пользователя (userpic), описания, спецификации в pdf и всё такое прочее. Такие файлы находятся не совсем в базе, но при оценке важно понимать, что они есть.

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

— Владимир Завертайлов, CEO & Founder

Как данные попадают в базу данных?

Обычно администратор или контент-менеджер садится и забивает данные ручками. Тогда здесь должен возникать вопрос, а хватит ли ему стандартных компонентов админки для этого. Для этого ПМ должен быть очень хорошо знаком с возможностями стандартной административной панели. А ещё с ними должен быть знаком аналитик и тестировщик (про кодера, понятно, молчим). В Сибирикс все QA-специалисты проходят базовый курс контент-менеджера, чтобы понимать, на что способна админка. Ну, а про то, что QA-спецы у нас обычно вырастают в проджект-менеджеров, мы уже как-то писали.

У вас на дизайне есть слайдер, где расставлены точки, по клику на которые открывается всплывашка, в которой есть фотография, описание и ссылка на куда-нибудь. Вопрос: как расставлять эти точки? Как вариант — координаты X и Y, но вряд ли контентщик будет счастлив от такого функционала. А значит, придётся что-то придумывать. И значит, в смету нужно это заложить.

Второй момент, который проджекты часто упускают, — права доступа и хватит ли их. А значит, это тоже нужно иметь ввиду и сразу перечислить потенциальные роли.

Вариант 4. Интеграция со сторонним ресурсом

Один из источников данных в базе — пользовательский контент. И здесь важно понимать, как он попадает в базу. На этом этапе часто теряется один из крупных сценариев: например, как пользователь вносит отзывы. У отзывов часто бывает рейтинг — штука с виду простая, но внутри она может быть довольно сложно организована. У чего больше рейтинг? Там, где поставили одну оценку в 10 баллов, или где 1000 оценок, но разных? Среднеарифметическое тут работает плохо. Но хитрые алгоритмы есть — привет, ещё один резерв в смете.

Если данные берутся всё-таки с внешнего источника, то без интеграции никак. Вариантов интеграции может быть несколько:

Другая проблема — админы сайтов, с которым парсятся данные, не слишком счастливы, что эти данные кто-то «ворует», и будут всячески защищаться. А это приводит к «падению» парсинга и попаданию в черные списки. Вы попытаетесь с этим бороться добавлением каких-нибудь платных proxy — короче, целый квест. Есть особые сервисы для организации парсинга — например, Mozenda, Automation Anywhere, Beautiful Soup, WebHarvy или Content Grabber (полный список из 30 сервисов ищите тут).

Здесь имеется ввиду, что есть какой-то интеграционный протокол, либо файловый протокол, либо XML, либо шина данных (сервер очередей вроде RabbitMQ, ZerroMQ или Apache Kafka) — подробнее о разнице штатной интеграции и по API наш техдир рассказывает тут. С чем именно интегрировать и по какому протоколу, на этапе предварительной оценки не столь важно — важнее, есть ли для этого документация. А у неё обычно бывает два состояния:

Хуже всего бывает, когда говорят «ну вы, программисты, между собой договоритесь и разберитесь сами как-нибудь». Если протокол не формализован и взаимной ответственности нет, критический путь проекта будет пролегать через интеграцию, и на ней он завалится. Или по крайней мере, здесь потратится куча времени на согласование с программистом заказчика его протокола и отладку.

Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).

Как все это «подружить»

Начинаем с крупных компонентов: первый, второй третий — можно расписать подробно. Следом важно примерно понять, какие есть пользователи (роли) и какие у них сценарии. Сами сценарии в смету лучше не прописывать. Дальше — идём по страницам. После — работаем с отдельными блоками, используя уже известную схему «Откуда эта хрень на странице?!».

Как только вы слышите слово «калькулятор» или «считается», напрягайтесь 🙂 Когда есть интеграция со сторонним сервисом — тоже. В остальном — ничего страшного, и всё довольно прозрачно 🙂

Когда это может не сработать

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

Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!

Источник