Анатолий Левенчук - Образование для образованных. 2021

Например, по поводу объекта «требования» (requirements) как части объекта «описание системы» в проекте будут договорённости между следующими ролями, которые занимаются этими требованиями с самых разных сторон:

Системный инженер интересуется требованиями как описанием целевой системы инженерного проекта (и его ещё интересует надсистема, на которую он мог бы как-то влиять). Предпринимателя интересуют требования как удовлетворяющие потребностям внешних проектных ролей и возможность сделать проект с такими требованиями. Менеджера проекта интересуют сроки разработки требований и ресурсы на их разработку (кто из членов команды будет этим занят), а также сроки разработки самой описываемой требованиями системы и требуемые для разработки ресурсы. Главного инженера/айтишника предприятия (CTO/CIO) интересует метод разработки требований и требуемый для поддержки этого метода софт инженерии требований.

Так что в проектах с ролями разобраться важно: у разных ролей разные интересы, и нужно всегда знать, с кем в какой роли говоришь, чтобы его понимать и давать правильный ответ. Ответ Принцу Гамлету или Васе Пупкину, который исполняет роль Принца? Ответ Принцу Гамлету или тени отца Гамлета? Ответ архитектору проекта или Васе Пупкину?

Вот пример реплики старшего программиста (это должность, не роль! Это ведь про ответственность – «старший», а не про то, какую роль будет играть этот «старший программист» в реальных проектах) на совещании: «когда я вчера смотрел на график нашего проекта, то понял, что нам может не хватить времени на тестирование, поэтому неплохо бы озаботиться контрактацией дополнительных серверов для этой работы».

Какой выберете вариант продолжения беседы?

• Инженерный: какие ошибки требуют дополнительных серверов для их тестирования? Можем ли мы уменьшить объём тестирования?

• Менеджерский: у нас предусмотрено это бюджетом, или как всегда? У вас есть проект контракта? Кто найдёт поставщика?

Можно ли верить, что «старший программист» желает обсудить свои, инженерные аспекты дела, исполнитель этой роли и вправду выступил как инженер-программист? Или он выступил как операционный менеджер, ибо ведь «старший»? Или его вопросы риторические, то есть он знает ответы, но строит какую-то интригу и занимает какую-то другую роль?

Вы бы сами какую линию разговора повели: чем бы озаботились, о чём спросили? Как кто бы вы поступили в этом разговоре, то есть какое бы своё мастерство вытащили в качестве основного? Где и как вы учились этому мастерству, или «самоучка, в разговорах нахватался»?

Вспомните, когда последний раз в разговоре вы проводили такой анализ «кто и о чём говорит – кто и о чём должен бы ему отвечать»? Точно ли не путали «действующее лицо» и «исполнителя» (Принца Гамлета и Васю Пупкина, инженера по требованиям и Дарью Михайловну, преподавателя и Петра Аристарховича)?

Отслеживаете ли вы смену предметов разговора, когда и роль тоже меняется, и используемая ролью дисциплина – вдруг начинают звучать совсем другие слова, другие термины? Как долго можете удерживать внимание на диалоге – в любой момент понимая «кто говорит – кто отвечает – предмет обсуждения»?

Приобрести ролевое мастерство как мастерство занятия и удерживания роли сразу не получится. Этому нужно целенаправленно учиться. Хорошо бы ещё в школе, и уж точно в бакалавриате.

И если вы считаете, что вы «над схваткой», вы «выше всех этих ролей», то это вы только сами себя так оцениваете. Окружающие оценивают вас ровно наоборот: как человека скользкого, который непонятно что в проекте делает, на которого непонятно в чём можно положиться, который «непонятного уровня квалификации в непонятной практике, скорее всего никакой квалификации в никакой практике». Так что лучше бы вам как-то ясно давать понять людям, какую вы роль играете в проекте, какой ваш ролевой интерес, что от вас можно ожидать в этом плане.

ОСНОВНЫЕ ВИДЫ ТРУДА:

ИНЖЕНЕРИЯ, МЕНЕДЖМЕНТ, ПРЕДПРИНИМАТЕЛЬСТВО

А. Тюков выделял в 1997 году 16 сфер деятельности 89 89 http://psyhoinfo.ru/programma-sozdaniya-obshchestvennoy-professionalnoy-sfery-prosveshcheniya : политика, религия, философия, искусство, наука, образование, здравоохранение, физкультура и спорт, технология, проектирование, коммерция, финансы, право, армия, материальное производство и «пока неоформившееся просвещение». В основу выделения этих сфер А. Тюков ставил идущие в этих сферах основные процессы/практики/деятельности. Для здравоохранения/медицины – лечебная деятельность, для армии – защита границ и государственного устройства. Такое структурирование деятельности, основанное на сферах (часто ассоциируемыми с организационными структурами: бизнес-экосистемами, министерствами с подведомственными им предприятиями) широко обсуждался в кругах СМД-методологов, и мы возьмём его за основу, чтобы не сочинять что-то самим.

Мы можем существенно упростить мышление обо всех этих деятельностях, если подметим: они все связаны с созданием или изменением состояния каких-то товарных (продукты) или даже чужих (сервисы) целевых систем. В этом плане во всех деятельностях можно найти их «инженеров» (например, в здравоохранении/медицине это врач, в образовании это педагог), но как мы увидели на примере курса, этих занимающихся изменением мира «инженеров» может быть довольно много разных, и они ещё и будут носить разные имена (например, в образовании это педагог, но и он разбивается на две подроли – работающего с пониманием студента «предметника» и работающего с мотивацией студента «лидера»).

Вот этот кругозор в разделении труда в самых разных проектах будет трансдисциплинарен (транс- тут означает, что «по ту сторону от встречающихся в проекте дисциплин» 90 90 https://en.wikipedia.org/wiki/Transdisciplinarity – мы говорим не столько о содержании практик, которыми занимаются исполнители проектных ролей, сколько о том, какие именно это практики и все эти практики собираются вместе в один проект).

Проще всего деятельность в проекте описывать, используя системный подход и системную схему проекта с её заданием важных объектов проекта как объектов предпринимательского (возможность, внешние проектные роли), инженерного (воплощение системы/целевая система, описание системы), менеджерского (работы, команда, метод/способ работы) интереса.

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