[chon]

Добрый день всем!
Интересует мнение участников форума по системам планирования и организации проектирования.

Сетевой график - понятно и хорошо работает, особенно если надо выявить все взаимосвязи в проекте или упорядочить. Pert - похож на сетевой график с небольшими отличиями, но смысл тот же.

Диаграмма Ганта (визуальное отображение затрат времени во времени "" - применимость большой частью для последовательных задач.

конечно в большинстве случаев нет чистого Ганта или Перта. Как пошутил знакомый - "Гантоперт".

Очень хочу услышать отзывы тех кто использовал систему Канбан. Есть ли в ней полезные моменты для проектировщиков.

Какие системы вы используете?

[Tyhig]

chon, честно говоря ничего не понял. Какие-то непонятные слова... А вы их сами понимаете ?
Расскажите форумчанам, пожалуйста, что понимаете ?
Авось и мы подтянемся...

[ArtEfimov]

Извините, а к чему такие сложности?
Мне интересно даже стало какие у вас проекты.
Или Вы менеджер?

[иваниваныч]

Сообщение от ArtEfimov Или Вы менеджер?

А кто ж еще? Вместо проектирования сетевые графики составляет - работать людям мешает.

[chon]

Не знакомые слова отлично ищутся в Яндексе.
Не то что бы не хочу объяснить, скорее не уверен в своей компетенции.
Менеджер - слово ругательное и прошу его ко мне применять .
А если серьезно, то объекты разные. Хочется просто организовать работу своей команды, чтобы не приходилось переделывать.
А возможность предусмотреть несколько шагов вперед считаю хорошим подспорьем.

[mainevent100]

Сообщение от chon Хочется просто организовать работу своей команды

вся команда, видимо, на удалении?
с гантом однажды пришлось столкнуться, не понравилось

[kp+]

Сообщение от chon Очень хочу услышать отзывы тех кто использовал систему Канбан. Есть ли в ней полезные моменты для проектировщиков.

Не использовал и стараюсь держаться подальше от всяких систем "эффективного менеджмента", т.к. они для массового конвеерного производства, а не для проектирования, где даже типовые решения не совпадают один в один.

Но читать в Википедии приходилось, и там обратил внимание на один момент, на который в "канбане" сделан упор - недопустимость (или сведение к минимуму) пересчета, перепроверки и "доработки напильником". Ну т.е. и так понятно, что это плохо, но в "канбане" борьба с такими вещами поставлена превыше всего и возведена в культ.

Для проектирования, IMHO, должно выражаться в частности, в:
- качественной подготовке заданий смежникам, подоснов и проч. Чтобы все со всем стыковалось, было понятно без напряжения и с минимумом объяснений на словах со стороны автора;
- тщательном соблюдении единых требований к разработке и оформлению документации (не только ЕСКД/ЕСПД, но и в части электронной модели).

Короче во всем том, что мы все и так знаем, но ленимся выполнить))

[Art1st]

Любые системы управления не работают в проектировании, хоть ты тресни. Немного моего видения творящегося хаоса и почему ничто не сможет работать в этих условиях.

