Русский
Русский
English
Статистика
Реклама

Метамодель

Уточняем детали проекта методами практической психологии

15.02.2021 18:22:10 | Автор: admin

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

Классика - что хотел заказчик?Классика - что хотел заказчик?

Текст написан по материалам внутреннего тренинга, который я проводил в нашей компании в начале февраля.

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

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

Эксперимент с передачей ТЗ

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

ТЗ заказчика из будущего. Оригинальная версия

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

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

Сплав Сиборгия с 3х и 1й тысячной % Ниобия нужно изготовить при температуре ниже 10 Кельвинов в емкости, обитой Скандием.

Форма сплава должна быть сферической с вырезами каждые 18 градусов. Глубина вырезов должна иметь точность в пределах 1 пикометра и составлять 1 миллиметр. Радиус сферы - 3 сантиметра.

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

Со всем остальным Маарыйа поможет, когда вернется.

ТЗ заказчика из будущего. Первый пересказ

К нам из будущего прилетело существо по имени Маарыйа. Оно сказало, что прилетит к нам еще раз для того, чтобы помочь построить машину времени. Машина называется Акша.

Чтобы выполнить эту задачу, нам нужно не дремать на своей планете и готовиться к второму приходу, т.к. Маарыйа не будет делать за нас все. С нашей стороны потребуется Сиборий и другое вещество - на букву Б (давай назовем его Борий). Их надо смешать в пропорции 3 и 1 тысячная грамма с еще одним веществом (кажется, он назывался Серентий) и что-то сделать при температуре минус 1000 градусов в сосуде, у которого есть отверстие 9 см.

ТЗ заказчика из будущего. Второй пересказ

К нам прилетает пришелец из будущего. Ее зовут Маарыйа. Нам нужно будет сделать машину времени - ее называют Акшна. У Маарыйа есть все знания о том, как ее сделать, но она не будет нам помогать.

Чтобы сделать машину времени, нам нужно три вещества: Борий, Сиборий и еще что-то. Температура, при которой идет реакция - минус 1000 градусов. При этом Бория нужно 3,001. Про остальные информации нет.

Маарыйа прилетит к нам еще раз, чтобы посмотреть результат.

ТЗ заказчика из будущего. Третий пересказ

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

Чтобы сделать машину времени, нужно 3 вещества: Борий, Себорий и еще что-то. Для Бория нужна температура минус 1000 градусов. Количество Бория - 3,001.

Отличный у нас получится проект, если мы будем следовать финишному ТЗ! (шутка).

Но давайте разбираться. Из истории постепенно исчезли подробности:

  • Изначально говорилось, что пришелец прилетал и оставлял ТЗ. В итоговой версии оказалось, что он не посещал нас, а прилетит только в конце, чтобы посмотреть результат.

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

  • Исказились детали: изменился состав сплава как по веществам, так и по их пропорции. Проценты в первоначальной истории превратились в граммы. 10 Кельвинов превратилось в -1000 градусов.

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

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

Метамодель

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

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

  • Неконкретные глаголы (править, получать, наплевать, любить, хватать, помнить, выходить). Это не просто объект, а какое-то продолжительное действие, которое каждый может воспринимать по-своему.

  • Сравнительные обобщения (больше, меньше, ровнее, успешнее, свои, чужие, качественный). В основном это прилагательные. Критерии для сравнения человек выбирает в соответствии со своим жизненным опытом. Нам они неизвестны.

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

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

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

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

  • Неконкретные существительные. Возьмем стол. Он может быть разным - высоким или низким, разной формы и назначения. Задача уточнения - определить важнейшие для нас параметры стола, чтобы восстановить картинку, которая была в голове у человека. Вопросы: Кто/что именно? Какой конкретно? Чей?

  • Неконкретные глаголы. Первый пример был - править. Править можно по-разному - есть монархия или демократия. Наша задача выяснить, какое поведение скрыто за этим термином. Что конкретно человек делает? Поэтому логично будет задать вопрос: как именно?

  • Сравнительные обобщения. Цель вопросов к такому обобщению - выяснить, с чем человек сравнивает, выявить более осязаемые критерии, приближенные к физическому миру. Вопросы: По отношению к чему? Насколько? В чем?

  • Номинализации. Раскрывая существительные, не представленные в физическом мире, наша задача понять, что именно человек подразумевает. Что это был за процесс, как он взаимодействовал с другими объектами. Вопросы: Кто? Когда? Где? С кем? Как именно?

  • Модальные операторы невозможности и необходимости. Это ограничения, которые человек сам себе ставит. Мы задаем вопросы, чтобы выявить его природу. Часть наших вопросов может быть направлена на то, чтобы помочь собеседнику выйти за выставленные себе рамки. Вопросы: Что мешает? Что случится, если бы вы сделали/не сделали? Кто вам это сказал?

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

