Цикл эволюции продукта

Мне всегда было интересно, каким образом продукты развиваются (не менее, чем интересно, каким образом они запускаются или умирают). Каким образом они проходят свой путь от единицы в сторону "бесконечности", постоянно наращивая свою ценность для потребителей и в чем именно заключается эта ценность. Если взять два новых совершенно одинаковых продукта (предположим, на разных территориально, но одинаковых по конъюнктуре, рынка) - насколько они будут отличаться через три года? Через пять лет? А что, если у нас будут два продукта для разных сегментов рынка, но в рамках одной и той же индустрии? Могут ли они стать одинаковыми через несколько лет? И если да, то как и почему?

Многие могут отметить, что существует модель консолидации рынка: продукты никогда не будут одинаковыми, но есть хорошие примеры телекома и рынка такси в России. Другие скажут, что все превратятся в супераппы, но в то же время мы знаем кейсы разделения продуктов (Facebook и Messenger, деление на бандлы b2b-продуктов в CRM).

Есть ли какая-то "естественная" последовательность того, каким образом эволюционируют продукты? Можно ли "прогнозировать" развитие конкурентных продуктов на этом основании? А еще лучше выстроить стратегию развития продуктов таким образом, чтобы все пути вели к победе в конкурентной борьбе?

Все помнят эту популярную картинку, как должен эволюционировать продукт в рамках одной ценности. Если продукты эволюционируют и развиваются, то как понять, где проходят "границы" продукта? Можно ли считать одним и тем же продуктом номер 2 и номер 3? А номер 3 и номер 5? Да и вообще, каким образом продукт 2 превращается в продукт 3, чтобы этот переход являлся бы "органичным" (мы же не новый продукт каждый раз с нуля создаем, так?).

В июле этого года ко мне обратился Сергей Колосков, product manager Ozon, которого тоже "мучили" эти вопросы. Наше общение превратилось в эту статью, где мы объединили мои наработки в этой области и его часть продукта Ozon в качестве примеров для модели цикла эволюции продуктов. Материал этой статьи может помочь другим продактам посмотреть на свой продукт или фичи с точки зрения динамики, сформировать стратегию развития продукта или найти слабые места, закрытие которых смогут значительно повысить ценность.

С чего начинается любой продукт?

Одна часть продуктов начинается с решения определенной проблемы, с которой потребители сталкиваются при использовании текущих решений. Тем самым, наше решение является более ценным (дешевле, удобнее, быстрее и т.д.) по сравнению с альтернативами. Например, технология No Frost в холодильниках явилась решением проблемы наледи, а производство более быстрых процессоров для компьютеров решало проблемы слабой производительности старых моделей.

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

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

Вспомним Uber, в самом начале который позволял только доехать из точки А в точку Б при помощи одного единственного тарифа. Facebook как сеть для студенческих контактов. Amazon как интернет-магазин для покупки книг. 1С как программа для бухгалтерского учета. Яндекс как система для поиска сайтов. Или пример из моей практики - компания LiveTex, которая начинала только с онлайн-чатика.

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

Рассмотрим первый случай на примерах. Какой шаг сделал Uber, который принес ему огромную популярность? Он добавил тариф UberX, который представлял собой более бюджетный способ решения той же самой проблемы - доехать из точки А в точку Б. Фактически, он предложил новое решение (в контексте продукта) для нового (в контексте бизнес-модели) сегмента потребителей.

Следующие шаги Amazon заключались в расширении ассортимента в сторону MP3 и видеопродукции. Этот кейс можно трактовать двояко (последующие по сути тоже). Либо это новые решения той же "проблемы способа покупки", в широком смысле. Либо новые решение отдельных проблем покупки книг, покупки MP3 и покупки видеопродукции. Вне зависимости от трактовки и то, и то расширяет сегмент потребителей платформы.

Яндекс продолжил решать ту же задачу поиска в интернете, увеличивая ценность за счет решений по поиску документов и картинок. Miro продолжает решать задачу коллаборации пользователей в онлайне за счет добавления новых инструментов и шаблонов. Facebook за счет средств коммуникации между пользователями (например, группы). 1С последовательно расширялся за счет добавления решений для задач новых сегментов пользователей, превращаясь из Бухгалтерии в Предприятие. Компания LiveTex начала добавлять новые способы взаимодействия посетителей сайтов с их владельцами: оффлайн-формы, формы заказа обратного звонка и SIP-телефонию.