Любая система подразумевает систематизированние исходных данных и оптимальную работу по ним.
Первое узкое место.
О какой систематизации может идти речь, если в любой абсолютно момент времени разработки проекта, заказчик может изъявить хотелку (хорошо если он ее оплатит), которая повлечет за собой просто выбрасывание проекта на помойку, вместе с системой контроля. Тоже самое касается внезапные смены конструктивных и прочих решений глав.спецами организации, без дачи себе отчета в том, что это влечет за собой переделки, а значит потерю денег. У нас почему-то принято считать что переделки это "неотъемлемая часть процесса", а не результат чьих-то недоработок. Однажды одновременно на 2х объектах организации: 1) на одном на стадии получения финальных разрешений на строительство (проект давно готов), заказчик вдруг решил что нужно переделать все планировки, а здание сложное, это повлекло за собой и изменение конструктивных решений, и вмешательство в расчетную схему, проект выбросили. 2) Здание просто попросили удлинитель на 1.2 метра. И не в одной какой-то оси. А по 50мм между каждыми двумя. Здание было из сборняка, последствия - можно себе представить. Проект переделали сызнова.
Второе узкое место.
Выдача заданий смежными разделами. Инженерные сети. Не в обиду представителям оных здесь, но ОЧЕНЬ часто люди, работающий в этой области к слову ИНЖЕНЕР вообще никакого отношения не имеют. Однажды, я даже объяснял специалисту ОВ что есть где на архитектурном разрезе здания. А на мое уже и вовсе удивленное восклицание "да это же перекрытие", следовал ответ "да я откуда знаю что это". Так вот. Качество заданий смежников. Тут несколько пунктов плодящих проблемы: их непостоянность (десятки версий заданий по каждому разделу - постоянно); общий уровень инженерного знания (не серьезно, когда ты рассказываешь инженеру что нарисовано на архитектурном разрезе здания, да, в других направлениях тоже бывают так себе уровнем специалисты, но такого - не встречал, видимо из-за того что требований и не предъявляют к спецам инженерных служб); хромающий уровень согласования решений как и между собой, так и между КР-АР-смежники (встречал ситуацию, когда 2 спеца, работая за соседними столами 20 лет, умудрились по одним местам прокинуть разные коммуникации и разъехаться - одна в Италию, другая на деревню к матушке, а объект завтра выдавать и это дет.сад).
Третье узкое место.
В погоне за экономией в фирмах нового поколения напрочь искажена система управления проектом. От нач.отдела(сектора ли) - нач.группы - ведущие - рядовые исполнители все скатывается к нач.сектора/гл.спец - непосредственные исполнители. На моей практике это привело однажды на большом объекте к тому, что треть информации была у человека, разрабатывающего каркас сложного здания, треть у фактического начальника сектора, ибо ему несли как единственному уполномоченному руководить, треть у расчетчика. И не один человек не обладал полнотой знаний об объекте даже в рамках одного раздела (конструкторский). Не стоит на этом жадничать. И не стоит на 1 ГАПа сваливать 10 объектов, все 10 ,которые ведет контора на 100 человек. Не стоит это же самое делать с ГИПами. Не стоит боятся вырастить из своих "старичков" специалистов у себя. Не хотите этого делать - они уйдут гарантированно, вопрос лишь времени. Но почему-то у нас (в проектировочном бизнесе) руководство испытывает не иллюзорный страх перед выдачей официальных полномочий кому-либо на руководство чем-либо. В итоге бывает ты вроде и за главного среди вот этих шести исполнителей, но вместо ответственного решения за всех, ты собираешь "конвульсиум" и вы там все конвульсируете, пока не сойдетесь на том решение, которое черти кому удобно (де факто - приняв сторону самых "вредных" участников коллектива, которые "я не буду ничего переделывать"). Одним словом не стоит превращать механизм проектировани в симулятор фермы, где есть фермер (нач.сектора) и стопитцот рядовых исполнителей, которых туда-сюда дергают, и черти кто должен вести все промежуточные этапы контроля передачи хотя бы информации.
Четвертое узкое место.
Передача информации. В проектах всегда куча мелких изменений. Создайте удобную платформу (куча готовых решений, в т.ч. бесплатных) в своем бизнесе, чтобы та обеспечивала взаимодействие участников без беготни туда-сюда по кабинетам или бесконечным звонкам в скайпе. Обязательно с возможностью оставлять оффлайн сообщения, передавать файлы (ну не в наш век документацию по почте слать, если честно).

