что такое продуктовая разработка
Продукт VS проект: отличия подходов
На связи Factory5 (входит в группу Ctrl2GO) — российский разработчик аналитических решений для бизнеса на базе умных алгоритмов обработки данных. У нас в компании есть опыт объединения двух разных команд, и мы хотели бы им поделиться. С одной стороны, мы развиваем свой продукт, который активно распространяется через партнерскую сеть. И есть команда, которая этим занимается — продуктовая. С другой стороны, мы занимаемся коммерческой разработкой. И для этого тоже есть команда — проектная.
И там и там разработчики, тестировщики, devops-ы, аналитики, менеджеры. Они обмениваются знаниями, напитывают друг друга идеями. Продуктовая команда может передать проект для проверки технологических и продуктовых гипотез в проектную команду, а проектная — может сложить результат проекта как технологию в продукт. И то и другое вполне легально происходит, но вот люди из одной команды в другую не переходят никогда. Так как между ними есть большая разница. Она заключается и в процессах работы, и структуре, и целеполагании, и даже профиле новых кандидатов. Это бывает сложно объяснить тем, кто не погружен, но Резеда Несынова, исполнительный директор Factory5, разложила всё по полочкам.
Продукт и проект — основные отличия
Начнем с азов продуктовой и проектной разработки. Ниже — сравнительная таблица, которая поможет определить важные составляющие подходов, например, временные промежутки, наборы операций, команду и другое.
Платформа анализа больших данных производственных предприятий Factory5, созданная для повышения эффективности бизнеса за счет аналитики и управления данными — это продукт. А создание алгоритма оптимизации производственной программы, функционирующий на этой платформе, для конкретного клиента — это проект.
Решение для мониторинга эксплуатации и прогноза технического состояния оборудования — это продукт, а внедрить инструмент расчета остаточного ресурса газотурбинной установки у конкретного клиента — это проект.
По азам прошлись, а теперь попробуем погрузиться в это более детально. Рассмотрим, как строится процесс и работает команда, кто и за что несёт ответственность.
Объект управления
В проектном бизнесе объектом управления становятся проекты клиентов, идущие в определённом ритме. Рано или поздно каждый из них заканчивается, и результат проекта переходит в поддержку, либо передается в следующий проект для развития.
Задача руководителя — обеспечить максимальную, в идеале, конечно, стопроцентную, утилизацию ресурсов. Участники команды проекта задействованы неравномерно и не всегда 100% своего времени. Сотрудник может участвовать сразу в нескольких проектах — это возможность эффективно использовать ресурсы. Тут есть много нюансов и рисков, к этому нужно подходить правильно. Уверены, эта тема достойна отдельной статьи.
Создание продукта — это процесс, стремящийся к бесконечности. Объект управления — метрики успешности и качества продукта. Команда тоже работает ритмично, но эти ритмы складываются в циклы постоянного улучшения продукта. Схематично классический процесс продуктового управления выглядит так:
Для себя мы определили жесткое правило: между проектной и продуктовой разработкой нужно строить железобетонную стену, иначе срочные проекты гарантированно сместят все продуктовые задачи без заданного дедлайна «на потом». Ни один проект ещё никогда не шёл по плану, точнее шёл по плану, но только по другому.
В какой-то момент руководитель проекта, сроки которого горят, обязательно подойдёт к руководителю разработки продуктов со словами: «Спасай, мне нужны люди» или, что еще сложнее: «У меня есть контракт на много миллионов, давай сделаем».
Эффективность — на что ориентируемся
не превысить плановую себестоимость,
выполнить требования заказчика.
маржинальность, за счет монетизации и продвижения,
перспективы дальнейшего развития и тиражируемости.
Требования — как ими управлять
Проектная группа ожидает указаний заказчика, да бывает, что проектная команда может предложить какие-то решения, но конечное решение всегда за заказчиком. В любом проекте на старте мы получаем цель и требования к конечному результату, а зачастую заказчик диктует также методы и инструменты реализации.
А основная задача продуктовой команды — обнаружить проблему и потребности пользователей через мониторинг рынка, исследования, интервью с пользователями и так далее. Это главное отличие продукта от проекта. Команда ежедневно формирует гипотезы по развитию своего продукта и проверяет их с точки зрения влияния изменений в продукте или методах его продвижения на его масштабирование на рынок. Для этого используется множество различных методик: конкурентный анализ, аналитика рынка, customer development и др.
Как пример, в команде появляется гипотеза, что клиентам в продукте нужен определенный тип диаграмм. Дальше команда формирует перечень, интересующих нас клиентов, материал для представления — схемы, макеты, описание — планирует структуру интервью, определяют показатели, которые подтвердят или опровергнут их гипотезу и договаривается о встречах с клиентами. На основании проведенных интервью и анализа того, сколько дополнительной выручки мы сможем привлечь, принимается решение о реализации данного функционала в продукте.
Структура работы — как работаем
Реализацию проекта разбивают на маленькие задачи и выполняют их чаще всего последовательно. В целом, когда мы говорим о проектах для клиента — это перечень конкретных задач, сроки и методы реализации, о которых мы заранее договариваемся с заказчиком. Мы можем делать что-то параллельно и даже использовать методику работы по спринтам, но работы сдаются чаще всего по план-графику с жесткими сроками и стоимостью.
Основной принцип продуктовой работы — это проверка продуктовых гипотез, итерационная разработка и постоянный пересмотр приоритетов. Бэклог продукта имеет длину до луны и обратно, и задача менеджера не только генерить и проверять идеи, но и постоянно оценивать, какие из задач бэклога на текущий момент более приоритетные. А после сформировать стратегию релиза нового функционала.
Прежде, чем задача попадёт в бэклог, мы стараемся всеми правдами и неправдами проверить её до того, как начнется разработка. В ход идут и просто исследования, и ux-тестирования, а иногда приходится из дизайн макетов собирать прототип. Лишь после получения обратной связи от достаточного количества клиентов, гипотеза валидируется и берётся в разработку.
Таким образом, одновременно в продукте может быть в проработке несколько гипотез на разной стадии. Задача в разработку переходит тоже дополнительно обработанная. Сначала мы выделяем MVP — минимально-жизнеспособный продукт, который проверяется на некотором количестве клиентов. Если показывать схематично, то работа с продуктом выглядит так:
На данный момент многие проекты используют концепцию MVP в рамках реализации каждой функциональности. И это помогает избежать лишних затрат на разработку ненужной или неэффективной функции, тем самым снижая себестоимость проекта и повышая удовлетворенность клиента.
Ответственность — кто за что отвечает
В проекте клиент берёт на себя ответственность за выбор цели. Задача подрядчиков в данном случае быть профессиональными, быстрыми и системными в достижении этой цели. Не исключено, что команда проекта и клиент могут стать партнерами, которые договариваются об общих целях и способах их достижения, но окончательный выбор всегда за заказчиком.
В создании продукта за постоянный выбор и проверку цели несёт ответственность команда. Среди противоречивых требований и ожиданий многочисленных потребителей важно выявлять те, что позволят максимально масштабировать продукт. Клиенты в данном случае не разделяют с вами ответственность за результат. Продуктовая команда отвечает за окупаемость и масштабируемость, приоритеты в разработке, сервис, продвижение и выбор между быстрыми деньгами и долгосрочным развитием.
Особенности работы в продукте и проекте
Сравним, как отличается работа в продукте и проекте для команды. Возьмем за характеристики временные промежутки для работы, формат работы — постоянный, параллельный, переменный — время достижения результата и другое.
Проект не равно продукт
Есть мнение, что результатом проекта является продукт. Это не правда.
Если такое случается, то очень редко, как встретить настоящего единорога в парке Горького. И вот почему:
Проект ориентирован на одного клиента и его специфические требования.
Проект очень редко учитывает требования надежности и безопасности, необходимой для выхода на рынок.
ПО не становится продуктом пока не обрастет артефактами, необходимыми для вывода его на рынок:
материалы для продаж,
настроенная служба поддержки и т.д.
Для упаковки ПО в продукт, даже если Вам повезло и по результату проекта получился универсальный функционал, в любом случае нужны вложения и перестройка всех процессов компании для непрерывного развития продукта. После проекта, скорее всего, может появиться технология, которой ещё нужны клиенты и дополнительная ценность.
Резюмируем
В проектной работе вас ждут быстрые результаты, драйв от жёстких дедлайнов, работа в режиме многозадачности, следование требованиям клиента и ограничения в ответственности.
В продуктовой же разработке время уделяется генерации идей, здесь есть причастность к чему-то большому и значимому, много работы в неопределенности и условиях изменяющегося рынка и ответственность за свои решения.
Да кто вообще такой этот продуктовый разработчик?
Сегодня в названиях вакансий всё чаще появляются приставки «продуктовый» — дизайнер, аналитик, разработчик… Компании, придерживающиеся продуктового подхода, ожидают от кандидатов определённого образа мышления, хороших технических скиллов бывает недостаточно. Меня зовут Михаил Мазеин, я тот самый продуктовый разработчик в ManyChat, занимаюсь бекэндом и участвую в процессе найма. Давайте расскажу, как это выглядит изнутри.
Помните известную байку про двух программистов-одногруппников? Один из них был троечником, второй — заядлым отличником. Троечник сделал небольшой прототип, за несколько месяцев открыл компанию, вышел на рынок. А отличник работал над очень продуманной и красивой архитектурой. В итоге через два года у троечника была компания и ниша на рынке, а отличник пришёл к нему на собеседование. История ироничная, но под капотом лежит довольно много правдивых фактов.
@innubis
Продуктовая разработка и MVP
Для начала давайте обсудим, чем продуктовая разработка отличается от проектной. Приведу пример — у проектной разработки путь такой же, как при ремонте квартиры: заказали дизайн-проект, пришли рабочие, реализовали всё по нему — готово. Схема рабочая и стара как мир. Но продукт — меняющаяся и живая сущность: в квартире вам могут разонравиться обои, потом нужно будет переделать гостиную под комнату для детей, вы заведёте кота и так далее. Поэтому подход «сначала делаем немного, потом смотрим, что с этим будет на рынке, затем доделываем» выгоднее экономически: меньше time to market, больше шанс не делать полгода работу, которая никому не будет нужна. Работа над продуктом – это бесконечный процесс, когда вы его улучшаете через небольшие итерации при помощи небольших проектов.
Создавая продукт мы чаще всего работаем по принципу проверки гипотезы на прототипе (MVP), который отдаём реальным юзерам. MVP — это минимально рабочий продукт, который даёт возможность продакту что-то протестировать, а разработчику — реализовать функционал минимальным количеством ресурсов, чтобы не аффектить архитектуру (ладно, не аффектить архитектуру слишком сильно). Это на тот случай, если гипотеза не оправдает ожиданий, и код будет выпилен, чтобы не поддерживать. Да, хоронить проекты никто не любит, но MVP тут как раз и помогает — сократить боль от невыполненных проектов. То есть прототип электромобиля — это не шасси или самокат с габаритной моделью, а «Запорожец» на аккумуляторе. Кондиционер и прочее повесим после.
Баланс между техникой и продуктом
Итак, я разговариваю на эльфийском, постоянно сыплю какими-то непонятными гипотезами, метриками и идеями, не давая спокойно пилить код. Хуже, я регулярно мешаю работать, прося что-то перестать делать, а что-то вообще выкинуть из прода. То есть веду себя как типичный продакт — какой-то опасный гиперобщительный чувак, попивающий смузи. При этом я же разработчик.
Опасная пересоциализация в образе ПР — это оттого, что идёт постоянное общение: с пользователями, коллегами, представителями бизнеса. Но нам необязательно это делать в таком же активном режиме, как это делают продакт-менеджеры, устраивая созвоны. Можно почитать тикеты в саппорте, посмотреть форум, ознакомиться с feature requests, попросить аналитика прислать какие-нибудь исследования — главное, это попытаться понять, какие именно проблемы решают при помощи вашего продукта другие люди и какие у них есть потребности.
Продуктовый разработчик находится посередине между программистом и продакт-менеджером, соединяя в себе лучшее от двух ролей, он озабочен технологиями и пользовательским опытом в равной мере. Ему нужно понимать продукт настолько, чтобы с технической точки зрения помогать продактам достигать целей и предлагать варианты, как проверить гипотезу минимальными средствами. Например, вместо того, чтобы делать сложную валидацию формы сбора номеров телефонов, можно начать с простой валидации длины и символов в номере, постепенно улучшая по фидбеку пользователей и добавляя дополнительные этапы валидации, включая определение страны и региона через внешние библиотеки/апи, добавляя в следующих итерациях определение оператора, обслуживающего номер телефона.
Не бойтесь быстрых экспериментов для проверки реакции. Сутки на фичу — и вот уже люди пишут, что и как нужно. А вы понимаете, как вашу архитектуру и вашу кодовую базу нужно будет поменять для того, чтобы в дальнейшем это было проще расширяемо и поддерживаемо. Так что ПР — это своего рода учёный, который через цепочку опытов открывает что-то новое.
Что мерить, если не длину кода
ПР ориентируется на продукт в глазах пользователя. Чем больше ценности у продукта — тем лучше работает ПР. Если говорить конкретно о ManyChat, то продуктовый разработчик — это человек, который начинает думать не только о том, как писать код, но и о том, какую ценность его код несёт.
Каждый раз, когда ты пишешь какую-то строчку кода, ты принимаешь решение о том, как твой пользователь воспользуется этим функционалом, который ты только что написал. И поэтому стоит думать в этот момент о том, будет такой кейс или не будет такого кейса, если будет, то сколько людей из сотен тысяч им воспользуются, стоит ли один пользователь из миллиона поддержки этого функционала в будущем и так далее.
Когда у нас продакт-менеджер приносит фичу, продуктовый разработчик вполне может почелленджить его на предмет, действительно ли эту гипотезу нужно делать. И когда они оба находят точки синхронизации, то это идёт в реализацию. После этого, когда видно, как заработал продукт, все вместе смотрят на фидбек и проблемы и находят решения.
Функция разработчика меняется с обеспечительной в духе «Напишите нам тут ещё кода» на стратегическую. То есть решения начинают приниматься там, где быстрее их реализовать. Чтобы стать ПР, на самом деле достаточно болеть за свой продукт или компанию и разбираться в деньгах. Полезно будет изучить, как бизнес монетизирует создаваемую ценность в софте, разобраться в ключевых метриках: что для вашего продукта и бизнеса важно (MAU, DAU, другие показатели), как эти метрики влияют, на чём сейчас фокусируется бизнес для того, чтобы стать успешнее. Стоит следить за трендами рынка, где позиционируется бизнес, погружаться в бизнес-контекст, но при этом не забывать о технической составляющей. Моя задача, как продуктового разработчика, объяснять бизнесу, как всё работает и находить компромисс, в том числе, чтобы закладывать время на архитектурные улучшения и поддержку, чтобы не копить техдолг.
Для разработчика в момент, когда он перестаёт решать какие-то конкретные узкие задачи, и начинает мыслить категориями бизнеса, — профессиональный и, наверное, в том числе, материальный рост. Не стоит забывать, что бизнес платит не за количество строк, а за решение проблем пользователей. А пользователи платят за это бизнесу.
С чего начать
Если желания самостоятельно выходить из зоны «я пишу код по задаче, и всё хорошо» нет — то не надо, кому-то важнее уровень определённости и ближе проектная разработка. Если человек не вылезает за пределы спеки и не спрашивает, как лучше писать фичу, — скорее всего, не в его характере мыслить «за ту сторону». А тем, кому хочется расширить кругозор и быстро видеть результат работы, я могу посоветовать следующее:
Почитать
Эрик Рис — «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
Экономичный стартап — это целый подход, который позволяет разрабатывать действительно нужные для пользователя продукты. Из названия может сложиться впечатление, что подход применим только к стартапам. Но сам автор утверждает, что это нет так: стартап для него — это любой проект, даже если он реализуется внутри крупной компании. На примерах историй различных бизнесов книга рассказывает о важности быстрого тестирования гипотез на реальных пользователях, сборе обратной связи, её анализе и последующих корректировках. В этой книге автор определяет такие понятия, как MVP, гипотеза роста, гипотеза ценности, прыжок веры и многое другое.
Cindy Alvarez — «Lean Customer Development»
Если вы уже готовы пообщаться с пользователями и провести свой первый CustDev, но не знаете, с чего стоит начать, это книга может вам помочь. Здесь вы легко сможете найти информацию о том, как правильно выбирать пользователей для интервью, как правильно проводить интервью, чтобы найти настоящую боль пользователя, почему полезно показать даже минимально жизнеспособный макет, чтобы получить первый фидбек и проверить свою гипотезу.
Майк Кон — «Пользовательские истории. Гибкая разработка программного обеспечения»
В этой книге подробно описан процесс подготовки требований к разработке на основании исследования пользователей продукта и выявления пользовательских историй — коротких и понятных кейсов, которые принесут ценность для конечного юзера продукта. Если вы решите прочитать книгу, то найдете практические методы сбора историй; как действовать в тех ситуациях, когда нет возможности непосредственно пообщаться с пользователями; объяснения, что делает истории хорошими или плохими и многое другое, что поможет эффективно применять данный подход для постановки задач и планирования.
Разработка проекта vs разработка продукта — в чем разница
Есть проекты, а есть продукты. Причем оба термина применимы далеко не только к айтишной сфере. Батон и бублик — продукты, а запуск на хлебокомбинате новой линии по выпечке капкейков — проект.
Но если бы всё было так же просто, как хлебушек, то не было бы статьи. А она есть. Как еще можно отличить продукт от проекта:
Ну то есть в целом понятно.
Если говорить про айтишные дела, то когда у тебя есть сервис, который ты бесконечно улучшаешь, меняешь, измеряешь реакцию целевых пользователей, снова меняешь, ищешь под него инвестиции, кусаешь локти, если что-то идет не так, закладываешь свой УАЗ в ломбард ради новой фичи — у тебя стартап продукт. И у тебя, вероятно, продуктовая команда.
Когда у тебя есть краткосрочная задача запилить что-то по определенным требованиям (сайт, логотип, рекламную кампанию и т.д.) забрать деньги и отдать то, что получилось, в руки заказчика — у тебя проект. Вернее, проекты — потому что один закончился, начался второй, конвейер крутится, профиты мутятся.
Казалось бы, разница невелика — проекты, продукты, один хрен те же самые специалисты сидят и делают примерно одно и то же. Так же за ними присматривает менеджер. Также бюджет берется из кармана владельца бизнеса. Но нет, всё работает по-разному.
Разберем различия с точки зрения владельца-заказчика, команды исполнителей и руководителя.
Работа над проектом и продуктом: в шкуре владельца
Проектная разработка
Хотя адепты гибких методологий и называют заказчика сайта Product Owner’ом — на деле же он таких функций не выполняет. Банкет оплачивает, иногда вторгается в уютный мирок заказной разработки со своей картиной мира и правочками. Но не больше.
Вообще аутсорсинговая природа проекта формирует отношение владельца ко всему процессу. Команду он не хантит по человеку в месяц, никого не собеседует (и своего эйчара не напрягает). У него не болит голова насчет того, что с этими людьми делать дальше, когда работа закончится. Он не парится о мотивации или поиске компетентного менеджера на проект. Не рассчитывает окупаемость, не планирует бюджет.
Вместо этого он поступает просто: берет рейтинг самых-самых, выбирает из него кусок с подъемным для себя бюджетом, из него выбирает подрядчика, который больше понравился.
И дальше уже пошло-поехало: ТЗ, презентации, правочки. Стоп, снято, в продакшен.
Нет, само собой, бывают и совсем другие истории — когда заказчик компетентный в разработке ИТ-проектов, у него сильная команда на своей стороне, маркетологи, техдиректор, проект-менеджер, дизайнеры, контентщики. А на аутсорс он пошел просто потому, что своих ресурсов не хватило (или не хватило специализации).
Еще случай «другой истории» — когда у бизнеса есть доверенное агентство, взявшее на себя весь диджитал. Разные возникающие проекты агентство отдает аутсорс-продакшену.
В обоих случаях уровень работы приближается к продуктовому — тоже KPI, внятные постановки с самого начала, меньше неопределенности. Но это, скорее, исключение из правил, как вы поняли.
Продуктовая разработка
Здесь всё иначе. Продукт, то есть программный продукт — это и есть конечная цель для владельца бизнеса. Вернее, бесконечная — потому что нельзя просто так взять и выложить программный продукт, а потом забить на его улучшения.
Теперь о том, как себя чувствует команда там и там.
Продуктовая команда и команда «на потоке»
Проектная разработка
Причем в процессе такой яростной гонки один из гребцов встает посреди лодки и говорит: «ребята, меня позвали вон на тот круизный лайнер, до свидания!». После чего включает свой реактивный ранец и улетает в голубую даль.
Работа команды, делающей проекты на потоке — это очень много стресса, переключений между задачами, подгорающий фитилек дедлайна и. чемодан опыта. Так что можно сказать, что потоковая разработка — для молодых и энергичных, здесь как нельзя быстрее можно научиться всему. Такой непрекращающийся интенсив длиною в несколько лет.
В продуктовой команде всё немного по-другому.
Продуктовая разработка
Программисты, которые ушли из студии и устроились в продукт — как правило, говорят о том, что там спокойнее. «Бесконечный» характер работы и отсутствие того самого подгорающего фитилька (и плеяды новых проектов на очереди) делают рабочий темп медленнее и вдумчивее.
У потоковой разработки в фокусе сроки — для студии их очень нежелательно сдвигать вперед (да и назад тоже). При плотной загрузке любой сдвиг идет в ущерб остальным проектам. Если при этом сроки растягиваются — то студия упускает прибыль.
В продуктовой разработке сроки важны, но не критичны. Здесь придерживаются философии: если сдвигаем — значит, совершенствуем, а значит, создаем потенциально более успешный продукт.
Ну это утрированно, но в целом так.
В продукте сильнее бизнес-составляющая. Собственно, та система координат, в которой работает вся команда, от продакт-директора до стажера — это целевые пользователи, конверсии, маркетинговые исследования и так далее. Просто так собраться кучкой и решить «а давайте следующий сайт запилим на Реакте!» — не получится. Маркетологи скажут, на чем, почему и зачем вы будете делать следующий сайт.
Сложно сказать, где команде работается лучше. Потоковая разработка — это отличное место для прокачки и развития «по горизонтали». Продуктовая — для углубления в какую-то одну тему. Вряд ли вы встретите человека, который бы хотел вернуться в потоковую разработку после продуктовой — как ни крути, а в продукте спокойнее (правда, если это типичный стартап, то «спокойствие» будет выражаться во впахивании по 12 часов в сутки).
Теперь о менеджменте всего этого.
Менеджер продукта и менеджер проекта — в чем разница
Проектная разработка
Менеджер проекта — это «свой парень». То есть, конечно, он немного из другой касты, но команда понимает: менеджер их защитит от неадекватных правок и нервотрепки.
С точки зрения экспертности проект-менеджера — он выступает для заказчика «консультантом по технологиям», дает экспертное мнение именно с точки зрения работы над проектом (а никак не с точки зрения бизнеса, здесь любая студия целиком полагается на экспертизу заказчика).
В чем заключаются главные функции проект-менеджера: обеспечить равномерную нагрузку на ресурсы, не промотать сроки, проконтролировать результат и продать готовую работу заказчику.
Продуктовая разработка
Вроде бы это тот же менеджер, вид сбоку, но нет. Главное отличие — продакт-менеджер является представителем бизнеса (умное слово: стейкхолдером).
На проектной разработке главным источником угрозы был заказчик — со всеми этими «я вам правочек принес», внезапными новыми идеями и поездками в отпуск. Поэтому менеджер был таким «фильтром», смягчающим внешнее воздействие на команду, защитником.
На продукте внешней угрозы нет — все работают над одним большим делом. Следовательно менеджер для команды сам становится источником угрозы. Для них он — как номенклатурный работник для простых работяг.
Соответственно, если менеджер переходит из потоковой разработки в продуктовую, его главная боль — научиться жить с тем, что он теперь еще в большей степени другая каста, нежели был раньше.
Что еще стоит добавить. Все умные методологии и роли, которые в них есть — изначально разрабатывались для продуктовых команд. Где реально делать ежедневные стендапы со всей командой и владельцем продукта. Где продакт-овнер — роль настоящая, а не номинальная. Где скрам — так скрам. Всё-таки на заказной разработке мало когда нужны эти самые поэтапные запуски, тестирование гипотез и прочая. Наше дело простое.
Применение всего этого опыта на заказной разработке — допустимо, иногда полезно, но не всегда обязательно.
Ну всё вроде бы
Понятно, что всех аспектов одной маленькой статьей не охватить, но мы хотя бы попытались. Есть ли третий путь, что-то между потоковым «клепанием» проектов одного за другим и усердным бдением над продуктом? Да, есть — но об этом расскажем потом.
Кстати, можно подписаться на наши пуши (вон там снизу справа колокольчик) — тогда свежие статейки будут поступать вам сразу по готовности.