Ключевой вопрос здесь - почему такое расширение ценности не может быть представлено в виде отдельных продуктов, тем самым диверсифицируя продуктовый портфель? Почему нельзя запустить два приложения UberX и Uber Black, если они предназначены под разные сегменты (если припомнить 2014 год, то Uber в России именно так и осуществлял свою экспансию, запустив только UberX)? Почему нельзя сделать отдельный поиск для сайтов и отдельный поиск для картинок в интернете, если они решают разные задачи? Почему нельзя сделать отдельно сервис обратного звонка и отдельно чатики?

Ответ здесь очевиден - конечно же, можно. Здесь нет никаких логических или продуктовых ограничений. И мы знаем кейсы такого разделения на примерах Foursquare и Facebook Messenger.

Однако, компании, как правило, этого НЕ делают, продолжая решать другие пользовательские проблемы внутри продукта или те же самые, но другим способом. Потому что это намного дешевле, чем создавать отдельные продукты. Потому что уже есть нечто, что нужно всего лишь доработать, а не создавать полностью с нуля. Это вопрос экономии времени и денег, ведь ключевая функция продуктового менеджмента заключается в том, чтобы добавлять ценность в минимальное время (max value, min time-to-market).

Практически все продукты на этой стадии (это первые шаги стадии роста) встречаются с тем, что начинают выстраивать платформу, которая и помогает им значительно сократить издержки на добавление ценности. И это действительно работает, т.к. именно логика абстракции сущностей внутри платформы помогает охватывать не один кейс пользователя, а сразу десяток. Например, именно такое свойство платформенности, как внутренний язык разработки, помогло 1С очень быстро захватить рынок, адаптируясь под разные кейсы разных по типу бизнеса компаний. Amazon всегда работали над своей платформой для масштабирования, что вообще привело к упаковке самой платформы в качестве самостоятельного продукта Amazon Web Services.

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

Однако, существование платформы еще не гарантирует того, что отдельные продуктовые решения внутри продукта (построенные на базе этой платформы) приведут к созданию "бесшовного" опыта пользователя, который бы позволял ему воспринимать этот продукт как нечто целостное, а не просто совокупность отдельных инструментов (которые могли бы совершенно спокойно существовать и в виде независимых мини-продуктов). Это приводит нас к интересному вопросу - а что именно делает несколько разных фич единым продуктом? Что это за свойство? И когда по мере своего развития продукт это свойство начинает размываться? Где проходят границы между целостным продуктом и просто набором разных функций, упакованных, например, в виде одного приложения?

Ключевой ответ на этот вопрос заключается в целостном контексте пользователя, который ведет его от начало возникновения потребности к получению результатов вследствие использования нашего продукта. Будем называть это value stream, как некоторую цепочку получаемой ценности внутри продукта на каждом шаге этого пути. Наверняка, вам известно понятие value chain, введенное Майклом Портером, как модель цепочки поставки ценности на рынке - от производства до конечного потребителя. Также, очень интересно о value chain написал Олег Якубенков в своем блоге, но в контексте выхода компаний на новые рынки. Советую почитать.

Я буду использовать термин value stream в контексте опыта потребителя. Его также не следует путать с термином user flow, как модели поведения пользователя, т.к. value stream может включать в себя несколько разных user flow продуктов. Это понятие намного ближе к customer journey map, т.к. фокусируется именно на уровне потребителя, но исключает контекст анализа конкретного продукта / товара / сервиса. Также тут есть отличие в атомарности - в value stream каждый из "кубиков" предполагает получение конечной ценности для клиента. Так или иначе, ключевой компонент value stream - это поведение пользователя, его опыт, то, как он идет от формирования потребности к результату (скорее даже повторным результатам).

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

Потребитель всегда проходит этот value stream, вне зависимости от того, какие продукты (или продукт) и как он использует на каждом его шаге. Все равно начинается с осознания потребности того, что ему "нужно больше золота" к результату, когда он оценивает импакт от инвестиций. Тут, конечно же, может быть много возражений вида "он не думает в этих терминах" или "он вообще не осознает такой шаг" и т.д. Да, у каждого конкретного потребителя в голове свои образы и слова, а многие вообще совершают какие-то действия, не осознавая, на самом деле, что именно они делают. Прелесть value stream заключается в том, что, несмотря, на способ реализации каждого из шагов конкретным потребителем (или сегментом), сам шаг все равно существует. При этом, этот шаг такой не потому, что продукт такой (value stream индифферентен к реализации), а потому что мир такой.

Очень хорошие примеры value stream находятся в области b2b-продуктов. Например, банк "Точка" начинали, как и все, с отдельных инструментов для предпринимателей (счета, платежи и т.д.). Но предприниматель - это совершенно понятный сегмент с более-менее понятными value streams. Он заключает сделки, подписывает акты, делает проводки, платит налоги. А эти действия уже выходят за границы продукта типа "банк" (хотя бы потому, что включают бухгалтерское и юридическое сопровождение). Мы можем наблюдать, как "Точка", последовательно развиваясь, закрывала всё новые и новые шаги вдоль value stream работы предпринимателей, постепенно превращаясь из банковской платформы в экосистему вокруг предпринимателя.

