соответствующих дисциплин и не имеет нужного инструментария), то его нельзя называть системным инженером (по роли).
Примерами систем могут быть: автомобиль, самолет, система документооборота, завод, смартфон, месторождение полезных ископаемых, клиника и т. д.
В этой книге мы уделим внимание ролям системного аналитика и системного архитектора, а предметную область выберем самую актуальную – Интернет вещей.
Часть 1. Тренировка на салфетках
Глава 1. Разделение зон ответственности
Давайте представим, что вы попали в новую организацию, и вам предстоит выполнять какую-то новую работу. Первым делом, вы понимаете, что ваша должность не имеет ничего общего с теми задачами, которые вам реально нужно решать в этой организации. Например, вы устроились на должность системного аналитика в ИТ-компанию. В лучшем случае, вас попросят первые три месяца доделывать прошлогодние отчеты по каким-нибудь псевдопроектам, потому что ни у кого не доходят руки. И вообще, дело понятное, что удел новичков – залатывать дыры.
Работа над прошлогодним отчетом, впрочем, как и любая другая работа, падающая на плечи новичка, является отличным поводом к моделированию вашей организации. На языке системной инженерии – вы имеете ценнейшее время, чтобы определить обеспечивающую систему для будущих проектов, то есть ту систему, которая будет, например, проектировать и воплощать целевые системы.
Целевой системой будем называть тот конечный продукт, подлежащий эксплуатации, за работу над которым инженерным организациям платят деньги или выдают еду (в зависимости от места работы).
В начале пути вам никто не скажет «спасибо» за модель организации как обеспечивающей системы. Основная польза от этой работы заключается в разделении зон интересов членов команды, как стейкхолдеров.
Присутствуя на периодических совещаниях, вы скорее всего заметите, что руководитель проекта очень часто берет на себя роль системного архитектора, продавца и даже заказчика. Системный архитектор порой ведет себя как менеджер. А еще иногда приходит какой-нибудь заместитель директора, который к проекту относится очень условно, и начинает констатировать конструкторские решения, потому что он человек опытный.
Присутствие различных стейкхолдеров на совещании – это, действительно, очень хорошо, но только в том случае, когда они свою «стейкхолдерскую» роль осознают и не играют других ролей, и другие им не потакают. Замдир может своим авторитетом полностью перегнуть палку, в результате чего вся команда согласиться на совершенно непродуманное решение, а сам этот замдир, в силу своей занятости, на совещаниях в ближайшие полгода не появится. В большинстве случаев может оказаться, что он, вообще, стейкхолдером не является.
Если у вас в команде есть системный архитектор, то конечное решение о системной архитектуре принимает именно он, а не коллективный разум программистов.