Декомпозиция что это такое
Декомпозиция задач: что это и зачем нужно
И как сделать так, чтобы всё шло по плану.
Приходит маркетолог интернет-магазина к разработчику с задачей:
Для маркетолога это одна строчка текста. Он думает, что такую простую задачку можно сделать за 15 минут. А разработчик пожимает плечами: «Подумаю, потом назову срок». Что за дичь? А вот так.
Прежде чем эту задачу делать, её было бы неплохо декомпозировать — то есть понять, из чего она состоит, на что влияет и в каком порядке её стоит делать. В случае со счётчиком покупок это получится такой набор подзадач:
В зависимости от архитектуры системы могут быть и другие действия. Поэтому назвать срок сразу разработчик не может: сначала надо понять, что вообще нужно делать и сколько времени займёт каждый пункт.
Чем крупнее задача, тем сложнее обойтись без декомпозиции. «Покрасить кнопку в красный» можно не раскладывать. А «Добавить новый раздел в админку» точно стоит сначала разобрать по частям: тут работа и для фронтенда, и для бэкенда. Декомпозиция нужна не всегда, но очень часто.
Была одна большая задача, стало несколько маленьких.
Зачем декомпозировать
Понять, что и в каком порядке делать. «Добавить счётчик на страницу» кажется задачей для фронтенд-разработчика. Но на самом деле он сможет сделать свою часть, только когда будет готова база данных и АПИ — механизм, по которому эти данные подтягиваются на сайт.
Если фронтенд попробует сам предположить, как будет выглядеть запрос, то после интеграции могут всплыть непредвиденные баги: бэкенд мог реализовать АПИ не так, как думал фронтенд-разработчик. Декомпозиция поможет понять, с какой стороны подступиться и в какой последовательности двигаться.
Оценить сроки. Когда задача разложена на части, можно оценить по времени каждую и понять, сколько потребуется на всё вместе. Понятно, что не получится запустить счётчик за день, если только на базу данных и АПИ нужно два.
Упростить тестирование. Тестировать проще, когда понятно, что нужно проверить. В случае со счётчиком: базу данных, метод и вёрстку.
Расставить приоритеты. Декомпозиция может показать, что задача большая и требует времени. Например, если маркетолог хочет указать не только количество покупок, но и количество городов, в которые товар доставляли. Разработчик может показать, что делать всё вместе — две недели, но счётчик покупок можно выкатить быстрее. А маркетолог уже решит, как лучше поступить.
Как декомпозировать
Декомпозировать можно по-разному, это зависит от масштаба и сути задачи.
Например, запуск мобильного приложения можно декомпозировать сначала на уровне платформ: iOS и Android. Потом — на уровне пользовательских сценариев: регистрация, просмотр контента, покупка, переписка с контактами. Сценарии можно разложить на интерфейс и серверную часть. А их — на отдельные конкретные задачи.
Чаще всего задачи раскладывают вертикально и горизонтально. Вертикально — значит по типам работ. Горизонтально — значит вглубь одного типа работы. Вот как это работает со счётчиком покупок в интернет-магазине:
Вертикальная декомпозиция:
Бэкенд: считать количество покупок и отдавать данные на фронт.
Фронтенд: запрашивать данные при загрузке страницы и выводить.
Горизонтальная декомпозиция:
Кто должен декомпозировать
Декомпозировать задачу может сам разработчик, тимлид, менеджер проекта или другой компетентный сотрудник: универсальных правил здесь нет. Руководитель службы разработки Яндекс.Практикума Александр Трегер рассказывает, как это работает у них:
Когда появляется новая большая задача, один из опытных разработчиков берёт её на себя. С этого момента он за неё отвечает: собирает встречи, даёт заказчикам обратную связь, определяет, как решить задачу, декомпозирует её. Для разработчиков это возможность расширить свою зону ответственности, попробовать себя в роли архитектора и менеджера проекта.
Иногда нужно выделить время и разобраться в задаче, подумать про пограничные случаи, изучить технологию, придумать решение. Бывает, что на этом этапе задача может разделиться на несколько этапов: что делаем сейчас, а что потом. Так было, например, с проверкой домашних работ от студентов: сначала они приходили в виде архива на проверку, потом появился полноценный интерфейс для ревью кода. Система будет развиваться и дальше, но декомпозиция помогает понять, что и в какой последовательности можно сделать, чтобы быстрее получить результат.
👉 Почитайте полное интервью с Александром Трегером. Там больше подробностей о разработке Практикума.
Декомпозиция целей
Когда перед человеком возникает большая задача, он часто теряется и тратит много времени на ее выполнение. Современный тайм-менеджмент предлагает эффективный путь достижения комплексных целей — декомпозицию.
Декомпозиция — это дедуктивный метод разбивки объемной главной цели на простые промежуточные этапы, которые требуют минимум времени для их прохождения. Простым языком, это разделение сложного объекта на элементарные составляющие. В идеале, на решение задачи низшего уровня тратится не более 2 часов.
Зачем нужна декомпозиция?
Методика применяется во многих сферах, в том числе для планирования в крупных холдингах, государственных организация и даже на международном уровне. Такой подход облегчает понимание бизнес-процессов, итоговой цели, методов ее достижения, а также упрощает и ускоряет механизм внедрения исполнителями.
Декомпозиция — это обычный способ мышления, когда мы мысленно разделяем проект на составные части, применим для проектов большего масштаба. Осознанное использование стратегии дает возможность заранее определить необходимые ресурсы, навыки и сроки для реализации каждого подуровня.
Главные плюсы декомпозиции
Декомпозиция цели по системе Брайана Трейси
В бизнесе широко применяется составление декомпозиции цели по методике Брайана Трейси, которая показала себя отличным инструментом для личностного роста, развития компании и эффективной адаптации желаемого к реальной действительности.
По мнению известного бизнес-тренера путь к глобальной цели разбит на 12 шагов:
Основное отличие Брайана Трейси заключается в применении психологических приемов, что значительно усиливает продуктивность метода. По его мнению достижение результатов в любом деле невозможно при отсутствии хотя бы одного из обязательных условий:
Другие методы декомпозиции целей
Порядок действий при выборе этого метода:
Такой цикл позволяет подстраиваться под изменчивые условия и кардинально менять ход выполнения, однако он неприменим для стратегического планирования.
7 принципов декомпозиции
Как рассчитывается результат декомпозиции цели?
Какой бы вид не был принят для работы, результат декомпозиции цели представляет собой четкую иерархическую структуру, состоящую из нескольких уровней, где верхний — это итог и база для формирования звеньев цепи. Количество звеньев и ветвей в структуре отличается и напрямую зависит от конечной задачи. К тому же расщепление задачи подразумевает не только выделение отдельных блоков, но и связь между ними. Поэтому при расчете результата и составлении структуры нужно проработать этапы перехода от одной задачи к другой.
В конечном итоге вы получите список простых заданий, следующих друг за другом, на выполнение которых требуется минимум времени. Помните о необходимости заранее заложить дополнительный срок на форс-мажор и возможность корректировки последующих действий.
Советы по декомпозиции
Выводы
Инструменты декомпозиции целей — это простой и эффективный способ разработки конкретного плана действия и четкого распределения абстрактных перспектив «по полочкам». Вы можете применять ее не только в жизни и организации рабочего времени, но и для осуществления стратегического планирования целей предприятия с четкой оценкой необходимых ресурсов. К тому же, применение методики не требует узкоспециализированных знаний и заложено в нашу привычную схему мышления, что делает процесс комфортным.
Хочешь получать еще больше полезных материалов, информацию о бесплатных вебинарах, скидках и новых курсах Like Центра?
Оставь свой email 😉
Like Centre — это не просто компания, занимающаяся созданием образовательных курсов, это настоящее сообщество предпринимателей, которые нацелены на развитие и готовы внедрять новые подходы ведения бизнеса.
Блог Лайк Центра помогает молодым стартаперам и опытным владельцам бизнеса черпать свежие идеи, первыми узнавать об эффективных инструментах и способах масштабирования своего дела. Это платформа для смелых, инициативных предпринимателей, которые не боятся рисковать, но риск этот должен быть оправданным и обоснованным.
В блоге в свободном доступе находится информация, которая помогает:
Мир меняется очень быстро, завладеть вниманием потребителя становится не так просто как раньше. Поэтому Лайк Центр делится актуальной информацией, которая помогает держать руку на пульсе и всегда оставаться в курсе изменений на рынке. При этом не забывает и об основных постулатах — нетленном своде правил, который помогает становлению и развитию бизнеса.
Новые технологии, маркетинговые приемы, дополненная реальность, соцсети с молниеносно изменяющимися алгоритмами — все это способно поставить в тупик. Поэтому Like Centre взял на себя обязательство пролить свет на все важные аспекты построения успешной компании, которая уверенно занимает высокие позиции на современных рынках, быстро подстраивается под нестабильную обстановку и неизменно выходит на новый уровень даже в кризисное время.
Безусловно, поддержка бизнеса не строится только на статьях из блога. «Лайк Центр» предлагает и обучающие курсы ведения бизнеса, которые содержат не только полезную информацию, но и реальные кейсы по выведению компании из кризиса, максимизации ее прибыли и решению других глобальных проблем.
Обучение ведения бизнеса подойдет тем, кто готов последовательно прилагать усилия, хочет всегда оставаться в курсе последних новостей и не бояться внедрять тенденции в работу.
Like Centre blog — это база знаний, позволяющая рассмотреть проблемы комплексно, оперативно их выявить и решить. А для тех, кто готов продвинуться дальше, Лайк Центр готов оказать помощь в ведении бизнеса в Москве и любом другом регионе России.
В блоге мы много рассказываем об этом, но лучше один раз попробовать самостоятельно. За 3 дня мы дадим все инструменты, чтобы начать. Четко, структурировано. Ничего лишнего.
Декомпозиция
Добавлено в закладки: 0
Что такое декомпозиция? Описание и определение термина
Декомпозиция – это научный метод исследования, вследствии которого определяется структура задачи, и одна большая задача заменяется несколькими небольшими задачами, которые взаимосвязаны друг с другом.
В конечном итоге эти задачи решаются гораздо проще.
С помощью декомпозиции любая подвергающаяся исследованию система, может быть условно разделена на несколько более мелких, но взаимосвязанных систем, которые, при необходимости, и далее могут подвергаться разделению.
Рассмотрим более детально, что значит термин декомпозиция.
Суть декомпозиции
Декомпозиция является основой любого аналитического процесса или просто анализа.
Это процесс упрощения чего-либо без потери целостности.
Декомпозиция – это действие, посредством которого расчленяется что либо цельное, при выполнении поставленных задач в различных областях деятельности. Декомпозиция, как процесс расчленени
я, делает возможным рассматривать любую исследуемую систему как сложную, которая состоит из отдельных взаимосвязанных подсистем, а они, в свою очередь, также могут быть расчленены на части. Как вариант систем могут выступать не только материальные объекты, но также и процессы, явления и понятия.
Декомпозиция позволяет рассматривать предстоящую деятельность по частям, при этом каждая деталь процесса важна и учитывается.
Начальная система располагается на нулевом уровне. После её расчленения получаются подсистемы первого уровня. Разделение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и так происходит дальше. Но при этом есть необходимое условие – вычленяемые подсистемы не должны взаимно исключать друг друга. Например, если при перечислении частей автомобиля опустить, допустим, мотор, то функциональное взаимодействие остальных подсистем не обеспечит нормальное функционирование всей системы (автомобиля) в целом. Степень подробности описания и количество уровней определяются требованиями обозримости и удобства восприятия получаемой иерархической структуры и её 
соответствия уровню знания работающему с ней специалисту. Число уровней иерархии всегда влияет на обозримость структуры: много уровней — задача трудно обозримая, мало уровней — возрастает число находящихся на одном уровне подсистем и тогда бывает сложно установить между ними связи.
Виды декомпозиции
Декомпозиция бывает разных видов: объектная, функциональная, структурная, по физическому процессу.
Одним из важных и обязательных условий декомпозиции – иерархическое подчинение нижних уровней верхним уровням. Также следует помнить, что декомпозиция не меняет сути декомпозируемого объекта или явления, а лишь уточняет его, упрощает, помогает снять неопределенность или локализовать ее.
Основным методом декомпозиции целей является переход от общего к частному. Например, дедукция является той основой, которая формирует всю сущность декомпозиции.
Но также можно выделить и обратную (индуктивную) форму, где частные моменты образуют общности. Это процесс, обратный декомпозиции можно назвать агрегированием целей или композицией. Только такой метод характерен в проектировании инженерных систем, программировании и/или в создании программного обеспечения, а никак при выстраивании целевой структуры организации.
Мы коротко рассмотрели термин декомпозиция, постарались раскрыть его главные особенности и виды.
Оставляйте свои комментарии или дополнения к материалу.
Декомпозиция. Как разобрать огромный проект на понятные сегменты для предварительной оценки
Вот притащили вам с охоты мамонта: выше вас ростом, упитанный и на вид пока несъедобный. Что делать?! Декомпозировать, конечно: лапы отдельно, шкуру отдельно. Но с чего начать? И когда хоть примерно будет готов ужин?
Если вам достался жирненький проект, вопросы примерно такие же — какой круг задач предстоит, и как их предварительно оценить. Декомпозиция — крутой способ разложить всё по полочкам и прикинуть объём работ, заложить резервы на трудные блоки и докопаться до неприятных задач со звездочкой. Как это сделать, мы уже рассказывали в одном из обучающих видео. А для любителей вдумчивого чтения мы преобразовали его в крутую статью.
Уровни декомпозиции
Казалось бы, проще простого: режем проект на большие части, эти части — ещё на части, а те части — снова на части. Но действительно ли всё так просто?!
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-канал за новыми полезными видео для проджектов (и не только)!