Другой интересный пример - это Microsoft PowerPoint, куда был добавлен виртуальный помощник для репетиции речи. Он слушает человека через микрофон, анализирует темп речи, лексику и наличие слов-паразитов, а потом отображает рекомендации по улучшению. Сам PowerPoint является продуктом для создания презентаций, но если мы будем думать value stream, то презентация - это этап где-то посередине. Ведь моя задача, как того, кто делает презентацию, не презентацию сделать, а в конечном итоге её запитчить. И даже если у меня будет сама презентация, мои проблемы на этом пути еще не решены - мне нужно её прогнать и отточить свой спич. И именно это и решает виртуальный помощник. Он помогает мне в закрытии следующего шага того же самого value stream. Тем самым, Microsoft PowerPoint выходит за границы продукта для создания презентаций до экосистемы подготовки к публичным выступлениям.

Эти границы всегда связаны с контекстом продукта, с воспринимаемой от него ценностью. Когда вы переходите от менее абстрактных понятий к более абстрактным, которые смотрят на разные частные потребности потребителя как элементы одной и той же системы. Например, Вконтакте остается платформой, т.к. просто предлагает на одном портале инструменты для разных value stream (общение, видео, музыка, игры и т.д.). Они не объединены в экосистему, т.к. нет более верхнеуровневого value stream, где они бы являлись её частью. Для сравнения - Яндекс имеет плюс-минус такой же набор сервисов, однако, они совершенно спокойно живут как отдельные независимые продукты (Яндекс.Музыка, Яндекс.Почта, Яндекс.Такси). Хотя в последнее время мы видим много шагов к тому, как они "сшивают" разные продукты между собой.

Именно по причине отсутствия более абстрактного value stream, воплощенного в продукте, и не получится никакой экосистемы, если просто к интернет-магазину добавить социальную сеть, без расширения контекста восприятия со стороны пользователей, не создав "связующую" ценность. Например, то, что Сбер накупил или создал много разных продуктов и добавил в них сквозную авторизацию по id, назвав это экосистемой, на самом деле ею не является. Т.к. это разные продукты для разных value stream, не объединенные некоторой "связующей" ценностью.

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

Этот принцип "естественности" таких изменений в Теории Решения Изобретательских Задач носит название закона перехода в надсистему, когда происходит исчерпывание возможностей развития системы, то дальнейшее её развитие возможно только за счет преобразования в систему более высокого порядка (надсистему), в которой прежняя система является лишь частью. Тот же ТРИЗ хорошо объясняет разницу между платформой и экосистемой при помощи понятия "свертывания": если есть две системы (функции) и вы просто их объединяете в одну систему, то вы не получаете особого выигрыша (грубо - не получаете надсистему). Однако, такой выигрыш (улучшение производительности или качества) происходит только тогда, когда некоторые свойства этих систем при объединении можно "сократить" (за счет использования одних и тех же частей для обоих объединяемых систем). Выстраивание продукта "вдоль" value stream как раз и подразумевает то, что каждая новая функция использует уже предыдущие части системы (т.к. является расширением), в отличие от платформы (еще раз важный момент - здесь идет речь не про технологическую реализацию, а про продуктовую архитектуру).

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

Сейчас мы можем увидеть, что и экосистема не является венцом эволюции, т.к. можем наблюдать, как отдельные продукты объединяются между собой в нечто большее. Я буду называть это термином "среда" или "окружение", потому что именно этим и занимаются большинство продуктовых компаний - выстраивают срезу вокруг потребителя. Это среда состоит из разных продуктов, относящихся к разным value stream, но все они имеют нечто общее, некий клей, который их связывает. Я буду использовать для обозначения этого клея термин seamless value, или "бесшовная ценность", по аналогии с термином seamless experience из области омниканального маркетинга.

Сейчас мне известен только один тип такого клея - кросс-аккаунт с подпиской (Яндекс.Плюс, Amazon Prime, СберПрайм, Combo от Mail.ru). С одной стороны кросс-аккаунтинг позволяет "задействовать" уже созданный опыт в рамках одного value stream в других продуктах среды. В большинстве SaaS продуктов на текущий момент этот "опыт" ограничивается только сквозной авторизацией, однако, есть и другие кейсы (например, Apple Continuity). С другой стороны, подписка позволяет получить больше ценности (сейчас - это доступ) от всей среды, чем от использования отдельных продуктов. Очень интересно о профите такого подхода писали Михаил Соколов и Никита Булгаков в статье "Bundle me harder".

Ключевым отличием environment от ecosystem является построение продукта не вокруг value stream, а вокруг потребителя. Именно жизнь потребителя (или какой-то крупный аспект его жизни) является "пределом", к которому стремится функция эволюции продуктов. Проходя от удовлетворения какой-то одной потребности одного values stream к нескольким, мы постепенно расширяем и расширяем понятие продукта и общей ценности для клиента. Например, логика эволюции продукта, связанного с управлением рекламой, может выглядеть вот так (зеленым отмечено, как продукт может быть только одним из этапов value stream более высокого уровня):

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

• С какой бы части (с начала, с конца, середины) value stream мы ни начинали, "органическое" развитие продукта все равно затронет его весь. Но чем раньше мы сделаем его цельным (не кубики, а переходы между ними), тем раньше потребитель сможет получить большую ценность.
  
  
• Можно развивать продукт вдоль одного value stream, предлагая все более качественные решения закрытия потребностей только его. Но можно и переходить на более высокий уровень, прекратив фокус на предыдущем. Здесь нет плохих или хороших решений, все зависит от целей и архитектуры конкретного продукта.
  

В рамках раскрытия теории мы взяли кейс с разделом "Избранные товары" и категориями продуктов питания и товаров для взрослых в интернет-магазине. Мы выбрали эти темы не только потому, что они обладают большей долей покупкой или процентом роста, но и просто потому, что нашли их интересными с точки зрения исследования.

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

Добавляются и выкупаются преимущественно товары таких категорий, как косметика, товары для дома, продукты питания, книги, детские товары и электроника. Дольше всего хранятся как повторные покупки (еда, косметика, детские товары), так и дорогие товары. Меньше всего хранятся недорогие нечастотные товары (посуда и товары для дома, все для хобби, книги, спортинвентарь).

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

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

Теперь, чтобы выстроить целостный опыт внутри продукта, который бы работал на увеличение соответствующий конверсий и adoption в функциональность Избранного, мы должны сформулировать гипотезы ценностных предложений, которые бы закрывали каждую стадию value stream. При этом, т.к. Ozon это маркетплейс, т.е. объединяет как покупателей, так и продавцов, то ценностные предложения можно проектировать для обеих сторон, т.к. именно их интеграция и создает совокупную ценность для обоих сторон. Но помимо этого можно рассматривать решения не только как решения для одного человека, но и с учетом того, что он является одним из многих, которые решают подобные кейсы на платформе. В нашем случае получились такие гипотезы ценностных предложений:

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

Что интересно, такое проектирование сильно связано с понятием ключевой ценности всего продукта целиком. По своей сути, от продукта требуется только одно - сократить расстояние между началом value stream и его концом. Product (одна проблема, одно решение) сокращает дельту на каком-то одном шаге. Чем больше дельта сокращения (по сравнению с альтернативными решениями), тем ценнее продукт. Platform сокращает некоторое множество дельт на разных шагах, ecosystem - на некотором неразрывном участке.

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

В кейсе со свежими продуктами пользователь начинает с информации о том, что продукты внезапно кончились / скоро закончатся, переходит к плану покупок, в котором есть знание всех диет и вкусов семьи, диет, истории покупок. Составляет список покупок (в соотношении около 70% повторных заказов / 30% новых заказов. Идет в поиск, каталог и откладывает в корзину и избранное, может создать список покупки. Оформляет покупку с приоритетом скорости доставки. Если какой-то товар может приехать не быстро, ищет аналоги для быстрой доставки. После оформления заказа хочет сохранить список покупок себе, чтобы в следующий раз повторить заказ и какие-то товары заменить или добавить.

Обнаруженные "инсайты": сделать подписку на доставку списка товаров (возможно, с аналогами и рекомендациями), готовые списки с рецептами и сетами на семью.

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

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

Изначально у Сергея Колоскова была гипотеза, что кратный рост ценности раздела Избранного лежит, на самом деле, ЗА пределами самого Избранного, но было не совсем понятно, каким же образом сформулировать гипотезы роста, которые бы органично дополняли функциональность, но не сильно размывали продукт. Здесь то и подошел анализ с применением модели цикла эволюции продукта и value stream. Конечно же, не все идеи, которые мы с ним рассмотрели, есть смысл тестировать, но кое-что из этого действительно будет превращено в эксперименты. Об этом Сергей обязательно поделится в своем телеграм-канале @freshproductgo. Например, кейс со списком повтора последнего заказа для свежих продуктов уже запущен и собирает первые цифры. Посмотрим, насколько теория может быть полезна для практики.