Декомпозиция цели это – что это такое, для чего проводится, инструменты и примеры

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

22 06 2015      Редактор       5 комментариев

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

 

Оглавление статьи

Характеристики и понятие темы
Методы декомпозиции целей
Декомпозиция дерева целей
Пример декомпозиции целей
Декомпозиция целей проекта
Вывод по статье

---

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

Характеристики и понятие темы

---

В случае с целями имеет следующие характеристики:
Надо понимать, что декомпозиция ради неё же самой никому не нужна. Она имеет три характеристики, а именно:

1. Разделение;
2. Достижение;
3. Распределение.

Из них попытаемся сложить определение:

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

Грубо говоря, она является подробной расшифровкой вышестоящего уровня.

 

Продемонстрируем пример:

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

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

 

Методы декомпозиции целей

---

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

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

 

Декомпозиция дерева целей

---

Начнём сначала, а именно с декомпозиции стратегических целей

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

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

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

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

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

Вернёмся к признакам и приведём варианты декомпозиции по ним…

Пример декомпозиции целей

---

Приведём три варианта,  в зависимости от её модели. Заметьте, что и у коммерческих предприятий, и у некоммерческих структур (вроде спортивных клубов, например) здесь наблюдается схожесть. Даже, казалось бы, — «какой у спортивного клуба продуктовый подход в целях?», однако у них продуктами могут быть виды спорта или их подвиды.
А вот и сами примеры:

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

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

 

рис. по продуктовому признаку. Нажмите для увеличения.

 

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

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

---

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

Генеральная цель проекта
	Подцель проекта А
		подцель проекта А1
		подцель проекта А2
		подцель проекта А3
	Подцель проекта В
		подцель проекта В1
		подцель проекта В2
		подцель проекта В3

Вывод по статье

---

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

Литература

1.    Пригожин А.И. Цели и ценности. Новые методы работы с будущим, М.: Дело, 2010;
2.    Коллектив авторов Руководство PMBOK Третье издание Издатель: Project Management Institute Inc., 2004;
3.    Медоуз Донелла  Азбука системного мышления М.: Бином. Лаборатория знаний,  2011.

stratego.ru

Достижение цели: декомпозиция по принципам SMART

Доброго времени суток, читатели блога Твое Решение!
Поздравляю вас с новым 2017 годом!

Январь — лучшее время подвести итоги прошедшего года и определиться с целями на новый год. А вы уже начали работать над своими целями? Очень часто первую половину года мы думаем что еще успеем определиться с целями и их реализовать, а вторую половину года — понимаем, что опоздали.

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

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

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

Наиболее удобным инструментом для проведения декомпозиции цели являются интеллект-карты. Еще их называют ментальные карты или mind-maps. Я пользуюсь бесплатной программой XMind.  Хотя в принципе для проведения декомпозиции достаточно простого листа бумаги и ручки.

Итак, записываем нашу цель на листе бумаги или в программе и задаем себе два простых вопроса:

1. Что для этого необходимо сделать?
2. Могу ли я это сделать прямо сейчас?

Например, ваша цель на год — написать дипломную работу. Задаем вопрос: что мне необходимо для этого сделать?
Например, выбрать тему диплома, написать план и найти источники информации для работы.

Задаем себе второй вопрос: могу я выполнить это сейчас? Если да, то разбивка данной ветки окончена, если -нет, то снова задаем себе первый вопрос.

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

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

SMART:

S — конкретная, т.е постановка цели должна быть конкретна и ясна,

M — измеримая, т.е результат выполнения цели должен быть измеримым,

A — ориентированная на конкретные действия,

R — реалистичная, уместная, полезная и ориентированная на конкретные результаты,

T — на определенный период, своевременная, отслеживаемая. Срок выполнения цели должен быть определен конкретной датой или периодом.

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

1. формулируем намерение (S)
2. определяем критерии или показатели, по которым в будущем можно будет оценить достижение цели (M)
3. формулируем достижения, т.е конкретные параметры критериев или показателей (A)
4. определяем перечень задач (дело, разовое или регулярное, выполнение которого займет от 15 минут до 1,5-2 ч) для достижения конкретных параметров (R)
5. определяем временной ресурс (T)
6. запускаем цикл контроля, выстраивая систему измерения ключевых показателей.

Наглядно это выглядит следующим образом:

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

 

Увеличенный вариант изображения можно скачать здесь.

Предложенная декомпозиция цели — улучшить свое здоровье- легла в основу моего личного проекта «Затачиваем пилу», который я реализую уже не первый год.

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