Как это работает на практике

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

Нам важно понять, насколько низкими? Для этого нам надо:

  • Увидеть паттерны метамодели. Начинать лучше с наиболее общих.

  • Придумать существенные вопросы, разобобщающие этот паттерн. Надо стараться не уйти в более крупное обобщение. Например, вопрос почему зачастую ведет как раз к обобщению. А что заставляет сделать именно так? - к разобобщению.

  • Корректно задать этот вопрос.

Будьте экологичны

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

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

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

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

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

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

  • Метамодель - инструмент коучинга. Но не нужно человека лечить, если он этого не просит. Не следует раскрывать абстрактные понятия, вроде любви, ответственности и т.п., если человеку это не интересно. Даже если вам кажется, что после раскрытия он мог бы действовать в мире более эффективно.

И удачи с практикой!

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

Автор статьи: Владимир Бушманов, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Подробнее..

Краеугольный камень анализа. Часть 1

16.06.2021 02:22:40 | Автор: admin

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

Я придерживаюсь убеждения, что задача анализа в IT это борьба с неопределённостью, с целью прийти к пониманию, которое выражается в виде модели. Неважно как представлена модель: в виде диаграммы, текста, таблиц, всё равно это модель. Модели бываю разные: модель проблемы, решения, предметной области, модель бизнеса, модель системы, разные модели. И статья целиком состоит из моделей, где будет использоваться простой вымышленный случай, когда потребовалось создание системы. Клиент: Пекарня ООО Три яблока, которая специализируются на производстве выпечки с начинкой из яблок. Заказ: Информационная система поддержки нового продукта пекарни на всех этапах жизненного цикла продукта. Итак, допустим бизнес-аналитики собрали все бизнес-требования, описали все бизнес-процессы. Системные аналитики описали модель данных и процессы на системном уровне. А разработчики реализовали систему по этим описаниям. Тестировщики тоже отработали, критических багов нет. А клиент говорит: Это не то, что нужно! Давай разбираться, где что-то в анализе могло пойти не так. Нас интересует только проблемы анализа.

Нам потребуется следующая иерархия уровней абстракций:

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

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

  • Модели не соответствует решаемой задаче аналитика.

  • Модели не согласованы внутри себя.

  • Модели не согласованы между собой.

  • Реализация по моделям не соответствует тому, что требуется пользователям и бизнесу.

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

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

Еще один способ движение точек зрения навстречу друг другу:
сверху вниз вовлечение пользователей в процесс разработки;
снизу вверх вовлечение разработчиков в обсуждение задач и проблем бизнеса.

А если эти два способа совместить, получим приближение к Agile. В нем эти способы закреплены следующими 2-мя принципами:
1. Частая поставка работающего программного обеспечения;
2. Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта.

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

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

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

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

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

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

А что есть модель? Что описывают модели? Если убрать из рассмотрения парадигмы, то в сухом остатке (исходные, базовые, основные) модели описывают, как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом. Дополнительными моделями и элементами моделей могут выступать события, интерфейсы и состояния.

Но основой, вокруг которой всё строится это: субъект, действие, объект. При этом без разницы в каком виде построена модель: BPMN, Use case или UML Диаграмма последовательности. Всё равно, это модель как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом.

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

Напомню проблемы, которые нужно решить:

  • Модели не согласованы внутри себя.

  • Модели не согласованы между собой.

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

Есть еще одна проблема, которую я указал в начале доклада:

  • Реализация по моделям не соответствует тому, что требуется пользователям и бизнесу.

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

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

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

Если подходить напрямую, то вероятнее всего вы попробуете построить верхеуровневую модель бизнеса. Поискав различные представления, скорее всего найдете Business Model Canvas Александра Остервальдера. И в этом табличном представление обнаружите элементы, которые могут оказать непривычными, если до это вы описывали только операционную деятельность организации. Вы можете попробовать использовать Архитектурные фреймворки, BIZBOK или TOGAF. Но без конкретных примеров они представляют собой теоретические абстракции. По моему мнению, сложность в том, что они созданы не для того, чтобы кого-то научить, они нужны для тех, кто уже знает и понимает, и хочет систематизировать знания.

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

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

