Похоже у вас в команде не хватает исполнителей как минимум следующих ролей:
1. Продакт (это если вы делаете продукт) — будет говорить зачем пользователю ваш продукт.
2. Аналитик — он как раз и будет переводчиком с русского языка бизнеса на русский язык разработчика.
3. Архитектор — будет проектировать то как должен быть устроен ваш продукт.
4. Тимлид (выше уже говорили про него) — будет управлять командой разработчиков.

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

основной задаче программиста — создания хорошего кода

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

«Атлант расправил плечи» очень хорошо показывает, что происходит в мире, из которого уходят те, кто «тащат». Если не читали, то очень рекомендую. Судя по приведенному фрагменту «Фонтана», режиссер читал «Атланта».

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

Спасибо за интересную статью!

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

Самое сложное в организационных изменениях — это изменить мышление и привычные паттерны поведения людей согласно новым идеям. Мне очень любопытно как именно внедрялась эта практика 6-ти часового рабочего дня, а не какие результаты получены. Если было директивное внедрение в формате «с завтрашнего дня у нас 4 смены вместо 3», то это бред и это не сработает. Регламенты старые, нормативы старые, люди старые опытные. Все это надо перепроектировать:
* нужны новые регламенты под новые реалии 6-ти часового дня и 4-х смен в сутки;
* нужны новые нормативы под новые реалии;
* нужно людей научить работать в таком режиме.
… и только после этого можно выпустить постановление о переходе на 6-ти часовой день.

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

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

Честно говоря, я бы вообще предпочел формат уплаты налогов «пришел получать ЗП, получил 10.000 в одном окошке, отдал 6.000 в другом окошке, расстроился»

В Штатах именно так и есть. И там целая отрасль — налоговые консультанты, которые помогают тебе все налоги посчитать и выплатить правильно и вовремя.

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

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

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

Если пытаетесь построить модель реального мира, то вам к физикам. Они пытаются это сделать: уже дошли до кварков и продолжают копать глубже. А корпускулярно-волновой дуализм всегда все портит и не позволяет смотреть на объекты только как на объекты — приходится еще и о волнах думать. Да еще эта теория струн…

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

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

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

И да, как выше в комментариях уже просили — дайте определение понятию «операция», а то возможно мы за этим словом видим совершенно разные смыслы.

На какие-то специализированные не натыкался. В основном опыт + гугл + попытка рассказать команде/клиенту что ты смоделировал и реакция на обратную связь.

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

Когда получается в одну модель (но естественно на несколько диаграмм) уложить несколько уровней абстракции функций и объектов предметной области, и помимо этого еще и показать какими средствами автоматизируется та или иная функция (и какими программными объектами выражается тот или иной бизнес-объект). А если еще есть инструментальная поддержка навигации по этой модели (как например это умеет Sparx Enterprise Architect). Вот тогда понимаешь что значит комплексное моделирование с учетом разных точек зрения.

Некропост, но все же не удержусь.

Чем не устраивает BPMN? Лучше пока ничего нет, и в общем далеко не самое плохое из возможного.

Посмотрите в сторону ArchiMate. Летом вышла версия 3.0. Похоже, что создателям стандарта таки удалось ухватить необходимую и достаточную метамодель, которая позволяет описывать именно предметные области (деятельность), а не отдельные процессы или создавать отдельные модели. Выделение пассивных структур, активных структур и поведения и перпендикулярных им слоев (бизнес, софт, хард) позволяет весьма полно описать многие и многие аспекты как предметной области так и конкретного предприятия. А встроенная в стандарт концепция точек зрения (viewpoint) позволяет создать множество описаний одного и того же понятия.

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

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

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

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

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

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

Я лично проходил первую ступень, мои знакомые проходили вторую. Скорость, равно как и понимание текста, реально возрастают на порядок.

Не совсем стыдно, а немного стыдно. Прочтите эту фразу как «не надо впадать в паралич перфекциониста».

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

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

И совсем забыл акцентировать внимание на разделении понятий «viewpoint» и «view»:
* Viewpoint — это спецификация описания (модели).
* View — это само описание (модель).
В таком разделении выносить объект «точка зрения» в информационную модель не корректно — это метамодель.

Отвергнутый вам Архимейт предполагает разделение модели на Viewpoint'ы, приводя в пример определенный набор. Если вы будете использовать инструмент (а не стандарт), который позволяет представлять одну модель с разных точек зрения (например, Sparx Enterprise Architect или бесплатный Archi), то расположение одного объекта на разных диаграммах позволяет создавать эти связи между точками зрения.

Так же в Архимейте в разделе Motivation есть понятие "Driver":

Drivers may be internal, in which case they are usually associated with a stakeholder, and are often called “concerns”. Stakeholder concerns are defined in the TOGAF framework [4] as ”the key interests that are crucially important to the stakeholders in a system, and determine the acceptability of the system. Concerns may pertain to any aspect of the function, development, or operation of the system, including considerations such as performance, reliability, security, distribution, and evolvability.” /blockquote> А стандарт TOGAF напрямую определяет понятие «concern».