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

Что такое декомпозиция целей

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

Что такое цель?

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

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

Понятие декомпозиции целей

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

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

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

Основные преимущества декомпозиции целей

Поставленные задачи проще решать

Представьте себе, что вместо цели «Разбогатеть» будет цель «Повысить доход до 500 тысяч»? А если еще точнее: «Сменить профессию и повысить доход до 500 тысяч в 2022 году». А можно поделить цель на более мелкие части:

Записаться на курсы по программированию (data-science, английский язык, SMM и т.п.).

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

Заниматься обучением каждый день по 2 часа.

Устроиться стажироваться/найти заказчиков на фрилансе.

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

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

Становится проще ориентироваться

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

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

Легче планировать новые задачи

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

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

Такой подход дает большое преимущество при работе в команде. Можно уверенно говорить о том, когда будет выполнен тот или иной этап работы. Неопределенность больше не будет мешать общему прогрессу.

Проще находить ресурсы для решения поставленных задач

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

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

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

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

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

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

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

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

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

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

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

Как реализовать декомпозицию

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

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

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

Пошаговая декомпозиция

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

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

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

Декомпозиция за счет изменяющихся показателей

Это почти та же пошаговая стратегия, только мерилом становятся не временные отрезки, а количественные значения.

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

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

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

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

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

Интеллект-карты

Брейнсторминг – распространенный метод генерации идей. Его же можно использовать в более размеренной манере и расширить на работу с масштабными проектами.

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

Поэтому использование интеллект-карт в качестве инструмента для декомпозиции позволяет сосредоточиться на решении мелких задач перед переходом к более крупным.

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

Декомпозиция в один шаг

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

Декомпозиция в один шаг работает следующим образом:

Сначала вы формируете глобальную цель.

Потом из нее извлекаете какой-то один этап.

Разбиваете этот этап на несколько дополнительных шагов.

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

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

Технология S.M.A.R.T

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

Аббревиатура S.M.A.R.T расшифровывается следующим образом:

S – Specific (Конкретность). Это то, о чем мы говорили выше. Задача должна быть описана понятным языком и точно, чтобы не возникло недопониманий.

M – Measurable (Измеримость). По методике S.M.A.R.T у задачи обязательно должен быть способ измерения степени ее завершенности.

A – Attainable (Достижимость). Нужно ставить себе реальные цели, реализуемые для вас лично или вашего бизнеса.

R – Relevant (Актуальность). Важно понимать, насколько задача релевантна в текущий момент времени. Действительно ли ее необходимо выполнить в этот момент.

T – Time-Bound (Своевременность). Технология S.M.A.R.T требует указывать точные сроки выполнения задачи при целеполагании.

Многие корпорации и предприниматели используют S.M.A.R.T, чтобы не наставить себе абстрактных целей и четко выполнять поставленные задачи.

Оценка результатов по итогам декомпозиции

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

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

Вместо заключения

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

Источник

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

Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?

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

Уровни декомпозиции

Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!

1 уровень. Крупные блоки или компоненты

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

2 уровень. Страницы сайта или экраны мобильного приложения

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

Для e-commerce основной сценарий — продавать, а путь пользователя в нём выглядит так: каталог → список товаров → карточка товара и так далее.

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

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

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

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

3 уровень. Содержание экранов

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

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

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

Откуда эта хрень на странице?!

Итак, вы добрались до какого-то блока или страницы. Самое время задать себе вопрос «Откуда это на странице?!». Но проджекты, аналитики и аккаунт-менеджеры (и даже заказчики) вот тут часто-часто ленятся — «подумаем об этом потом».

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

Чем меньше вы понимаете в момент «Откуда это на странице!?», тем больше у вас должен быть зазор в смете. И когда к вам приходит клиент и говорит «а почему тут такой большой зазор?!», у вас должен быть готовый ответ — потому что вы не понимаете, как работает то, то и это (лучше — фиксированный перечень конкретных вопросов), и что эти вопросы вы будете выяснять вместе с ним позже.

