Технология создания товаров и услуг
Для получения необходимого результата — производство продукта или оказание услуги — любой компанией выполняется некая последовательность действий. Она носит название бизнес-процесса и, как правило, характеризуется цикличностью.
От того, насколько эффективными являются действия, зависит:
- Прибыльность организации.
- Ее конкурентоспособность.
Общепринятая методология описания бизнес-процессов подразумевает использование одного из трех способов:
- текстовый;
- табличный;
- графический.
В первом случае оно будет иметь примерно такой вид: департамент продаж компании А разрабатывает и составляет договор, а затем передает его на согласование в юридическую службу. То есть, здесь мы имеем последовательное описание процесса:
- тип операции — составление договора/согласование договора;
- ответственный — департамент продаж/юридическая служба;
- вход — договор;
- поставщик — департамент продаж;
- выход — договор;
- клиент — юридическая служба.
Практика показывает, что анализ и оптимизация деятельности организации наиболее эффективны при использовании графического способа.
Методология и правила описания
В этом отношении у компании имеется широкое пространство для маневра, так как методов описания бизнес-процессов существует множество: более двух десятков — точно. Вопреки распространенному мнению, большое количество способов не является проблемой, так как все они основаны на двух главных — WFD и DFD (Work Flow Diagram и Data Flow Diagram соответственно).
Существует семь золотых правил описания БП:
- Составление, уточнение и подтверждение выполняется совместно с заинтересованными лицами — участниками БП.
- Повышение эффективности дает применение всех трех способов описания (текстовый, табличный, графический).
- При обсуждении следует использовать такие категории, которые понятны каждому его участнику.
- Создавать нужно схемы деятельности, а не организационных структур.
- Излишняя детализация вредит делу.
- Разработка схемы ради схемы не имеет смысла, так как к дальнейшему анализу не располагает.
- Следует четко различать понятия «как будет», «как должно быть» и «как есть сейчас».
Подробнее о декомпозиции
Для чего необходимо знать стандарты описания бизнес-процессов? Для того, чтобы грамотно проектировать их, «разбирать» и «собирать». Второе и третье действие помогает улучшить управляемость любым процессом и, как следствие, деятельностью организации в целом.
«Разборка» подразумевает дробление БП на части, которыми легче управлять. Каждую из них рассматривают отдельно. Части также называют подпроцессами, и все они имеют начало, механизм реализации, окончание, показатели и так далее.
Характеристики бизнес-процесса
Используются для оценки. Благодаря им легко заметить, какой процесс является наиболее слабым звеном и нуждается в изменении. Характеристика основана на следующих критериях:
- результативность;
- эффективность;
- определенность;
- повторяемость;
- адаптируемость;
- длительность;
- стоимость.
Декомпозиция цели в Agile
В методе управления проектами Agile лежит техника декомпозиции. Клиенту не показывают готовый продукт, а представляют его по частям, чтобы получить обратную связь по ходу выполнения каждой задачи. В Agile существует 2 подхода к декомпозиции: вертикальный и горизонтальный.
Горизонтальный подход
Задачи разбиваются по типу работ, которые нужно выполнить, либо по компонентам которые задействованы в системе. Часть работ отдается в работу разработчику, часть тестировщику, дизайнеру, специалисту и так далее. Продукт становится рабочим, когда все части реализованы.
Вертикальный подход
Выделение изолированных задач внутри системы, что подразумевает выполнение пользовательского сценария. Каждый сценарий может быть реализован и выпущен независимо друг от друга. Такой подход более эффективен, так как:
- части проекта можно продемонстрировать независимо друг от друга;
- каждая воплощенная задача несет ценность;
- в реализации участвуют специалисты различных областях.
Зачем нужна декомпозиция?
Декомпозиция очень часто используется в планировании, и это не случайно. Она помогает:
-
Облегчить выполнение задач. Крупные задачи часто кажутся непомерно сложными, что вызывает у нас приступы прокрастинации. Декомпозиция позволяет разложить такие «страшные» задачи на простые и понятные кусочки. Например, написать большую книгу — довольно сложно, а ежедневно писать по 1000 слов — вполне осуществимая задача.
-
Оценить реалистичность цели. Во время декомпозиции становится понятно, насколько цель достижима и не нужно ли ее подкорректировать. Например, мы решили научиться виртуозно играть на классической гитаре за три месяца. Но если мы разделим эту цель на отдельные этапы, то увидим, что на ее достижение уйдет как минимум три года.
-
Составить план достижения цели. Все подзадачи, на которые мы дробим цель — это конкретные шаги по ее достижению. В результате вместо абстрактной мечты у нас появляется подробный план по воплощению этой мечты в реальность.
-
Оценить ресурсы. В процессе декомпозиции мы узнаем, какие нам понадобятся материалы и инструменты, сколько времени и денег уйдет на каждый этап и каких людей потребуется привлечь для работы.
На самом деле, декомпозиция — это неотъемлемая часть нашего мышления. Приступая к любому делу, мы автоматически пытаемся если и не разбить его на этапы, то хотя бы выделить из него первоочередное действие. А столкнувшись с каким-нибудь незнакомым объектом или явлением, мы всегда стараемся мысленно разделить его на какие-то составные части.
Другое дело, что в тайм-менеджменте декомпозиция применяется осознанно, а значит и более эффективно.
Как устроена корневая оптимизация
Представим, что у нас есть массив a, и с подмножеством его элементов от a до a нужно что-то сделать — например, найти их сумму или вставить новый элемент. Запросов на подобные действия может быть много, причем для каждого — свои значения x и y. Всего в массиве n элементов.
Простейшее решение. С первого взгляда решение кажется простым: нужно перебрать элементы от a до a в цикле и выполнить требуемое действие для каждого из них. Это действительно самый простой способ, но он же наименее оптимальный. В некоторых ситуациях, особенно если массив большой, выполнение такого алгоритма займет очень много времени.
Разделение. Чтобы оптимизировать решение таких задач, нужна корневая оптимизация. Ее идея в том, чтобы разделить массив на отрезки длиной в квадратный корень из n. Если корень из n — дробное значение, оно округляется в большую сторону. Количество таких отрезков также будет примерно равно корню из n — это следует из самого математического определения квадратного корня. Получается, длина одного отрезка и количество отрезков — одно и то же число.
Структура, которая получается после разделения, называется корневой декомпозицией — так же, как и весь подход.
Совершение операций. Операции сложения, умножения и другие в результате проводятся не над целым массивом, а над его отрезками длиной в квадратный корень. Сразу после разделения операция, скажем, последовательного сложения проводится для каждого отрезка. Получается набор отрезков-блоков, для каждого из которых уже подсчитана общая сумма.
Теперь, если понадобится подсчитать сумму на любом произвольном участке массива, этот участок можно представить как набор блоков или их кусочков. Если нужное подмножество от a до a уместит в себя целый блок или даже несколько, это серьезно сократит количество операций — суммы для блоков уже подсчитаны. Кусочки-«хвостики» из других блоков можно просто подсчитать вручную. Это не окажет серьезного влияния на скорость выполнения.
Но надеяться, что подмножество для расчета суммы целиком поместит в себе какой-то блок, нельзя. В худшем случае оптимизации не будет. Поэтому расчеты производятся иначе.
Расчеты для сложения. Чтобы оптимально подсчитать сумму на участке от a до a при корневой декомпозиции, используется такая формула: sum = sum – sum. То есть:
- сначала подсчитывается сумма элементов от начала массива до a, то есть до конечной точки нужного участка;
- потом подсчитывается сумма от начала массива до a, то есть до элемента, стоящего перед начальной точкой нужного участка;
- из первой суммы вычитается вторая. Согласно правилам арифметики полученное число и есть сумма элементов от a до a.
Такой подход позволяет легко оперировать полученными при декомпозиции блоками: складывать и вычитать их, а не элементы поочередно. Оставшиеся «хвостики» можно считать вручную: выше мы уже говорили, что на скорость выполнения они практически не влияют.
Расчеты для других операций. Если вместо сложения нужно проводить другие операции, например умножение или поиск максимума, формула может быть немного другой. Иногда ее дополнительно усложняют для оптимизации тех или иных действий. Но она существует практически для любых ассоциативных операций — тех, для которых и используют корневую декомпозицию.
Метод 2: Разбиение по позитивным и негативным сценариям.
Фактически каждая функциональность имеет правильный\прямой сценарий использования, который приводит к ожидаемому\позитивному результату. Однако, когда пользователь работает с тем или иным функционалом могут произойти отклонения от правильного процесса: переданы не те данные, выполнены не все обязательные условия, нет необходимых прав доступа и т.п. Такие отклонения от прямого сценария работы приведут к негативным результатам (действие не выполнится, функция отработает некорректно и т.п.).
Соответственно мы можем выполнить декомпозицию на ожидаемый сценарий использования функционала и на неправильные, но возможные и вероятные сценарии работы
Для каждого сценария важно выделить отдельные пользовательские истории:
- Для позитивного – реализация правильной работы функционала.
- Для негативных – реализовать правильную отработку той или иной возможной ошибки, разработать альтернативный сценарий.
В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:
- Позитивный сценарий: пользователь заходит в свою учетную запись на сайте и совершает покупку оплачивая ее по карте. Или в формате пользовательской истории: «как клиент я могу войти в свою учетную запись, чтобы совершить покупку по карте».
- Негативный сценарий 1: клиент пробует совершить покупку без авторизации.
- Негативный сценарий 2: пользователь пробует совершить покупку, но у него на счету не хватает средств и оплата не проходит.
- Негативный сценарий n: клиент пробует совершить покупку, но его учетная запись заблокируется из-за неправильного ввода пароля.
Подобный тип декомпозиции позволяет выделить, проанализировать и запланировать отработку различных исключений и неверных сценариев использования ПО, которые в любом случае будут возникать.
Что такое декомпозиция?
Декомпозиция — это разделение крупного на составные системы вплоть до самых мелких частей — до элементарных и понятных действий. Это способ упростить объект, но в то же время сохранить его целостность.
Это разделение на подпункты жизни, ее отдельных сфер, целей, задач, проблем, проектов.
Это не просто выдумка тайм-менеджмента — это научный метод, доказавший свою эффективность. В этой статье я буду писать максимально кратко и просто обо всем, но вы можете почитать и более умные тексты о составляющих и важных нюансах декомпозиции.
Наверняка вы слышали такой термин тайм-менеджмента, как «Cъесть слона по кускам» — это вот как раз про декомпозицию. Разделить на куски, сделать бифштексы, порезать еще на кусочки поменьше и легко потихоньку съесть один за другим, когда они все лежат перед тобой на тарелке, маленькие и готовые к употреблению.
Крупная цель разбивается на подцели, потом еще на подцели, на конкретные шаги, более мелкие шаги и так далее.
Декомпозиция может иметь много уровней — оптимально 3, можно до 6 и даже более. Очень желательно, чтобы каждый финальный пункт занял у вас по времени максимум 1-2 часа. Нужно разбивать и разбивать задачи до того, как конечные будут такого объема.
Важнейший элемент — дедлайн напротив каждого мелкого шага.
Основные принципы
Прежде чем углубляться в теорию, давайте немного поговорим об инструменте, которым мы будем пользоваться.
Для разделения целей и задач на подзадачи, мы с вами будем рисовать вот такую диаграмму:
Такая иерархическая структура называется деревом целей. С его помощью можно окинуть свой план одним взглядом, понять, чем его дополнить, и сразу найти его слабые места. Почти все приведенные в этой статье примеры декомпозиции будут представлять собой такие деревья.
В принципе для построения деревьев можно использовать любую программу для создания схем — Microsoft Visio или, например, бесплатный сервис draw.io. Древовидные структуры умеют создавать и некоторые современные органайзеры, например, LeaderTask.
Но удобнее всего рисовать такие деревья в виде ментальных карт. Для этого вам потребуются специальные программы для их создания: X-mind, MindNode, MindManager, бесплатная Freemind и т. д.
Итак, приступим. В общем виде декомпозиция выглядит так:
- Выбираем задачу или цель.
- Спрашиваем себя: какие шаги потребуется предпринять для ее осуществления? Записываем результат. У нас получаются цели (или задачи) 2-го порядка.
- Задаем к ним все тот же вопрос и снова записываем результат. Получаем цели 3-го порядка.
- Повторяем эту процедуру необходимое количество раз.
Уровень детализации зависит от ваших потребностей. Если вам, например, нужен план ежедневных действий, то остановиться можно на тех задачах, которые занимают от 15 минут до 2 часов.
В процессе декомпозиции важно соблюдать следующие правила:
1. Следить, чтобы записанных подзадач было достаточно для выполнения задачи верхнего уровня. Посмотрите на список подзадач и подумайте: если все это сделать, будет ли задача выполнена? Если нет, то каких-то подзадач явно не хватает.
2. Стараться не делить задачи более чем на 7 подзадач. По правилу Джорджа Миллера мы способны за один раз удержать в памяти 7±2 объекта, и если подзадач окажется больше, нам будет труднее воспринимать свои планы. В таких случаях можно разделить задачи на группы по какому-нибудь признаку:
Впрочем, последнее правило не является аксиомой: делайте так, как вам удобнее.
Метод 1: Разбиение по этапам\фазам бизнес процесса.
Используя этот метод можно попробовать разбить большую задачу, описывающую некий бизнес процесс на составные части и этапы. Для этого в данном процессе необходимо выделить последовательную цепочку шагов , которые могут быть реализованы и выполнены независимо друг от друга. В качестве пояснения этого метода декомпозиции можно привести следующий пример:
- В бэклоге у нас есть большое требование — реализовать для клиента функцию покупки в интернет магазине.
- В рамках процесса покупки можно выделить, например, следующие этапы:
- вход в личный кабинет
- просмотр товаров в «корзине»
- формирование счета на оплату
- отправка счета по почте
- выполнение оплаты различными способами: банковский перевод, карта и т.п., подтверждение оплаты.
- Каждый такой этап можно выделить и описать в виде отдельной пользовательской истории.
В результате мы разбиваем большой бизнес процесс на составляющие его этапы. Какие-то этапы при этом могут быть критичными и обязательными, а какие-то опциональными. Такая декомпозиция дает возможность:
- Во-первых, определить различные приоритеты для каждой истории и сосредоточиться в первую очередь на самых важных для бизнеса этапах.
- Во-вторых, при таком разбиении лучше понятен сам процесс, его шаги и составные части, возможные зависимости меду этапами.
Метод 4: Разбиение по видам операций.
Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.
На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:
- Create — создание нового продукта в интернет магазине
- Read — просмотр описания продукта
- Update — редактирование\обновление описания продукта
- Delete — удаление продукта из магазина
Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:
- Какие из операций являются действительно необходимыми для работы с тем или иным объектом? Как правило операции связанные и не имеет смысла реализовывать, например, создание объекта без возможности его просматривать. Однако, выделение операций позволит расставить для них приоритеты.
- Каким образом необходимо реализовать каждую из операций? Возможно одна и та же операция должна быть реализована несколькими способами. В этом случае декомпозицию можно продолжить и вынести реализацию каждого из способов в отдельную пользовательскую историю. Например, нам необходимо реализовать создание нового объекта через интерфейс web-приложения, через панель администратора на сайте магазина, путем добавления информации в базу данных и т.д.
Характеристики и понятие темы
В случае с целями имеет следующие характеристики: Надо понимать, что декомпозиция ради неё же самой никому не нужна. Она имеет три характеристики, а именно:
- Разделение;
- Достижение;
- Распределение.
Из них попытаемся сложить определение:
Грубо говоря, она является подробной расшифровкой вышестоящего уровня.
Продемонстрируем пример:
рис. Элементарная декомпозиция целей организации. Нажмите для увеличения.
Мы считаем, что оптимальным разделением является декомпозиция до третьего уровня. Третий уровень должен прояснять картинку и отвечать на вопрос: «что делать?». Однако при создании дерева целей для больших организаций и/или холдинговых структур могут наблюдаться до шести вложений.
Рекомендации
- Саймон, Герберт А. (1963), «Причинная упорядоченность и идентифицируемость», у Андо, Альберт; Фишер, Франклин М .; Саймон, Герберт А. (ред.), Очерки структуры моделей социальных наук, Кембридж, Массачусетс: MIT Press, стр. 5–31..
- Саймон, Герберт А. (1973), «Организация сложных систем», в Патти, Ховард Х. (ред.), Теория иерархии: вызов сложных систем, Нью-Йорк: Джордж Бразиллер, стр. 3–27..
- Саймон, Герберт А. (1996), «Архитектура сложности: иерархические системы», Науки об искусственном, Кембридж, Массачусетс: MIT Press, стр. 183–216..
- Тонг, Фред М. (1969), «Иерархические аспекты компьютерных языков», в Уайте, Закон Ланселота; Уилсон, Альберт Дж .; Уилсон, Донна (ред.), Иерархические структуры, Нью-Йорк: American Elsevier, стр. 233–251..
Основное математическое определение
Пример слабо связанной структуры зависимостей. Направление причинного потока — вверх.
Для многомерной функции у=ж(Икс1,Икс2,…,Иксп){displaystyle y = f (x_ {1}, x_ {2}, dots, x_ {n})}, функциональная декомпозиция обычно относится к процессу идентификации набора функций {грамм1,грамм2,…граммм}{displaystyle {g_ {1}, g_ {2}, dots g_ {m}}} такой, что
- ж(Икс1,Икс2,…,Иксп)=ϕ(грамм1(Икс1,Икс2,…,Иксп),грамм2(Икс1,Икс2,…,Иксп),…граммм(Икс1,Икс2,…,Иксп)){displaystyle f (x_ {1}, x_ {2}, dots, x_ {n}) = phi (g_ {1} (x_ {1}, x_ {2}, dots, x_ {n}), g_ {2) } (x_ {1}, x_ {2}, точки, x_ {n}), точки g_ {m} (x_ {1}, x_ {2}, точки, x_ {n}))}
куда ϕ{displaystyle phi} это какая-то другая функция.[требуется разъяснение ] Таким образом, можно сказать, что функция ж{displaystyle f} раскладывается на функции {грамм1,грамм2,…граммм}{displaystyle {g_ {1}, g_ {2}, dots g_ {m}}}. Этот процесс по сути является иерархическим в том смысле, что мы можем (и часто делаем) стремиться к дальнейшей декомпозиции функций. граммя{displaystyle g_ {i}} в набор составляющих функций {час1,час2,…часп}{displaystyle {h_ {1}, h_ {2}, dots h_ {p}}} такой, что
- граммя(Икс1,Икс2,…,Иксп)=γ(час1(Икс1,Икс2,…,Иксп),час2(Икс1,Икс2,…,Иксп),…часп(Икс1,Икс2,…,Иксп)){displaystyle g_ {i} (x_ {1}, x_ {2}, dots, x_ {n}) = gamma (h_ {1} (x_ {1}, x_ {2}, dots, x_ {n}), h_ {2} (x_ {1}, x_ {2}, точки, x_ {n}), точки h_ {p} (x_ {1}, x_ {2}, dots, x_ {n}))}
куда γ{displaystyle gamma} это какая-то другая функция. Разложения такого рода интересны и важны по целому ряду причин. В общем, функциональная декомпозиция имеет смысл, когда существует определенная «разреженность» в структуре зависимостей; то есть, когда оказывается, что составляющие функции зависят приблизительно от непересекающиеся множества переменных. Так, например, если мы можем получить разложение Икс1=ж(Икс2,Икс3,…,Икс6){displaystyle x_ {1} = f (x_ {2}, x_ {3}, dots, x_ {6})} в иерархическую композицию функций {грамм1,грамм2,грамм3}{displaystyle {g_ {1}, g_ {2}, g_ {3}}} такой, что Икс1=грамм1(Икс2){displaystyle x_ {1} = g_ {1} (x_ {2})}, Икс2=грамм2(Икс3,Икс4,Икс5){displaystyle x_ {2} = g_ {2} (x_ {3}, x_ {4}, x_ {5})}, Икс5=грамм3(Икс6){displaystyle x_ {5} = g_ {3} (x_ {6})}, как показано на рисунке справа, это, вероятно, будет считаться очень ценным разложением.
Пример: арифметика
Базовым примером функциональной декомпозиции является выражение четырех двоичных арифметических операций сложения, вычитания, умножения и деления в терминах двух двоичных операций сложения. а+б{displaystyle a + b} и умножение а×б,{displaystyle a imes b,} и две унарные операции аддитивного обращения −а{displaystyle -a} и мультипликативная инверсия 1а.{displaystyle 1 / a.} Затем вычитание может быть реализовано как композиция сложения и аддитивной инверсии, а−б=а+(−б),{displaystyle a-b = a + (- b),} и деление может быть реализовано как композиция умножения и обратного умножения, а÷б=а×(1б).{displaystyle adiv b = a imes (1 / b).} Это упрощает анализ вычитания и деления, а также упрощает аксиоматизацию этих операций в понятии поле, так как есть только две двоичные и две унарные операции, а не четыре двоичных операции.
Расширяя эти примитивные операции, существует обширная литература по теме полиномиальное разложение.
Начало работы
Выберите значок дерева декомпозиции в области «Визуализация».
Для визуализации требуется два типа входных данных.
- Анализ — метрика, которую требуется проанализировать. Это должна быть мера или агрегат.
- Объяснение по — одно или несколько измерений, для которых требуется выполнить детализацию.
После перетаскивания меры в поле визуальные элементы обновляются, чтобы продемонстрировать агрегированную меру. В приведенном ниже примере мы визуализируем среднее % продуктов на заднем поле (5,07 %).
Далее требуется выбрать одно или несколько измерений, для которых необходимо выполнить детализацию. Добавьте эти поля в контейнер Объяснение по
Обратите внимание, что рядом с корневым узлом отображается знак «плюс». С помощью знака «плюс» можно выбрать, для какого поля нужно выполнить детализацию (вы можете детализировать поля в любом порядке)
Щелкните Forecast bias (Смещение прогноза), чтобы развернуть дерево и разбить меры по значениям в столбце. Этот процесс можно повторить, выбрав другой узел для детализации.
Если выбрать узел из последнего уровня, будет выполнена перекрестная фильтрация данных. Выбор узла на более раннем уровне приведет к изменению пути.
При взаимодействии с другими визуальными элементами осуществляется перекрестная фильтрация дерева декомпозиции. В результате порядок узлов в уровнях может измениться.
Чтобы показать другой сценарий, в приведенном ниже примере рассматривается продажи видеоигр по издателю.
Когда мы перекрестно фильтруем дерево по Ubisoft, путь обновляется для отображения продаж Xbox, перемещающихся с первого на второе место, превзошел PlayStation.
Если затем перекрестно отфильтровать дерево по Nintendo, продажи Xbox будут пустыми, так как игры Nintendo, разработанные для Xbox, отсутствуют. Xbox, а также его последующий путь, отфильтровывается из представления.
Несмотря на то что путь не отображается, существующие уровни (в нашем случае игровой жанр) остаются закрепленными в дереве. Таким образом, при выборе узла Nintendo дерево автоматически развертывается до уровня игрового жанра.
Пример декомпозиции целей
Приведём три варианта, в зависимости от её модели. Заметьте, что и у коммерческих предприятий, и у некоммерческих структур (вроде спортивных клубов, например) здесь наблюдается схожесть. Даже, казалось бы, — «какой у спортивного клуба продуктовый подход в целях?», однако у них продуктами могут быть виды спорта или их подвиды. А вот и сами примеры:
рис. по функциональному признаку. Нажмите для увеличения.
рис. по территориальному признаку. Нажмите для увеличения.
рис. по продуктовому признаку. Нажмите для увеличения.
Внимание! На рисунках изображены исключительно примеры в схематичных изображениях. В реальных документах выноски с комментариями отсутствуют
Специфика декомпозиционных процессов
Структурирование — основа всех методик декомпозиционного анализа. Создание стратегии для достижения целей вынуждает придерживаться определенных правил:
- Четкое следование иерархической системе, то есть подчинение низшего уровня более высокому. При этом каждый из них может быть связан только между собой и не иметь логического отношения к другим выше- или нижестоящим;
- Деление одной задачи на некоторое число подзадач по однотипному принципу;
- Разделение целей на этапы, каждому из которых присваивается процентное значение. Сумма всех значений должна равняться 100%;
- Глубина или видимость многоуровневой системы должна позволять на первом этапе визуально охватывать всю систему целиком.
Зачем декомпозировать
Понять, что и в каком порядке делать. «Добавить счётчик на страницу» кажется задачей для фронтенд-разработчика. Но на самом деле он сможет сделать свою часть, только когда будет готова база данных и АПИ — механизм, по которому эти данные подтягиваются на сайт.
Если фронтенд попробует сам предположить, как будет выглядеть запрос, то после интеграции могут всплыть непредвиденные баги: бэкенд мог реализовать АПИ не так, как думал фронтенд-разработчик. Декомпозиция поможет понять, с какой стороны подступиться и в какой последовательности двигаться.
Оценить сроки. Когда задача разложена на части, можно оценить по времени каждую и понять, сколько потребуется на всё вместе. Понятно, что не получится запустить счётчик за день, если только на базу данных и АПИ нужно два.
Упростить тестирование. Тестировать проще, когда понятно, что нужно проверить. В случае со счётчиком: базу данных, метод и вёрстку.
Расставить приоритеты. Декомпозиция может показать, что задача большая и требует времени. Например, если маркетолог хочет указать не только количество покупок, но и количество городов, в которые товар доставляли. Разработчик может показать, что делать всё вместе — две недели, но счётчик покупок можно выкатить быстрее. А маркетолог уже решит, как лучше поступить.
Метод 5: Декомпозиция по типам платформы/ОС.
Тут все довольно просто – критерием разбиения требований на составные части является необходимость реализации одного и того же функционала для разных платформ, устройств, операционных систем.
Например, нам необходимо разработать в веб-приложении функцию оплаты пользователем какой-то покупки. В этом случае можно декомпозировать требование на задачи по реализации функции покупки:
- Для разных платформ: персональные компьютеры, планшеты, смартфоны.
- Для разных ОС: Windows, iOS, Android.
- Для работы в различных браузерах.
Разбивая требование таким образом, может довольно легко выделить наиболее приоритетные направления для развития продукта и сфокусироваться на них в первую очередь. Например, вначале вы можем сосредоточиться на разработке мобильной версии приложения, а версию для десктоп оставить для более поздних релизов.
Заключение
В том или ином виде декомпозицию используют практически во всех отраслях человеческой деятельности. Простейшим примером может быть изготовление технических механизмов, в процессе которого выполняется сборка и увязка отдельных элементов. Однако далеко не всегда метод декомпозиции может быть столь же простым и понятным. В сложных системах возникают такие проблемы, как нарушение функционирования и взаимодействия отдельных подсистем между собой. Отсутствующий алгоритм соединения расщепленных блоков также является распространенной проблемой, в решении которой используют несколько вариантов реализации декомпозиции. На практике также не всегда удается выполнить расчленение системы до приемлемого уровня из-за нехватки базовых сведений о системе и ее свойствах.