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

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

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

Представим, что у вас магазин бытовой техники с собственным интернет-магазином. Обозначим основные бизнес-процессы:

Клиент находит нужную технику и оставляет заявку на обратный звонок с целью уточнения деталей по комплектации и свойствам продукта.
Заявка поступает в CRM вашего отдела продаж.
Менеджер звонит клиенту и дает консультацию, закрывает на покупку.
Клиент узнает нужную информацию и в идеальном случае – оформляет заказ прямо по телефону с оператором. Оплата по карточке.
Заказ поступает в CRM.
Заказ обрабатывается и передается на склад.
Складские сотрудники комплектуют заказ.
Готовый к отгрузке продукт отправляется к заказчику.
Заказчик получает свою покупку.

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

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

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

Прослеживая все звенья цепочки, вы вскоре сможете сделать выводы о том, что не так и что нужно менять. Заявок 140, а прозвонов 70, заказов после них 3. Оператор не справляется. Сервисы, вроде AmoCRM помогут вам узнать, какое время оператор затратил на каждый разговор, скольких обзвонил, как разговаривал. Возможно вам нужно расширить штат, а может быть оператор ленив и не хочет работать.

Воронка продаж и декомпозиция

Построим простую воронку продаж для интернет-магазина:

1000 человек увидело вашу контекстную рекламу.
100 человек перешли по контекстной рекламе на ваш сайт.
70 человек из 100 поюзали сайт.
10 человек оставили заявку на обратный звонок.
5 человек были закрыты на сделку менеджером.

Здесь мы можем выделить несколько конверсий

Конверсия из показов рекламы в посетители сайта.
Из посетителей в лиды (заявки).
Из лидов в покупатели.

Детализируем воронку на 5 уровне

Менеджер получает заявку в CRM-системе и звонит клиенту. Что он говорит ему и что предлагает? Яркий пример декомпозиции не только бизнес-процессов, но и тактики продажи – предложение не самого товара, а услуги для него. Бесплатные замеры, бесплатные консультации. Человек может не согласиться купить сразу по телефону, но, если к нему отправится замерщик (монтажник), проведет необходимые мероприятия, даст пару рекомендаций и при этом может рассказать о компании и продукте – вероятность того что сделка состоится увеличивается в разы. Таким образом, мы выделяем подпроцесс – предложение предварительной услуги в которую упаковываем презентацию и строим предложение оператора не на продаже, а на предложении бесплатной услуги.

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

Что будет, если не пользоваться данным подходом?

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

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

Если хотите быстро разобраться и проработать бизнес-процессы вашей компании, обращайтесь за консультацией по номеру 8-800-700-33-89 или

До встречи в следующих статьях!

Недавно мы с клиентом полностью изменили стратегию его бизнеса. Нужно было видеть его реакцию.

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

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

Майкл Джексон жив

Помните знаменитую походку Майкла Джексона? Да! Ту самую лунную походку, которую повторяют и будут повторять в ближайший век еще точно.

Это когда он идет вроде бы вперед, но обратным способом (вроде так можно это описать).

Вот такая вот, иду вперед, а на самом деле назад

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

Сразу забегу вперёд, чтобы вы не расстраивались. В этой статье мы рассмотрим разные примеры использования данной темы в маркетинге/бизнесе. Особенно обратите внимание на третий пример.

Понимаю, что пока ничего не понятно. Это же не просто термин, а целый научный метод или даже подход.

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

Вы едете отдыхать

Приведу пример на самом желанном. Вам нужно поехать в отпуск s_____ (вставьте страну, куда бы сейчас хотели поехать).

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

Теперь понимаете о чем я? Вы берете любую задачу и разбиваете ее на подзадачи, а потом на еще более мелкие задачи.

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

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

Декомпозиция цели

Есть предположение, что чем сложнее у вас декомпозиция, тем сложнее вам видеть глобальную задачу. Но я с этим не согласен.

Причем в корне. Одна из ключевых способностей эффективных людей – что все свои задачи они расписывают максимально подробно, буквально по 10-15 минут. Но это лирика. Переходим к главному вопросу.

Зачем ЭТО в маркетинге?

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

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

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

А также как говорится “Многое другое”. Думаю направления понятны. Теперь рассмотрим три варианта реализации