Вот когда на 80% решатся хотя бы эти проблемы - тогда стоит подумать и о применении каких-то известных систем управления. Так как будет чем управлять. И да. Создайте "ящик", куда любой участник организации может анонимно отправить свои пожелания по решению тех или иных узких мест. Анонимный, я сказал. А не так, чтобы промежуточный начальник на тебя потом зуб точил, за то что это не он придумал, как "баг" из производственной цепочки убрать. Люди, они разные.

[Marsikus]

Работал с канбан досками в Trello и Jira, но в области программного обеспечения. Не знаю, нужно ли оно конструктору, тогда как-то обходился без этого.

[Tyhig]

chon, как вы думаете, а как обходились в СССР без канбана, перта и ганта ?
Страшно сказать, Гагарина запустили... Правда и сельское хозяйство тоже...

Offtop: Почитал - классная штука, наверное. Уже тем, что можно прийти на собеседование и завернуть: "А я вот на работе в канбане работал... А вы не знаете что это такое ? Эх вы..."

Понаписал всякой фигни, но стёр. Нехорошо ругаться, а вас жизнь научит.

[Brandashmыg]

Пробовали и канбан (kanbanflow) и всякие таск-трекеры. Время на поддержание актуальной информации нужно очень много. А учёт прибегающих ГИПов (Отвлекись на пару минут, к завтра авторский лист сделать) - вообще не реален. Возможно, для руководителя и полезно будет, особенно если работники на субподряде. Диаграммы Ганта у нас попытались делать для всей фирмы - но сроки при каноничном построении получались такие, что руководству не нравилось. А параллельно несколько объектов на одного человека очень наглядно и негуманно выглядело.
Специфика не та.

[Tyhig]

Вроде бы Суворов пришел в полководцы из снабжения. Оно у нас ещё тогда было плохим.
Беда тут одна. У Суворова была война и в связи с этим жестокая конкуренция кто кого. И выигрывал один.
А вот домики строить проще. Строительное дело прощает и чертежи тяп-ляп, и отсутствие снабжения и планирования... Итог все равно один, просто цена и сроки чуть больше.
И на этом фоне я даже задумываюсь, может оно всё и правда не надо...

[Enik]

Погуглил. Если я верно уловил суть, то...
Канбан - дудка для бездельников. Проще завести записную книжку и обзванивать с матюками исполнителей, чем заставить их следить за изменениями и отрабатывать план по собственной воле.
Диаграмма Перта - слишком долго и сложно. Простому рабоче-крестьянскому человеку вещь абсолютно чуждая. Последний раз видел в дипломе для ПГС.
Диаграмма Ганта... Делал я всю жизнь, стало быть, графики производства работ и даже не подозревал, что это оно самое. Гант - понятный и крайне полезный вид диаграммы.

Offtop: Но я бы такие слова не произносил, иначе мужики со мной в баню ходить не станут.

Сообщение от Art1st Любые системы управления не работают в проектировании, хоть ты тресни...

+++

[Brandashmыg]

Сообщение от Enik Погуглил. Если я верно уловил суть, то... Канбан - дудка для бездельников. Проще завести записную книжку и обзванивать с матюками исполнителей, чем заставить их следить за изменениями и отрабатывать план по собственной воле.

Ну он изначально использовался на заводе, в рамках реализации концепции бережливого производства. И Тойота очень даже выиграла от его использования. Так что я бы не стал так сразу...

[Enik]

Сообщение от Brandashmыg Ну он изначально использовался на заводе, в рамках реализации концепции бережливого производства. И Тойота очень даже выиграла от его использования. Так что я бы не стал так сразу...

Я придерживаюсь мысли, что
не внедрение систем вроде Канбана повышает уровень культуры производства [этот тезис неверный],
а наоборот,
что высокая культура производства позволяет внедрять инновационные методы управления,
что влечёт за собой повышение экономической эффективности.

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

----- добавлено через ~17 мин. -----
Применительно к нашим реалиям.

