Альфы — общий объект отслеживания организации/команды/коллектива/кооперации проекта ​

С одной стороны, многие члены организации/команды/коллектива/«рабочей группы»/кооперации проекта как индивидуальные оргзвенья, играющие определённые оргроли в проекте в порядке разделения труда занимаются каждый «своими» альфами. Далее мы не будем перечислять все возможные синонимы (в том числе и «проект» как синоним «организации проекта», а не работ этой организации --- это перечисление всего, что участвует в работах организации, как в 4D онтологии, все физические объекты, которые взаимодействуют в проекте, входят в объект «проект» через отношение участия/participation, поэтому что организация, что работы проекта так рассматриваемые, представляются более-менее одинаково, хотя и с разными акцентами в этом рассмотрении). Команду будем рассматривать в её функциональном рассмотрении: как оргроли, а не как играющие эти роли оргзвенья.

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

Меньшие степени взаимодействия приводят к другим результатам. Например, при кооперации результат одной операции подаётся на вход другой операции, но ответственности за итог в целом никто не берёт. Если кто-то выдаёт нитки, а кто-то шьёт парус, то кто-то может выдать гнилые нитки, а кто-то шить из них парус --- и тот, кто шьёт, будет шить великолепно (и получить за своё шитьё премию), но парус порвётся! А тот, кто выдаёт гнилые нитки, тоже будет уверен, что сделал своё дело отлично (ибо нитки сгнили по дороге к тому, кто шьёт --- какие претензии к изготовителю ниток?). В результате: кооперация есть, премии вроде как заработали все, а сотрудничества нет --- парус рвётся, деньги на премию заказчик не платит, да и за сам рвущийся парус не платит, у фирмы проблемы. Конечно, каждая новая степень взаимодействия включает в себя и предыдущие (нет сотрудничества без кооперации)[^129^[1]{#back_note129 .sspopuptext}]{.sspopup onclick="document.getElementById('back_note129').classList.toggle('show')"}:

• Игнорирование (ignorance) того, что делают другие люди, можем даже нанести им вред. При этом иногда заявляют «ничего личного, это бизнес» --- и что самое интересное, и заявитель такого верит, что это отличное оправдание, и даже те, кому вредят, вроде как «понимают мотивы». А поскольку игнорируем, то никакого общения, делами других не интересуемся, свои дела никому не показываем.
• Информирование и общение (networking): готовы общаться, но не готовы ничего менять в своих планах и действиях. Если кто-то готов подстроиться под нас, то и хорошо. Но сами работаем, как работаем. Скажем, вывешиваем часы своей работы --- но не готовы их менять даже когда кому-то очень надо.
• Координация (coordinated networking): готовы поменять какие-то свои планы и действия. Например, поглядеть на часы работы соседа и прийти в его рабочие часы. Заполнить форму, какую от меня требуют в той системе, в которой требуют, а не написать заявку в произвольном формате и отослать личным письмом.
• Кооперация (cooperation): участвуем в разделении труда и ресурсов, то есть договариваемся о том, как взаимодействуем на входных и выходных интерфейсах, согласовываем всё с соседями. При этом ответственность за то, что всё в целом будет как надо, у участников кооперации отсутствует. Если пиджачок сшит криво, и он ко мне попал на пришивание пуговиц, то я пришью пуговицы крепко, зубами не оторвёшь: к пуговицам точно претензий не будет, а что пиджачок в итоге кривой --- не моя забота.

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

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

Цель системного мышления --- всем участникам проектадоговориться об объектах коллективного сложного труда, ацель практики методологии --- скооперироваться и сотрудничать в коллективном сложном труде! Члены команды договариваются о том, что это за альфы (какие объекты в физическом мире им соответствуют) и о своих действиях по поводу этих альф, причём так, чтобы не было конфигурационных коллизий.

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

• Замышлена (conceived, внешние проектные роли согласились в необходимости новой системы для удовлетворения потребностей)
• Ограничена (bounded, функции новой системы в её окружении понятны)
• Непротиворечива (coherent, концепция использования непротиворечиво описывает существенные характеристики новой системы)
• Приемлема (acceptable, концепция использования описывают систему, которая приемлема для проектных ролей)
• Учтена (addressed, функции достаточно реализованы воплощением системы так, чтобы это было принято внешними проектными ролями как удовлетворение их потребностей)
• Удовлетворена (fulfilled, на текущий момент потребности внешних проектных ролей удовлетворены)

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

Мы не будем дальше писать тип, как в предыдущем абзаце «альфа описания системы», или даже «описание системы»::альфа. Люди не произносят названия типов, это вы должны сами внимательно следить за тем, какие типы у понятий, скрывающихся за терминами! Не говорят «система самолёт», говорят просто «самолёт». Не говорят «альфа описания системы», говорят «описание системы» (но это альфа/предмет интереса: объект, на котором вы должны удерживать ваше внимание в проекте). Если что-то меняется в проекте и эти изменения важно отслеживать --- это и есть альфа (чаще всего подальфа какой-то из основных альф, возможно из области интересов дальше по цепочке создания). То же про «проектную/трудовую/деятельностную/инженерную роль» как тип. Не пишем «трудовая роль бизнесмена/коммерсанта/предпринимателя/продавца», пишем «бизнесмен/коммерсант/предприниматель/продавец». Только иногда мы будем напоминать, что речь идёт именно об альфах, или проектных ролях, или системах. Но вы должны отслеживать типы объектов, задействовать«машинку типов» в своём мозгу! Иначе вы не сможете привязать знания о типе, которые вы узнали из нашего курса к объектам в реальности. Грубо говоря:

• в голове удерживаете типы мета-мета-модели изфундаментальных дисциплин (например, наших курсовсистемного мышления и методологии),
• в заголовках столбцов табличек прописываете типы из мета-модели предметной области с принятыми в учебнике (метаУ-модель) или в текущей ситуации на предприятии(метаС-модель) терминами. То есть вы выбираете из «почти синонимов» то, что будет понятно окружающим людям. Но эти типы в заголовках столбцов табличек будут типизированы типами мета-мета-модели трансдисциплин «в голове»,
• в ячейках строк табличек будут значения характеристик объектов операционной модели (модели экземпляров из реального мира), классифицированные типами мета-модели(из учебника, или ситуационной/принятой в предприятии) в колонках, которые классифицированы типами мета-мета-модели «в голове».

Отслеживать нужно все три уровня моделей! Без типов мета-мета-модели(типов из наших курсов, удерживаем внимание на них «в голове»)вы плохо будете выделять важные объекты внимания в предметных областях (из учебника, или на предприятии), наверняка забудете продумать культурно-обусловленные/«цивилизационно известные»важные характеристики системы и проекта, сделаете новичковые ошибки (или просто ошибки из-за несобранности личной или коллективной).

Если вы опять не поняли, что написано в этих выделенных абзацах, вам нужно повторно пройти курсы «Моделирование и собранность» и «Системное мышление» и выполнить там все задания по моделированию. Это обязательные пререквизиты к курсу методологии.

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

Операционного менеджера (в небольших проектах эту роль играет назначенный на должность «руководитель проекта», «тимлид») интересует система создания, его оргзвено. Для продвижения по состояниям концепции использования целевой системы (альфа области интересов целевой системы) операционному менеджеру нужно выделять время и ресурсы разработчиков.

«Станочный парк» многих проектов сегодня часто соответствует «парку корпоративных информационных систем». За них отвечает инженер производственной платформы. Чаще всего эта роль выполняется оргзвеньями под руководством CTO и/или CIO. В их ведении обычно и метод разработки, в том числе поддержка практик метода технологиями. Для практики разработки концепции использования целевой системы инженер платформы должен предусмотреть моделер, её поддерживающий (например, для практики use case выбрать какой-то моделер, позволяющий записывать результаты моделирования), а также предусмотреть управление конфигурацией для версий концепции использования (версий документов с моделями, входящими в концепцию использования целевой системы).

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

Примерно то же самое происходит и со всеми остальными альфами и подальфами, а не только с концепцией использования: состояния всех из них изменяются командой не порознь, а в тесной взаимосвязи, их изменения уторговываются командой, согласуются, о них договариваются, об их изменениях сообщают/извещают друг друга. Организация/команда/коллектив проекта совместно обсуждает текущее состояние альф и подальфпроекта и на основе этого обсуждения планирует шаги (работыпо каким-то методам/практикам) по достижению следующих состояний, далее следует планам и отслеживает их выполнение. Командадоговаривается о том, что такое в жизни эти альфы и каковы их состояния, а также сотрудничает в изменении состояний альф ---для этого она моделирует состояние альф («коллективное мышление моделированием»), удерживает внимание на этих важных объектах («коллективная собранность»). При этом план необязательно «от начала до конца проекта», планироваться и выполняться может каждый отдельный мелкий шаг в проекте в ходе не только начального создания, но и в ходе последующего непрерывного развития --- это agile, работа в рамках кейс-менеджмента. Главная идея в том, что это командное/коллективное/кооперативное/групповое/организованное сотрудничество, а не работа неорганизованных одиночек в разных ролях каждого над своей альфой.