Итак, какими могут быть варианты, откуда берутся данные на странице?

Вариант 1. Хардкод

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

Вариант 2. Включаемая область

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

Вариант 3. Из админки (из базы данных)

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

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

Например, это формула

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

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

Видите формулу — копайте глубже. У неё внутри есть коэффициенты — а откуда берутся эти коэффициенты? Добро пожаловать в новый виток расследования «Откуда эта хрень на странице!?».

Вот из-за этого о формулах никто не любит думать:)

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

Очень часто файлы в самой базе данных не хранятся, чтобы не «раздувать» её. Из-за этого работа с ними организована иначе. В случае банального каталога товаров файлом может быть фотография у пользователя (userpic), описания, спецификации в pdf и всё такое прочее. Такие файлы находятся не совсем в базе, но при оценке важно понимать, что они есть.

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

— Владимир Завертайлов, CEO & Founder

Как данные попадают в базу данных?

Обычно администратор или контент-менеджер садится и забивает данные ручками. Тогда здесь должен возникать вопрос, а хватит ли ему стандартных компонентов админки для этого. Для этого ПМ должен быть очень хорошо знаком с возможностями стандартной административной панели. А ещё с ними должен быть знаком аналитик и тестировщик (про кодера, понятно, молчим). В Сибирикс все QA-специалисты проходят базовый курс контент-менеджера, чтобы понимать, на что способна админка. Ну, а про то, что QA-спецы у нас обычно вырастают в проджект-менеджеров, мы уже как-то писали.

У вас на дизайне есть слайдер, где расставлены точки, по клику на которые открывается всплывашка, в которой есть фотография, описание и ссылка на куда-нибудь. Вопрос: как расставлять эти точки? Как вариант — координаты X и Y, но вряд ли контентщик будет счастлив от такого функционала. А значит, придётся что-то придумывать. И значит, в смету нужно это заложить.

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

Вариант 4. Интеграция со сторонним ресурсом

Один из источников данных в базе — пользовательский контент. И здесь важно понимать, как он попадает в базу. На этом этапе часто теряется один из крупных сценариев: например, как пользователь вносит отзывы. У отзывов часто бывает рейтинг — штука с виду простая, но внутри она может быть довольно сложно организована. У чего больше рейтинг? Там, где поставили одну оценку в 10 баллов, или где 1000 оценок, но разных? Среднеарифметическое тут работает плохо. Но хитрые алгоритмы есть — привет, ещё один резерв в смете.

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

Другая проблема — админы сайтов, с которым парсятся данные, не слишком счастливы, что эти данные кто-то «ворует», и будут всячески защищаться. А это приводит к «падению» парсинга и попаданию в черные списки. Вы попытаетесь с этим бороться добавлением каких-нибудь платных proxy — короче, целый квест. Есть особые сервисы для организации парсинга — например, Mozenda, Automation Anywhere, Beautiful Soup, WebHarvy или Content Grabber (полный список из 30 сервисов ищите тут).

Здесь имеется ввиду, что есть какой-то интеграционный протокол, либо файловый протокол, либо XML, либо шина данных (сервер очередей вроде RabbitMQ, ZerroMQ или Apache Kafka) — подробнее о разнице штатной интеграции и по API наш техдир рассказывает тут. С чем именно интегрировать и по какому протоколу, на этапе предварительной оценки не столь важно — важнее, есть ли для этого документация. А у неё обычно бывает два состояния:

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

Соответственно, если на проекте планируется интеграция с внешним сервисом, на неё нужно закладывать большие резервы. Лайфхак, если нужно интегрироваться, а протокола пока нет — делать MOCK-объекты. Это специальные заглушки для интеграционного протокола, которые можно быстро сделать. А как только будет реальный протокол — просто заменить их (но обязательно с перепроверкой).

Как все это «подружить»

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

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

Когда это может не сработать

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

Успехов в декомпозиции и почаще заглядывайте к нам на YouTube-канал за новыми полезными видео для проджектов (и не только)!

Источник