1 вариант – низкая сложность

Представим, что у вас розничный магазин, которому нужно сделать оборот в месяц в размере 1 950 000 руб.

Средний чек в 3 470 рублей;
Средняя конверсия в покупку 35%.

Внимание, вопрос знатокам. Какое число клиентов должно посетить магазин за месяц?

Считаем (1 950 000 (оборот) / 3 470 (средний чек)) / 35% (конверсия в покупку) = 1 606.

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

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

НАС УЖЕ БОЛЕЕ 29 000 чел.
ВКЛЮЧАЙТЕСЬ

2 вариант – средняя сложность

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

Средний чек – 137 000 рублей;
Конверсия 10% – из холодного звонка в продажу (на каждом этапе);
Рентабельность 25% (всем бы такую рентабельность в оптовом бизнесе)

Опять вопрос знатокам. Сколько нужно делать холодных звонков, ежемесячно, чтобы зарабатывать 5 млн. рублей чистой прибыли? Вы не поверите, но 150 000 звонков! Тому утверждение ниже скрин.

Расчеты 1

Тут только несколько вариантов: либо поднимать средний чек, либо увеличивать конверсию. Я просто поиграл с цифрами и увеличил конверсию из встречи в продажу в 2 раза, то есть получилось 20 процентов. Чистый доход увеличился даже чуть больше, чем в два раза.

Расчеты 2

А если подтянуть другие цифры? Такие как проход секретаря или назначения встречи. Жаль, что не все так просто в жизни. Но, думаю, эти статьи с примерами скриптов Вам помогут.

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Почему это важно?

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

Почему так происходит? Всё просто: человеческая психология заставляет людей смотреть на ситуации с точки зрения собственного комфорта . Разработчику не всегда хочется думать о том, что будет с кодом после его написания. Решил задачу – и хорошо. Его крайне редко это интересует (именно поэтому мы, айтишники, и работаем в этой отрасли – наша мотивация в основном держится на интересности задач), ведь в отношениях с людьми столько неопределённости. Гораздо более комфортно многие разработчики чувствуют себя, сидя за компьютером и сосредоточившись на решении своей собственной интересной задачи – блокчейнах с нейросетями – им совсем не хочется отвлекаться и думать о каких-то продакт-менеджерах, дедлайнах, пользователях, которые потом будут использовать их гениальное произведение (а то ещё и критиковать начнут!).

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

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

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

Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации . И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.

Workflow

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

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

Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.

Во-первых , обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).

Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.

Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?

Тем, кто смотрит на проблему однобоко, этот подход с одной веткой может показаться очень удобным. Зачем мучиться с какими-то ветками, париться со стабилизацией кода в них, если можно написать код, закоммитить (запушить) в общее хранилище – и радоваться жизни? И правда, если в команде работает не очень много человек, это может быть удобно, поскольку избавляет от необходимости слияния веток и организации веток для релиза. Однако данный подход имеет один очень существенный недостаток: код в общем хранилище может быть нестабильным. Вася, работающий над задачей №1, может легко сломать код других задач в общем хранилище, залив свои изменения; и пока он их не исправит/ не откатит, код выкладывать нельзя, даже если все остальные задачи готовы и работают.

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

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

Feature branches

При всём многообразии вариантов workflow у нас в компании у них есть общая черта – они все основаны на отдельных ветках для фич . Такая модель позволяет нам работать независимо на разных этапах, разрабатывать разные фичи, не мешая друг другу. А ещё мы можем тестировать их и сливать в общее хранилище, только убедившись, что они работают и ничего не ломают.

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

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

Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!

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

Отсюда – второе правило хорошей декомпозиции : фичебранчи должны содержать как можно меньше изменений, чтобы как можно быстрее попадать в общий код.

Параллельная работа

Хорошо, но как же тогда работать в отдельных ветках, если несколько программистов трудятся над одной и той же задачей, разбитой на части? Или если им нужны изменения в общих для разных задач частях кода? И Петя, и Вася используют общий метод, который в рамках задачи Пети должен работать по одному сценарию, а в задаче Васи – по другому. Как им быть?

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

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

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

В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.

