Метод разработки ничего не скажет об оргзвеньях
Не ждите от описаний метода разработки каких-то деталей**, подробного разложения метода на его составляющие****.** Нет, там будут какие-то общие сигнатуры методов. Скорее, детали вы найдёте в литературе по отдельным методам**.** Скажем, вам покажут, что «надо заниматься архитектурой»****— но вот какие методы принятия архитектурных решений, какие архитектурные метрики**—** этого не будет, за этим придётся лезть в литературу по методам архитектной работы в вашей предметной области, для вашего вида систем.
Орг-проектировщики обычно кладут в основу концепции организации метод разработки, по которому будет работать организация. Часто это даже не полный метод разработки, а только те методы, которыми будет заниматься организация. Скажем, если это завод — то только методы изготовления системы и методы инженерных обоснований в части испытаний, но не методы замысливания и проектирования системы. Или наоборот — если это КБ, то только методы архитектурной работы, проектирования, но не изготовления (хотя инженерам надо учитывать методы изготовления! Но оргпроектировщик этим не будет озабочен).
В отличие от инженеров целевой системы, которых тренируют думать о полных инженерных процессах, полных методах разработки (всё время создания и развития по ходу всех проектов всех организаций графа создателей! Учитывать и то, что уже происходило с системой и её описаниями, и то, что только будет происходить в будущем, включая попытки предсказать это будущее!), у орг-проектировщиков, а также у менеджеров в их разговорах с инженерами, во внимание обычно попадает только та часть методов, составляющих полный инженерный процесс создания и развития системы, которыми занимается вверенное им оргзвено. Оргзвено для них «наша система», и требуется довольно много труда, чтобы обратить их внимание на целевую систему и всех создателей в графе её создателей.
Не ждите от описаний метода разработки какой-то оргструктуры (органиграммы: кто кому подчиняется, решения орг-проектировщика) или структуры управления (централизованной, децентрализованной, матричной, функциональной и т.д., решения орг-архитектора). То есть в методе разработки не будут указаны отделы, команды. Не будут указаны сроки. Но будут указаны отдельные методы инженерной работы более подробно, чем сигнатуры одного уровня разложения — решения по конкретному варианту отдельных методов работы отдаются на откуп методологам соответствующих предметных областей.
Метод разработки — это поведение создателей, то есть изменения состояний предметов метода во времени, поэтому он представляется развёртками во времени:
- пару десятков лет назад это была диаграмма работ-стадий в физическом времени,
- потом двумерная диаграмма методов и стадий,
- современный вариант — это функциональная диаграмма связи методов по потоку их предметов в логическом времени, а
- самый современный вариант представляет собой исполняемые варианты в каких-то табличных моделерах, часто связанных с issue tracker, что позволяет связать в жизни управление процессом/методом разработки с управлением работами.
При обсуждении метода разработки вопрос «кто::оргзвено это выполняет» обычно остаётся за рамками обсуждения, а вопрос назначения ресурсов поднимается только при обсуждении управления работами. Например, обсуждаем выбор метода создания концепции системы (метод, который будет изменять состояния альфы концепции системы), а потом назначаем работы по выбранному методу на оргзвено, имеющее оргвозможность/capability выполнять этот выбранный метод, то есть на такое оргзвено, которое:
- имеет людей и AI-агентов с нужным мастерством,
- моделеры с нужными шаблонами, или на которых можно эти шаблоны получить и подстраивать, если метод включает в себя рекомендации по адаптации шаблонов моделирования,
- имеет полномочия по трате времени и других ресурсов на выполнение этого метода создания концепции системы, да ещё и
- это время, и все другие ресурсы наличествуют.
Это два разных вопроса: 1. Как будем работать, по какому методу (функциональный) и 2. Кто будет работать (конструктивный). Сама работа получается только после ответа на оба вопроса!
Физическое время тоже нельзя найти в описаниях метода разработки, там «работы по составляющим методам для указанных нами сигнатур выполняются, когда возникнут для этого обстоятельства». Физическое время надо смотреть в моделях управления работами (планы-графики в системах проектного управления, штампы времени в выдачах трекеров) соответствующих проектов, а на диаграммах процессов разработки или в описаниях методов их не увидишь. Конечно, всегда могут быть гибридные описания (скажем, в регламентах предприятия вполне может быть описан какой-то метод, а также указано, кто именно из оргзвеньев выполняет по нему работы), но всё-таки эти гибридные описания в литературе редки, они встречаются именно как результат адаптации методов к условиям конкретных проектов, конкретных организаций.
Для продуктовых линий (product lines[1], иногда product families, когда из стандартных модулей собираются разные конфигурации системы для разных потребностей, и это происходит на нескольких системных платформенных уровнях), инженерные процессы разных таких платформ как частей системы или систем в окружении могут быть переплетены причудливым образом. Нужно всегда помнить, что системы выделяются из окружающего мира субъективно (хотя это и хорошо организованная субъективность! Все договариваются, системное мышление для этого!), в зависимости от интереса роли, выполняющей какой-то частный метод работы в рамках инженерного процесса со множеством участников в весьма сложном графе создателей.
И даже выявление (прежде всего — моделирование, модель делает невидимое видимым, даёт возможность обсуждения и основу для договорённостей) метода разработки как поведения создателей в их графе — субъективно. Разные агенты (люди и AI-системы) с разным опытом и предложат разные варианты «инженерного процесса»/«метода разработки» для одной и той же системы, и опишут по-разному составляющие методы уже полным ходом идущей разработки и последующего развития системы, и признают в ней разные «виды методов разработки» и даже «модели жизненного цикла».
Ещё нужно помнить, что метод разработки может существенно дрейфовать по ходу проекта. Там постоянно будет идти совершенствование, будет заменяться инструментарий, но в любой момент может быть затеян переход на новые методы работы — создатели системы тоже развиваются, так что организации, занимающиеся созданием и развитием системы будут непрерывно развиваться. Более того, «развитие организации»/«организационное развитие»****/transformations— это и есть изменение **инженерного процесса в этой организации, изменение методов работы, получение новых оргвозможностей!**И даже какой-нибудь «выход на рынки Юго-Восточной Азии» — это прежде всего создание оргвозможности по созданию клиентуры в этом регионе, оргвозможностей по дистрибуции и сервисному обслуживанию. Это всё про методы работы, про инженерный процесс. И инвесторы, и клиентура, и целевая система, и создатели из их графа (в том числе личности сотрудников) — они все сами тоже создаются и развиваются, поэтому все рассуждения об «инженерном процессе»/«методе разработки» применимы и к этим объектам, хотя там могут быть какие-то терминологические особенности.
Нужно всегда помнить, что должна быть оргвозможность управления методом разработки, управления инженерным процессом, оргвозможность оргразвития: кто-то::роль с его инструментами моделирования методов инженерии и мастерством это делать должен проектировать метод разработки и превращать его в оргвозможность (чаще всего это ответственность CTO или CIO с их службами, и там особо выделим роль методолога, оргпроектировщика, оргархитектра и лидера, чтобы договариваться со всеми причастными).
У ответственного за метод разработки должны быть полномочия убирать из проекта (а то и увольнять из компании) сотрудников, которые не хотят или даже просто не умеют работать по составляющим методам из разложения выбранного метода разработки, а также не хотят или не умеют работать в предложенном варианте инженерного процесса. Если какой-то инженер будет считать, что он работает по «водопаду» в команде, которая придерживается какого-то варианта гибких методов разработки, то или он смиряется и тоже работает по предложенным практикам гибкой разработки, или просто увольняется (уговаривать может быть дольше и дороже: он успеет своей вроде как работой нанести много вреда, будет ведь много конфигурационных коллизий, которые потребуют тратить на его упрямство и неумение время многих других инженеров. Проще уволить, и это правильно: пусть вовремя повышает квалификацию).
Обязательно узнайте метод разработки не только целевой системы, вашей системы где-то в цепочке создания, но и их надсистем, и даже создателей (то есть методы разработки, которые применяют внешние проектные роли в проектах создания всех этих систем). И у систем в окружении целевой, и у создателей (станков, организаций), как и любых других систем, тоже есть свои методы создания и развития, свои инженерные процессы, а для работ по их созданию и развитию их создатели тоже используют методы управления работами.
Вот это одновременное удержание внимания на целевой системе в её окружении****и методах/функциях её работы в первую очередь**,** а****работах по методам выбранного инженерного процесса (поведении системы создания**)** во вторую очередь и отличает системного мыслителя. Системное мышление**—** это всегда первый мыслительный ход от целевого объекта рассмотрения наружу, к окружению, а не внутрь к частям**. Затем внутрь к частям****—** и после этого обязательно к создателям, сначала их методам работы (инженерный процесс и роли его исполнителей), а затем и к самим работам и исполнителям этих работ (оргзвеньям).
Конечно, это мы ещё раз очень кратко помянули системную мантру.
И все поминаемые в ходе прохождения системной мантры объекты надо моделировать, не надейтесь на то, что разбираться с инженерными процессами удастся «умозрительно»! Разбираться надо исключительно по моделям! В первом разделе мы рассказали как моделируются функциональные описания, во втором разделе рассказали, как поменялся предмет моделирования в инженерном процессе (с моделирования работ перешли к моделированию методов), в третьем разделе мы показали, как по-разному могут выглядеть верхнеуровневые описания инженерных процессов на уровне сигнатур методов. Дальше мы расскажем, как моделировать отдельные методы работы, чтобы их выполнение было удобно отслеживать в ходе организационного развития, то есть получении новых оргвозможностей.