Стейкхолдеры. Субъективность восприятия реальности


4 мес. 3 нед. назад - 4 мес. 3 нед. назад #54018 от Александр Запорожцев
Александр Филонов пишет:

\
А когда SADT говорит о субьекте, она имеет ввиду человека или систему?

Если "Поэтому субъектом моделирования служит сама система" - субъект моделирование это то, что мы моделируем.
Я предлагаю прекратить обсуждать термины - лучше обсуждать суть обсуждаемого вопроса.
Вопрос Как разрабатывать проект модернизации системы на основе выявления функциональных требований стейкхолдеров, позволяющих устранить действие нежелательных явлений в работе системы?
Функциональные требования - требования стейкхолдера к функции поставщика, которые формулируются в рамках следующего шаблона: Для обеспечения <результата>необходимо, чтобы поставщик выполнял <требование>.

Суть вопроса:
1. Рассматриваться ситуация начала проекта модернизации существующей деятельности, что означает наличие неудовлетворенности в результатах этой деятельности
2. Я обозначаю эту неудовлетворенность как Проблема, которую можно конкретизировать в виде нежелательных явлений в этой деятельности
3. Инициатор проекта формулирует свое понимание того, что должно быть сделано. Эту формулировку я рассматриваю как требование стейкхолдера - инициатора проекта.
4. В рамках стандартного проектного подхода это требование формулируют как цель проекта.

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад #54019 от Георгий Лейбович
Александр Запорожцев пишет:

...
Я предлагаю прекратить обсуждать термины - лучше обсуждать суть обсуждаемого вопроса.
Суть вопроса:
1. Рассматриваться ситуация начала проекта модернизации существующей деятельности, что означает наличие неудовлетворенности в результатах этой деятельности
2. Я обозначаю эту неудовлетворенность как Проблема, которую можно конкретизировать в виде нежелательных явлений в этой деятельности
3. Инициатор проекта формулирует свое понимание того, что должно быть сделано. Эту формулировку я рассматриваю как требование стейкхолдера - инициатора проекта.
4. В рамках стандартного проектного подхода это требование формулируют как цель проекта.


Возможно, это суть вопроса :) А где сам вопрос? Потерялся? А по-моему, он так и не был сформулирован.

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад - 4 мес. 3 нед. назад #54020 от Александр Запорожцев
Георгий Лейбович пишет:

А где сам вопрос? Потерялся? А по-моему, он так и не был сформулирован.

Вопрос сформулирован в Предыдущем сообщении

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад - 4 мес. 3 нед. назад #54021 от Александр Филонов
Александр Запорожцев пишет:

Вопрос сформулирован в Предыдущем сообщении


А где сумасшедший? - спросили санитары у трапа.
Сумасшедший молча показал пальцем на следующего за ним капитана.:laugh:

Вы когда постфактум формулируете <вопрос> извиняйтесь хотя бы.:) :laugh:

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад - 4 мес. 3 нед. назад #54022 от Александр Филонов
Александр Запорожцев пишет:

Я предлагаю прекратить обсуждать термины - лучше обсуждать суть обсуждаемого вопроса.
Вопрос Как разрабатывать проект...


А что <Как>?

Link1

Link2

Link3

Что конкретно из <как> вы хотите обсудить?

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад - 4 мес. 3 нед. назад #54023 от Александр Запорожцев
Александр Филонов пишет:

А что <Как>?

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

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад #54024 от Александр Филонов
Александр Запорожцев пишет:

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


Для начала давайте уберем "6 сигм". Я понимаю Ваше желание бросить камень в огород 6s, Lean или ТОС. Давайте назовем - "несмотря на то, что выполнен проект АЗ". Т.е. Вами. Так будет ближе к сути. И быстрее Вам поможет выйти на коренную причину.

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад #54025 от Александр Запорожцев
Александр Филонов пишет:

Для начала давайте уберем "6 сигм".

Заменил на "проект улучшений"

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад #54026 от Александр Филонов
Александр Запорожцев пишет:

Например, требование - несоответствия не должны повторятся. ...<... >
Как можно составить список нежелательных явлений для этого случая?


<несоответствия не должны повторятся>

Список НЯ:

1. Несоответствия повторяются.
2. ???

Пожалуйста Войти , чтобы присоединиться к беседе.


4 мес. 3 нед. назад - 4 мес. 3 нед. назад #54027 от Александр Запорожцев
Александр Филонов пишет:

<несоответствия не должны повторятся>

Список НЯ:

1. Несоответствия повторяются.
2. ???

2. Информация а Акте о несоответствии недостаточно для анализа причин несоответствий
3. Выявляются только предполагаемые причины несоответствий
4. Нет подтверждения предполагаемой причины несоответствий
5. Отсутствуют практики оценки результативности КиПд и их учета при планировании КиПд
Если меня спросить - откуда я взял этот список - мне будет трудно объяснить, как я его составил.

Пожалуйста Войти , чтобы присоединиться к беседе.

Работает на Kunena форум