Декомпозиция 5 – Декомпозиция онлайн — бесплатный сервис по расчету воронки бизнеса онлайн

Декомпозиция онлайн — бесплатный сервис по расчету воронки бизнеса онлайн

Количество показов ваших объявлений (в Я.Директ или G.Adwords, к примеру)

Сколько процентов из всех, кто увидит объявление, кликнет на него. (для рекламы в Я.Директ и G.Adwords в среднем- от 1 до 10%, для таргетинга в соц.сетях в среднем от 0,1 до 1,5%

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

Сколько процентов из всех зашедших на сайт оставит заявку или позвонит или купит (сделает полезное действие для вас)

Кол-во заявок которые вы получите за период

Сколько процентов из всех заявок за период станут в итоге вашими клиентами

Клиенты

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

Рентабельность продаж — отношение операционной прибыли к выручке. Считается по формуле R = (операц. прибыль / выручку)*100%. Как посчитать здесь операционную прибыль? Вычтите из выручки все расходы, кроме расходов на рекламу (они учитываются позже в формуле)

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

Показы объявлений

Конверсия1 (сайта)

Конверсия2
(в продажу)

Рентабельность
(без рекламы)

Чистая
прибыль

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

Сколько вам стоит 1 клиент, учитывая цену за клик, конверсию 1 и 2

ROI — коэффициент, показывающий окупаемость инвестиций. Здесь считается так: ROI = ((Средний чек*Кол-во клиентов*Рентабельность(без рекламы)- Расходы на рекламу)/ Расходы на рекламу) * 100%

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

Нажми на лайк, если считаешь
что сервис полезен

+

Добавить еще 4 строчки

• 1

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

• Введите значение CTR, цену за клик, % конверсии первой и второй, средний чек, рентабельность и в конце чистую прибыль которую нужно получить.

• 2

  Узнать, какую прибыль получим, если известно число показов объявлений.

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

• 3

  Посчитать ROI (окупаемость вложений в рекламу), среднюю цену 1 лида и 1 клиента при заданных значениях всех конверсий.

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

xn--5-gtbdifalqrbk1gxf.xn--p1ai

Декомпозиция онлайн — бесплатный сервис по расчету воронки бизнеса онлайн

Количество E-mail адресов в базе по которым будете делать рассылку

Сколько процентов из всех получивших рассылку откроет и прочтет письмо.

Кол-во прочитанных писем

Сколько процентов из всех прочитавших письмо ответит или позвонит или купит (сделает полезное действие для вас)

Кол-во заявок которые вы получите из рассылки

Сколько процентов из всех заявок за период станут в итоге вашими клиентами

Клиенты

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

Рентабельность продаж — отношение операционной прибыли к выручке. Считается по формуле R = (операц. прибыль/ выручку)*100%. Как посчитать здесь операционную прибыль? Вычтите из выручки все расходы, кроме расходов на рекламу (они учитываются позже в формуле)

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

База (кол-во Email)

Процент прочтения

Писем прочитано

Конверсия1 (письма)

Конверсия2
(в продажу)

Рентабельность
(без рекламы)

Чистая
прибыль

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

Сколько вам стоит 1 клиент, учитывая стоимость рассылки, конверсию 1 и 2

ROI — коэффициент, показывающий окупаемость инвестиций. Здесь считается так: ROI = (Средний чек*Кол-во клиентов*Рентабельность(без рекламы)/ Расходы на рекламу) * 100%

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

Нажми на лайк, если считаешь
что сервис полезен

+

Добавить еще 4 строчки

• 1

  Узнать, сколько нужно иметь E-mail адресов в базе, если известна чистая прибыль, которую хотим получить.

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

• 2

  Узнать, какую прибыль получим, если известно число показов объявлений.

• Введите число показов, CTR компании, показатели конверсий, а также средний чек и рентабельность.

• 3

  Посчитать ROI (окупаемость вложений в рекламу), среднюю цену 1 лида и 1 клиента при заданных значениях всех конверсий.

• Введите свою цену за клик, после решения первой или второй задачи.

xn--5-gtbdifalqrbk1gxf.xn--p1ai

Декомпозиция онлайн — бесплатный сервис по расчету воронки бизнеса онлайн

Количество всех звонков, которые вы делаете за период

В скольки процентах случаев дозваниваетесь и говорите с ЛПР (лицо принимающее решение)

Кол-во разговоров с ЛПР (лицо принимающее решение)

Сколько процентов из всех разговоров с ЛПР (лицо принимающее решение) заканчиваются следующим шагом (назначенной встречей, например)

Кол-во лидов (потенциальных клиентов) или назначенных встреч, которые вы получите за период

Сколько процентов из всех заявок за период станут в итоге вашими клиентами

Клиенты

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

Рентабельность продаж — отношение операционной прибыли к выручке. Считается по формуле R = (операц. прибыль/ выручку)*100%. Как посчитать здесь операционную прибыль? Вычтите из выручки все расходы, кроме расходов на рекламу (они учитываются позже в формуле)

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

% дозвонов до ЛПР

Разговоры с ЛПР

Конверсия1 (скрипта)

Лиды
(встречи)

Конверсия2
(в продажу)

Рентабельность
(без рекламы)

Чистая
прибыль

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

Сколько вам стоит 1 клиент, учитывая расходы на звонки, конверсию 1 и 2

ROI — коэффициент, показывающий окупаемость инвестиций. Здесь считается так: ROI = (Средний чек*Кол-во клиентов*Рентабельность(без рекламы)/ Расходы на рекламу) * 100%

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

Нажми на лайк, если считаешь
что сервис полезен

+

Добавить еще 4 строчки

• 1

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

• Введите значение процента дозвонов до ЛПР, конверсии первой и второй, средний чек, рентабельность и в конце чистую прибыль которую нужно получить.

• 2

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

• Введите число звонков, процент дозвонов до ЛПР, показатели конверсий 1-й и 2-й, а также средний чек и рентабельность.

• 3

  Посчитать ROI (окупаемость вложений в рекламу), среднюю цену 1 лида (назначенной встречи) и 1 клиента при заданных значениях всех конверсий.

• Введите свою цену за звонок, после решения первой или второй задачи.

xn--5-gtbdifalqrbk1gxf.xn--p1ai

Как заработать на Мерседес? Декомпозиция

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

Разделение целого на части называется декомпозицией (от французского décomposer). Это — научный метод, который позволяет решить большую задачу, разложив её на мелкие и понятные. Давайте разберёмся, как декомпозиция работает в бизнесе.

Мышление миллиардера

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

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

У миллиардеров мышление трансцендентное, оторванное от конкретных ресурсов и условий. Это — мышление от обратного: от результата к настоящему. Например: я хочу получать 10 000 000 ₽ в месяц, а это значит 1000 продаж по 10 000 ₽ моей личной прибыли. Что это за продукт с такой ценностью и таким спросом? Что я должен сделать для его создания?

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

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

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

Как рассчитать декомпозицию?

P × Q. Понятен второкласснику

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

По методу декомпозиции, сначала нам нужно определить желаемую цель — точку Б. Читайте в  статье «Как правильно ставить цели? Точки А и Б».

Личный доход рассчитывается по формуле:

P × Q

P — ваш личный результат от одного действия (личный доход с одной сделки или средний чек)

Q — количество повторений (количество сделок)

Допустим, вы хотите заработать 300 000 ₽ в месяц. Для этого есть масса комбинаций: 1 сделка с вашим личным доходом в 300 000 ₽, 2 сделки по 150 000 ₽, 3 сделки по 100 000 ₽, 300 сделок по 1000 ₽, 3000 сделок по 100 ₽ и т. д. Вы можете либо больше зарабатывать за раз, либо больше раз зарабатывать.

Можем пойти дальше и разложить P ещё на четыре показателя:

L × CV × $ × # = P

L — количество лидов (потенциальных клиентов) за период
CV — конверсия или эффективность переработки обращений в сделки
$ — средний чек одной сделки
# — средняя частота покупок одного клиента

Например: 600 лидов × 5% × 2300 ₽ × 2 покупки в месяц = 138 000 ₽.

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

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

Спрашивая себя «От чего результат зависит на самом деле?», вы быстрее поймёте, на чём сосредоточиться. Всё сведётся к простому вопросу: сколько нужно проводить встреч в неделю или сколько объявлений нужно разместить на Авито, чтобы достичь цели?

Воронка продаж

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

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

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

Например, на сайт зашло 100 посетителей, из них 30 оставило заявку и только 5 купили. Значит:

• конверсия посещений в заявки — 30 / 100 × 100% = 30%
• конверсия заявок в продажи — 5 / 30 × 100% ≈ 17%
• конверсия посещений в продажи — 5 / 100 × 100% = 5%

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

Читайте статью «Управление воронкой продаж в маркетинге».

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

Вот живой пример декомпозиции для покупки Мерседеса от Сергея Гречкина.

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

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

А что с расходами?

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

Декомпозиция расходов — это ответ на вопрос: какими должны быть расходы, чтобы при тех же доходах бизнеса мы получили больше прибыли?

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

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

Личный доход = доход бизнеса — расходы бизнеса — налоги — реинвестирование

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

Искусство маленьких шагов

Декомпозиция нужна для предсказуемого и понятного достижения целей.

Чтобы получить желаемую сумму личного дохода, есть такие пути:

• увеличивать доходы за счёт входящего потока и среднего чека (P×Q)
• повышать конверсию в воронке продаж
• снижать расходы

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

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

Ставьте лайк, если статья
вам понравилась

Записывайтесь на новую программу от Бизнес Молодости «Дельта»!

Суть программы — рост в деньгах на вашем любимом деле с фокусом на долгосрочный результат. В основе методология БМ, которую мы оттачивали 9 лет.

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

На «Дельте» вас ждёт 8 недель насыщенного обучения, общения с десяткой и активной работы с наставником.

Какие темы мы подробно раскроем за время обучения:
1. Цели и выбор ниши.
2. Быстрые деньги.
3. ТОП 5 рычагов привлечения клиентов.
4. Продажи 8 из 10.
5. Финансы и порядок.
6. Технология масштабного мышления.
7. Стратегия годового развития.

Успейте записаться сегодня до 23:59 по минимальной стартотовой цене и получить бонусом бесплатно 3 онлайн-курса по продажам, Авито и Инстаграму.

Записаться на Дельту

molodost.bz

Декомпозиция онлайн — ADCONSULT Online

Декомпозиция онлайн

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

Показы объявлений

Количество показов ваших объявлений (в Я.Директ или G.Adwords, к примеру)

CTR

Сколько процентов из всех, кто увидит объявление, кликнет на него. (для рекламы в Я.Директ и G.Adwords в среднем- от 1 до 10%, для таргетинга в соц.сетях в среднем от 0,1 до 1,5%

Клики

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

Конверсия1 (сайта)

Сколько процентов из всех зашедших на сайт оставит заявку или позвонит или купит (сделает полезное действие для вас)

Лиды (заявки)

Кол-во заявок которые вы получите за период

Конверсия2 (в продажу)

Сколько процентов из всех заявок за период станут в итоге вашими клиентами

Клиенты

Клиенты

Средний чек

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

Рентабельность (без рекламы)

Рентабельность продаж — отношение операционной прибыли к выручке. Считается по формуле R = (операц. прибыль/ выручку)*100%. Как посчитать здесь операционную прибыль? Вычтите из выручки все расходы, кроме расходов на рекламу (они учитываются позже в формуле)

Чистая прибыль

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

Цена за звонок Расходы на звонки

adconsult.online

Декомпозиция — Википедия

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

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

При декомпозиции руководствуются следующими правилами.

Каждое расчленение образует свой уровень[править | править код]

Рис. 1. Пример иерархической структуры (блок-схема) Рис. 2. Граф структуры системы (И-дерево) Рис. 3. Пример И-ИЛИ-дерева

Исходная система располагается на нулевом уровне. После её расчленения получаются подсистемы первого уровня. Расчленение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т. д.

Упрощённое графическое представление декомпозированной системы называется её иерархической структурой.

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

Здесь на нулевом уровне располагается исходная система С₁, на следующих уровнях — её подсистемы (число уровней и количество подсистем, показанных на рисунке, выбрано произвольно). С целью получения более полного представления о системе и её связях в структуру включают надсистему и составляющие её части (системы нулевого уровня, например, вторая система С₂).

Для анализа иерархической структуры могут применять теорию графов. Это позволяет перейти от графической модели к математической, в которой описание ведётся по уравнениям, аналогичным законам Кирхгофа в электротехнике или уравнениям гидравлики.

Иерархическая структура часто изображается в виде дерева, то есть графа без замкнутых маршрутов, с расположением вершин по определенным уровням, например, как показано на рис. 2. Вершина верхнего уровня (на рисунке — 0) называется корнем.

Граф, представленный на рис. 2, соответствует И-дереву: вершины, которые расположены на одинаковых уровнях, являются обязательными элементами вышерасположенных систем.

Так, для вершины 0.1 обязательные элементы — 1.1, 1.2, а для вершины 2.2 — 3.1, 3.2 и 3.3. Например, автомобиль состоит из двигателя, И кузова, И шасси.

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

Часто применяют И-ИЛИ-дерево, которое соединяет уровни с обязательными элементами структуры с уровнями вариантов всех или части этих элементов (рис. 3). Сочетание И- и ИЛИ-уровней может быть произвольным и не обязательно они должны чередоваться.

Система расчленяется только по одному, постоянному для всех уровней, признаку[править | править код]

В качестве признака декомпозиции может быть:

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

Так, в приведённом выше примере выделение в составе автомобиля мотора, шасси и кузова проводилось в соответствии с функциональным признаком. При построении И-ИЛИ деревьев возможно сочетание нескольких признаков: одного — постоянного для И-структуры, и одного или различных на каждом уровне — для ИЛИ-структуры.

Вычленяемые подсистемы в сумме должны полностью характеризовать систему[править | править код]

Но при этом вычленяемые подсистемы должны взаимно исключать друг друга (особенно это касается ИЛИ-деревьев).

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

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

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

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

Глубина декомпозиции[править | править код]

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

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

Число уровней иерархии влияет на обозримость структуры: много уровней — задача труднообозримая, мало уровней — возрастает число находящихся на одном уровне подсистем и сложно установить между ними связи. Обычно, в зависимости от сложности системы и требуемой глубины проработки, выделяют 3…6 уровней.
Например, разрабатывая механический привод, в качестве элементарного уровня можно взять колеса, валы, подшипники, двигатель в целом. Хотя подшипники и двигатель являются сложными по устройству элементами и трудоемкими в проектировании, но как готовые покупные изделия для разработчика они выступают в виде элементарных частей. Если бы двигатель пришлось бы разрабатывать, то его, как сложную систему, было бы целесообразно декомпозировать.

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

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

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

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

• Хорошев А. Н. Введение в управление проектированием механических систем: Учебное пособие. — Белгород, 1999. — 372 с. — ISBN 5-217-00016-3. Электронная версия 2011 г.
• Методическое пособие для школьников 9-11 классов «Применение метода декомпозиции при решении неравенств». — Москва, 2019. — ^[1]
• Цурков В.И. Декомпозиция в задачах большой размерности. Под ред. Г.С. Поспелова. 1981. 352 с.

ru.wikipedia.org

Как workflow разработки влияет на декомпозицию задач / Badoo corporate blog / Habr

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава 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» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.

Если же поискать на git-scm.com (хорошо бы вообще погуглить), то с удивлением можно обнаружить, что никакого рекомендованного (и уж тем более «стандартного») workflow не существует. Всё потому, что Git – это, по сути, фреймворк для систем хранения версий кода, и то, как вы организуете это самое хранение и совместную работу, зависит только от вас самих. Всегда нужно помнить о том, что, если какой-то флоу «взлетел» на каких-то проектах, это вовсе не означает, что вам он тоже полностью подойдёт.

Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.

В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.

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

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

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

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

Feature branches

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Feature flags

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

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

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

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

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

Заключение

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

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

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

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

habr.com