Представьте себе обычную компанию из 50 человек. Из которых 10-20 дают реальную выработку, приносят компании деньги. Обычно это вчерашние студенты или люди предпенсионного возраста, на низких окладах, все в долгах и болячках. А остальные занимаются менеджментом и перекладыванием бумажек. И вот генеральный принимает стратегическое решение и нанимает ещё одного менеджера с тем же Канбаном, перераспределяя на него часть и без того скудных финансов. И вот этот кадр начинает ходить и всех доставать. Само-собой, у него ничего не получается, потому что все уставшие и озлобленные. Он стучит генеральному. И тогда генеральный увольняет человек 5 из тех, кто даёт выработку. Как самых нелояльных руководству. И вот в компании уже 45+1 человек, и дела всё хуже и хуже...

[Marsikus]

Это азиатский (и наш пост-советский заодно) способ управления, если ценят не профессионализм а преданность хану.

[Tyhig]

Enik, этот поразительно доходчивый рассказ надо на этом форуме закрепить вверху всех тем.
Голосую за Еника, как за самого ораторного форумчанина года.
Вам надо срочно идти учить людей куда-нибудь. Я бы никогда не смог так доходчиво написать. К несчастью.

[Enik]

Сообщение от Tyhig Enik, этот поразительно доходчивый рассказ надо на этом форуме закрепить вверху всех тем.

Спасибо! Но я ведь всего лишь "снял с языка" то, что и так витает в воздухе. Где тут моя заслуга?

Сообщение от Tyhig Вам надо срочно идти учить людей куда-нибудь.

Когда-то давно хотел уйти в науку. Даже аспирантуру закончил. Но потом я понял, что между наукой и производством - бесконечная пропасть. Наука - вещь в себе. Производство - тоже. Жизнь диктует свои правила, нужно было выбирать. И я выбрал производство. Просто потому, что там платят больше. Начинал с просотого рабочего, потом пошёл в проектирование, сейчас тружусь в ПТО. Но мысли о несовершенстве бытия мне всё так же не дают покоя, как и много лет лет назад. Наверное, это судьба. Не знаю, кого и чему я могу научить. Но если что - обращайтесь.

[hasa]

Вообще, система планирования и организации - хорошая штука. Но не работает. В малом коллективе важнее межличностные отношения, а при переходе вовне отсутствуют кнут и пряник для обязательности выполнения. ИМХО недостаточный уровень культуры = мозгов не хватает. Но ведь культура относится к группе людей, а мозги то у каждого свои.
Бережное производство = сдача станков на металлолом,
KPI = уравниловка, чтобы никому не было обидно,
бакалавриат - недоделанные инженера. Пришел тут к нам один. Ну кто это приравнял к инженерному образованию? Это офисный планктон.
Только массовые расстрелы и далее по тексту.

[Art1st]

Я придерживаюсь мысли, что не внедрение систем вроде Канбана повышает уровень культуры производства [этот тезис неверный], а наоборот, что высокая культура производства позволяет внедрять инновационные методы управления, что влечёт за собой повышение экономической эффективности. Иными словами, сначала научись уважать себя, окружающих и свою работу. Начни ценить своё время, брать на себя обязательства и в точности их выполнять. Только на такой почве могут прижиться передовые методы производства и управления. А не в атмосфере уныния и нищеты.

