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

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

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

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

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

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

Наши продукты помогают вашему бизнесу оптимизировать расходы на маркетинг

Визуализация декомпозиции

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

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

  • Miro (бывший RealTimeBoard);
  • XMind;
  • MindMeister;
  • MindJet Mindmanager;
  • Draw.io;
  • LucidChart.

Среди них есть простые и сложные, платные и бесплатные, для индивидуальной работы и коллективной.

Характеристики

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

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

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

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

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

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

Прежде всего, важно сформулировать ключевую идею цели.

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

Как известно, по данной технологии цель должна быть:

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

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

Затем все данные вносятся в систему управления проектами, CRM, таск-трекер или же формируется диаграмма Гантта. Команда приступает к реализации плана для достижения поставленной цели.

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

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

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

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

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

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

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

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

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

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

Сквозная аналитика

от 990 рублей в месяц

  • Автоматически собирайте данные с рекламных площадок, сервисов и CRM в удобные отчеты
  • Анализируйте воронку продаж от показов до ROI
  • Настройте интеграции c CRM и другими сервисами: более 50 готовых решений
  • Оптимизируйте свой маркетинг с помощью подробных отчетов: дашборды, графики, диаграммы
  • Кастомизируйте таблицы, добавляйте свои метрики. Стройте отчеты моментально за любые периоды

ПОЛИТИКА В ОТНОШЕНИИ ОБРАБОТКИ ПЕРСОНАЛЬНЫХ ДАННЫХ В ИП Жестков Н. В.

1. Общие положения

1.1. Политика в отношении обработки персональных данных (далее — Политика) направлена на защиту прав и свобод физических лиц, персональные данные которых обрабатывает ИП Жестков Н. В. (далее — Оператор).
1.2. Политика разработана в соответствии с п. 2 ч. 1 ст. 18.1 Федерального закона от 27 июля 2006 г. № 152-ФЗ «О персональных данных» (далее — ФЗ О персональных данных»).
1.3. Политика содержит сведения, подлежащие раскрытию в соответствии с ч. 1 ст. 14 ФЗ «Оперсональных данных», и является общедоступным документом.

2. Сведения об операторе

2.1. Оператор ведет свою деятельность по адресу 664009, г. Иркутск, ул. Ядринцева, 1/9, 70.
2.2. Руководитель Жестков Никита Владимирович (телефон +7 (964) 111-8758) назначен ответственным за организацию обработки персональных данных.
2.3. База данных информации, содержащей персональные данные граждан РоссийскойФедерации, находится по адресу: mailigen.ru, in-scale.bitrix24.ru, mail.yandex.ru, in-scale.ru, vk.com, facebook.com, manychat.com.

3. Сведения об обработке персональных данных

3.1. Оператор обрабатывает персональные данные на законной и справедливой основе для выполнения возложенных законодательством функций, полномочий и обязанностей, осуществления прав и законных интересов Оператора, работников Оператора и третьих лиц.
3.2. Оператор получает персональные данные непосредственно у субъектов персональных данных.
3.3. Оператор обрабатывает персональные данные автоматизированным и не автоматизированным способами, с использованием средств вычислительной техники и без использования таких средств.
3.4. Действия по обработке персональных данных включают сбор, запись, систематизацию,накопление, хранение, уточнение (обновление, изменение), извлечение, использование,передачу (распространение, предоставление, доступ), обезличивание, блокирование,удаление и уничтожение.
3.5. Базы данных информации, содержащей персональные данные граждан РоссийскойФедерации, находятся на территории Российской Федерации.

4. Обработка персональных данных клиентов

