Тут есть, о чем поговорить. Одна из колоссальных проблем приживления западных практик к нашей действительности - несовместимость модели управления, культуры и менталитета. Если в любой отечественной проектной области (что строительной, что машиностроительной, что во многом в ИТ) цикл ТЭО-концепция-проектирование-производство-внедрение неделим, то на западе есть узкая специализация и в каждой фазе работают разные компании. В России в любом проектном институте, где сохранилась советская модель управления действует матричная структура, в которой ведущий специалист или главный инженер проекта - это технический специалист, выполняющий функции менеджера проекта, при том, что инструменты мотивации остаются в руках начальников отделов. То есть менеждмент и техника переплетены. В результате каждый технарь, если хочет расти, обязан осваивать и культуру управления и культуру проектирования (и у них есть много общего). Свода по инжинирингу (то есть по чистому проектирования) недостаточно для инженера в нашей стране. Хорошей иллюстрацией разницы менталитета была фраза "это не наши activity", на одном из семинаров. В России все по другому было и есть, что будет - не знаю.
Насчет связи менеджмента и инженерного проектирования:
1. В отечественной практике сотрудник проектной организации никакой юрисдикции над рабочими, которые строили по его чертежам дом или самолет, практически не имел. Если он и приобретал практику управления, то в основном управления своими подчиненными внутри проектной организации. Опыта управления рабочими на стройке или производстве он при этом не приобретал. Остановить работы на площадке или в цеху в рамках авторского надзора за нарушение проекта он практически не мог. Для сравнения: один знакомый рассказывал, как несколько лет назад заказали горелки для подогрева перед прокатом на стане металлической заготовки по немецкому проекту одному отечественному предприятию. Приехал немец в рамках авторского надзора, осмотрел готовые горелки, все забраковал полностью. Пришлось еще несколько сотен баксов платить - заказывали другому предприятию. Я что-то не слышал аналогичных историй из отечественной практики советского времени.... Поэтому инженерное дело в зарубежном варианте предполагает иной уровень ответственности автора проекта за результат. Сама отечественная практика часто не предполагала высокого качества проектирования, многое потом делалось по месту на производстве. В лучшем случае низкая культура производства и ограниченность средств учитывалась при проектировании. При этом детальность объяснений инженера проектировщика фактически переходила в управление технологическим процессом. Это не стимулировало и высокую культуру производства, особенно в гражданском секторе - значительная часть объектов и деталей могла выполняться вообще без чертежей, а только на основании эскизов и устных объяснений проектировщиков.Эта кривизна часто выставлялась чуть ли не как наше ноу-хау...
2. На производстве, чтобы реализовать проект по кривой документации хороший исполнитель, прежде всего линейное руководство, должен был иметь приличную инженерную культуру. Поэтому прораб у нас - это в гораздо большей степени инженер, чем менеджер. И вот у него как раз инжиниринг и менеджмент часто сливаются нераздельно... У зарубежных строителей инженер-проектировщик и прораб отличаются даже цветом касок,когда находятся на площадке (корпоративная норма в рамках компании).
3. Поэтому представляется важным развивать
3.1 практики выработки требований к проекту не только по строгому соответствию неким НСИ но и требованиям конкретного Заказчика, пользователя, реального человека для которого это все это делается.
3.2 иметь возможность проверить, как сделано и иметь право и возможность отказаться санкционировать приемку работы, если она требованиям не соответствует. При этом чтобы не надо было "стоять над душой" у исполнителя, учить и заствлять его выполнять его прямые обязанности, а иметь возможность прийти и проверить
сделанную работу. Иметь возможность прописать такое разделение функций в договоре, чтоб Исполнитель потом не мог оправдать собственную беспомощность низким качеством проектирования.
3.3 При этом чтобы Исполнитель мог оценить качество проекта
до того, как он обнаружил его кривизну в процессе исполнения.
По любому придется расставаться с практиками, опирающимися на "человека-оркестра" и готовность переделки работы from the scratch на каждом этапе. Как в ИТ, так и в других сферах.
Если эти практики удастся исправить опираясь на уже существующие термины и понятия - ну что ж, тем лучше...
Манифест: Лучший в России Учебник