Программные продукты, как и организации, являются самыми сложными из систем, которые делают люди (а дальше я нагло буду использовать текст http://sites.computer.org/ccse/SE2004Volume.pdf, Software Engineering 2004, curriculum guidlines for undergraduate degree programs in software engineering):
-- софтвер и организации сложны, невидимы, изменчивы (Brooks, 95)
-- техники программирования и создания организаций, пригодные для создания небольшой программы или группы/бригады, не масштабируются для создания большой организации (тут вообще масло масляное: большие программы не создаются маленькими группами людей, равно как и большие организации);
-- скорость изменений в компьютерных и программных технологиях, равно как и в организационных технологиях требуют создания новых программных продуктов, равно как и новых организаций. И то и другое требуется создавать с приемлемым качеством, причем вовремя.
Опять повторюсь: организации люди делают, этим занимается отдельный предмет "организационное развитие" (http://en.wikipedia.org/wiki/Organizational_Development), и от замены слов "люди делают" на безличное "развитие" ничего по сути не меняется. Операционные системы, равно как и интернет тоже "развиваются". Игры языка, это все естественно-искусственные объекты -- один взгляд видит "естественное", а другой взгляд различает "сделанное".
Формальная дискуссия по программной инженерии прошла в 1968 году на NATO Conference on Software Engineering. Софтовый инженер разбирается не только в кодировании, но и понимает качество, планирование работ, экономику, использует инженерные принципы и дисциплину (понимаемую как инженерную область знания). Организационная инженерия (http://www.google.com/search?q=%22organizational+engineering%22, 24000 упоминаний) -- это признание того, что организации не только "становятся", но также и "строятся".
Инженерия -- это использование устойчивых методов для получения надежных артефактов. Организации -- вполне себе артефакты (хотя их и нельзя "пощупать руками" -- это тонкие материи), они также отличаются и от традиционных инженерных сооружений -- мостов, самолетов, электростанций. Так что можно говорить не только об организационном развитии и организационном дизайне, но и об организационной инженерии.
Увы, термин "организационная инженерия" уже довольно плотно занят. Как и в случае программной инженерии, организационная инженерия подразумевает множество толкований того, о чем она -- от конкретной методологии I opt Института организационной инженерии (http://www.oeinstitute.org/ -- это еще один вариант "составления команды" из людей с разным стилем обработки информации, наподобие классификации Ицхака Адизеса, подробнее http://www.oeinstitute.org/articles/Engineering_Principles.pdf) до традиционного толкования ежегодного симпозиума прикладного компьютинга ACM (http://ceo.inesc.pt/sac2007/track.htm): организационная инженерия объединяет мультидисциплинарные концепты, методы и технологии моделирования, разрвития и анализа различных аспектов изменяющихся организаций, с упором на организационную архитектуру и гармонизацию отношений между бизнес-стратегией, бизнес-процессами и системами поддержки бизнеса (судя по глоссарию http://ceo.inesc.pt/sac2007/topics.htm тамошний подход к организации весьма еще далек от системного -- скорее, вариации "структурного" и "процессного" подходов).
Все эти заходы на "организационную инженерию" не более и не менее, как использование лингвистических ассоциации слова "инженерия" (устойчивость методов в получении надежных результатов) менеджеров, а также попытки инженеров заняться организационным развитием (http://en.wikipedia.org/wiki/Organizational_Development).
Впрочем, недостатка в скрещивании менеджерского ежа с инженерным ужом не наблюдается -- как в варианте management engineering, так и в варианте engineering management. Нас будет интересовать не столько engineering management (как управлять "простыми инженерами", чтобы они смогли что-то сделать -- см. http://en.wikipedia.org/wiki/Engineering_management. Собственно, и часть software engineering как раз об этом: как управлять "простыми программистами" в количестве большем, чем бригада, чтобы они не потеряли возможность сделать что-либо полезное), сколько именно управленческая инженерия, management engineering: как инженерно (с естесственнонаучным, а не гуманитарным уклоном) подкованные менеджеры могут нанести непоправимую пользу своим организациям.
Примеров тут несть числа:
http://www.mansci.uwaterloo.ca/undergrad/program.php?id=3 -- Университет Ватерлоо 5 июля 2006г. запустил полноценную программу management engineering в "применении методов инжиниринга и принципов менеджмента к дизайну, планированию и деятельности систем людей, материалов, информации и технологии". Выпускники будут профессиональными инженерами, которые "могут работать в междисциплинарных командах и могут принести научный подход в выработку управленческих решений". Недостатка в студентах не будет: "ожидается привлечение самых разных студентов, которые имеют способности в математике и естественных науках, и интерес к социальным вопросам и менеджменту" (из http://www.bulletin.uwaterloo.ca/2006/jul/05we.html). Программа ((http://www.mansci.uwaterloo.ca/undergrad/program/management_eng.htm?id=3) содержит не так уж и много менеджмента -- буквально один (максимум -- два) курс в семестр из пяти-семи. Остальные -- математика, механика, химия, информационные технологии.
Вот чуть меньший закос в инжиниринг, но та же смесь математики и лидершипства: http://www.mgt.wpi.edu/Graduate/MSODL/curriculum.html (M.S. в Operations Design and Leadership).
Вот польский институт управленческой инженерии (http://www.me.put.poznan.pl/english.php) в составе Познаньского технологического университета, в котором слово engineering используется даже в контексте
Вот очень странная смесь курсов на степень в Industrial Management Engineering технологического кампуса Наваррского университета, в которой 6 кредитов Industrial Buildings соседствуют с 4.5 кредитами Ethics, а Operations Research III на 4.5 кредита соседствует с 6 кредитами Work organization and Human Resource Management, а в electives можно выбирать из Computer Science III и Theology -- http://www.tecnun.es/English/curriculums/manage.htm.
Long Island University лаконичен в определении того, что он предлагает в 36-кредитной программе M.S. in Management Engineering: "главная цель этой программы обеспечить наших студентов знаниями и умениями, требуемыми для того, чтобы быть эффективными лидерами в мультидисциплинарных проектных командах" (http://www.liu.edu/cwis/cwp/cics/mana_eng.html). Про людей там, правда, всего один курс (Human Resources and Communications Management), все остальное в обязательных курсах крутится вокруг управления проектами (http://www.liu.edu/cwis/cwp/cics/mana_eng_pro.html).
И так далее, и тому подобное: таких учебных программ миллион и маленькая тележка -- много инженеров хочет стать заодно и менеджерами (что, заметим, много проще, чем стать "обычным менеджером", а потом всю жизнь пытаться разобраться в самых разных технологиях, с которыми наверняка "обычному менеджеру" придется сталкиваться, если он не осел где-нибудь в финансах или маркетинге, а пытается рулить производством продуктов и/или услуг).
Мои мысли:
а) не понимаю, насколько можно подобные курсы запихивать во всякие MBA или MPA. Не лучше ли придумать какое-то отдельное название?
б) то, что я пытаюсь сделать -- так это какой-то похожий на все эти management engineering курс, в котором:
-- увеличить за счет "чисто инженерных" курсов число часов на работу с собой (рефлексивный подход), людьми и ориентирование в общественном контексте;
-- сделать упор на выпуск человека дела, а не человека-аналитика. Выпускник должен уметь организовывать сам, а не возглавлять отдел системных аналитиков.
-- вместо классического инженерного цикла взять неклассический компьютерный цикл -- на котором прежде всего отрабатывать дисциплинированное мышление. Не естественнонаучное/инженерное, а "просто дисциплинированное", "просто научное".
-- вместо обзорных курсов "чего бывает в мире" (все равно это "чего бывает" устареет к моменту выпуска -- помним о сингулярности!) преподать несколько базовых идей, которые позволят выпускнику потом всю жизнь ориентироваться в непрерывно изменяющихся условиях работы. Лучше меньше освоенных, но более базовых идей ("постановка мозгов"), нежели поверхностное знакомство с текущей на момент получения образования практикой.
-- попробовать сделать такую программу, чтобы обучение было удовольствием для студентов за счет специально организованного учебного процесса.
Тем не менее, продолжим с аналогиями программной и организационной инженерии/организационного развития/организационного дизайна/менеджмента, оставив за скобками всю политкорректность и осторожность языка -- рубим старый и устоявшийся лес, обязательно будут щепки лететь, всем угодить наверняка не удастся. Сейчас мы творим новые понятия, закреплять их в языке и причесывать будем вторым или даже третьим проходом, когда появится предмет для причесывания. Пойдем дальше по документу http://sites.computer.org/ccse/SE2004Volume.pdf.
В софтовой и организационной инженерии есть предмет -- первая является одной из дисциплин (областей знания) компьютинга, вторая -- менеджмента (management sciences). Ошибкой является сведение этих дисциплин к чисто инжиниринговым -- с упором на разработку требований, дизайн, проверку качества, улучшение процессов и управление проектами. Софтовый инженер должен знать компьютинг, и самым большим разделом в SEEK (Software Engineering Education Knowledge) является Computing Essentials. В организационной инженерии менеджер-организатор должен знать Organization (Group, People) Essentials прежде всего, и только потом -- разработку требований к организационным изменениям, организационный дизайн, проверку качества работы организации, улучшение процессов управления изменениями и управление проектами организационных изменений (впрочем, и просто "управление проектами" менеджеру пригодится -- "проект" ведь -- это тоже организация, хотя и временная).
Вот еще один ("меметический", он же -- "программистский") взгляд на организацию: это такая специальная исполняющаяся и непрерывно изменяющаяся совокупность "культурно-управленческих программ" (в смысле потенциально реализуемых в случае наступления тех или иных условий сценариев поведения в многовариантном будущем), разработанных и внедренных в сознание членов организации разными людьми. Эта совокупность программ не только "сидит на людях", но и поддерживается всевозможными информационными инфраструктурами. Как софтовый инженер понимает в компьютерных программах, и как они исполняются, так и организационный инженер способен понять, что движет людьми (какие у них "программы"), когда они сотрудничают (или воюют) в рамках организации. Факт, что любой человек способен осознать свою "программу" и самостоятельно тут же творчески переписать ее, ничего не меняет: возможность это сделать вовсе не означает, что такая возможность тут же реализуется -- иначе никакую организацию невозможно было бы создать/углядеть в мире ("организация -- она в глазах смотрящего").
Похожесть софтовой инженерии и организационной заключается и в том, что в них нет никакого "производства" в традиционном смысле слова, а "сопровождение" относится к продолжению основного процесса разработки/эволюции, а не к "ремонту".
А вот основные черты собственно инженерии:
-- инженер делает серию решений, в каждом из которых находит компромисс между стоимостью и выгодами;
-- инженеры много измеряют, работают с количественными оценками, калибруют и проверяют средства измерений, используют аппроксимации, основанные на личном опыте и данных эксперимента.
-- инженеры настаивают на использовании упорядоченного процесса, когда создают свои дизайны, и эффективно работают как часть команды в этом процессе;
-- инженеры могут иметь множество ролей: исследователь, разработчик, дизайнер, производитель, тестировщик, сборщик, работник, управляющий, и даже другие -- такие как продавец, консультант и учитель.
-- инженеры через свои профессиональные сообщества развивают и проверяют свои принципы, стандарты и лучшие практики.
-- инженеры повторно используют (reuse) дизайны и сдизайненные изделия.