Согласен, рамки важны. Изначально и презентация и статья адресовалась
- начинающему разработчику
- начинающему аналитику
- начинающему руководителю проектов
И я думаю, что рамки установим такими: культура деятельности, связанной с автоматизацией деятельности (каламбур, однако
).
Я имел в виду несколько рамок, применительно к перечисленным Вами специализациям можно предложенные мной рамки переименовать как
«рамка контекста деятельности разработчика» (я её назвал «рамка автоматизация деятельности»)
«рамка деятельности аналитика» (рамка бизнеса)
«рамка деятельности по управлению проектами» - рамка деятельности, "перпендикулярная" деятельности в предыдущих контекстах.
Принципиально важно, что рамок
несколько. Для каждого тезиса хорошо бы сразу говорить, какому контексту он соответствует, примерно так, как Вы сделали в следующем цитируемом фрагменте. Это позволяет рассматривать проблему как взаимодействие заинтересованных лиц, причем эти лица могут смотреть на проблему каждый из своего конкретном контекста.
К тому же каждая специализация часто вкладывает свой смысл в термины и понятия.
Не совсем так. Типичны такие проблемы, связанные с автоматизацией деятельности:
- отсутствие критического взгляда молодых разработчиков на ставящиеся задачи и отсутствие критического взгляда на целесообразность собственных действий (это культура разработки)
Првильно ли я понял - это всё в рамке разработки?
- отсутствие инструмента верификации и упорядочивания материалов обследования заказчика (это культура системного и бизнес-анализа)
Стоит ли относить это к бизнес-анализу (даже в плане «только» культуры бизнес-анализа)? Ведь речь идет о контроле результатов работы бизнес-аналитика. Если приобретение культуры бизнес-анализа предполагает, что данное лицо фактически должно уметь проводить бизнес-анализ, то это обесценит разделение труда между бизнес-анализом и разработкой.
Может быть, как раз, ценным было бы вооружить разработчика специфическими представлениями, общими для разработчика и бизнес-аналитика (так сказать, пересечение множеств необходимых знаний разработки и бизнес анализа)? В частности, например, Ваше утверждение об избегании колец в иерархии целей, если его удастся развернуто обосновать, могло бы ИМХО претендовать на инструмент из пересечения компетенций бизнес-аналитика и разработчика
- отсутствие критического взгляда заказчика на собственные цели и цели, которые он ставит перед проектом автоматизации (это культура управления)
Это также всё предполагается, что можно раскрыть, детализировать в рамке разработки? Или в рамке управления проектами?
И все эти проблемы - это во-первых отсутствие культуры целеполагания, во-вторых - отсутствие навыков целеполагания. Именно в таком ракурсе хотелось бы излагать материал.
Навыки невозможно выработать без практики. Поскольку Вы предполагает воздействовать на потенциальную аудиторию словом, наверное, имеет смысл ограничиться формализацией знаний, которые представляют именно теоретическую ценность (но для практического применения)?