#project

Серия Смешариков про работу Менеджера проектов.
Если что, записывайте всех в книжечку!

https://youtu.be/I5mNfhsimfA

@projectsproducts

#project #product

А вдруг вы еще не знаете, что есть школа менеджеров Яндекса,
и что сейчас в открытом доступе на Youtube очень классные лекции по управлению проектами и продуктами:
https://www.youtube.com/channel/UCQmAuu6V3kSzdIfrszr5iKg
Видео добавляются постепенно.

@projectsproducts

#project #product

Я писала в посте https://tttttt.me/projectsproducts/16 об инструментах, которые я использую в работе.
И как-то не стала писать о том, какие классные и удобные (на мой взгляд) инструменты используются внутри Яндекса.
А сегодня вспомнила, что ведь несколько недель назад Яндекс открыл свой Я.Трекер для публичного использования, а задолго до этого стал доступен Я.Коннект с функционалом: Календарь, Стафф, Вики..
То без чего я просто не представляю свою жизнь 🤓

https://connect.yandex.ru
https://yandex.ru/tracker/

Трекер правда платный (после первых двух месяцев использования), а вот Вики и Стафф («Люди и команды») можно использовать бесплатно (с рекламой и некоторыми ограничениями). Пользуясь этими инструментами уже 7 лет, я так к ним привыкла, что считаю это лучшими продуктами на свете, тем более они пока сильно дешевле продуктов Atlassian.

Если возникли вопросы по этим продуктам, пишите на почту elena.kotina@gmail.com.
@projectsproducts

#project

Жизненный цикл проекта - Project life cycle.

Сегодня про то, из каких фаз состоит жизнь проекта (к слову, набор фаз и их названия могут меняться в зависимости от метода управления проектами, который вы применяете, и от уровня контроля, который в организации есть).
Через несколько дней вернусь с постом про жизненный цикл продукта.

В рамках методологии PMI жизненный цикл проекта имеет 5 фаз (просто напросто этапов, на которые мы разбиваем нашу работу):
1. Инициация (Initiation);
2. Планирование (Planning);
3. Выполнение (Executing);
4. Контроль и мониторинг (Controlling and Monitoring);
5. Завершение (Closing).

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

В IT как правило применяется итерационная или смешанная модель жизненного цикла.

На картинке ниже коротко о том, что входит в каждый из этапов.

Мне, кстати, очень нравится, как об основах управления проектами (на базе PMBOK) рассказывает Александр Зубрицкий (вице-президент московского отделения PMI). С чувством, с толком, с расстановкой. Я слушала его курс на Project Management Master's Program. А еще нашла онлайн курс, но не знаю, будет ли он еще перезапущен - https://universarium.org/course/628

@projectsproducts

Жизненный цикл проекта

Ответ к публикации https://tttttt.me/projectsproducts/18:

Чем характеризуется проект?
1. Есть конкретная дата начала.
2. Есть конкретная дата конца или конечный результат.
3. Результат проекта уникален. В этом состоит главное отличие проекта от процесса или регулярной деятельности.
4. Ресурсы ограничены. Ресурсы для проекта ограничены всегда: ваше время, деньги, оборудование и т.д

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

Таким образом мой вариант ответа:
1. Строительство дома - это проект.
2. Сайт Привет-из-Германии.рф- создание этого сайта для веб-студии будет проектом, а для владельца - это продукт, который он будет развивать, и о котором он будет думать каждый день и ночь.
3. Проведение концерта Мэри Поппинс во Владивостоке - проект. (провели и забыли)
4. Регистрация входящих звонков в ИП «Ромашка» - это процесс. Мы регистрируем эти звонки каждый день, и будем продолжать регистрировать пока существует ИП «Ромашка»
5. Зубная щетка Colgate® 360° - продукт.
6. Регистрация ООО «Филимон» - проект.
7. Создание журнала «Звёздочка» - само создание журнала, это проект, а вот журнал «Звездочка» - уже вполне себе продукт.

Вопросы отправляйте на почту elena.kotina@gmail.com
@projectsproducts

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

Сегодня запись с лекции Школы менеджмента Яндекса: «Как создавать полезные продукты», Илья Воробьев.

99% проектов фэйлятся, по причине того, что мы оперируем неопределенностью о будущем и настоящем. Например, до середины 19 века люди считали, что лебеди бывают только белые, но в начале 19 века они нашли в районе Австралии черных лебедей. Об этом написано в книге «The Black Swan: The Impact of the Highly Improbable» (Nassim Taleb).
Суть в том, что когда мы пытаемся что-то описать (модель, формулу), то мы оперируем набором значений, которые нам на данный момент известны, но на самом деле это далеко не всё! Мир и будущее - это большая неопределенность, которую стоит подтвердить или опровергнуть.

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

Есть фреймворк для создания бизнес-модели «Lean Canvas»,
в которой есть блоки ключевых вопросов. Они помогают сформулировать вашу гипотезу. (Подробнее напишу в отдельном посте).

Почитать по теме можно книгу «Running Lean: Iterate from Plan A to a Plan That Works» (Ash Maurya) - https://www.amazon.com/Running-Lean-Iterate-Plan-Works/dp/1449305172

и что дальше?
Как тестировать гипотезы?
Про это есть другая хорошая книга »Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity" (Jeff Sutherland), где автор на примере своего проекта (разработка системы учета для ФБР) рассказывает, как они применяли SCRUM в своем проекта, и о тех проблемах, ошибках, которые у них были до этого. И первая из них состояла в том, что они фиксировали требования на долгий период. А чем дальше вы уходите в разработке, тем вам дороже становится цена ошибки.

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

Если говорить о снижении рисков, то важно отметить работу с «первыми пользователями».
Есть книга «Diffusion of Innovations (Everett Rogers)», где есть кривая Technology Adoptive Curve - она показывает, как технологии осваиваются пользователями.
Есть три основные группы в этой кривой: инноваторы (люди, которые готовы стоять в очереди за новым iphone, но их интерес скорее идейный), ранние потребители (люди, для которых решение проблемы очень важно, они без нее не выживут или не смогут дальше хорошо работать, они лояльны), массовый рынок (весьма консервативные товарищи).
Проводить все тестирования и ждать лояльных отзывов имеет смысл именно от ранних потребителей.

Продолжение следует…

#product #book
@projectsproducts

Часть 2, продолжение записи лекции «Как создавать полезные продукты»:

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

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

Метрики:
Метрики - это способ понять делаете вы хорошие или плохие вещи с точки зрения пользователей и бизнеса.

Есть 2 простых фреймворка, с которых можно начать:
- AARRR (книга: «Product Marketing for Pirates: AARRR!»);
- HEART (подробно можно почитать: «Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications (Google)»).
(Про продуктовые метрики напишу потом отдельно подробно.)

Мы много говорим о новых продуктах, о стартапа, но продукты бывают не только новые, а и вполне себе зрелые.
Жизненный цикл продукта состоит из таких блоков:
- Разработка
- Запуск
- Рост
- Оптимизация (подбор правильных структур доходов и расходов)
- Эволюция (например, продукт может остаться даже тем же, но вы поменяете этикетку, так как например в FMCG одни и те же продукты пользователям надоедают)
- Затухание, уход с рынка.

Кстати, ссылка на полное видео: https://www.youtube.com/watch?v=s3fNhgt7gBc&list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl&index=2

Продолжение следует…

#product #book
@projectsproducts

Часть 3 (финальная), продолжение записи лекции «Как создавать полезные продукты»:

Тестирование гипотез:
Есть 3 инструмента. Обычно они используются друг за другом, но не стоит доходить до маразма :) Они отличаются степенью точности и трудозатратностью.

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

- Качественные исследования (интервью пользователей):
В Яндексе для этого есть отдельная комната, где мы спрашиваем людей о том, какие проблемы у них есть, уточняем, подойдет ли им вот «такое» или «такое» решение.
В начале тестирования важно проверить, что этот тот человек, который вам нужен: сделать какое-то проверочное задание или задать контрольные вопросы. После этого уже можно делать выводы, можем ли мы этому человеку доверять.
На этом этапе можно достаточно дешево можно в фотошопе или Скетче нарисовать прототип , сделать его кликабельны в InVision и дать посмотреть пользователю.
По результатам мы уже можем понять, чем можно помочь, как можно решить задачу пользователя. В итоге формируем минимальный ценный продукт.

- Количественные исследования (A/B тестирование):
Преимущество в том, что можно проверить гипотезы на большом количестве человек. Если коротко: у нас есть группа А - у которых ничего не меняется, и группа В такого же размера - экспериментальная группа с нашей новинкой.
Для этих групп мы считаем метрики. Важно не забывать про статистическую значимость. Статистическая значимость в Яндексе обычно используется 99.9%, что соответствует P-value < 0.01.

Если все это совместить с тем, о чем мы говорили до этого, о том как можно формировать идеи, о том как их тестировать, то все это может выглядеть так:
- У вас есть идея, которую вы можете описать за 1-2 часа вместе с друзьями и коллегами;
- Начнете задавать вопросы: А какие вещи мы считаем более рискованными? Какие вопросы мы должны задать к этим утверждениями?
- Протестируете решение;
- Соберете прототип;
- Проведете количественно тестирование.

И ещё книги по теме:
«The Most Powerful Way to Turn Clicks Into Customers (Dan Siroker and Pete Koomen)»,
High Output Management (Andrew S. Grove)

Презентация Ильи тут - https://yadi.sk/i/gWcgZW803Neq5R

#product #book
@projectsproducts

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

«Getting Started with Agile and Design Thinking»
https://www.futurelearn.com/courses/agile-meets-design-thinking/#section-topics

#project #product #foundation

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

Обычно в крупных компаниях и тем более в тех, чьи акции котируются на бирже NASDAQ (например, МТС, Яндекс, Facebook,…) есть Правила корпоративной этики, что в целом должно исключать такие неприятные ситуации.

А для PM есть еще дополнительный стандарт, с которым соглашаются и по которому должны работать все сертифицированные специалисты PMI. Это «Кодекс профессиональной этики и поведения»

Полный текст на русском можно почитать по ссылке: http://www.pmi.org/-/media/pmi/documents/public/pdf/ethics/pmi-code-of-ethics.pdf?sclangtemp=ru-RU

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

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

#project #product
@projectsproducts

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

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

Вот несколько пунктов из статьи - то о чем мы всегда должны помнить при проектировании интерфейсов:
1. The Splash Screen
2. The Forgot Password Flow
3. The “Thanks for Signing Up” Page
4. The Welcome Email
5. The Terms of Service & Privacy Pages
6. The User Onboarding
…..
50. The “Delete and Recover” Flow

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

Ссылка на статью:
https://medium.com/ux-power-tools/50-things-you-probably-forgot-to-design-7a288b0ef914

Вопросы отправляйте на почту elena.kotina@gmail.com
@projectsproducts

#project #product

​​#project

Подготовила подборку про то как стать сертифицированным специалистом в сфере управления проектами.

