Меню

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

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

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

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

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

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

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

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

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

Сама по себе задача «построить дом» кажется очень комплексной. Пока мы не разобъем ее на понятные составляющие, скорее всего нам будет очень непросто взяться за ее выполнение, так как мы даже не понимаем, с чего начать. Можно упростить себе задачу, декомпозиров ее на листе бумаги или в вашем таск-менеджере.

Первый уровень декомпозиции:

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

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

Источник

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

image

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

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

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

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

image

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

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

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

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

Пример

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

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

image

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

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

image

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

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

image

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

Читайте также:  Основные понятия и законы кинематики

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

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

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

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

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

image

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

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

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

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

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

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

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

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

Пример

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

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

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

image

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

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

Парсинг — не самая приятная тема. Когда вам говорят «сходите за этими данными на сторонний ресурс и аккуратненько всё своруйте», заканчивается это чаще всего плохо. А когда еще этих ресурсов 10−15−20, — тогда вообще смерть. Потому что данные или структура на них, как правило, могут меняться, а вы об этом узнаете в самую последнюю очередь, когда всё уже отвалится.

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

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

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

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

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

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

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

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

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

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

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

Источник



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

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

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

Зачем нужна декомпозиция?

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

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

Главные плюсы декомпозиции

  • Разбивка стратегической задачи на простые этапы.
    Разделение сложного проекта на цепочку выполняемых этапов уменьшает вероятность прокрастинации и дает четкое понимание направления движения. Задача «съесть слона» трудновыполнимая для простого сотрудника, но персонал эффективно справится с цепочкой «нарезать слона на куски» – «приготовить бифштекс» – «съесть». От сложности итоговой задачи напрямую меняется количество уровней.
  • Оценка реалистичности цели и сроков ее достижения.
    Во время декомпозиции целей предприятия четко видны все необходимые шаги и время их реализации, что делает возможным сдвиг дедлайна. Например, становится понятно, что нельзя увеличить производство на 10 000 единиц за неделю, если текущий максимум — 5к, а установка доп.оборудования и поиск сотрудников требуют времени.
  • Составления конкретного пошагового плана воплощения.
    Решение абстрактного стратегического вопроса превращается в цепочку шагов и конкретный план действий по внедрению идеи.
  • Подробный анализ необходимых ресурсов.
    В процессе разделения становится четко видно, какие инструменты, навыки и компетенции потребуются на каждом этапе, что позволяет провести точную оценку затрат и правильно распределить резервы.
Читайте также:  Маркировка IPhone определяем тип айфона новый восстановленный подменный заменный как новый и т д

Декомпозиция цели по системе Брайана Трейси

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

По мнению известного бизнес-тренера путь к глобальной цели разбит на 12 шагов:

  1. Четкое осознание задуманного желания.
  2. Реалистичность и измеримость идеи.
  3. Письменная формулировка цели.
  4. Список ожидаемых выгод.
  5. Определение исходных показателей и имеющихся ресурсов.
  6. Установление сроков.
  7. Определение препятствий и барьеров.
  8. Получение дополнительной информации, исследование ситуации.
  9. Составление списка необходимых помощников.
  10. Разработка плана действий.
  11. Визуализация.
  12. Внедрение принятых шагов.

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

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

Другие методы декомпозиции целей

  • Разделение на этапы
    Подходит для несложных проектов, когда достаточно составить план. Этапы могут быть одинаковыми (например, написать первую\вторую\главу), так и разными (залить фундамент, возвести стены, смонтировать кровлю и т.д). Каждую задачу можно разбить на более конкретные шаги, пока не получится ежедневный план работ. На первое время достаточно подробной детализации только первых уровней, так как в ходе работы скорее всего понадобится внести корректировки в дальнейшее внедрение.
  • Измеримая декомпозиция целей организации
    Главное отличие от предыдущего метода — преобразование задач в конкретные показатели. Способ используется, если у вас есть четкое измерение цели (количество посетителей, средний чек) и вы можете спрогнозировать их количественный рост.
  • Создание дерева элементов
    Не всегда итоговой цели можно достичь, двигаясь по линейному направлению. Чаще всего необходим ряд действий, порой несвязанных друг с другом. Примером таких задач в бизнесе может служить увеличение дохода и рост предприятия. Например для роста прибыльности торговой точки необходимо рассмотреть: количество посетителей, конверсию в покупателей, средний чек, маржу. Для улучшения каждого показателя необходимо составить свой детализированный план действий с визуализацией в форме паутины или дерева.
  • Методика SMART
    Для ее использования у цели нужно определить следующие характеристики: конкретность, измеримость, достижимость, значимость, ограниченность по срокам. С ее помощью можно декомпозировать даже неопределенные цели. Для каждого этапа задают сроки исполнения, задачу фиксируют в планировщике и делегируют ответственным лицам.
  • Одношаговая декомпозиция
    Эта стратегия работает в случае недостаточной определенности цели, когда невозможно заранее спланировать каждый шаг, а непредвиденные обстоятельства критически влияют на результат.

Порядок действий при выборе этого метода:

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

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

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

  1. Структуризация итоговой цели ведет к максимальному упрощению конечных этапов.
  2. Максимально четкая и понятная формулировка подзадач.
  3. Оценка нужного количества уровней декомпозиций с условием простоты реализации.
  4. Строгая структурная иерархия подчинения задач только одному верхнему уровню.
  5. Единый принцип разделения на этапы.
  6. Каждый шаг — это доля результата, а их сумма в итоге составляет 100%
  7. Заранее проработанный уровень разделения с учетом глубины для полной визуализации системы.