Бинго. Это точно таже самая проблема как с внедрением новых систем проектирования. Все рвутся к ревитам и новым расчетным комплексам, ибо модно. И никого не волнует, что в переходящей на ревит организации - никакой организации передачи информации из рук в руки, никакой культуры работы хотя бы в автокаде, никаких знаний о использовании хотя бы его возможностей. Хотят внедрять нанотехнологичные системы управления, а при этом какие-нибудь нормоконтроли запарывают работу своей же организации, в типовых, казалось бы комплектах, каждый раз выдумывая новые правки. (тут прецедент случился, ребята делают 27 типовых комплектов стен на высотку, выдали 10, выдавая каждый из 10 нормоконтроль находила "еще что-то", заставляя поднимать и исправять уже выданные 10, причем, все это на уровне "указание расстояние между выпусками и стержнями армирования вертикальными", т.е. вещи - никому не нужные от слова "вообще", мне кажется , к 27 комплекту половина уже уволится от этого подхода).
Есть мнение, что в любой сфере нужно сначала выработать 80% возможностей инструментария текущего уровня, а уже потом "шагать" на следующий тех.уровень данного направления. О каких системах менеджмента может идти речь, когда банального контроля выдачи заданий в 10 из 10 организаций - нет, и "задание" считается "внутренним документом", на уровне туалетной бумаги.

[Stierlitz]

проектирование - это творческая работа, хотя не все видят в нем творчество
причем в творчестве участвуют и представители заказчика и заказчик и господа из государственных и муниципальных служб
творческий подход экспертов это отдельная тема

пс. так же проектирование - это борьба с хаосом. Ну какие тут графики?))

[vd17]

Сообщение от Stierlitz проектирование - это творческая работа, хотя не все видят в нем творчество причем в творчестве участвуют и представители заказчика и заказчик и господа из государственных и муниципальных служб творческий подход экспертов это отдельная тема пс. так же проектирование - это борьба с хаосом. Ну какие тут графики?))

Программирование тоже, тем не менее там методологии разработки применяются, причем успешно. И никто не ругает менеджеров за то что они менеджеры, тестировщиков (этакий нормоконтроль) зато что они заставляют программистов исправлять ошибки.

Тут на форуме много недовольных что ПО работает не так как надо, но всех устраивает чтобы нормоконтроль пропустил проект зданий с кучей ошибок оформления или вообще не по ГОСТу, заказчик же и так примет.

[Art1st]

Offtop:

пс. так же проектирование - это борьба с хаосом. Ну какие тут графики?))

Ну от чего же, есть же в некоторых сферах науки и об этом что-то. Эффект бабочки, и прочие штуки, связанные с хаосом :р

[vd17]

Сообщение от hasa Вообще, система планирования и организации - хорошая штука. Но не работает. В малом коллективе важнее межличностные отношения, а при переходе вовне отсутствуют кнут и пряник для обязательности выполнения. ИМХО недостаточный уровень культуры = мозгов не хватает. Но ведь культура относится к группе людей, а мозги .

Есть например SCRUM для маленьких коллективов. (но опять же в ИТ)

[Art1st]

Сообщение от vd17 Программирование тоже, тем не менее там методологии разработки применяются, причем успешно. И никто не ругает менеджеров за то что они менеджеры, тестировщиков (этакий нормоконтроль) зато что они заставляют программистов исправлять ошибки. Тут на форуме много недовольных что ПО работает не так как надо, но всех устраивает чтобы нормоконтроль пропустил проект зданий с кучей ошибок оформления или вообще не по ГОСТу, заказчик же и так примет.

Дело том, что в ПО творчество отделено в отдельный сегмент "дизайна/верстки/нуиличтотам". А в проектировании это самое "творчество" оно как раз по большей части на уровне структурирования всего - будто принятие ключевых решений, методов оформления, выбор конкретных решений из ассортимента организации. И так далее. И как раз эту "около творческую" сферу и пытаются загнать под разные системы управления. И пытаются научиться управлять первородным Хаосом, не меньше.

[vd17]

Сообщение от Art1st Дело том, что в ПО творчество отделено в отдельный сегмент "дизайна/верстки/нуиличтотам". А в проектировании это самое "творчество" оно как раз по большей части на уровне структурирования всего - будто принятие ключевых решений, методов оформления, выбор конкретных решений из ассортимента организации. И так далее. И как раз эту "около творческую" сферу и пытаются загнать под разные системы управления. И пытаются научиться управлять первородным Хаосом, не меньше.

