что такое декомпозиция бизнес процесса
Как справиться с декомпозицией задач и не перестараться
Меня зовут Виктор, я системный аналитик в компании «Спортмастер». И сегодня я хотел бы поговорить о декомпозиции задач и передачи их в разработку. Любой объект состоит из частей, будь это автомобиль или программный продукт. И чтобы собрать любой из этих объектов в единое целое из составных частей, потребуется время. Иногда — даже очень много времени. Особенно, если перед этим вы не просто разобрали основную часть, а решили докопаться до сути на атомарном уровне.
Как видно из приведенных примеров, описание каждой задачи зависит по большей части от фантазии и здравого смысла заказчика. Где-то оно больше, где-то оно меньше, но аналитикам надо как-то с этим работать. Иногда указывают еще и границы функционала, а иногда присылают просто тему. Если передать такую задачу сразу в разработку, на выходе получим что-то непонятное. Что приходится делать?
Идти к заказчику ногами и выспрашивать все требования, уточнять, что именно должно быть на выходе. Правда, бывают еще золотые заказчики, которых, на самом деле, большинство — они пишут все требования у себя в Confluence, поэтому можно в любой момент пойти и спокойно почитать, задать вопросы. И когда уже все понятно с рамками фичи, можно приступать к нарезке задачи.
Зачем нужна декомпозиция
Основная цель декомпозиции заключается в том, чтобы бизнес мог быстро реализовывать все свои хотелки, и чтобы от самой идеи до появления функционала у пользователя проходило как можно меньше времени. Для этого можно делать более мелкие задачки, от которых пусть небольшой, но все-таки рабочий функционал будет доходить до пользователя.
Помимо достижения глобальной цели удовлетворения потребностей пользователя и бизнеса, декомпозиция задач позволяет получать более быстрый фидбэк от заказчика, в правильном ли направлении копает разработка, или же получилось совсем не то, что заказчик себе представлял.
Если задача изначально большая и мы взялись за нее сразу целиком, то мы потратим на нее очень много времени и после комментариев заказчика нам придется все выбросить. Ну а если задача маленькая, день-два работы от силы, — ничего страшного. Переделка займет еще примерно столько же. Второй подход, к тому же, обойдется еще и дешевле. Не говоря уже о сэкономленных нервах с обеих сторон.
Если один функционал разбить на несколько кусочков, разработчики могут работать над ними параллельно. Таким образом мы распараллелим поток и ускорим вывод функционала в прод. Важная штука — при этом задачи должны как можно меньше зависеть друг от друга.
Плюс быстрое тестирование и исправление багов. Опять же, мелкий функционал гораздо проще и быстрее тестировать, чем монструозную махину. И если что-то пойдет не так, на «пофиксить» разработчик потратит совсем немного, и все быстрее заработает.
На этапе разбивки задач вместе с заказчиком можно сразу понять, какой функционал важен прямо здесь и сейчас, чтобы уже начать получать прибыль, что можно оставить на потом, а что, возможно, само отвалится за ненадобностью.
Бизнесу же важно знать, как быстро появится рабочий функционал. И при разбивке на задачи мы можем спрогнозировать и более точно оценить время, которое потребуется на их реализацию, чем когда у тебя один большой фронт работ. Но помимо того, что мелкие задачи легче оценить в плане времени на их проработку, разработчику также проще оценить риски, которые могут возникнуть в процессе работы.
Например, обновились фреймворки, какие-то методы вывели из эксплуатации, проблемы с кодом и прочее. Беря в работу небольшие задачи, мы минимизируем все эти риски, и даже если такая задача что-то заблокирует в потоке, это будет не так критично, как если бы это был здоровенный кусок (который бы заблокировал вообще всё). В случае необходимости можно будет сделать рабочее решение и в бэклог положить техдолг, с которым можно будет разобраться чуть позже, когда проблемы будут решены.
Основные подходы и правила декомпозиции
Существуют два основных подхода к декомпозиции задач — горизонтальный и вертикальный. При горизонтальном задачи делятся по типам работ, по уровням или по компонентам. Например, у нас каждая задача проходит через несколько стадий: фронтенд, бэкенд, базы данных. И при горизонтальном подходе одна задача идет в бэк, вторая во фронт, а третья приводит к изменениям в базе данных.
Чем плох данный подход? Мы не получаем рабочий функционал после выполнения каждой отдельной задачи. Только собрав результаты из трех источников, мы можем получить какой-то результат и фидбэк на него. По этой причине горизонтальную декомпозицию чаще всего не используют.
Гораздо удобнее вертикальный подход, при котором в каждой задаче можно сделать наглядный функционал — задача проходит по всем стадиям и на выходе есть результат, который можно проанализировать, протестировать, показать заказчику и поправить, если надо. И быстренько запустить в работу и использовать.
Если говорить про правила, здесь я выделил всего три. Во-первых, задача должна быть логически завершенной, то есть независимой сама по себе. Она не должна ломать логику вокруг себя и обязательно должна нести в себе хоть какой-нибудь бизнес-смысл, который в результате получит пользователь. При этом не стоит разбивать на части те задачи, которые не несут бизнес-смысла (в идеале их вообще не должно быть).
Во-вторых, результат выполнения одной небольшой задачи должен нести небольшие изменения. Чем меньше изменения, тем быстрее они попадают в общий код, и таким образом код не устаревает. Кроме того, маленькие задачи помогают избежать конфликта между разработчиками при мердже.
В-третьих, не стоит разбивать задачу на совсем уж микроскопические части. Если разбить слишком мелко, очень много времени уйдет на управление этими задачами. На каждом этапе их, возможно, придется переприоритезировать, заново проставлять связи зависимости и вот это всё. Таким образом, скорость разработки не увеличится, а наоборот, резко упадет. Поэтому нужно искать золотую середину.
Способы декомпозиции
В зависимости от источника, количество способов декомпозиции очень сильно варьируется: где-то их указывают всего восемь, где-то десять, где-то двадцать. Я бы хотел остановиться на тех способах, которыми мне приходится пользоваться каждый день на работе.
Несколько потребностей
Этот способ удобнее всего использовать, когда в истории присутствуют союзы «и», «или». Например, потребитель хочет сделать заказ и оплатить его картой или бонусами. Эту задачу можно разделить на три: первая, в которой пользователь делает заказ, вторая, где он оплачивает его картой, и третья, где в ход идут бонусы.
Сценарии использования
Еще один часто встречающийся способ — делить задачи в зависимости от сценария использования. В этом случае одна история представляет из себя один основной путь и несколько альтернативных. Допустим, пользователь хочет купить товар, и это будет основной сценарий. Но есть еще альтернативные пути — он может сразу положить товар в корзину и оплатить, а может захотеть перед покупкой сравнить этот товар с другими. И тогда отдельной задачей мы делаем сравнение товаров.
Возможно, он не хочет покупать прямо сейчас, а отложить куда-нибудь, добавить в избранное, чтобы позже к нему вернуться. Или пользователю понравился товар и уже готов его купить, но его нет в наличии. Значит, надо дать ему знать о том, когда товар появится. И вот таким образом получается четыре сценария.
От простого к сложному
Главная страница сайта «Спортмастер» состоит из баннеров. И самое простое, что мы можем сделать — взять одну картинку и показать ее пользователю. Это самый простой и быстрый способ донести нужную информацию. Дальше мы можем наращивать функционал и добавлять не одну картинку, а три-четыре, которые объединяются в сетку. Это уже отдельная задача.
При таком подходе с каждой последующей задачей функционал должен расти. Мы можем, например, сделать из сетки карусель, а потом добавить какие-нибудь ссылки, тексты, кнопки и остальное. В общем, сначала реализуем самый простой и быстрый в исполнении вариант, а затем движемся к более сложному.
Как раз недавно я занимался похожей задачей по реализации баннера. Баннер должен был висеть на главной управляться из CMS. Если спросить у заказчика, а чем бы именно он хотел управлять, он, не моргнув, радостно ответит — всем. Поэтому здесь было важно немного погрузиться в тему и выделить то, чем нужно управлять прямо сейчас, чем просто часто, а чем почти совсем не пользуются. И таким образом расставить приоритеты по реализации и поделить на задачи.
Операции (CRUD)
Это, наверное, самый распространенный способ декомпозиции. Здесь задачи деляться по операциям Create, Read, Update и Delete. Он подходит для задач, где нужно чем-то управлять или что-то конфигурировать. Например, задача по оформлению заказа делится на четыре более мелкие: создание заказа, его просмотр, редактирование и удаление.
Варианты интерфейса
Используется, когда надо поддержать несколько вариантов интерфейса. Например, сайт должен поддерживать несколько языков. Сначала мы делаем русскоязычную версию. Затем, при запусках в других странах, добавляем английский. Если же в стране используется язык, отличный от английского, то можем добавить и его. В этом случае проще все сделать сначала на одном языке, а потом постепенно добавлять переводы.
Совсем недавно мы завершили проект личного кабинета для юридических лиц, в котором нужна была поддержка мультиязычности. Сроки были сжатые, поэтому изначально сделали все на одном языке, но заложили основу для дальнейшего перевода. Теперь, чтобы добавить поддержку нового языка, нужна всего лишь одна небольшая задача. Если нужно добавить сразу несколько языков, на каждый из них заводится отдельная задача.
Разделение по ролям
Подходит для ситуаций, в которых функциональность подразумевает работу нескольких ролей и групп пользователей. На сайте «Спортмастера» у пользователя могут быть разные роли. Например, пользователи делятся по ролям на авторизованного пользователя, анонимного пользователя, и, допустим, пользователь колл-центра. Последняя роль также может делиться на две — это может быть как рядовой пользователь, так и администратор.
Для каждой роли мы можем сделать отдельную задачу. Начать с отображения для анонимного пользователя, а затем добавить какой-нибудь расширенный функционал в рамках задачи для авторизованного. И не забыть про технические роли операторов колл-центра и функционал для них.
Обработка ошибок
Если сроки сжатые, а минимальный функционал нужен как можно быстрее, можно вынести обработку ошибок в отдельную задачу. Здесь речь идет не о написании тестов, а об обработке ошибок пользователей и систем, с которыми интегрирован сайт. Представим, что мы обрабатываем страницу с каталогом, которая содержит плитку с товарами. В каждой карточке есть описание, фото и дополнительная информация.
Случилось так, что какая-то часть информации не приходит из баз данных.
Возможно, если речь идёт о бренде или материале, то этим можно пренебречь и просто не показать информацию. Но если не дойдет цена или название, стоит ли показывать эту карточку?
Что в такой ситуации делать? Этот вопрос можно вынести в отдельную задачку и затем обрабатывать каждое отдельное поле. То есть, если не пришла цена, то выполняем одно действие, потерялось описание товара — другое. То же самое с ошибками пользователя. Если он ввел что-то некорректно и отобразилась ошибка, например, «Страница не найдена» или ошибка 500, мы должны показать ему конкретную информацию о том, что случилось, и предложить ему сценарий, что он может сделать дальше.
Этот способ также подходит для ситуаций, когда нужно быстро получить обратную связь на функциональность, чтобы решить, оставлять ее или нет.
Статические, затем динамические
Это один из моих любимых способов. Подходит в ситуациях, когда можно реализовать функционал «на заглушках», то есть внешние системы не готовы поддержать функционал. Например, какие-то блоки на главной странице не могут управляться из CMS. Или меню, когда мы делаем его у себя в коде и отображаем пользователю, но при этом им не может управлять бизнес. И чтобы внести изменения, бизнесу надо постоянно ходить в разработку и просить это сделать.
Здесь мы выносим потребности пользователя и получение прибыли в приоритет. Пользователь получает готовый функционал сразу, пусть мы внутри можем испытывать некоторые неудобства. Поэтому мы делим задачу на несколько и сначала делаем новый блок доступным для пользователя, но бизнес им пока напрямую управлять не может. Но затем мы можем интегрироваться с какой-то системой или базой данных, где бизнес сам сможет менять пункты местами и добавлять новые самостоятельно, а мы их будем отрисовывать без участия разработки.
Мы часто используем этот способ: сначала делаем функционал на своих данных, которыми нельзя управлять со стороны, а потом уже добавляем динамику и начинаем получать данные из сторонних систем.
Производительность
Если задача в целом сложная и объемная, непонятно, с какого конца за нее взяться, то производительностью можно пренебречь. В первую задачу вынести готовый функционал, который хоть как-то, пусть медленно, но работал. А следующей задачей сделать ускорение работы. Например, это может быть медленная работа поиска товаров, применение фильтров, получение какой-либо информации
Иногда большая часть усилий вкладывается в быстрое создание функции — первоначальная реализация не так уж сложна. Но можно многому научиться из медленной реализации, плюс это имеет определенную ценность для пользователя, который иначе не смог бы выполнить какое-нибудь важное действие. Во всех этих случаях задачи разбиваются на «заставьте это работать» и «сделайте это быстрым».
Возможные трудности
Если вы решите использовать декомпозицию задач в своих проектах, то скорее всего первой сложностью, с которой вы столкнетесь, будет зависимость задач друг от друга. По моему опыту, именно эта проблема приводит к блокированию всего потока и встречается наиболее часто. Чтобы этого избежать, к декомпозиции стоит подходить ответственно и уделять ей достаточное количество времени.
Еще одна трудность — определить, насколько мелко надо декомпозировать задачу. И здесь границами выступает только здравый смысл. Например, мы берем компонент выбора города. В нем есть кнопки, какой-нибудь текст, поле ввода. Насколько мелко нужно бить эту задачу?
Мы для себя вывели правило, что задача должна проходить по всему потоку не больше, чем за одну неделю (около 40 часов). Речь идет про все стадии: стадию аналитики, разработки, тестирования. Плюс учитываются две стадии разработки бэкенда и фронтенда, включая ревью и тестирование на каждой.
Еще у нас была проблема с тем, что не всегда понятны границы эпика. Недавно нам поставили задачу с оформлением заказа. Где у нее границы? Что должно получиться на выходе? Нам было непонятно, нужно ли нам делать весь функционал до самого конца, или выбрать какую-то часть. Входит ли в этот эпик оплата, или это уже отдельный эпик.
Бывают задачи, с которыми сложно понять, как их декомпозировать и когда. Большую часть задач мы декомпозируем на стадии приема эпика, но бывают ситуации, когда это нужно сделать, например, на этапе аналитики. Мы берем задачу в работу и считаем, что все нужные данные в наших интеграционных системах уже есть, но в процессе анализа выясняется, что либо нас не устраивает формат данных, либо проблема в качестве самих данных, либо требуется доработка со стороны других систем, с которыми мы связаны. Тогда нам приходится делать задачу «на заглушках» и заводить еще один пункт в бэклог, к которому мы приступим уже после того, как решим основные проблемы.
Вот, вроде бы, и всё. Будет здорово, если поделитесь в комментариях историями о том, какой подход к декомпозиции задач используете вы и почему.
Декомпозиция: что это и как использовать в маркетинге
директор по маркетингу
Расскажем, что такое декомпозиция, как использовать её в планировании и постановке задач, почему маркетологи декомпозируют воронку продаж, приведём примеры декомпозиции.
Декомпозиция: что это простыми словами
Декомпозиция — это деление целого на части. В маркетинге можно декомпозировать большую цель на несколько маленьких. Например, не просто поставить задачу «привести 1 000 лидов», а разбить её на несколько более мелких: «привести 400 лидов с Google Ads», «получить 300 лидов с Яндекс.Директ» и «привлечь 100 лидов с рекламы в Facebook».
Представьте, что нужно помыть Boeing 737. Это большой самолёт, на мойку не сдать — он не влезет в помещение, где моют машины. Пройтись с ведром и губкой не получится — самолёт стоит на шасси, с него можно упасть. Позовём две бригады с кёрхерами на кране — одна будет мыть кузов самолета, другая крылья и хвост. Внутри будут работать уборщики — они почистят салон, кабину, туалеты, отсеки для хранения багажа.
Мы составили план по уборке самолёта. Большую задачу «помыть Boeing 737» разбили на два уровня — уборка снаружи и внутри. Каждый уровень разбили ещё на несколько задач. Это и есть декомпозиция. Это инструмент упрощения — от большого к малому, от сложного к простому. Сделать одну большую задачу непросто, а разобраться с десятком мелких — легко.
Что такое декомпозиция цели на задачи
Инструмент упрощения или декомпозиции используют во многих сферах. В криминалистике его называют методом дедукции, а в физике используют для решения сложных задач. В быту тоже используют упрощение, когда что-то планируют. Это декомпозиция конечной цели.
Пример: Женя хочет стать маркетологом — это её цель. Просто так взять и в одночасье стать маркетологом не получится. Нужно пройти обучение, чтобы освоить сферу знаний, затем приобрести и потренировать навыки, необходимые в профессии. Подобная подготовка может занять много времени. К тому же в процессе обучения Женя может передумать, что ей подходит профессия маркетолога.
Но пока Женя замотивирована, ей хочется настраивать классные рекламные кампании и помогать бизнесу получать прибыль от запусков рекламы. К счастью, Женя знает, что такое декомпозиция. Ведь если продумать, из каких составляющих складывается путь от текущих навыков Жени к тем, что нужны настоящему маркетологу, можно повысить свою мотивацию. Выполняя мелкие задачи и наблюдая за прогрессом, проще дойти до конца и освоить профессию.
С помощью декомпозиции Женя разбивает свою цель — стать маркетологом — на несколько задач:
В декомпозиции важно разбить цель на задачи, а для каждой задачи — продумать шаги. Иначе можно попасть в ловушку, когда и задачи будут казаться такими крупными, что непонятно, как за них браться.
Каждый шаг внутри задачи — простое и понятное действие. Например, пройти первый урок курса по маркетингу, сделать домашнее задание или почитать Фила Бадена.
Рассказали в блоге о 5 полезных маркетологу книгах.
Зачем нужна декомпозиция целей
Возьмём одну цель — купить новую машину. Какой из вариантов достижения цели нравится больше?
Одна цель — непонятно, что с ней делать, с чего начинать
Цель декомпозировали — составили план действий. Чтобы достичь цели, двигаемся от задачи к задаче
Вариант справа даёт развернутую картину действий. Понятно, какие шаги нужно предпринять, чтобы купить машину. Декомпозиция разворачивает изнанку цели — чем подробнее расписать шаги и задачи, тем проще достичь результата.
Преимущества декомпозиции целей:
3 способа декомпозировать цели
1. Разбить цель на шаги
Это самый простой способ — разбить цель на задачи и записать их подряд, друг за другом. Можно ручкой в блокноте, в заметках в телефоне или в любом планере (например, Todoist). Внутри задач можно прописывать шаги и ставить сроки для выполнения. Примеры: список покупок, чек-лист, инструкция.
2. Построить майндмэп
Майндмэп (от англ. mind map) или ментальная карта визуально отображает структуру цели — какие есть задачи, как они связаны друг с другом, в какой последовательности их выполнять, кто за какую задачу отвечает.
В майндмэпе проще создавать подзадачи. Если записывать их друг за другом на бумаге, общая картина может потеряться. К тому же иногда нужно выполнять шаги параллельно, а они из разных задач. В майндмэпе это легко отследить. Поэтому их используют для во время мозговых штурмов. Из множества идей создаётся структура цели и понимание, какие задачи нужно решить для её достижения.
3. Использовать метод SMART
SMART — метод декомпозиции и оценки целей, это аббревиатура на английском языке. Состоит из 5 слов, — каждое слово определяет, какой должна быть цель:
Декомпозиция в маркетинге
Маркетологи используют декомпозицию для работы с воронкой продаж. Они переворачивают воронку на 180 градусов и раскладывают её по этапам — от последнего к первому.
Обычная воронка продаж — от знакомства с продуктом до конечного действия
Обратная или декомпозированная воронка продаж — от целевого действия до знакомства
Нужно не просто перевернуть воронку, а разбираться, как клиенты доходят до каждого из этапов, что влияет на переход из одного этапа в другой. Получается обратная воронка с причинно-следственной связью.
Декомпозиция помогает определить приоритетные этапы воронки с целью понять, как можно повлиять на рост прибыли.
Например, Павел владеет интернет-магазином детских игрушек. Он хочет увеличить прибыль в два раза и идёт к маркетологам из компании А. Они предлагают увеличить рекламный бюджет в два раза. Но Павел понимает, что маркетологи ошибаются. Увеличение бюджета не гарантирует, что прибыль автоматически вырастет. К тому же Павел хочет больше зарабатывать, а не больше тратить.
Павел идёт к маркетологам из компании Б и узнаёт про декомпозицию. Ему рассказывают, что это способ по-другому взглянуть на воронку продаж, и помогают увеличить прибыль.
Как декомпозировать воронку продаж
1. Берём воронку продаж для интернет-магазина.
Читайте подробно о том, что такое воронка продаж и как её использовать в маркетинге.
2. Переворачиваем воронку и собираем в обратном порядке.
3. Разбираемся в причинах перехода от этапа к этапу — что влияет на движение по воронке. Получается такая декомпозиция:
Что маркетологу делать после декомпозиции воронки продаж
Необходимо изучить путь клиента по воронке — посмотреть конверсию на каждом этапе и перед запуском новой рекламы отследить эффективность текущей кампании. Для этого можно использовать сервис сквозной аналитики — такой есть у Roistat. В нём можно отследить путь клиента от первого клика по рекламе до целевого действия — в нашем случае до покупки.
Анализируем конверсию и замечаем низкий CTR объявления. Его можно увеличить с помощью выбора позиции объявления и ставки. Чем ниже позиция в поисковой выдаче, тем ниже CTR. Ещё одна проблема — много пользователей заходят на страницу с продуктом, но не добавляют его в корзину. Для повышения конверсии можно улучшить оформление карточки — добавить яркие картинки товаров, видеоотзыв, сделать более заметной кнопку «Добавить в корзину», предлагать рассрочку в способах оплаты.
И дальше разбираем так каждый этап — смотрим статистику, обнаруживаем барьеры и думаем, как их можно убрать и улучшить конверсию.
Для работы с собственной воронкой проще использовать отчёт «Воронка событий» в Roistat. Нужно добавить события под свою воронку и указать период для анализа. Сэкономите время на декомпозиции.
Главное
На нашем Telegram-канале делимся полезными материалами по маркетингу и аналитике, кейсами клиентов, собираем познавательные дайджесты и анонсируем бесплатные обучающие вебинары. Подписывайтесь, чтобы ничего не пропустить!
Будьте в курсе новостей
Присоединяйтесь к нашему каналу в Telegram или подпишитесь по E-mail
Маркетинговая платформа сквозной аналитики,
привлечения трафика, повышения конверсии и лояльности