Как рассчитывается результат декомпозиции цели?

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

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

Советы по декомпозиции

  • Приступайте к декомпозиции только после четкой формулировки результата во всех деталях.
  • Сформируйте количество подзадач достаточное для выполнения вышестоящей цели, но не стоит дробить легкие заурядные действия.
  • Не используйте более 9 шагов для выполнения каждого этапа для улучшения восприятия. Человек длительное время может удерживать в сознании последовательность из 5-9 объектов.
  • Не детализируйте сразу весь процесс, достаточно конкретизации первых шагов. Это упростит внесение корректировок в будущем.
  • Определите и укажите приоритетность и значимость каждого шага. Сначала реализуйте наиболее ценные пункты.
  • Используйте для декомпозиции онлайн-сервисы и ментальные карты. Это значительно упростит работу и обеспечивает хорошую визуализацию.
  • Всегда оставляйте достаточный временной запас, не устанавливайте жесткие ограничения, чтобы весь план не рухнул при первой проблеме.
  • Выделите в отдельный блок задачи, выполнение которых не привязано к четкому сроку и может быть реализовано в любой момент. Решите их в первую очередь.
  • Заранее учтите, какие шаги можно делать параллельно, чтобы ускорить достижение большой цели.
  • Не забывайте о синергетических качествах системы, когда суть ее функционирования во взаимодействии компонентов, а не отдельных модулях.

Выводы

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

Источник

Что такое декомпозиция и зачем она нужна?

Я дpuzzleавно хотел написать цикл статей о том, как научится программировать. И сначала думал сделать статью о мышлении программиста. Одной из ее частей должна была стать «Декомпозиция». Но она стала слишком большой и я решил, что необходимо вынести ее в отдельную статью. Кроме того, кому программирование не интересно — все равно советую почитать, особенно в конце статьи для вас тоже будет полезная информация.

Декомпозиция — это разбиение одной большой задачи на меньшие, связанные между собой. Все кто сталкивался с программированием, сталкивались с декомпозицией. Это могли быть как части ООП в вашей Java программе, так и разные template какой-нибудь CMS. Так как само понятие задачи абстрактно, задачей можно назвать создание целого проекта, в тоже время «исправить ошибку в тексте программы» — тоже задача.

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

Зачем нужна Декомпозиция?

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

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

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

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

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

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

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

Как научиться декомпозировать задачи?

Идеальное обучение — практика. Но сложно начинать практиковатся на реальных задачах, если вы еще не до конца понимаете весь процесс. Как же быть? Я вижу два вектора тренировок.

Читайте также:  Таблица общество командная система традиционное система

1. Задачи из реальной жизни

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

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

  1. Разбейте сложную задачу на множество простых. Если они кажутся все равно сложными — разбейте их еще раз.
  2. Придуймайте решение каждой.
  3. Выстройте план действий.
  4. Приступите к выполнению.

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

2. Поиск объяснения устройства различных процессов

Что я имею ввиду? Ищите объяснения как устроены привычные для вас вещи. Вы когда то думали как устроен замок в вашей двери? Или, например, как работает электрический чайник?

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

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

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

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

Выводы

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

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

Пробуйте, развивайте свое мышление и решайте свои проблемы, достигайте целей!

Источник

Декомпозиция задач: что это и зачем нужно

И как сделать так, чтобы всё шло по плану.

Приходит маркетолог интернет-магазина к разработчику с задачей:

  • добавить на страницу товара счётчик, сколько раз его купили.

Для маркетолога это одна строчка текста. Он думает, что такую простую задачку можно сделать за 15 минут. А разработчик пожимает плечами: «Подумаю, потом назову срок». Что за дичь? А вот так.

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

  • Добавить в базу товаров столбец с количеством покупок.
  • Написать новый или доработать старый метод для АПИ, чтобы сайт получал значение из этого столбца.
  • Добавить строку текста на страницу товара.
  • Протестировать метод и вёрстку.
  • Подумать, что делать с редкими случаями, например, товар купили, а потом вернули; или если товар суперпопулярный и его купили 9999999999999999 раз.

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

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

Была одна большая задача, стало несколько маленьких.

Зачем декомпозировать

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

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

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

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

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

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

Декомпозировать можно по-разному, это зависит от масштаба и сути задачи.

Например, запуск мобильного приложения можно декомпозировать сначала на уровне платформ: iOS и Android. Потом — на уровне пользовательских сценариев: регистрация, просмотр контента, покупка, переписка с контактами. Сценарии можно разложить на интерфейс и серверную часть. А их — на отдельные конкретные задачи.

Чаще всего задачи раскладывают вертикально и горизонтально. Вертикально — значит по типам работ. Горизонтально — значит вглубь одного типа работы. Вот как это работает со счётчиком покупок в интернет-магазине:

Бэкенд: считать количество покупок и отдавать данные на фронт.

Фронтенд: запрашивать данные при загрузке страницы и выводить.

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

Кто должен декомпозировать

Декомпозировать задачу может сам разработчик, тимлид, менеджер проекта или другой компетентный сотрудник: универсальных правил здесь нет. Руководитель службы разработки Яндекс.Практикума Александр Трегер рассказывает, как это работает у них:

Когда появляется новая большая задача, один из опытных разработчиков берёт её на себя. С этого момента он за неё отвечает: собирает встречи, даёт заказчикам обратную связь, определяет, как решить задачу, декомпозирует её. Для разработчиков это возможность расширить свою зону ответственности, попробовать себя в роли архитектора и менеджера проекта.

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

👉 Почитайте полное интервью с Александром Трегером. Там больше подробностей о разработке Практикума.

Источник