Материал из PL Engineering
Метод инженерии требований (что делает инженер по требованиям)
Международный совет по системной инженерии — INCOSE (англ. International Council on Systems Engineering) — некоммерческая организация, ставящая своей целью развитие системной инженерии и профессиональный рост системных инженеров.
Инженерия требований - это социотехническая дисциплина (так написано во всех учебниках), т.е. инженерия требований - это про работу с людьми.
Инженер по требованиям (вид) - это системный инженер (род), специализирующийся в методах (поддисциплинах) инженерии требований. Инженер по требованиям должен быть:
- инженером (разбираться в ситуационной инженерии инженерных методов [пардон за рекурсию "инженерий"], владеть системным мышлением).
- психотехником (т.е. владеть психотехнологиями, работать с конкретными людьми)
- социотехником (т.е. владеть социальными технологиями - работать с безличными группами людей)
- грамотным человеком в смысле Alan Kay, (т.е. владеть компьютерным моделированием)
- и получить в этом всем надлежащее образование и тренинг.
1. Психотехник занимается тем, что упихивает живых людей с их фонтанирующими в разные стороны личными интересами (у кого выпить, у кого "самореализоваться", а у кого и похуже) в рамки культурно-обусловленных позиций ("пользователь", "архитектор", "регулятор", причем поспецифичней и часто поэкзотичней). Как замечал Форд, "удивительно, но когда мне нужна лишь пара рабочих рук, я получаю всего рабочего впридачу". Вот этим преобразованием "всего рабочего" в "пару рабочих рук" и занимается психотехник (с учетом захода в коучинг).
Если живой человек в такую позицию не упихивается (например, "вор" по внутреннему ощущению не будет упихиваться в позицию "представитель инвестора" - его решения по проекту будут приводить к уменьшению прибыли "инвестора", но зато к обогащению его самого), или живых людей слишком много, и нет возможности сделать, чтобы они договорились (например, много-много департаментов крупной организации, каждый из которых себя и считает истинным представителем организации-позиционера), или живой человек недоступен по каким-то иным причинам, психотехник рекомендует сразу перейти к социотехнике (и тогда говорят про "метод персонажа").
Живые люди на схемах не находятся, они живут, кушают и ходят в туалет. Психотехник работает с живыми людьми, а не "позициями". Это социотехник работает с "позициями".
Методы работы: психотехнологии. Хоть как-то с этим разбирались (лучшие) СМД-методологи (в их ипостаси игротехников) и (обычно не меньше чем тренеры, и то не все) НЛП. Конечно, полным полно людей, которые это хорошо умеют делать "без метода", на собственных гениальных способностях. Эти методы еще ждут своего моделирования (и трудность тут в том числе и в том, что широкое знание о них подразумевает соответствующее развитие контрметодов. Так, знакомые с игротехникой люди начинают нервно реагировать на любые похожие на игротехнику приемы работы -- см., например, . То же самое было бы, если бы люди были знакомы с приемами работы НЛП-мастеров. Люди не любят, чтобы их куда-либо "упихивали" ментально, если это не образовательная ситуация. Проект же не представляется образовательной ситуацией для участвующих в нем людей. Это искусство психотехника представить проектную ситуацию как возможность для роста. Вообще-то этим обычно занимаются менеджеры, но человек, занимающий позицию инженера по требованиям должен быть готов к такой психотехнической работе: отнюдь не все менеджеры хорошо выполняют в проектах свою психотехническую работу...
Психотехник должен также понимать про те самые культурные "позиции", в которые должен быть упихнут ментальный кисель будущей заинтересованной стороны. Это дополнительная трудность, тут нельзя "обратиться к психологу", ибо психотехники, применяемые бесцельно, не ведут к результату. Так что психотехник существенно в своих задачах пересекается с социотехником, вряд ли это разные люди (хотя такое регулярно случается).
Тут также игнорируем традиционные базары и разборы "манипулятивности" любой психотехнической работы с людьми (ибо любая коммуникация кого-то в чем-то убеждает, заставляет узнать новое, переубеждает -- и дальше нужно определяться, в какой форме и с какими целями этично вступать в коммуникацию, и "что такое манипуляция").
Тренированный культурный человек (живая тушка) легко надевает на себя какую-то "позицию" (метод работы, подразумевающий какие-то цели и ценности) и железно ее удерживает - равно как легко (сознательно!) снимает и меняет (сознательно!) на другую. Задача психотехника в коучинговой ипостаси обучить человека, играющего роль заинтересованного лица, этим техникам.
Главный артефакт в работе психотехника - человек, который становится заинтересованным лицом.
2. Социотехник извлекает (из живого человека, или из литературы, или еще каким-то образом) требования заинтересованной стороны. Заинтересованная сторона - это та схема ("пара рабочих рук"), которая осталась от живого человека ("всего рабочего"), упихнутого в культурно-обусловленную профессиональную, общественную, управленческую, экспертную или какую-то еще позицию. На схеме появляется стилизованная фигурка ("морковка" в СМДМ, "бюст героя" в PowerPoint-2007, или застывшая упячка у предпочитающих моделировать в стереотипах UML).
Инженер по требованиям как социотехник ответственен за то, чтобы обнаружить и учесть все заинтересованные стороны проекта, включая разработчиков (являющихся заинтересованными сторонами по определению).
Заинтересованные стороны (stakeholders) живут в диаграммах (а живые люди их "играют", как роли в театре - кто лучше, кто хуже, кто натужно, кто искренне, кто "играет, как живет = живет, как играет", а кто-то по системе Станиславского).
Заинтересованные стороны ожидают, что система адресует их интересы (concerns), и поэтому требуют специализированных описаний для каждого из своих интересов. Они ожидают, что для них будут подготовлены экономические, эксплуатационные, инженерные, логистические и самые разные другие описания, из которых они поймут, что их интересы удовлетворяются.
Инженер по требованиям создает специальное описание проекта (на формальном языке: модель), в котором отражены заинтересованные стороны и их интересы (цели, намерения). По ходу принятия архитектурных (то есть "основных проектных") решений (средств достижения целей заинтересованных сторон) на этой модели отражаются также эти решения, и показатели достижения этими решениями целей заинтересованных сторон (ключевые показатели эффективности проекта).
Поскольку требования заинтересованных сторон противоречивы, то либо находятся (архитектурные) решения, снимающие эти противоречия (эти решения предоставляются архитектором), либо проводятся переговоры между людьми, исполняющими роль заинтересованных сторон (в этой ситуации опять приходится прибегать к помощи психотехников, ибо живые люди вовсе не стремятся участвовать в переговорах, и уж тем более удерживать на этих переговорах какую-то рациональную позицию). За то, чтобы было найдено устраивающее всех решение, и не возникло какого-то социального (между людьми) конфликта позже по жизненному циклу, отвечает социотехник.
Обратим особое внимание на тонкую разницу: психотехник занимается такими вопросами, как поддержание эмоционального фона при групповых встречах, групповая динамика в коллективе проекта и т.д. - работает с "живыми людьми". А вот социотехник работает с "социумом": проводит принципиальные переговоры, выявляет пропущенные профессиональные позиции, помогает сформулировать непротиворечивые требования заинтересованных сторон, соответствующие их интересам и т.д. - его работа не с самими людьми, а с взаимодействием позиций, проектными (непсихологическими) "отношениями" в коллективе проекта.
Главный артефакт социотехника - описание мотивации (описание целей, описание результатов, описание интересов).
Для выражения этих описаний в форме (датацентрической) модели уже сегодня можно найти множество языков моделирования и поддерживающих их инструментов, в которых с различной подробностью выражаются вопросы удовлетворения какими-то указываемыми для каждого проекта "средствами" (means) каких-то "целей" (ends):
- дерево действий и результатов Голдратта (но там нет "заинтересованных сторон" в явном виде), зато есть "доказательства"
- OMG BMM (business motivation model), но там все подогнано под систему=предприятие, и нет выхода на собственно модель системы
- URN, i* и прочие языки GORE (goal-oriented requirement engineering).
- позиционные диаграммы СМДМ
Все эти модели обладают важным социотехническим свойством: они дают целостное представление обо всех заинтересованных сторонах и их интересах, и они понятны для представляющих эти заинтересованные стороны самых разных людей - они подразумевают коллективное обсуждение под руководством социотехника.
Работа с этой моделью часто называется ранней инженерией требований (early requirement engineering), и важность ее в том, что "требований к системе еще нет, а заинтересованные стороны и их интересы уже известны - и можно уже предлагать альтернативные архитектурные решения, при обсуждении которых выскакивают все более и более детальные требования".
Инженер по требованиям должен быть грамотным по Alan Key, что означает умение выражать мысли с использованием самого современного медиа - глинянных табличек в древнем Вавилоне, бумаги и ручки в прошлом тысячелетии - в том числе с использованием формул последнюю пару сотен лет, и компьютера с возможностями моделирования в третьем тысячелетии. Инженер по требованиям должен уметь моделировать и разбираться в компьютерных (имитационных и концептуальных, динамических и онтологических) моделях. Его главный артефакт - описание, которое в третьем тысячелетии представляет собой модель, и эта модель тесно связана с другими моделями (прежде всего архитектурной моделью, в которой инженеру по требованиям тоже нужно уметь разобраться).
3. Инженер по требованиям работает, тесно сотрудничая другими позициями (представляемыми или другими людьми, или тем же самым "системным инженером", или "системным аналитиком" - всякое бывает) в команде. Тут мы рассмотрим лишь одну из них - архитектора, но перед этим заметим:
- именно социотехник организует принятие решений (включая решения по "прохождению развилок", trade-off). Ибо это его профессиональная прерогатива: провести переговоры, предложить метод, при котором люди согласятся, что их устраивает предлагаемое решение. То есть практику "принятие решений" я отношу к инженерии требований: принятое решение как раз и становится "дОлжным", т.е. требованием. Другое дело, что инженер по требованиям как социотехник работает с этими решениями не по содержанию (по содержанию работают технические специалисты - архитекторы, инженеры по специальностям, менеджеры и т.д.), а по форме. Его содержание -- предложить метод принятия решений, обеспечить следование этому методу, придать статус требований результату.
- управление требованиями (понимаемое как сбор, хранение, т.е. учет, а затем маршрутизация всех требований) я отношу к практике управления конфигурацией. Это обеспечивает не инженер по требованиям, сколько ответственный за инфраструктуру человек (т.е. я отношу "управление требованиями" в терминах ISO 15288 не к группе технических практик, а к группе проектных практик). В свою очередь в управление конфигурацией я включаю управление сведениями (информацией) - тем самым "управление требованиями" является для меня лишь "управлением сведениями о требованиях", то есть практикой управления конфигурацией, близкой к айтишной/инфраструктурной/проектной, а не к содержательной технической (в порядке управления требований не нужно принимать никаких особых решений. Нужно просто не забывать об элементарной учетной политике. Но это особый разговор, понятие "учёта", равно как и понятие "управления конфигурацией" весьма трудно для понимания. Пока достаточно запомнить, что "управление требованиями" сводится к "не забывать записывать в правильное место" и "не забывать использовать записанное из правильного места").
4. Архитектор - это системный инженер, отвечающий за важнейшие (одно из определений архитектуры - "это все то, что важно") технические решения.
Главный артефакт архиектора - согласованное внутри себя архитектурное описание (мультимодель системы), состоящее из групп описаний, удовлетворяющих интересы разных заинтересованных сторон.
Он работает не с людьми, он работает с уже известными интересами людей и адресует эти интересы в своей модели. Об интересах он узнает от инженера по требованиям, из артефакта "описание целей". Архитектор обязан все учесть и предложить целостное (непротиворечивое внутри себя, и удовлетворяющее требованиям) техническое решение. Ежели такое решение не находится, то он сообщает об этом инженеру по требованиям, и тот выходит на переговоры с заинтересованными сторонами.
Тем самым артефакты "описание целей" и "архитектурное описание" должны быть теснейшим образом связаны на уровне инструментария моделирования - для описания целей средствами являются как раз указанные в архитектурном описании решения, а группы описаний архитектурной модели как раз адресуют интересы заинтересованных сторон и перечисляемые в модели целей.
Напомню, что "описание" может существовать в любой форме, а под "моделью" я имею ввиду современную датацентрическую (компьютерную "семантическую", с адресуемыми элементами) модель, имеющую как внутреннюю форму компьютерного представления, так и внешние разнообразные человекочитаемые виды экранного/бумажного представления.
Не удивлюсь, если придется "модель целей" реализовывать на Modelica как одну из специализированных предметных библиотек, чтобы иметь технологическую возможность обсуждения предлагаемых архитектором решений разными заинтересованными сторонами на общей мотивационно-архитектурной модели. Это будет давать возможность хоть как-то "не внутри головы" оценить, насколько архитектура (данная группами описаний мультимодели, "симултреком") адресует интересы заинтересованных сторон.
Вопрос о многоуровневости моделирования целей и архитектурного описания, и в каком там месте появляются собственно "требования к системе" (в отличие от "требований заинтересованных сторон"), как детализируется архитектурное описание, переходя в "рабочий проект" (описание, достаточное для изготовления) оставим на потом. Для этого нужно разобраться с мереологией (раздел онтологии, изучающий взаимоотношения "частей" и "целого") и моделированием холонных представлений (предложено Кестлером для описания "матрешек" систем, состоящих из систем).
Описание метода: инженерия требований
