Декомпозиция это в бизнесе

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

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

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

что такое декомпозиция

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

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

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

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

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

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

Пример: Вы едете отдыхать

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

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

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

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

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

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

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

Важно. Выжимайте из бизнеса максимум с помощью нашей методички формата “фишечная стратегия”. В ней самый сок из сотен тренингов и книг по маркетингу и продажам. А также концентрат успешных действий. По ссылке скидка 50% в течение 4 часов, кликайте -> “200+ фишек маркетинга: от привлечения до удержания“

ПРИМЕНЕНИЕ

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

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

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

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

Вариант 1. Низкая сложность

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

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

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

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

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

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

ВКЛЮЧАЙТЕСЬ В СОЦСЕТИ УЖЕ 40 000+ С НАМИ

Екатерина

Сергей

Иван

Елена

Екатерина

Вариант 2. Средняя сложность

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

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

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

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

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

Вариант 3. Высокая сложность

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

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

1. Количество потенциальных клиентов в поисковой системе (количество запросов по вордстат.яндекс) — 5 000 чел.;
2. CTR рекламного объявления (отношение сколько человек увидит Вашу рекламу и сколько кликнет по ней) — 10%;
3. Стоимость клика за переход по рекламе — 10 руб.;
4. Конверсию сайта в заявку (правильная структура сайта и другие детали) — 15%;
5. Конверсию из заявки в запись (работа администратора) — 70%;
6. Конверсию из записи в приход на услугу (человеческий фактор) — 90%.

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

5 000 человек увидели рекламу —> перешло на сайт 500 (10% CTR) —> заплатили за них 5 000 р. (500 человек * 10 руб. клик) —> из них 75 оставило заявку (15% конверсия сайта) —> из них администратор записал 52 человека (70% от заявок) —> 47 пришло в салон красоты (90% от записи).

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

НО! Положительная новость заключается в том, что один клиент нам обходится в 106 рублей (без учёта стоимости других расходов), что лучше, чем мы ожидали. Вот вам и фокус.

рассчитываем декомпозицию

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

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

Скажу больше, Вы можете не искать. Я сделал это за Вас и нашёл сервис, который Вам поможет все рассчитать.

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

Коротко о главном

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

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

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

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

Нашли ошибку в тексте? Выделите фрагмент и нажмите ctrl+enter

Источник: in-scale.ru

В помощь маркетологу: какие задачи решает декомпозиция

Как декомпозиция облегчает жизнь маркетологу, почему её стоит использовать в планировании и постановке задач, как декомпозировать воронку продаж и что делать после? Собрали основное про декомпозицию и объясняют на примерах специалисты Roistat.

2049 просмотров
Декомпозиция: что это простыми словами

Декомпозиция — это деление целого на части. В маркетинге можно декомпозировать большую цель на несколько маленьких. Например, не просто поставить задачу «привести 1 000 лидов», а разбить её на несколько более мелких: «привести 400 лидов с Google Ads», «получить 300 лидов с Яндекс.Директ» и «привлечь 100 лидов с рекламы в Facebook».

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

Мы составили план по уборке самолёта. Большую задачу «помыть Boeing 737» разбили на два уровня — уборка снаружи и внутри. Каждый уровень разбили ещё на несколько задач. Это и есть декомпозиция. Это инструмент упрощения — от большого к малому, от сложного к простому.

Сделать одну большую задачу непросто, а разобраться с десятком мелких — легко.

Декомпозицию можно представить в виде списка дел или графика с задачами
Что такое декомпозиция цели на задачи

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

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

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

С помощью декомпозиции Женя разбивает свою цель — стать маркетологом — на несколько задач:

• Записаться на курсы по маркетингу — например, у Roistat есть бесплатный курс-симулятор «Бизнес-аналитика в маркетинге».
• Изучить теорию — посмотреть лекции, начать читать тематические каналы, посмотреть кейсы.
• Осваивать новые знания и навыки по маркетингу каждый день по 1-2 часа.
• Попасть на стажировку и прокачать скиллы на практике.

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

Каждый шаг внутри задачи — простое и понятное действие. Например, пройти первый урок курса по маркетингу, сделать домашнее задание или почитать Фила Бадена.

Зачем нужна декомпозиция целей

Возьмём одну цель — купить новую машину. Какой из вариантов достижения цели нравится больше?

Источник: vc.ru

Как справиться с декомпозицией задач и не перестараться

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

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

Где же та грань между адекватной постановкой задач и тотального хаоса? Поделюсь примером того, как к нам в «Спортмастере» периодически поступают задачи в разработку от бизнеса.

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

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

Зачем нужна декомпозиция

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

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

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

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

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

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

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

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

Основные подходы и правила декомпозиции

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

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

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

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

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

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

Способы декомпозиции

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

Несколько потребностей

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

Сценарии использования

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

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

От простого к сложному

Главная страница сайта «Спортмастер» состоит из баннеров. И самое простое, что мы можем сделать — взять одну картинку и показать ее пользователю. Это самый простой и быстрый способ донести нужную информацию. Дальше мы можем наращивать функционал и добавлять не одну картинку, а три-четыре, которые объединяются в сетку. Это уже отдельная задача.

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

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

Операции (CRUD)

Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.

Варианты интерфейса

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

В этом случае проще все сделать сначала на одном языке, а потом постепенно добавлять переводы.

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

Разделение по ролям

Подходит для ситуаций, в которых функциональность подразумевает работу нескольких ролей и групп пользователей. На сайте «Спортмастера» у пользователя могут быть разные роли. Например, пользователи делятся по ролям на авторизованного пользователя, анонимного пользователя, и, допустим, пользователь колл-центра. Последняя роль также может делиться на две — это может быть как рядовой пользователь, так и администратор.

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

Обработка ошибок

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

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

Что в такой ситуации делать? Этот вопрос можно вынести в отдельную задачку и затем обрабатывать каждое отдельное поле. То есть, если не пришла цена, то выполняем одно действие, потерялось описание товара — другое. То же самое с ошибками пользователя. Если он ввел что-то некорректно и отобразилась ошибка, например, «Страница не найдена» или ошибка 500, мы должны показать ему конкретную информацию о том, что случилось, и предложить ему сценарий, что он может сделать дальше.

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

Статические, затем динамические

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

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

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

Производительность

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

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

Возможные трудности

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

Еще одна трудность — определить, насколько мелко надо декомпозировать задачу. И здесь границами выступает только здравый смысл. Например, мы берем компонент выбора города. В нем есть кнопки, какой-нибудь текст, поле ввода. Насколько мелко нужно бить эту задачу?

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

Еще у нас была проблема с тем, что не всегда понятны границы эпика. Недавно нам поставили задачу с оформлением заказа. Где у нее границы? Что должно получиться на выходе? Нам было непонятно, нужно ли нам делать весь функционал до самого конца, или выбрать какую-то часть.

Входит ли в этот эпик оплата, или это уже отдельный эпик.

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

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

Спасибо, что дочитали!

• аналитика
• декомпозиция
• спортмастер
• постановка задач
• task management
• декомпозиция задач
• управление временем

• Блог компании Sportmaster Lab
• Анализ и проектирование систем
• Управление разработкой
• Управление проектами

Источник: habr.com