4.1. Оператор обрабатывает персональные данные клиентов в рамках правоотношений сОператором, урегулированных частью второй Гражданского Кодекса Российской Федерацииот 26 января 1996 г. № 14-ФЗ, (далее — клиентов).
4.2. Оператор обрабатывает персональные данные клиентов в целях соблюдения норм законодательства РФ, а также с целью:
— заключать и выполнять обязательства по договорам с клиентами;
— осуществлять виды деятельности, предусмотренные учредительными документами ИПЖестков Н. В.;
— информировать о новых продуктах, специальных акциях и предложениях;
— информировать о новых статьях, видео и мероприятиях;
— выявлять потребность в продуктах;
— определять уровень удовлетворённости работы.
4.3. Оператор обрабатывает персональные данные клиентов с их согласия,предоставляемого на срок действия заключенных с ними договоров. В случаях,предусмотренных ФЗ «О персональных данных», согласие предоставляется в письменном виде. В иных случаях согласие считается полученным при заключении договора или при совершении конклюдентных действий.
4.4. Оператор обрабатывает персональные данные клиентов в течение сроков действия заключенных с ними договоров. Оператор может обрабатывать персональные данные клиентов после окончания сроков действия заключенных с ними договоров в течение срока,установленного п. 5 ч. 3 ст. 24 части первой НК РФ, ч. 1 ст. 29 ФЗ «О бухгалтерском учёте» и иными нормативными правовыми актами.
4.5. Оператор обрабатывает следующие персональные данные клиентов:
— Фамилия, имя, отчество;
— Тип, серия и номер документа, удостоверяющего личность;
— Дата выдачи документа, удостоверяющего личность, и информация о выдавшем его органе;
— Год рождения;
— Месяц рождения;
— Дата рождения;
— Место рождения;
— Адрес;
— Номер контактного телефона;
— Адрес электронной почты;
— Идентификационный номер налогоплательщика;
— Номер страхового свидетельства государственного пенсионного страхования;
— Должность;
— Фотография.
4.6. Для достижения целей обработки персональных данных и с согласия клиентов Оператор предоставляет персональные данные или поручает их обработку следующим лицам:
— менеджер по продажам
— руководитель проекта
— менеджер проекта
— маркетолог

5. Сведения об обеспечении безопасности персональных данных

5.1. Оператор назначает ответственного за организацию обработки персональных данных для выполнения обязанностей, предусмотренных ФЗ «О персональных данных» и принятыми в соответствии с ним нормативными правовыми актами.
5.2. Оператор применяет комплекс правовых, организационных и технических мер по обеспечению безопасности персональных данных для обеспечения конфиденциальности персональных данных и их защиты от неправомерных действий:
— обеспечивает неограниченный доступ к Политике, копия которой размещена по адресу нахождения Оператора, а также может быть размещена на сайте Оператора (при его наличии);
— во исполнение Политики утверждает и приводит в действие документ «Положение об обработке персональных данных» (далее — Положение) и иные локальные акты;
— производит ознакомление работников с положениями законодательства о персональных данных, а также с Политикой и Положением;
— осуществляет допуск работников к персональным данным, обрабатываемым в информационной системе Оператора, а также к их материальным носителям только для выполнения трудовых обязанностей;
— устанавливает правила доступа к персональным данным, обрабатываемым в информационной системе Оператора, а также обеспечивает регистрацию и учёт всех действий с ними;
— производит оценку вреда, который может быть причинен субъектам персональных данных в случае нарушения ФЗ «О персональных данных»;
— производит определение угроз безопасности персональных данных при их обработке в информационной системе Оператора;
— применяет организационные и технические меры и использует средства защиты информации, необходимые для достижения установленного уровня защищенностиперсональных данных;
— осуществляет обнаружение фактов несанкционированного доступа к персональным данным и принимает меры по реагированию, включая восстановление персональныхданных, модифицированных или уничтоженных вследствие несанкционированного доступак ним;
— производит оценку эффективности принимаемых мер по обеспечению безопасностиперсональных данных до ввода в эксплуатацию информационной системы Оператора;
— осуществляет внутренний контроль соответствия обработки персональных данных ФЗ «Оперсональных данных», принятым в соответствии с ним нормативным правовым актам,требованиям к защите персональных данных, Политике, Положению и иным локальнымактам, включающий контроль за принимаемыми мерами по обеспечению безопасностиперсональных данных и их уровня защищенности при обработке в информационнойсистеме Оператора.

6. Права субъектов персональных данных

6.1. Субъект персональных данных имеет право:
— на получение персональных данных, относящихся к данному субъекту, и информации,касающейся их обработки;
— на уточнение, блокирование или уничтожение его персональных данных в случае, еслиони являются неполными, устаревшими, неточными, незаконно полученными или неявляются необходимыми для заявленной цели обработки;
— на отзыв данного им согласия на обработку персональных данных;
— на защиту своих прав и законных интересов, в том числе на возмещение убытков икомпенсацию морального вреда в судебном порядке;
— на обжалование действий или бездействия Оператора в уполномоченный орган позащите прав субъектов персональных данных или в судебном порядке.
6.2. Для реализации своих прав и законных интересов субъекты персональных данныхимеют право обратиться к Оператору либо направить запрос лично или с помощьюпредставителя. Запрос должен содержать сведения, указанные в ч. 3 ст. 14 ФЗ «Оперсональных данных».

