Поэтому несколько лет назад я разработал приложение, которое позволяет строить диаграммы процессов, чтобы планировать исполнение проектов или просто достигать каких-либо целей. Всё это время я тесно работал с пользователями, довольно часто и по разному поводу они присылали мне свои диаграммы. Изучая сотни различных схем, я замечал, что некоторые из них проще воспринимать и понимать, чем другие, и наоборот, отдельные схемы было чертовски сложно разобрать. Интересно то, что зачастую дело было не в сложности или простоте самого процесса, а в манере построения диаграммы. Проявив толику усердия, даже самый простой процесс можно проиллюстрировать путанной схемой, суть которой будет сложно понять без дополнительного изучения.
Анализируя свой опыт по построению диаграмм и систематизируя удачные находки и ошибки пользователей, я выработал набор принципов, которые позволяют строить хорошие диаграммы.
Пару слов о структуре статьи. Материал довольно обширный, поэтому я попробую разбить его на несколько частей и постараюсь излагать материал тезисно, избегая лишних разъяснений. Эта статья будет посвящена довольно общим принципам, вполне очевидным, но которые следует упомянуть. Последующие части будут ближе к конкретным практикам.
Итак, сначала договоримся об основном предмете статьи — диаграммах процессов (далее для лаконичности иногда просто диаграммы). Как правило, диаграмма процессов представляет собою набор графических объектов, поименованных текстом, которые связаны между собою стрелками. Объекты обозначают процессы, ресурсы, состояния и т. д. Стрелки же обозначают порядок перехода управления от одного объекта к другому. Следует отличать диаграммы процессов от внешне очень похожих структурных диаграмм, диаграммы процессов предполагают динамику, в то время когда структурные диаграммы носят статичный характер, описывая конструктивные взаимосвязи объектов, обычно это описание организационных иерархий, структур данных или “карты разума”.
Существует много нотаций описания диаграмм процессов, это IDEF0, BPMN, UML, EPC, CMMN и другие. Данная статья в равной степени относится к ним всем, в примерах использована нотация собственного приложения.
В статье словом “процесс” в зависимости от контекста может обозначаться как основной процесс, описываемый диаграммой, так и процессы, входящие в состав диаграммы. Слово “задача” может означать процесс, цель или ресурс, либо цельное сочетание ресурса, процесса и цели. В общем, смотрите по контексту.
Так как именно динамика является основной отличительной чертой рассматриваемых нами диаграмм, то, следовательно, ключевой частью такой диаграммы является её сценарий. Основные требования к сценарию — это непротиворечивость и непрерывность. Противоречия возникают при неверном порядке причин и следствий, а также в ситуации, когда один объект должен быть одновременно в разных местах (или два совмещаться в одном и том же месте). Непрерывность теряется, когда следствия не обусловлены причинами либо когда утерян существенный фрагмент повествования.
Вот здесь нужно осветить один важный момент касательно сценария и диаграммы в целом. Цель создания диаграммы не только в описании конкретного процесса, но и в передаче этого знания адресату. То есть на сюжет диаграммы влияет как описываемый ею процесс, так и её аудитория. К примеру, если вам нужно разъяснить пункт ПДД детям, вы воспользуетесь иной методикой изложения, нежели та, что использована в официально установленных правилах. Как правило, если сюжет не адаптирован к аудитории, то теряется его непрерывность, поскольку отдельные причинно-следственные связи неочевидны или непонятны адресатам.
Можно упомянуть много различных методов отладки диаграмм с целью устранения противоречий и соблюдения непрерывности. Но эффективнее будет сразу строить качественные диаграммы, и так как статья носит больше практический характер, то вместо описания методов анализа качества я просто приведу пошаговый алгоритм построения хороших диаграмм.
Шаг 1. Разместите свои цели как ресурсы в правом нижнем углу диаграммы.
Обычно процессы, которые имеет смысл описывать, имеют чётко выраженную конечную цель или группу целей. Такой целью может также служить состояние, после которого дальнейшее исполнение процесса не имеет смысла. Как правило, процессы создаются под конкретные цели, и зачастую очевидно, что написать в правом нижнем углу диаграммы. Однако иногда бывает дальновидным указать не только положительную цель, но перечислить состояния, в которых исполнение процесса прерывается, но исходная цель не достигнута или достигнута не полностью. Рекомендуется явно перечислять подобные негативные цели в случаях, если вероятность достижения основной цели ниже 60%.
Забегая вперёд, скажу, что рекомендация по размещению конечной цели справа внизу диаграммы (как и последующие подобные рекомендации) относится к композиции диаграммы, которая будет предметом рассмотрения другой статьи.
Шаг 2. Отметьте доступные ресурсы в виде объектов в верхней части диаграммы.
Очевидно, что перечислять следует не все возможные ресурсы, а только те, которые видятся полезными для достижения цели и ликвидность которых не вызывает сомнений. Перечень этих ресурсов будет являться исходными условиями начала процесса. Одним из таких ресурсов должен быть триггер, запускающий весь процесс, обычно это внешнее воздействие: заявка клиента, смена состояния индикатора, запрос от системы и т. д.
Шаг 3. Разместите предполагаемые промежуточные цели как ресурсы в средней части диаграммы.
Комплексные цели обычно состоят из набора компонентов, которые необходимо реализовать предварительно. Большие проекты удобно разбивать на этапы, результатом исполнения которых является получение одного из компонентов конечной цели. Мысленно расчлените конечную цель на такие компоненты и поместите их на диаграмму. В некоторых случаях вместо компонентов можно разбить конечный продукт на последовательность эволюций зрелости продукта или совмещать оба подхода.
Шаг 4. Перед целями, имеющимися на диаграмме, разместите процессы, которые приводят к достижению данных целей, и соедините новые процессы с их целями.
Заметьте, что пока на нашей диаграмме процессов не было ни одного процесса, это неслучайно. Специфика нашего мышления такова, что, начиная что-то делать, мы больше концентрируемся на процессах, немного забывая, что суть нашей деятельности в целях. Диаграммы процессов, состоящие из одних только процессов, — частое явление, однако следует помнить, что мы стремимся к непрерывности и ясности изложения, а зачастую указание целей исполнения процесса говорит о нём больше, нежели название процесса и его описание. Старайтесь всегда явно указывать цели процесса, на практике это означает, что стрелка от одного процесса к другому — это редкое явление, обычно между процессами располагается промежуточный ресурс, являющийся результатом исполнения одного процесса и исходным ресурсом для другого. В некоторых формализмах (например DFD) сама стрелка может являться описанием ресурса. Однако если такой промежуточный ресурс очевиден, то ради упрощения схемы его можно опустить и провести стрелку от одного процесса к другому. Например, если в прачечной после процесса “Сушка” следует процесс “Глаженье”, то в некоторых случаях промежуточный ресурс “Сухое бельё” можно пропустить.
Шаг 5. Проведите связи от имеющихся на диаграмме ресурсов к использующим их процессам; если необходимого для процесса ресурса нет на диаграмме, добавьте новую цель, вернувшись к Шагу 3 ^.
Очевидно, что если требуемого процессом ресурса нет, то это приводит к противоречию в исполнении задачи, так как соблюдены не все причины для желаемых следствий. Следовательно, необходимо исполнить критерий полноты — всё необходимое для исполнения каждого процесса должно быть в наличии. Впрочем, не всегда оправдано явно указывать очевидные ресурсы, например, при обработке детали станком одним из очевидных ресурсов является электроэнергия, явное выделение этого ресурса, скорее всего, не сделает диаграмму понятнее, однако без значимых причин усложнит её. Помните о своей аудитории: часть диаграммы зритель всегда достраивает мысленно, это неизбежно. Старайтесь, чтобы мнимая часть диаграммы касалась очевидных всем моментов, более того, слишком явные вещи, выписанные на диаграмме, могут утомлять и даже раздражать.
Шаг 6. Проведите связи между процессами, исполнение которых зависит друг от друга.
Попарно проверьте все процессы, размещённые на диаграмме, нет ли между ними неявных зависимостей или взаимного влияния. Например, часто полезно “грязные” процессы группировать вместе, чтобы экономить на очистке рабочей области. Также если два процесса конкурентно используют ограниченный ресурс, то их следует развести во времени, проложив связь от одного из них к другому. Заметьте, что ресурсы, которые мы не отображаем на диаграмме, тоже могут быть причиной скрытых зависимостей, к примеру, когда два процесса используют энергоёмкие станки, которые не следует включать одновременно.
Шаг 7. Убедитесь, что диаграмма легко читается и содержит не более 20 объектов; если это не так, сгруппируйте несколько контекстно связанных объектов в один объект подходящего типа с вложенной диаграммой, содержащей данную группу.
Практика показывает, что когда диаграмма содержит более 20 объектов (ресурсов или процессов), то схема перестаёт восприниматься цельно, а начинает выглядеть, как лабиринт, в котором зрителю нужно выискивать интересующие его пути. С другой стороны, редко какой проект или бизнес-процесс уложится в такое небольшое число объектов. К счастью, то, что не вместит одна диаграмма, поместится на нескольких, не стремитесь всё изложить сразу, помните: всегда можно сделать ещё одну диаграмму.
Итак, если схема получилась громоздкой, выделите группу объектов, по возможности слабо связанных с другой частью диаграммы, и замените их одним процессом. Удалённые объекты станут основой новой диаграммы, которая будет пояснять суть нового процесса.
Такая, казалось бы, чисто техническая задача на самом деле имеет большое значение, так как подобным образом выстраивается иерархия детализации задач и разделение контекстов исполнения процессов. Теперь с точки зрения основной диаграммы не важно, как реализован новый процесс, подробности его реализации вынесены в отдельную диаграмму, они существуют как бы в отдельном пространстве, на которое основная схема имеет ограниченное влияние. Это довольно полезное свойство: чем более независимы соседние задачи, тем меньше вероятность, что ошибки и проблемы одной из них будут влиять на другие.
Другим важным аспектом детализации диаграмм является возможность развести аудитории: как правило, диаграммы верхнего уровня интересны менеджерам, а вложенные диаграммы больше полезны техническим специалистам. Разбив диаграмму на уровни, мы можем каждую новую диаграмму проектировать с учётом её аудитории, формируя сюжет, понятный и увлекательный именно для неё.
Шаг 8. Убедитесь, что объекты имеют тип, соответствующий их сути, визуально разделите информационные и физические потоки. Если диаграмма содержит несколько контекстно связанных объектов, выделите их с помощью группы. В местах, требующих пояснений, разместите объекты типа комментарий.
В зависимости от выбранной нотации описания процессов нам будут доступны различные типы графических объектов, описывающих специфические аспекты задач, внимательно изучите перечень доступных объектов и используйте наиболее подходящее описание для каждой из задач. Иногда нотация позволяет отдельно выделить область на диаграмме, внутри которой можно расположить задачи, связанные каким-то общим признаком: исполнителем, местом исполнения и т. д.
Часто такие области оформляются как горизонтальные дорожки, после чего диаграмма выглядит, как бассейн, в котором каждый исполнитель плывёт по своей дорожке вдоль своих задач. Такая организация диаграммы довольно наглядна, но может иметь свои композиционные недостатки.
Шаг 9. Для процессов, не являющихся элементарными операциями, постройте вложенную диаграмму, начиная с Шага 1.
На Шаге 7 мы синтетически создавали новую задачу из группы объектов и детализировали её вложенной диаграммой. На этом шаге делается то же самое, но аналитически: мы пытаемся сложный объект разложить на более простые процессы и отобразить их во вложенной диаграмме. В управлении проектами этот процесс называют структурной декомпозицией работ. Разбивая задачи на более мелкие или объединяя их в более крупные, следует следить, чтобы задачи одного уровня, отображаемые в одной диаграмме, были приблизительно равны по значимости и трудоёмкости.
Шаг 10. Для отдельных ресурсов там, где это необходимо, добавьте вложенную диаграмму подготовки ресурса к использованию. Для избранных целей добавьте диаграмму по проверке требуемых качеств достигнутой цели.
Продолжаем работу по декомпозиции, но акцентируем внимание на ресурсах и целях.
Успешно завершив все десять шагов, мы должны получить набор процессных диаграмм, иллюстрирующих непротиворечивый и непрерывный сценарий по достижению запланированных целей. Однако эти диаграммы ещё не являются готовым продуктом, для каждой из них нужно найти подходящее композиционное решение и оформить их, соблюдая ряд визуальных формальностей и нюансов. Тому, как превратить нашу сырую руду в звонкий металл, будут посвящены следующие статьи, пока же подведём итог этой.
Итак, описание любого процесса начинается с составления сценария, который связывает объективную структуру процесса с аудиторией, для которой предназначено описание. В случае если адресатом является человек, удобно пользоваться компактными диаграммами процессов, организованными в иерархическую структуру, основанную на архитектуре процесса. Заметьте, что внедрённая в описание процесса иерархия может не быть частью самого процесса, она больше нужна для целей эффективного восприятия аудиторией — иногда, чтобы что-то сделать проще, сначала это нужно усложнить.
Комментарии (35)
vvagr
20.09.2017 21:11+2«Существует много нотаций описания диаграмм процессов, это IDEF0...»
Увы, не нашёл, что бы можно было сделать по инструкции после прочтения этой фразы.
JustRamil
21.09.2017 11:36+1IDEF0 не для описания процессов, а для разработки функциональной модели. Дабы не объяснять тут, привожу статью habrahabr.ru/post/322832
Кстати в статье я привожу схожий пример (сразу скажу что моя статья вышла раньше).
Shortki Автор
21.09.2017 13:11Да, формально вы правы IDEF0 — для функционального моделирования. Однако на практике функциональная модель по структуре может практически совпадать с моделью процессов и наоборот, отчего часто модель процессов верхнего уровня просто заменяют функциональной моделью. Можно считать это некорректным, но вполне практичным решением.
JustRamil
21.09.2017 15:21Вообще описание процессов это и есть формализм чистой воды. Ибо без правильной формы в данном случае мы не поймем содержание правильно.
antage
21.09.2017 08:26Тема статьи интересная, но очень не хватает иллюстраций для демонстрации примеров.
Bimawa
21.09.2017 09:16Круто, спасибо за статью.
Главное чтобы не уйти в художники после этого навыка.
McSimEst
21.09.2017 13:13Спасибо! Отличная статья.
Споткнулся только на Шаге 5. Почему просто не добавить ресурс, который забыл указать на Шаге 2? Вероятно, тут не про вариант «если вы забыли», а про… что?Shortki Автор
21.09.2017 13:23На Шаге 2 определяются исходные ресурсы, то есть те которые должны быть в наличии перед началом исполнения работ, это довольно узкий список. А на Шаге 3 определены ресурсы, которые так или иначе становятся доступны в процессе работ, в принципе они могут включать в себя и исходные ресурсы и те ресурсы, которые были произведены по ходу дела. Ресурсы Шага 3 представляют собою более общее множество поэтому переход и ведёт к этому шагу.
perfect_genius
21.09.2017 13:13+1Статья без диаграмм про диаграммы.
Shortki Автор
21.09.2017 13:41В конце статьи её содержание приведено в виде диаграммы. Примеры я не стал приводить сознательно, так как они побуждают действовать по шаблону, а на данном этапе куда важнее “схватить” общий принцип изложенного метода.
Хотя, вот сейчас подумал, что можно было бы привести несколько негативных примеров, как не нужно делать, они точно не стали бы шаблоном, но иллюстрацию дали бы.
Sannis
21.09.2017 14:32Shortki, традиционный вопрос: диаграммы руками рисовали?
Shortki Автор
21.09.2017 14:50Всё в так или иначе делается руками, но нет, диаграммы не были “нарисованы”, они были построены руками из готовых блоков в специальном приложении, после чего можно задать временные параметры созданного процесса, провести симуляцию исполнения, назначить исполнителей, сформировать план исполнения, получить диаграмму Гантта, отслеживать прогресс и делать много другое.
Если вопрос о другом, то нет, диаграмма не была построена автоматически из формализованного описания.
p6sh-p6sh
21.09.2017 14:40+1Спасибо! Интересная и полезная статья. Сайт wokflow.link с удовольствием просмотрел, классно сделано.
PArtamonov
21.09.2017 16:06Есть способ строить диаграммы — ДРАКОН. Его использовали при построении Бурана, в этом проекте участвовало 2 миллиона человек.
Вашу диаграмму можно улучшить с помощью этой концепции.
Рекомендую книгу на эту тему «Как улучшить работу ума» — В.Д.Паронджанов.
sortarage
21.09.2017 22:20+1Честно попробовал пользоваться сервисом, но невозможность делать папки или блоки одинакового размера превращает все в цирк. Добавьте, пожалуйста, или направляющие, или возможность указать точный размер, иначе это просто ад перфекциониста.
sortarage
21.09.2017 22:21А то что лист начинается не с целой ячейки, а с половины, вообще убивает :)
sortarage
21.09.2017 22:24При попытке создать папку хотя бы напоминающую папку «Руководство пользователя» поймал нервный тик, ибо папки не выравниваются по клеткам, размеры сжимаются автоматически по непонятной логике, практически ад. Сервис выглядит очень полезным, но лично для меня им пользоваться невозможно.
Shortki Автор
21.09.2017 23:27Спасибо, что поделились опытом пользования. Все размеры автоматически выравниваются по сетке, странно что у вас не так, а то что лист начинается не с целой ячейки, а с половины, вообще не понятно — у себя я такого не отыскал. Можно поинтересоваться какой у вас браузер и ОС? При правке контента в браузере, есть некоторые неудобство по сравнению с десктоп-приложением, но чтобы “нервный тик” не сталкивался, но я не в терминальной стадии префекциониста, хотя временами предаюсь этому пороку.
sortarage
22.09.2017 00:58+1Последний Chrome, Windows 10.
Скрин стартового листа с половиной ячейки:
i.imgur.com/G68xf0i.png
Моя лучшая попытка сделать одинаковую папку (потратил около 3-х минут и все равно видно, что одна папка выше):
i.imgur.com/zVIOm1i.png
Я для работы использую Mindjet, и там вообще нет сетки, но при этом есть возможность скопировать стиль. Какие варианты я вижу у вас, чтобы все выглядело более-менее структурированно:
а) указать размер элемента в клетках по ширине/высоте — отсутствует
б) указать размер элемента в пикселях — отсутствует
в) сделать копию стиля папки без копирования входящих элементов — отсутствует
г) возможность сдвигать элементы кнопками мышки на мини-клетку вверх вниз, чтобы выровнять точнее — отсутствует
д) подгонка размера элемента под клетки — присутствует, но неточная (как в моем примере, разница в 2-3 пикселя не критична, но лично мне портит все впечатление).
То есть я искренне пытался заставить себя пользоваться инструментом, но получается абсолютно кривая разноразмерная каша (именно у меня, инструмент прекрасный).Shortki Автор
23.09.2017 00:24На первом скрине не «половина ячейки» просто часть поля съедается линией отделяющей заголовок, хотя сама линия своим центром (но не краем) выровнена точно по третьей сверху клетке. Вообще объекты выровнены по сетке, но учитывая что ширина штрихов у них может варьироваться, то это может стать причиной наблюдаемого вами эффекта. Но не с папкой «Руководство пользователя» :) она создаётся особым образом и немного не подчиняется правилам, это особый случай, посмотрю что с этим можно сделать. Попробуйте повторить ваш эксперимент с двумя не системными папками.
а-б) Вполне возможно сделать, подумаю.
в) Объекты можно копировать, а свойств стилей не так много чтобы городить вокруг этого функционал, а ведь это новая кнопка в уже и так довольно сложном интерфейсе, который хотелось бы оставлять насколько возможно простым.
г) Там конфликт со скроллингом, не ясно как лучше, в общем пока оставили так.
pebble
22.09.2017 08:42+11. Полностью согласна, что диаграмма должна быть адаптирована под аудиторию.
Но, на мой взгляд, нужно не только определить аудиторию, но и оставить об этом информацию будущим пользователям диаграммы (на самой диаграмме, в сопроводительной документации).
2. Пожалуй, соглашусь с предложенной последовательностью построения (конечные цели — доступные ресурсы — промежуточные цели — процессы) для схем to be.
Для схем as is, думаю, нужно начинать с процессов, а уж к ним пристегивать цели и ресурсы: пользователи часто охотнее рассказывают о своей деятельности (то бишь о процессах), а вот цель этой деятельности не всегда могут сформулировать.
И одна из задач as is — определить процессы с неясными целями и, либо поставить им в соответствие какую-то полезную цель, либо «официально убить» эти процессы. Для as is, предложенная в статье последовательность будет способствовать «потере» процессов c неясными целями на схеме, но в реальной жизни они по прежнему будут исполняться.Shortki Автор
22.09.2017 18:481. Естественно это так и должно быть, любая диаграмма не существует сама по себе, он всегда находится в каком-то контексте с уже сформировавшейся аудиторией.
2. Чувствуется опыт. С моей экстремальной точки зрения в развитой корпоративной культуре as is не должно существовать, но в жизни всё иначе. Если to be это работа строителя, то as is это призвание реставратора в хорошем смысле, и патологоанатома в плохом. Это совсем разные подходы, и если для построения процесса еще можно предложить какой-то метод, то с анализом на месте всё сложнее, здесь работа больше похожа на занятие детектива.
Вспомнил байку, внешний консультант на предприятии никак не мог понять путь принятия решений — всё непрозрачно, куча комитетов, совещательных органов, согласований, но предприятие работает как часы. И вот заходит он в один небольшой отдел на отшибе где работали всего три девушки, как работали — бумажки перекладывали, в общем так и не понял он чем они заняты, но уходя заметил у одной пятна на руке от чернил двух цветов, а такие встречались на предприятии только в одном месте. Вот он и спрашивает: “А у вас есть Большая Круглая Печать?” А она: “Да, вот, а что такое?” Вот так вскрылся альтернативный оперативный путь принятия решений почти без согласований и болтовни. По пятнам! Такое ни в одной методике не предусмотреть.
Спасибо за комментарий.pebble
22.09.2017 22:03+1Чувствуется опыт.
Есть немного.
В моей идеальной картине мира as is должны получаться из to be сразу после внедрения с отражением всех расхождений, которые образовались в процессе реализации. + должна постоянно поддерживаться актуальность этих схем. Я работаю на стороне клиента и мне, в отличии от внешних консультантов, важно иметь актуальную информацию по процессам: что бы быстро находить нужную инфу, что бы знания не лежали в чьей-то конкретной голове, а были доступны всей команде, для того, что бы разговаривать с пользователями на одном языке и т.д.
Но в жизни, конечно, все не так. Безусловно, крайне не хочется тратить время на as is до внедрения новых оптимальных процессов, но в некоторых случаях, на мой взгляд, это оправдано. Например, в следующих:
а) пользователи крайне неохотно делятся инфой о своих процессах (возможно из-за страха потерять свое насиженное место, уникальность-незаменимость или просто от природного косноязычия, не суть). В таких случаях мне важно отрисовать схемы и получить от пользователей подпись под ними. Что бы потом не было обвинений, что мы что-то не так поняли, упустили, не учли.
б) для иллюстрации каких-либо наших предложений по оптимизации, требующих волевого решения сверху: положительное решение более вероятно, если руководитель сравнивает as is и to be, чем когда просто лицезреет to be.
в) очень часто делаю выборочно схемы просто для себя — они могут понадобиться мне/коллегам позже в случае, если их трансформация под to be отложилась или отменилась.
У внешних консультантов таких необходимостей как правило не возникает, они пришли и ушли, а мне дальше с этим работать. Так что для меня as is — эта работа терапевта или даже этакого врача общей практики.
И да, запутанные процессы иногда распутываются на интуиции и мелких зацепках.Shortki Автор
23.09.2017 02:08Похоже вы на секунду подумали, что я недооцениваю важность работы as is :), уверяю это не так. Я искренне желаю чтобы у медиков или пожарных не было работы, но это не значит что я плохо отношусь к их деятельности. Иногда проще профилактически внедрить что-то как должно быть, до того как понадобится диагностировать «что у нас там» и «лечить/тушить» это.
И да, актуальность это бич. Здесь помогает подход при котором исполнителям разрешено править конкретный процесс по мере его исполнения, и не относиться к процессам как к «золотому шаблону» — все случаи бывают разные, лучше зафиксировать как получилось, чем не знать что там было. Когда проявляешь гибкость, иногда прикрывая исполнителей в сложных ситуациях и «косяках», то сотрудники перестают «шифроваться», чаще приходят за советом «как лучше здесь поступить». Кстати, на стороне клиента я тоже долго проработал.pebble
23.09.2017 10:09+1Именно так я и подумала, после фразы
в развитой корпоративной культуре as is не должно существовать
у меня иных вариантов особо и не было :). Но с вашим последним комментарием полностью согласна.
ARadzishevskiy
22.09.2017 10:04+1Спасибо, за статью!
Описанные тут рекомендации, подходят для построения большинства канонических диаграмм и изложены они аргументировано и очень наглядно. То что это сделать тяжело, знаю по своему опыту. Читая, статью большей частью описание ассоциировало у меня именно с IDEF0 (кроме бассейна конечно). Этот тип диаграмм помоему набирает популярность, после незаслуженного забвения.
В моем курсе Практика формирования требований в ИТ проектах от А до Я. именно описание функционального проектирование набрало максимальный рейтинг из прочих стадий, хотя я думал будет наоборот.Shortki Автор
23.09.2017 01:45Я читал ваши статьи — познавательно, но очень много материала, так много сразу сложно воспринимать, и мне показалась что часть с функциональным проектированием чуть проще на фоне остальных.
Хотя сам я довольно осторожно отношусь к чисто функциональному подходу, так легко получаются подразделения с «чётко очерченными функциями», но без понятия чем они заняты (функциональный подход), или понимающими чем заняты, но не знающими зачем (процессный подход).
Вот забавная видеоиллюстрацияARadzishevskiy
23.09.2017 11:44+1я довольно осторожно отношусь к чисто функциональному подходу
Без определения функций системы, можно упустить часть важных потребностей пользователей, которые лежат на поверхности, но мало связаны с основными деловыми процессами. Например, создание и корректировка справочников, возможность настройки вариативности алгоритмов системы и т.д. Отсюда возникает риск не включить их в контракт на разработку и потом препираться с заказчиком за чей счет их реализовывать.Shortki Автор
23.09.2017 16:32Здесь я соглашусь, в написании требований или прототипировании приложений функциональный анализ действительно полезен. Мой комментарий скорее относился к проектированию бизнес-процессов и планированию проектов, вот где существует опасность начать с функционального анализа и на нём же и остановиться.
vassabi
Если это всё счастье рисовалось Вашим приложением, то следует признать, что презентация её возможностей Вам явно удалась! :)
Shortki Автор
Что же, чудесно, спасибо за комплимент! Но, такой результат не полностью заслуга приложения, диаграммы составлены так чтобы легко и чисто читаться — вот этим опытом я и хочу поделиться.
JustRamil
Приложение же не ваше? Я где то даже видел его в Appstore.
Shortki Автор
Отчего же, приложение и web-сервис разработаны мною, у меня в профиле есть ссылки на сайты wokflow.link и inShort.