Как у тут в соседней теме писалось, что проект перед тем как брать нужно обсудить со своими инженерами, но никто конечно этого не делает.

[Art1st]

Сообщение от vd17 Как у тут в соседней теме писалось, что проект перед тем как брать нужно обсудить со своими инженерами, но никто конечно этого не делает.

В текущей конторе владельцы бизнеса, они же заключающие договора: управляющий директор - инженер от архитектуры, вторым совладельцем - ГИП, инженер от конструктива. Но и это не спасло от парочки "болотных" объектов, когда сами признавались "знали б - не полезли б". Так что даже инженеры у руля не всегда спасают. Но когда без них - это вообще ад.

[Ranli]

Сообщение от vd17 никто конечно этого не делает

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

[hasa]

Сообщение от vd17 Есть например SCRUM для маленьких коллективов. (но опять же в ИТ)

Дело не в аббревиатуре, а в реализации: практической работе по реализации красивых слов на бумаге, т.е. как заставить людей соблюдать любые нормы и правила. Как было написано в Госте "несоблюдение гост преследуется по закону".

[Stierlitz]

Сообщение от vd17 Программирование тоже, тем не менее там методологии разработки применяются, причем успешно. И никто не ругает менеджеров за то что они менеджеры, тестировщиков (этакий нормоконтроль) зато что они заставляют программистов исправлять ошибки. Тут на форуме много недовольных что ПО работает не так как надо, но всех устраивает чтобы нормоконтроль пропустил проект зданий с кучей ошибок оформления или вообще не по ГОСТу, заказчик же и так примет.

это говорит лишь о том что программирование - достаточно предсказуемый процесс. Про ругают не надо - я вот тоже не ругаю "своего менеджера", и что?)
тестеровщики крайне далеки по сути от нормоконтроля - они ищут реальные ошибки, нормоконтроль мнимые.


Art1st
по подробнее можно?

[Art1st]

Сообщение от Stierlitz Art1st по подробнее можно?

Брали одно зданице, задумывалось максимум - небольшое усиление уголками. Планировалось: пересчитать каркас уже возведенный на предмет возможности заменить пеноблоки как заполнитель на кирпич, да усиление сделать, если нужно. Плюс перерисовать нужно было часть рабочки, они утеряли чертежи, были только сканы от них. За это около ляма давали, казалось - ну неплохо. А кончилось все тем, что была обнаружена 2-4х кратная нехватка несущей способности всех вертикальных элементов здания (ошибки расчетчиков, делавших до нас). И разрабатывали усиление, объемом в 35кк рублей (стоимость самих работ по усилению). Такого поворота событий не мог предвидеть никто. Трудочасов было убито - жесть сколько, в конкретный минус ушли.Но заказчик был "старый знакомый" и отказаться было решительно неудобно нашему руководству. (уже после того как вляпались)

[vd17]

Сообщение от Stierlitz тестеровщики крайне далеки по сути от нормоконтроля - они ищут реальные ошибки, нормоконтроль мнимые. ?

Есть ГОСТ и его нужно соблюдать, вполне реальные ошибки - несоблюдение ГОСТа оформление и других.

[Сергей812]

Сообщение от vd17 Есть ГОСТ и его нужно соблюдать, вполне реальные ошибки - несоблюдение ГОСТа оформление и других.

нормоконтроль - это всего лишь одна из составляющих процесса проектирования, и не самая важная в плане возможных финансовых потерь.

[Stierlitz]

Сообщение от vd17 Есть ГОСТ и его нужно соблюдать, вполне реальные ошибки - несоблюдение ГОСТа оформление и других.

к тестированию проекта никакого отношения не имеет)

[Ranli]

Сообщение от Art1st Трудочасов было убито - жесть сколько, в конкретный минус ушли

исполнительные сметы не прокатили? или постеснялись предложить из-за того, что

Сообщение от Art1st заказчик был "старый знакомый"

?