УТВЕРЖДАЮ
Н. В. Жестков
29.06.2017

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

Как же провести декомпозицию требований в Product Backlog? Рассмотрим 8 техник, которые помогут эффективно выполнить разбивку требований на User Stories. В работе по Agile большим плюсом будет одновременное применение нескольких вариантов декомпозиции, поэтому важно представлять спектр возможных методов.

Зачем и в какой момент следует проводить декомпозицию требований?

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

  • Если в рамках итерации (спринта) мы работаем над несколькими большими и сложными задачами, то, во-первых, такие задачи будет сложно оценить с высокой точностью, во-вторых, недооценка даже одной из них может сильно повлиять на достижение целей спринта. Ведь не выпустить 1 из 2 запланированных фич, это сразу -50% полезного результата.
  • Мелкие и атомарные задачи напротив имеют не такое серьезное влияние на цели спринта, так как их больше планируется на спринт (а значит каждая имеет меньший вклад) и их оценка будет гораздо точнее.

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

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

Два основных подхода к декомпозиции.

Существует две концепции, два базовых подхода к декомпозиции крупных задач на пользовательские истории – «горизонтальное» и «вертикальное» разбиение:

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

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

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

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

Метод 1: Разбиение по этапам\фазам бизнес процесса.

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

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

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

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

Метод 2: Разбиение по позитивным и негативным сценариям.

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

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

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

В качестве примера декомпозиции требований на позитивные\негативные сценарии снова рассмотрим функцию покупки в интернет магазине:

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

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

Метод 3: Разбиение по правилам\условиям бизнес процесса.

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

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

Данный метод разбиения требований позволяет:

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

Метод 4: Разбиение по видам операций.

Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях. Эти операции можно отнести к разряду набора действий «по умолчанию»: создать, читать, обновить или удалить. Сокращенно метод называется CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.

На примере все того же интернет магазина можно сделать такую декомпозицию функциональности по работе с карточкой продукта:

  • Create — создание нового продукта в интернет магазине
  • Read — просмотр описания продукта
  • Update — редактирование\обновление описания продукта
  • Delete — удаление продукта из магазина

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

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

Метод 5: Декомпозиция по типам платформы/ОС.

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

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

  • Для разных платформ: персональные компьютеры, планшеты, смартфоны.
  • Для разных ОС: Windows, iOS, Android.
  • Для работы в различных браузерах.

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

Метод 6: Разбиение по типам данных и параметрам.

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

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

  • Поиск с использованием текста (наименование товара)
  • Поиск с использованием числовых значений (номер товара)
  • Поиск с использованием регулярных выражений

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

Метод 7: Разбиение по ролям\правам доступа.

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

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

  • Владелец интернет магазина:
    • Создание\удаление продукта в интернет магазине.
    • Просмотр и редактирование описания продукта.
  • Администратор интернет магазина:
    • Просмотр и редактирование описания продукта.
    • Отработка запросов\комментариев клиентов.
  • Клиент\покупатель:
    • Просмотр описания продукта.
    • Резерв\покупка товаров в интернет магазине.

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

Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.

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

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

  • Товар есть в наличии и он доступен покупки.
  • Товар есть в наличии, но он уже зарезервирован другим покупателем
  • Товара нет в наличии

Какие преимущества дает использование данного метода декомпозиции:

  • Эта стратегия фактически объединяет многие техники декомпозиции, которые были рассмотрены ранее. В процессе формирования списка тест-кейсов мы автоматически проанализируем:
    • Условия и правила бизнес процесса
    • Позитивные и негативные сценарии использования функционала
    • Форматы данных и параметров.
  • Анализируя тестовый сценарий легко понять насколько он распространен и вероятен в условия реального использования продукта, что позволяет выставить соответствующие приоритеты.
  • При таком способе разбиения мы сразу получаем и описание для задачи\пользовательской истории и сценарий, по которому можно проверить успешность ее реализации.

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

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

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

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

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

Рис. 5.3. Схема декомпозиции проекта

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

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

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

Иерархическая структура работ служит основой:

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

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

