Системное мышление

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

Команда проекта может быть и на пару тысяч человек сотрудников предприятия, а может состоять и из пары человек, и даже одного человека. Разделение на внешних стейкхолдеров и команду как внутренних стейкхолдеров может быть даже более дробным: внутренние стейкхолдеры предприятия (юрлица) и команда предпринятия (отдельного проекта внутри предприятия). Внутренние стейкхолдеры предприятия (например, финансисты, юристы, высшие менеджеры предприятия) заинтересованы в успехе целевой системы, но преследуют совсем иные интересы, нежели команда проекта. Если у вас появятся лишние $1000 в проекте – вы куда их потратите? Улучшите на эту сумму целевую систему, не увеличивая её стоимости – т.е. подарите клиенту? Улучшите ресурсы команды – наймёте более квалифицированных людей, закупите более дорогое оборудование? Отдадите на дивиденды владельцам предприятия? Интересы всех стейкхолдеров разные, критерии принятия ими решений разные.

Нужно коллективно/группой договориться, что считать целевой системой, какие цели преследует проект, в чём состоят возможности проекта. И ещё нужно понять, какой именно коллектив/группа договариваются.

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

Признаки целевой системы

Целевая система определяется ситуативно, о ней договариваются командно, нет никакого алгоритма. Тем не менее, есть эвристики (правила, которые срабатывают часто, но не всегда103), которые помогают найти свою целевую систему среди многочисленных чужих систем в самых разных холархиях. Да, в системном мире царит хаос из совокупности самых разных субъективных мнений, но человек склонен упорядочивать хаос, наводить в нём структуру – символ хаоса совсем не случайно выглядит весьма структурированно:

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

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

Целевая система – это то, что делает (то есть полномочно меняет, а не «влияет на то, что кто-то другой поменяет») команда проекта. Если команда делает описание, по которому потом сделают систему – это непосредственное изменение мира, план этого изменения. Это не уговоры кого-то, чтобы он изменил свою систему. У команды есть какие-то полномочия по отношению к целевой системе, по отношению к другим системам полномочия команды сильно ограничены.