[Art1st]

Offtop:

Сообщение от Ranli исполнительные сметы не прокатили? или постеснялись предложить из-за того, что ?

Я знаю лишь цену стартового предложения. Но т.к. был на одной планерке с заказчиком - тот не был настроен на трату хотя бы одного рубля сверху. А когда ему озвучили катастрофичные 33-35кк рублей на требуемое усиление он впал в депрессию. Возможно, нам и докидывали сверху, возможно нет. Но трудоресурсов было убито кол-во, плюс минус требуемое для создания если не такого же, то "простенького" по планировке жилого дома той же этажности, только с нуля. Вычертить усиление ~70-80 вертикальных элементов на 5-6 ярусах (этажах), а еще куча сопутствующих расчетов-пересчетов, созданий схем с кучей допущений, так как в схемах здание разве что не падало, у меня одних эксель табличек с тех пор - под 1гб лежит. В монолитном варианте усиления, путем наращивания сечения. Разных высот, разных сечений, разного начального армирования (начальный проект содержал 38!!! типов армирования элементов. Т.е. ~2 колонны на один тип, вот скучно было то им). Ценник такого бардака, даже если б он был заранее известен был бы сравним с реальной ценой проекта жилого дома сходной этажности, но столько бы никто и не дал, а стало быть идея заведомо провальна. Так что, как уже сказал выше, не всегда спасает от шага в болото даже наличие у руля глав.спецов организации.
пс. вопроса о том во сколько рублей мы должны уложиться по стоимости будущих работ - изначально и не стояло, никто не ждал такого поворота, планировалась то замена пеноблоков на кирпич в перегородках, т.е. просто едва ли не поверочный перерасчет, а оказалось что расчетчики "так себе" были, экспертиза и вовсе может куплена. Примечательно, что тот самый эксперт, что это подмахнул - порывался сделать и усиление :р и демпинговал нас и по цене работ и по цене грядущего усиления.


----- добавлено через ~3 мин. -----
Offtop:

Сообщение от Сергей812 нормоконтроль - это всего лишь одна из составляющих процесса проектирования, и не самая важная в плане возможных финансовых потерь.

В том то и дело. Что при всей фиктивной важности, нормоконтрольные должности не редко занимают "реликты", в прошлой моей организации этот были две бабушки, годящиеся мне в прабабушки. И работают они сугубо на своей волне, и чихали они на сроки выдачи чего-либо, переработки, задержки выплат по объекту, и, как следствие - задержки всем зп.

[Pavel_V]

Сообщение от vd17 Есть ГОСТ и его нужно соблюдать, вполне реальные ошибки - несоблюдение ГОСТа оформление и других.

Может и раньше, во времена рисования тушью, критично было отличать букву О от цифры 0, а сейчас доскональное следование требованиям ГОСТ-а на оформление резко снижает производительность и уже большая часть требований к оформлению мало кому нужна. А нормоконтроль из бабушек занимается тем, что требует изменения падежей в комментариях к строкам кода и расстоянием между строк в переводе на программерские реалии.
А тестировщики на проектны лад, это те, кто испытывают каркас на сейсмические воздействия - выдержит/не выдержит или систему отопления на предмет способности согреть здание в морозы. Что с точки зрения пользы гораздо интереснее.
Тестированием должна экспертиза заниматься (например пересчет каркаса в другом программном комплексе с полной перепроверкой исходных нагрузок и коэффициентов), что с каждым годом все дальше и дальше от реалий.

[Brandashmыg]

Когда поиск коллизий в программах будет нормально реализован и проект будет полностью в 3д - даже узлы - тогда, возможно, и у нас появятся тестировщики. Вполне разумно было бы смоделировать автоматом все ситуации при монтаже/эксплуатации и обнаружить косяки до строительства. Поменял узел, запустил тесты - а фасонка мешает монтажу какого либо блока ОВ на 4-м месяце стройки...