Skip to main content

Блог инженера

Блог о минимализме, инжинерии и программировании.



Типичный дерьмовый проект

  | #Блог

Только что получил письмо. В понедельник состоится совещание по “окончательному выбору технологии утилизации отходов бурения”. Весьма символично, первое совещание, на котором были утверждены технические решения для полигона по переработки отходов производства и потребления состоялось 10 месяцев назад. С тех пор проектирование приостанавливалось, менялись требования к проекту, менялись исходные условия. С точки зрения проектного менеджмента это типичный дерьмовый проект. Я не ропщу, это закономерно, когда я приступал к проекту, у меня тоже отсутствовало видение, каким он должен быть. А у главного инженера проекта оно должно быть изначально. Если кратко проанализировать проблемы, то выводы следующие:

1) Наличие чётких требований к результату процесса.

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

2) Наличие чётких требований к “конечным точкам” переработки.

С этим было хуже. Единых требований к содержанию нефтепродуктов в продуктах переработки нет. Для получения отходов V класса опасности нужно, чтобы содержание нефтепродуктов было < 0,5% (и выбранные технологии этого не обеспечивают). В Югре есть местное законодательство, устанавливающее куда более мягкие требования к остаточному содержанию нефтепродуктов. Задание на проектирование, технические условия не указывали, каковы требования к “конечным точкам” процесса переработки. Это создаёт дополнительные риски и заказчику проекта и проектному институту.

3) Наличие чётких начальных условий проекта.

Они могут пересматриваться, но пересмотр должен происходить на предпроектной стадии. В нашем случае объёмы образования отходов менялись дважды, по одной из позиций объём образования отходов просто не установлен.

4) Наличие постоянной рабочей группы.

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

С ходу, это всё. Итоги несоблюдения этих принципов - календарный план поломан, проект опаздывает на пол-года, проектные решения корректируются на поздних этапах проектирования.

Из позитивных моментов - со стороны заказчика сейчас проект курирует человек имеющий полномочия, принимающий решения и пытающийся организовать этот проект. Будем считать, нам повезло.

About Mikhail Kiselev

Photo of Mikhail Kiselev

Приветствую в моём блоге! 😄 Меня зовут Михаил. Я инженер и программист. Живу в Израиле. Но мой блог связан с работой в Сибири и на Сахалине, путешествую где придётся. Я предпочитаю пост в блог посту в твиттер. Описание полезной технологии или гаджета предпочитаю описанию заката или посиделок в кафе.