1. Четкий пошаговый план реализации цели от квартального плана до чек-листа на день

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

2. Организация эффективного контроля достижения цели

   Декомпозиция с использованием принципов SMART выстраивает взаимосвязь показателей целей и выполнения задач, задает критерии или показатели достижения цели

3. Расчет времени и прочих ресурсов, необходимых для достижения цели

   Четко определяет какой объем выполненных задач и какие конкретные показатели должны быть достигнуты к конкретному времени

4. Оценка реалистичности цели и ее корректировка

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

   Часто мы переоцениваем то, что можем сделать за день и недооцениваем то, что можем сделать за год

Надеюсь, предложенный метод декомпозиции цели по принципам SMART поможет вам в достижении своих целей. Рекомендую также для постановки и достижения своих целей воспользоваться сервисом Smart Progress.

Вспомните, какие обещания вы дали себе в Новый Год под бой курантов?

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

Начни прямо сейчас! И это будет ТВОЕ РЕШЕНИЕ!

Понравилась статья? Буду признательна, если поделитесь этой статьей в социальных сетях!
Подпишитесь на обновления блога, чтобы не упускать полезные знания!

Читайте еще:

tvoe-reshenie.com

Декомпозиция — это… Что такое Декомпозиция?

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

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

Правила декомпозиции

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

Каждое расчленение образует свой уровень

Рис.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 уровней.
Например, разрабатывая механический привод, в качестве элементарного уровня можно взять колеса, валы, подшипники, двигатель в целом. Хотя подшипники и двигатель являются сложными по устройству элементами и трудоемкими в проектировании, но как готовые покупные изделия для разработчика они выступают в виде элементарных частей. Если бы двигатель пришлось бы разрабатывать, то его, как сложную систему, было бы целесообразно декомпозировать.

Декомпозиция и эвристика

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

Декомпозиция в технике

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

Декомпозиция в теории систем

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

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

См. также

Литература

dic.academic.ru

Планирование и декомпозиция целей, определение состава операций.

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

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

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

1. потребности, для выполнения которых проект осуществляется;

2. результаты проекта, т.е. перечень продукции, выпуск которой будет означать выполнение проекта;

3. описание продукта проекта;

4. измеримые критерии успеха.

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

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

Декомпозиция целей позволяет:

1. повысить точность стоимостных, временных и ресурсных оценок;

2. создать основу для измерения результатов и управления исполнением проекта, в том числе и для применения методики освоенного объема;

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

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

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

1. Определить главную цель проекта.

2. Разложить главную цель на составляющие элементы — подцели.

3. Каждую из подцелей разложить на более детальные составляющие до нужного уровня детализации.

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

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

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

7. Проверить корректность декомпозиции, для чего определить:

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

• определена ли каждая операция или требует дальнейшего уточнения;

• допускает ли каждая операция нижнего уровня назначение ресурсов и вычисление стоимости;

• соответствует ли структура работ проекта требуемой структуре отчетности (агрегированию информации).

В результате выполнения данной последовательности будет получено дерево целей проекта, которое соответствует составу фаз проекта. Такое дерево в управлении проектами принято называть Иерархической структурой работ ИСР (Work Breakdown Structure – WBS). Это — сердце проекта.

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

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

ИСР представляют либо в виде диаграммы либо в виде списка с признаком принадлежности к определенному уровню структуры.

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

1. ИСР по объектам. В этом случае цель проекта на верхнем уровне разбивается по объектам, а затем по процессам.

2. ИСР по процессам – противоположна предыдущей.

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

studfile.net

это что? Декомпозиция целей. Значение слова «декомпозиция»

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

Определение

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

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

Особенности

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

1) Всегда должна быть соблюдена уровневая система.

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

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

Руководствуясь простой формальной алгеброй и логикой можно также строить «деревья И» и «деревья ИЛИ».

2) Расчленение целого на части должно происходить только по одному признаку.

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

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

3) Все подсистемы декомпозиции должны раскрывать суть системы.

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

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

4) Глубина декомпозиционной проработки должна быть определена на начальном этапе.

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

Классификация

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

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

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

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

Анализ действий

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

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

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

Классический прием

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

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

Применение в бизнесе

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

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

Пример декомпозиции

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

Далее следуют подразделы:

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

Разделы и подразделы проектной и рабочей документации – это подзадачи третьего уровня.

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

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

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

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

fb.ru

Как 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

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

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

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

Правила декомпозиции[ | ]

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

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

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

ru-wiki.ru