Важно иметь в виду, что любое изменение в коде, даже слияние веток, вливание общих веток в стабильный Master и т. д., обязательно должно быть протестировано (помните про конфликты по коду и логике, да?). Поэтому если вы пришли к выводу, что вам необходима общая ветка кода, то нужно быть готовым к ещё одному этапу тестирования – после момента слияния необходимо тестировать, как фича интегрируется с другим кодом, даже если она уже протестирована в отдельной ветке.

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

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

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

Feature flags

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

А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags . Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.

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

Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).

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

Заключение

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

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

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

Желаю удачи в разработке новых фич!

Теги: Добавить метки

Первый и, возможно, самый главный этап работы с Product Backlog в Agile заключается в декомпозиции задач, разбиении разноплановых требований на атомарные, понятные пользовательские истории (User Stories). Чем качественнее разбиты требования, тем понятнее их смысл и способы реализации, а также тем точнее можно запланировать время работы над ними. Чем задачи, тем выше шансы достичь целей спринта, тем более прогнозируемые составы релизов.

Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.

Зачем и в какой момент следует проводить декомпозицию требований?

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

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

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

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

Два основных подхода к декомпозиции.

Существует две концепции, два базовых подхода к декомпозиции крупных задач на пользовательские истории – «горизонтальное» и «вертикальное» разбиение:

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

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

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

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

Техники декомпозиции требований в Agile

Метод 1: Разбиение по этапам\фазам бизнес процесса.

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

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

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

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

Метод 2: Разбиение по позитивным и негативным сценариям.

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

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

Для позитивного – реализация правильной работы функционала.
Для негативных – реализовать правильную отработку той или иной возможной ошибки, разработать альтернативный сценарий.

В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:

Позитивный сценарий: пользователь заходит в свою учетную запись на сайте и совершает покупку оплачивая ее по карте. Или в формате пользовательской истории: «как клиент я могу войти в свою учетную запись, чтобы совершить покупку по карте».
Негативный сценарий 1: клиент пробует совершить покупку без авторизации.
Негативный сценарий 2: пользователь пробует совершить покупку, но у него на счету не хватает средств и оплата не проходит.
Негативный сценарий n: клиент пробует совершить покупку, но его учетная запись заблокируется из-за неправильного ввода пароля.

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

Метод 3: Разбиение по правилам\условиям бизнес процесса.

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

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

Данный метод разбиения требований позволяет:

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

Метод 4: Разбиение по видам операций.

Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.

На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:

C reate - создание нового продукта в интернет магазине
R ead - просмотр описания продукта
U pdate - редактирование\обновление описания продукта
D elete - удаление продукта из магазина

Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:

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

Метод 5: Декомпозиция по типам платформы/ОС.

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

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

Для разных платформ: персональные компьютеры, планшеты, смартфоны.
Для разных ОС: Windows, iOS, Android.
Для работы в различных браузерах.

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

Метод 6: Разбиение по типам данных и параметрам.

Для некоторых функций можно можно выделить различные типы данных или параметров, которые они должны обрабатывать. Соответственно, мы можем разбить большое требование\фичу на ряд мелких пользовательских историй, в рамках каждой из которых нужно реализовать работу только с каким-то одним типом данных.

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

Поиск с использованием текста (наименование товара)
Поиск с использованием числовых значений (номер товара)
Поиск с использованием регулярных выражений

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

Метод 7: Разбиение по ролям\правам доступа.

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

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

Владелец интернет магазина:
- Создание\удаление продукта в интернет магазине.
Администратор интернет магазина:
- Просмотр и редактирование описания продукта.
- Отработка запросов\комментариев клиентов.
Клиент\покупатель:
- Просмотр описания продукта.
- Резерв\покупка товаров в интернет магазине.

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

Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.

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

Рассмотрим пример функциональности – клиент выбирает товар в интернет магазине и откладывает его в «корзину» для совершения покупки. В рамках этой функциональности могут быть выделены следующие тестовые сценарии (ниже только пример части возможных тест-кейсов):

Товар есть в наличии и он доступен покупки.
Товар есть в наличии, но он уже зарезервирован другим покупателем
Товара нет в наличии

Какие преимущества дает использование данного метода декомпозиции:

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

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

Наша цель:

Определить стоит ли идти в нишу в данном регионе;

Узнать бюджет и возможную стоимость клика.

Но не стоит полагать, что вы можете узнать точные цифры по результату прогноза.