Наиболее известные сертификаты в России:
- Project Management Professional (PMP) от PMI (на базе стандарта по управлению проектами The Guide to the PMBOK® - на русском про сертификацию можно почитать тут https://pmi.ru/certificates/
- PRINCE2™ by APM Group - коротко тут https://newmotivations.ru/ru/prince2/
- IPMA (Россия в IPMA представлена национальной ассоциацией управления проектами СОВНЕТ) - http://www.sovnet.ru/specialists/
- РМЕ® (это российский сертификат от PM Expert) - http://www.pmexpert.ru/services/certification/pme/
- ПМ СТАНДАРТ (еще один российский сертификат от «Центра оценки и развития проектного управления») - https://www.isopm.ru/sertifikatsiya/information/

Количество специалистов с разными сертификатами:

​​Как сформулировать свое видение о будущем продукте?

Есть фреймворк для создания бизнес-модели «Lean Canvas» (автор Ash Maurya, это адаптация Business Model Canvas), в которой есть блоки ключевых вопросов, которые помогают сформулировать ваши гипотезы для MVP (Minimum Viable Product):

1. Какие есть проблемы пользователя? («какие три ключевые проблемы мы хотим решить?»)
2. Кто ваши Целевые клиенты?
3. Решение. (Как пользователь решает эти проблемы сейчас? Если человек эту проблему сейчас вообще не решает, то она ему скорее всего не важна. А как предлагаете решать ее вы?)
4. Конкурентное преимущество? (Почему клиенты должны выбирать вас?)
5. Пути к пользователю - каналы. (Они все могут стоить разных денег)
6. Структура расходов и Структура доходов (рекламная модель, подписка, …)
7. Ключевые метрики (хорошо бы привязывать к каждому блоку этой модели)
8. Скрытое преимущество (Чем уникальным обладаете именно вы? Уникальна технология/патент, крутая команда, большая аудитория,…)

Таким образом на одном листе А4 у вас будет полное представление о вашем продукте.

Обратите внимание, что лишь 1/9 часть этой модели занимает описание решения, которые вы предлагаете пользователям.
И тут нужно вспомнить цитату Дэйва МакКлура (500 Startups): Вашим покупателям неинтересно ваше решение. Их интересуют только их проблемы.
При разработке продукта не забывайте об остальных частях вашей бизнес-идеи.

Ссылка на модель на русском языке:
http://ru.wiki.rademade.com/uploads/ckeditor/pictures/584a81a93152b744a4d44d4b/contentTable28rus1.jpg

Кстати, есть онлайн проект самого Ash https://leanstack.com, где вы можете создать свою доску Lean Canvas. Ну и конечно есть много аналогичных сервисов, например realtimeboard.com и другие.

#product
@projectsproducts

Кстати, к Новому году как раз :)
Нашла подробную статью с примером заполнения Lean Canvas для Санта Клауса: http://ru.wiki.rademade.com/lean-canvas-santa

#product
@projectsproducts

Продолжу выкладывать записи лекции.
Сегодня «Школа менеджмента Яндекса — О продуктовом мышлении.» (Юрий Подорожный)

Со временем сложность систем имеет свойство накапливаться.
В связи с этим нужно вспомнить слова Джона Галла (теоретика в области систем):
«Сложная система, созданная с нуля, никогда не заработает.
Начинать надо с работающей простой системы.»
Всегда важно начинать с простой работоспособной системы.

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

Аргументы, которые вам могут приводить:
- «Просят пользователи»
- «Есть у конкурентов»
- «Требует начальство»
- «Василий написал, что это круто»
- «Команда хочет»
- «Пишут в интернете»
- «Просит наш главный клиент».

И продакт-менеджеру (или человеку ответственному за продукт) нужно уметь ответить нет.

Мораль: необходимо развить в себе умение говорить «нет». Не «позже» или «может быть», а «нет».

Если мы научились говорить «нет», то как же дальше выбирать, что стоит делать, а что нет?
Поговорим теперь о важном и неважном.

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

Продолжение следует…

Ссылка на видео - https://www.youtube.com/watch?v=m8h_KsDovRw&list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl&index=3

#product
@projectsproducts

Часть 2, продолжение записи лекции «О продуктовом мышлении»:

Переходим ближе к практике.
Поговорим об идеальном пути.

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

И если идти по идеальной воронке, то часто бывают проблемы на стыке взаимодействий:
1. Дизайнер подумал только про идеальный сценарий.
2. Разработчик нашёл и другие сценарии, но у него нет
времени думать о том как решить проблему.
3. Разработчик предполагает как должно быть. И делает как
считает нужным.
4. Так ошибка проектирования становится ошибкой в продукте.

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

