Контекст: я хочу научиться плавать, чтобы иметь более сильное и здоровое тело
1. Целевая система: сильное здоровое тело
2. Надсистема: более продуктивный человек
3. Внешние роли: я в роли ученика, мои потребности: сильное здоровое тело,
Внутренние роли: тренер по плаванию, его потребности: сделать мое тело сильным и здоровым, обучив меня правильной технике плавания
4. Требования к системе: постановка правильной техники плавания
5. Архитектура: отдельные движения во время плавания, их последовательность.
6. Практики и методы: подготовительные упражнения на суше, постановка техники дыхания, практика плавания кролем
7. Система обеспечения: плавание
8. Подсистемы: тело и движения тела
Юлия, спасибо за пост!
Описание однозначно улучшилось) но его еще можно доработать. Что я бы порекомендовала уточнить:
- целевую систему и надсистему) "сильное и здоровое тело" для "повышения продуктивности" – это какие-то общие слова (да, сильное и здоровое тело, конечно, лучше слабого и больного, если нужна продуктивность; но что именно вы от тела хотите? помогут ли вам, например, прокачанные икроножные мышцы с продуктивностью? или вы хотели что-то еще?). Почему именно плавание выбрано в качестве системы обеспечения для сильного и здорового тела, а не, скажем, скалолазание? Системное разбиение должно вносить ясность, давать ответ на вопрос "почему/зачем/для чего" (надсистема), "что именно" (целевая система), "каким образом это сделаем/организуем" (система обеспечения). Если системное разбиение проведено на "отлично", то ответы на эти вопросы должны быть понятны даже человеку, который в первый раз видит этот текст.
- потребности. Все-таки целевая система =/ потребности (а тут они совпали). Потребности описывают надсистему как "черный ящик" (без знаний об устройстве этого ящика). Например, потребностью может быть "хочу реже ходить к врачам – 1-2 раза в год, а не 1-2 раза в месяц". Чтобы описать потребности хорошо, нужно точнее выделить надсистему и внешние проектные роли.
- потребности есть у внешних проектных ролей, которые за удовлетворение этих потребностей/неудовлетворенностей заплатят. Вообще, с внешними проектными ролями и внутренними мы работаем по-разному: внешние роли выявляем, сегментируем (сразу говорим, потребности каких ролей тут не будут удовлетворяться), описываем. Внутренние роли может потребоваться выявить/определить в ходе какого-то проекта, но исполнителей внутренних ролей мы еще и нанимаем. С их потребностями тут не работаем, они приходят в проект, уже согласные что-то делать (а если не согласны – есть практики лидерства).
- требования и архитектура прописаны не для целевой системы. Если ЦС – "сильное и здоровое тело", то требования должны описывать это самое сильное и здоровое тело, а они сейчас описывают технику плавания. Архитектура – аналогично. Архитектура должна описывать, какие именно штуки вам важны в теле, чтобы его вообще можно было назвать "сильным и здоровым" и дальше продуктивно эксплуатировать в какой-то деятельности.
- лучше сначала называть систему обеспечения, и только потом практики. Почему – поговорим на тренинге 10)
- если тело – цс, то подсистемой оно быть не может))
Анна, большое спасибо за комментарий! Иду исправлять! А вот мне пример с плаванием как раз очень интересен, т.к. с 1 сентября я действительно иду учиться плавать )
Отлично, тогда будет интересно посмотреть на следующие версии)
Подсказка: чтобы создать хорошее описание, понадобится изучить немного прикладной информации по практикам задействованных ролей. И начать лучше с подбора хороших источников информации по теме плавания.
В блоге есть пост “Практика формирования ленты новостей по интересам”, можно посмотреть там, как отобрать такие источники.