Всё начинается с потребности в какой-то продукции. Умные люди рассчитывают, сколько этой продукции нужно, в каких местах её имеет смысл производить — и после этого ищут допустимые места для стройки. Решение зависит от имеющихся ограничений, но в большинстве случаев само здание проектируется вокруг основного оборудования.
Например, трубопрокатный цех и трубоэлектросварочный цех для меня отличаются верхнеуровнево только центральной линией. С 1960-х годов в основном оборудовании мало что поменялось, всё просто обрастает новыми приводами, автоматизацией, двигателями, вспомогательными механизмами, роботами и т. п. И по большому счёту всё типизировалось до повторяемых блоков — линия контроля качества практически везде одинаковая, отделка тоже, погрузка-хранение-отгрузка тоже.
После понимания, какое оборудование нужно, где его поставить, что, куда и в каком количестве подвести, рождаются основные технические решения. Дальше первоначальный расчёт бюджета, с которым большие дяди идут к ещё большим дядям за деньгами.
Затем будущее здание разбивается на сотни подсистем и начинаются сначала предпроектные, а потом проектные работы. Моя задача — следить за тем, чтобы все нужные части технической и программной инфраструктуры, во-первых, не забыли, а во-вторых, чтобы они соответствовали нашим требованиям и были правильно вписаны в существующую ИТ-архитектуру.
Дальше осталось только построить
Составляется график проекта или проектов (подпроектов), всё это дело утверждается.
И начинается довольно нудная и кропотливая работа, состоящая по большому счёту из четырёх этапов: проектирование, тендер, закупка, стройка. То есть по изначальным требованиям (ОТР) или техническим условиям, выдаваемым уже внутри проекта, проводится проектирование, далее идёт обработка замечаний, если таковые имеются, и согласование. Если не вдаваться в подробности, далее всё это дело тендерится, что нужно покупается — и строится.
Эта цепочка работает во всех случаях и на всех объектах, со своими нюансами. Сама команда тут уже состоит классически из проектировщиков, строителей и службы заказчика, которая, собственно, и формирует требования к выполняемым работам, следит за их выполнением. Костяк этой службы — обычно те люди из предпроекта, которые и прорабатывали ОТР.
Средние сроки реализации от идеи до готового производства — от 3 до 6 лет, в зависимости от объёмов и масштаба производства.
Проекты такого масштаба, как правило, управляются методом параллельного проектирования. Упрощённо, происходит разбивка по блокам (основное здание, вспомогательные здания, дороги и т. д.) и каждый блок управляется по классической каскадной модели. Гибкие методы проектирования применяются либо там, где подсистемы совсем маленькие (и то редко), либо когда начинаются какие-то сюрпризы. Обычно всё идёт чётко от вехи к вехе, но бывают и накладки, когда приходится прибегать к временным решениям.
Моя работа
Собственно, я руководитель проекта в технической команде, которая занимается ИТ-частью, совсем небольшой в масштабах всей стройки.
Условно, у меня такие типы задач:
Читать дальше.
Например, трубопрокатный цех и трубоэлектросварочный цех для меня отличаются верхнеуровнево только центральной линией. С 1960-х годов в основном оборудовании мало что поменялось, всё просто обрастает новыми приводами, автоматизацией, двигателями, вспомогательными механизмами, роботами и т. п. И по большому счёту всё типизировалось до повторяемых блоков — линия контроля качества практически везде одинаковая, отделка тоже, погрузка-хранение-отгрузка тоже.
После понимания, какое оборудование нужно, где его поставить, что, куда и в каком количестве подвести, рождаются основные технические решения. Дальше первоначальный расчёт бюджета, с которым большие дяди идут к ещё большим дядям за деньгами.
Затем будущее здание разбивается на сотни подсистем и начинаются сначала предпроектные, а потом проектные работы. Моя задача — следить за тем, чтобы все нужные части технической и программной инфраструктуры, во-первых, не забыли, а во-вторых, чтобы они соответствовали нашим требованиям и были правильно вписаны в существующую ИТ-архитектуру.
Дальше осталось только построить
Составляется график проекта или проектов (подпроектов), всё это дело утверждается.
И начинается довольно нудная и кропотливая работа, состоящая по большому счёту из четырёх этапов: проектирование, тендер, закупка, стройка. То есть по изначальным требованиям (ОТР) или техническим условиям, выдаваемым уже внутри проекта, проводится проектирование, далее идёт обработка замечаний, если таковые имеются, и согласование. Если не вдаваться в подробности, далее всё это дело тендерится, что нужно покупается — и строится.
Эта цепочка работает во всех случаях и на всех объектах, со своими нюансами. Сама команда тут уже состоит классически из проектировщиков, строителей и службы заказчика, которая, собственно, и формирует требования к выполняемым работам, следит за их выполнением. Костяк этой службы — обычно те люди из предпроекта, которые и прорабатывали ОТР.
Средние сроки реализации от идеи до готового производства — от 3 до 6 лет, в зависимости от объёмов и масштаба производства.
Проекты такого масштаба, как правило, управляются методом параллельного проектирования. Упрощённо, происходит разбивка по блокам (основное здание, вспомогательные здания, дороги и т. д.) и каждый блок управляется по классической каскадной модели. Гибкие методы проектирования применяются либо там, где подсистемы совсем маленькие (и то редко), либо когда начинаются какие-то сюрпризы. Обычно всё идёт чётко от вехи к вехе, но бывают и накладки, когда приходится прибегать к временным решениям.
Моя работа
Собственно, я руководитель проекта в технической команде, которая занимается ИТ-частью, совсем небольшой в масштабах всей стройки.
Условно, у меня такие типы задач:
- Понимать, что хочет заказчик и корректировать решения в ИТ-части.
- Планировать и управлять бюджетом ИТ.
- Обеспечивать разбивку задач по командам и координировать работы.
- Выдавать технические условия (ТУ) для проектировщиков.
- Составлять ТЗ для поставщиков.
- Проверять, что предложенное ими решение — это именно то, что мы хотели. А не то, как можно обойти формулировки ТЗ либо немножечко деградировать.
Читать дальше.