В данной статье для наглядности я использовал сервис “Декомпозиция 5.рф”. Он является удобным инструментом для понимания того, на что вы можете повлиять (как на уровне вашей рекламной компании, так и на уровне отдела продаж), чтобы успешнее продвигать свое дело или бизнес, на что стоит сделать упор для увеличения вашей чистой прибыли.

Итак, приступим.

Для чего нужно медиапланирование?

Для начала поймем, что такое Медиапланирование.

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

Для составления медиаплана или прогноза бюджета в контекстной рекламе (давайте договоримся что медиаплан и прогноз бюджета это одно и тоже) требуются следующие вводные:

Адрес сайта или описание ниши (если сайта нет).

Конверсия сайта (показатель насколько эффективно ваш сайт перерабатывает переходы в заявки, звонки или другое целевое для вас действие). Если вы не знаете конверсию сайта, то среднее значение для лендинговых (одностраничных) сайтов условно равно 5%, для интернет магазина берем 1-1,5%.

Так зачем же делать медиаплан перед запуском рекламы? Я хочу быстрее настроить да и получать какой то трафик на сайт. Согласен, но если рассматривать работу на потоке, то это нужно как минимум:

Подготовить ожидания, чтобы вы понимали, что при запуске рекламы в Яндексе или Google сможете получить следующие цифры (стоимость клика, количество заявок, стоимость заявки).

Прогноз бюджета

Заходим в Яндекс Директ и переходим во вкладку Прогноз бюджета.

Для Прогноза бюджета вам нужно выполнить три шага (выбрать 3 настройки).

Первый шаг – выбор региона показа нашего рекламного объявления

Второй шаг – нам нужно указать параметры расчета.

Время, за которое будет сделан расчет (неделя, месяц, квартал или год);

Площадка (в данном случае на всех или на мобильных);

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

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

Для сбора списка ключевых фраз и минус-фраз используется

Обработка результатов прогноза

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

В нашем случае выбрана позиция спецразмещения с объемом трафика -100%.

Сразу нужно сказать, что - это те позиции размещения рекламного объявления на поиске, которые размещены вверху, а – то что внизу.

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

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

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

Допустим у нас нет 82 296.40 руб., у нас, скажем, есть 66 112.70 руб. в месяц, то выбираем второе спецразмещение с объемом трафика -85%.

Из этого отчета нам понадобиться следующие показатели:

Прогноз показов - 27 792;

Прогноз кликов - 3 748.

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

CPC = Прогноз бюджета / Прогноз кликов

CPC = 66 112.70 / 3 748 = 17.64 руб.

Вот мы и получили наши показатели для дальнейшего медиапланирования в “Декомпозиции 5.рф”

Декомпозиция 5.рф – является калькулятором для расчета вашей воронки продаж. Показывает пути, которые проходят все ваши клиенты, начиная с первого знакомства с вашим бизнесом. Например, от просмотра вашего объявления в Яндексе, до момента, когда клиент заплатил вам деньги.

Выбор раздела "Оплата за клик"

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

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

Пример

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

Наш товар или услугу запрашивают в месяц примерно 28 000 раз (в Яндексе). Этот показатель мы посмотрели из Прогнозатора бюджета от Яндекса, там же мы взяли среднюю цену за клик 17 руб., кликабельность объявления поставили 5%, мы надеемся что рекламная компания будет хорошая.

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

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

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

Посетители попадают на наш сайт или посадочную страницу, например, ее конверсия 2% (заявка на покупку, консультацию, любое целевое действие, которое вы поставите). Выставляем конверсию (в продажу), то есть эффективность работы (ваш собственный или вашего отдела продаж). Пусть они в этом примере закрывают 25% сделок, средний чек выставляем 25 000 рублей и рентабельность (какой процент из этих 25 000 рублей вы вынимаете для себя чистыми, после вычета всех расходов). Например, если чистыми остается 11 200 руб., то рентабельность составит 20%. Видим, что бизнес процесс с такими показателями выдает нам 11 200 рублей ежемесячной прибыли.

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

Найдете более выгодное предложение от поставщиков, тем самым поднимите рентабельность до 35%. Обратите внимание как изменилась чистая прибыль.

Как workflow разработки влияет на декомпозицию задач. вариант – средняя сложность