Еще расскажу про самые распространённые сценарии, которые стоит учитывать при разработке:
- Пустые экраны
- «Ничего не найдено» в результатах поиска
- Отображение ошибок (валидация, получение, отправка)
- Потеря соединения с интернетом
- Местоположение пользователя
- Контекст пользователя
- Локализация (текст на другом языке может занимать сильно больше места, чем вы оставили на макете)

О сценариях, про которые не стоит забывать, я писала в посте - https://tttttt.me/projectsproducts/30

Кроме этого полезно пользоваться методом от обратного. Когда вы задаете себе вопрос: «Как сделать самый неудобный интерфейс на свете?» (Почитать подробнее: Ководство Артемия Лебедева. § 150. От обратного - https://www.artlebedev.ru/kovodstvo/sections/150/)

Резюмируя: Мир не идеален, поэтому помните о пограничных случаях. Ожидайте неожиданное.

Продолжение следует…

Ссылка на презентацию - https://yadi.sk/i/XTn44y8S3NmteL

#product #book
@projectsproducts

Часть 3 (заключительная), продолжение записи лекции «О продуктовом мышлении»:

А теперь пойдем дальше, когда мы уже поняли, что важное и не важное и пошли реализовывать.

Тут хочется рассказать историю про корабль Васса, который строили 3 года в Швеции (1625г), на первом же своем выходе корабль утонул.
Проводили расследование «Почему утонул корабль?». Расследование выяснило, что это была «Божья воля».

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

Какие выводы можно сделать из этой истории?
- Фиксируйте объём работы
- Ведите документацию
- Тестируйте на реальных пользователях
- Вникайте в устройство вещей.

И еще совет:
Применяйте метод Сакити Тоёда:
«Задавая вопрос «Почему?» 5 раз, вы определяете характер проблемы, решение становится понятным.»

И в заключение еще одна цитата:
«Верить или не верить, это не имеет никакого значения. Интересно лишь задавать себе всё больше и больше вопросов.»- Бернар Вербер.

Ссылки на видео и презентацию были в постах выше.

#product
@projectsproducts

​​Сегодня про книгу «Спринт» (Джейк Кнапп, Джон Зерацки, Брейден Ковитц. Все трое – сотрудники Google)

Спринт является составной частью широко известной концепции Scrum, но авторы его модифицировали.
Это 5 дней работы команды (до семи человек), которые занимаются только заранее обозначенными задачами.

Все расписано по дням:
- Понедельник - ставим цель (долгосрочную, на полгода-год).
- Вторник – каждый делает “набросок финального решения”.
- Среда - выбираем только один набросок.
- Четверг - делаем максимально возможный прототип. прорабатываем сториборд.
- Пятница - тестируем (всего 5 человек на тест! так как “85% проблем выявляются после интервью всего с пятью пользователями”.) и решаем, будет ли проект жить.
при тестировании главную ценность представляет именно спонтанная реакция потребителей

Пара цитат:
“Приступая к проведению «спринта» для своих стартапов, мы разрываем порочный круг бесконечных дебатов и делаем за неделю то, на что ушло бы несколько месяцев”.

“В целом демократия – прекрасная вещь, если речь идет об управлении государством, но она совершенно неуместна при проведении «спринтов»”.

#book
@projectsproducts

​​Когда писала про лекцию Юры Подорожного в Яндексе, обратила внимание на сайт, на который у него была ссылка:
http://www.productstrategymeanssayingno.com/

Это страница ярко иллюстрирующая одну мысль: «Продакт-менеджеру нужно уметь говорить нет!».

Сайт говорит: Saying no is hard, but a great product manager isn’t afraid to make tough decisions to keep their product bloat-free.

А здесь подробный рассказ про то, когда же нужно говорить «Да»:
https://blog.intercom.com/rarely-say-yes-to-feature-requests/

Собственно ровно это и было в лекции Юры, но если вы хотите почитать подробнее оригинал Интеркома, то ссылка выше.

#product
@projectsproducts