И с этим выводом формируется Краеугольный камень анализа:
1) Модели на всех уровнях абстракции должны представить собой систему.
2) Назначение элементов системы определяет система.
3) Назначение самой системы находится на вышестоящем уровне абстракций. То есть его определяет вышестоящая система (экосистемы).

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

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

Есть еще технические приемы. Как много вы думали над тем, почему часть User Story после слова чтобы очень тяжело написать? И почему критерии INVEST именно такие?

Шаблон User Story:

Как <субъект>, я хочу/могу <выполнить деятельность или получить объект>, чтобы <зачем или почему>.

INVEST критерии хорошей User Story:

Independent независимая от других историй;
Negotiable обсуждаемая, отражает суть, а не детали;
Valuable ценная для клиентов, бизнеса и стейкхолдеров;
Estimable оцениваемая по сложности и трудозатратам;
Small компактная, может быть сделана командой за одну итерацию;
Testable тестируемая, имеет критерии приемки.

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

В 2020 в руководство по Scrum добавлен понятие Цель продукта, а рамках планирования особое внимание уделяется вопросу Почему для цели спринта. Agile сосредоточен на верхней части пирамиды абстракций. Авторы не глупые люди, они понимают, что это залог успеха.

Для проработки вопроса назначения и ограничений вместе с Agile подходом можно использовать дополнительные методики: Дизайн мышление, Impact mapping и JTBD. Все они хорошие, рекомендую попробовать практиковать. Но тут есть большое НО это не будет работать, если у вас команда неопытных аналитиков. Несмотря на кажущуюся легкость и заявленную опору на простой здравый смысл использовать Agile могут только квалифицированных специалисты с достаточным опытом. Потому что Agile игнорирует уровни абстракций. А в Scrum, по идее, вообще нет аналитиков, есть кроссфункциональная команда, которая работает, не обращая внимание на уровни абстракции.

Примечание

Даже с профессионалами, это возможно только для одной команды из 7-9 человек, как только у вас появляется большой проект и 3-4 команды, то требуется архитектура, модели, проектирование.

Итак, Agile это подход, который делает упор на организационные способы решения задач с опытными профессионалами. Используя различные приемы, указанные ранее, можно получить некоторое представление о назначении и ограничениях, в виде набора стикеров, job stories и mind map.

А есть ли более строгий, аналитический способ понять назначение и ограничения?

Этому будут посвящена вторая часть статьи.

Подробнее..

Краеугольный камень анализа. Часть 2

18.06.2021 00:22:38 | Автор: admin

Потребуется достроить пирамиду абстракций. За основу я использовал метамодели OMG Business Motivation Model и Open Group ArchiMate.

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

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

Оказывается, движущей идеей было создание пекарни с самыми вкусными яблочными пирогами. Это его vision. Логично, что у такой пекарни должен быть свой фирменный, самый вкусный яблочный пирог. Уметь делать его - является целью. А какой пирог является самым вкусным? Только свежий. Значит, нужно обеспечить длительное сохранение свежести это задача. Клиент рассчитывает, что реализация этой цели принесет ему ценность в виде дохода, а покупателям качественный товар.

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

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

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

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

Общий вид модели мотивации и стратегии, а также связь с моделью бизнеса. Пробежимся еще раз: Третья колонка слева это: Vision, Цели, Задачи. Элементы слева это ценности, которые представляются по достижению целей. Далее колонка в центре это способы: Миссия для достижения Vision, детализуется в Стратегии для достижения целей, далее стратегии детализируется в тактики для решения задач. Вторая колонка справа это средства реализующие способы. Это Бизнес-модель в интерпретации Остервальдера для выполнения миссии, Продукты, реализующие стратегии и операционная деятельность, реализующая соответствующие тактики. Последняя колонка это нижележащий уровень абстракций с бизнес-процессами, привычными для бизнес-аналитиков.

Метамодель

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

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

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

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

Добавим в таком представлении элементы стратегии и мотивации, который мы получили ранее.

Свернем их в один элемент, получим краеугольный камень анализа.

И вот ключевой вопрос:
Можно ли хорошо построить модель операционной деятельности без понимания стратегии и мотивации?

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

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

Примечание

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

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

А еще, наверно, можно развернуть мысль: Если у вас команда профессионалов, то неважно по какой методологии они работают.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru