Образование для образованных. 2021 - стр. 49
Одни из этих объектов внимания – это трудовые/деятельностные/проектные роли. Они могут быть в команде проекта и отвечать за создание целевой системы этого проекта, но могут быть и внешними, у которых другие их целевые системы, а целевая система команды для них интересна только по сопричастности к их целевой системе (целевой системой едока за обедом в кафе будет не еда, а сытый его желудок. И для этого ему нужна еда, которую готовит команда поваров). Трудовые роли всегда играют люди – в маленьких проектах один человек играет множество ролей, а больших проектах одну роль играет множество людей.
Так, в проекте курса если у вас учебная организация из одного человека, то этому человеку придётся играть все эти роли. Если у вас большой университет, то там множество исполнителей каждой из ролей. Если вы пошли работать в какой-то образовательный проект, то лучше бы вам иметь тут какой-то трудовой кругозор (общие представления о том, как устроено ролевое разделение труда в образовательном проекте, какие практики/деятельности выполняют разные трудовые/деятельностные роли) и прочесть хотя бы один учебник по практике каждой роли, чтобы понимать происходящее в проекте.
Если вернуться к описанию проекта общего вида, то за основу там принят инженерный проект общего вида, где предприниматели находят возможность выполнения проекта, и инженеры реализуют эту возможность, проектируя и изготавливая систему (сервис – это просто участие в изготовлении системы, только из материала заказчика: парикмахерская предоставляет услугу, изготавливая причёску из материала заказчика), а менеджеры организуют этот проект. В любом случае все роли удерживают во внимании самые разные важные изменяющиеся в ходе выполнения проекта объекты, но интересуют их разные свойства этих объектов и разные изменения.
Например, по поводу объекта «требования» (requirements) как части объекта «описание системы» в проекте будут договорённости между следующими ролями, которые занимаются этими требованиями с самых разных сторон:
Системный инженер интересуется требованиями как описанием целевой системы инженерного проекта (и его ещё интересует надсистема, на которую он мог бы как-то влиять). Предпринимателя интересуют требования как удовлетворяющие потребностям внешних проектных ролей и возможность сделать проект с такими требованиями. Менеджера проекта интересуют сроки разработки требований и ресурсы на их разработку (кто из членов команды будет этим занят), а также сроки разработки самой описываемой требованиями системы и требуемые для разработки ресурсы. Главного инженера/айтишника предприятия (CTO/CIO) интересует метод разработки требований и требуемый для поддержки этого метода софт инженерии требований.
Так что в проектах с ролями разобраться важно: у разных ролей разные интересы, и нужно всегда знать, с кем в какой роли говоришь, чтобы его понимать и давать правильный ответ. Ответ Принцу Гамлету или Васе Пупкину, который исполняет роль Принца? Ответ Принцу Гамлету или тени отца Гамлета? Ответ архитектору проекта или Васе Пупкину?
Вот пример реплики старшего программиста (это должность, не роль! Это ведь про ответственность – «старший», а не про то, какую роль будет играть этот «старший программист» в реальных проектах) на совещании: «когда я вчера смотрел на график нашего проекта, то понял, что нам может не хватить времени на тестирование, поэтому неплохо бы озаботиться контрактацией дополнительных серверов для этой работы».