Существуют и другие способы построения иерархической структуры работ. Основы для построения ИСР:

  • — по фазам жизненного цикла;
  • — по ключевым результатам проекта (deliverables);
  • — по организационной структуре проекта (ключевым участникам);
  • — по источникам финансирования;
  • — по ключевым функциям проекта;
  • — по объектам управления проекта и др.

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

ГОСТ 34.601-40 «Автоматизированные системы. Стадии создания» имеет четкую иерархическую структуру для декомпозиции работ при разработке программного обеспечения: все восемь стадий разделены на этапы, а для каждого этапа определено содержание основных работ. Например, верхние уровни иерархии можно представить следующим образом:

  • 1. формирование требований к АС.
  • 1.1. Обследование объекта и обоснование необходимости создания АС.
  • 1.2. Формирование требований пользователя к АС.
  • 1.3. Оформление отчета о выполнении работ и заявки на разработку АС.
  • 2. Разработка концепции АС.
  • 2.1. Изучение объекта.
  • 2.2. Проведение необходимых научно -исследовательских работ.
  • 2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей.
  • 2.4. Оформление отчета о проделанной работе.
  • 3. Техническое задание.
  • 3.1. Разработка и утверждение технического задания на создание АС.
  • 4. Эскизный проект.
  • 4.1. Разработка предварительных проектных решений по системе и ее частям.
  • 4.2. Разработка документации на АС и ее части.
  • 5. Технический проект.
  • 5.Х. Разработка проектных решении по системе и ее частям.
  • 5.2. Разработка документации на А С и ее части.
  • 5.3. Разработка и оформление документации на поставку комплектующих изделии.
  • 5А. Разработка заданий на проектирование в смежных частях проекта.
  • 6. Рабочая документация.

А С и ее части.

Ь.2. Разработка и адаптация программ.

  • 7. Ввод в действие.
  • 7.Х. Подготовка объекта автоматизации.
  • 7.2. Подготовка персонала.
  • 7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно -техническими комплексами, информационными изделиями).
  • 7.4. Строительно -монтажные работы.
  • 7.5. Пусконаладочные работы.
  • 7.6. Проведение предварительных испытаний.
  • 7.7. Проведение опытной эксплуатации.
  • 7.2. Проведение приемочных испытаний.
  • 2. Сопровождение АС.
  • 2.Х. Выполнение работ в соответствии с гарантийными обязательствами.
  • 2.2. Послегарантийное обслуживание.

Допускается исключить стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в одну стадию «Технорабочий проект». В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.

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

Правила построения иерархической структуры работ:

  • — каждый элемент структуры представляет собой отдельный (единичный) осязаемый и проверяемый результат;
  • — каждый элемент ИСР представляет собой объединение всех связанных элементов непосредственно нижестоящего уровня;
  • — элемент ИСР может быть связан только с одним элементом непосредственно вышестоящего уровня;
  • — результаты проекта должны быть декомпозированы до уровня, который ясно показывает, каким образом эти результаты могут быть получены (разработаны, закуплены, произведены и т.д.);
  • — разделение элементов ИСР от самого высокого до низших должно иметь логические основания;
  • — результаты, соответствующие узлам ИСР, должны быть уникальными, отличными от других результатов;
  • — результаты должны быть четко сформулированы и должны исключать возможность дублирования работ;
  • — элементы ИСР должны четко ограничивать отдельные результаты, в то же время они не должны быть настолько малы, чтобы вызывать дополнительные трудности и издержки при контроле и управлении проектом;
  • — разработка структуры работ должна быть гибкой и динамичной для возможности изменения содержания проекта;
  • — каждый элемент ИСР, соответствующий результату работы, выполняемой сторонним исполнителем, должен быть тщательно согласован при составлении договора на выполнение работ для исключения изменения структуры работ;
  • — все результаты проекта должны явно присутствовать в иерархической структуре работ;
  • — ИСР должна быть совместимой с организационной структурой управления проекта, а также со структурами других проектов, реализуемых одновременно, и общей организационной структурой компании;
  • — система кодирования работ в ИСР должна четко показывать место работы во всей структуре.

Упражнение

Составите иерархическую структуру работ для некоторого проекта. Сколько уровней детализации у вас получилось’1 Можно ли разделить элементы нижнего уровня?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Генеральная цель проекта

Подцель проекта А

подцель проекта А1

подцель проекта А2

подцель проекта А3

Подцель проекта В

подцель проекта В1

подцель проекта В2

подцель проекта В3

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

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

Литература

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