Скільки може тривати робота над проектом
Скільки може тривати робота над проектом?
Вічне питання, яке мучить керівників проектних організацій: чому так повільно виконуються проекти? Причому поняття «повільно» у кожного своє: для когось місяць на проектування – багато, а комусь і тиждень здається недозволеною розкішшю. Але всі сходяться в одному – треба цей процес прискорити. Ось тільки як? Можна набрати цілий штат співробітників для виявлення причин, що гальмують проектування, можна придбати спеціальні програми, які допоможуть копуше-проектувальнику швидше малювати квадратики.
Я, як людина, яка безпосередньо займається проектуванням, висловлю свою думку з цього приводу. Отже, що мені, проектувальнику, потрібно виконати проект у термін? Пропоную розглянути деякі найбільш відповідальні етапи проектування, щоб з'ясувати, де собака закопаний.
Проектування починається з отримання технічного завдання головного інженера проекту (ГИП). Чим чіткіше і точніше сформульовано завдання, тим правильніше буде виконано проект. Часто через якісь причини проектувальнику надається недопрацьоване завдання. Це може статися, якщо, наприклад, ГІП ще не домовився із замовником щодо деяких аспектів. Чи може проектувальник розпочати роботу при неповному технічному завданні? Не може, але часто приступає.
Основна причина недосконалого технічного завдання – вихідні дані. Тут можливі різні варіанти:
- Вихідних даних немає;
- вони є, але не всі;
- Вихідні дані змінилися.
Останнє призводить до найбільш кардинального перекрою, а отже, затримки випуску проекту.
Дуже важливим пунктом вихідних даних є кабельні траси. Без кабельних трас проектувальник застряє на початку проекту, як «Жигулі»кучугурі. Що робити, якщо замовник «поки не визначився» та «працює над цим питанням»? Можна, звичайно, почекати, але, як на мене, краще постаратися прискорити роздуми замовника. Найдієвіший спосіб – уявити йому генплан, на якому будуть довільно нанесені кабельні траси. Далі слід запитати, чи влаштовує його, замовника, таке рішення? Якщо ні, то попросити його підкоригувати трасу. Не сумніваюся, що справа піде веселіше, тому що завжди легше внести виправлення в чиюсь роботу, ніж зобразити щось самому. Можливо, замовнику буде потрібно проконсультуватися з електриком або зв'язківцем. Можна вважати, справа зрушила, і, не відкладаючи на потім, треба відразу розшукати вищевказаних фахівців, щоб спільними зусиллями отримати заповітні лінії на плані.
Буває так, що замовник не зовсім розуміє, що в кінцевому підсумку являтиме пропонована йому система безпеки. Для того, щоб він зміг ухвалити остаточне рішення та підписати угоду, йому потрібно поглянути на проект. Не у кожного замовника настільки добре розвинена уява, щоб за одними словами ГІПу: «Ми повісимо телекамеру на тій опорі і на цій, а датчики в лівому крилі коридору трохи правіше від входу…» уявити всю картину системи безпеки. Замовнику потрібно підказати. Для цього варто запропонувати йому план із нанесеними на нього технічними засобами охорони (ТЗН). Завдає ТСО на плани, звичайно ж, проектувальник. Увага! Тут може бути ще одна причина переробки проекту. Справа в тому, що іноді деякі ГІПи з якихось загадкових причин не бажають розкривати перед проектувальниками всі карти - пояснити справжній стан речей. Вони воліють позиціонувати як технічне завдання його заготівлю. Тобто замість того, щобзапропонувати проектувальнику заздалегідь нанести на плани ТСО і зупинитися, ГІП вимагає створити проект цілком. Далі відбувається таке. Проектувальник на всіх парах розгортає бурхливу діяльність: креслить схеми підключення коробок, вимальовує комутації шаф, старається над кабельними журналами. З усіх його праць ГІП потрібні лише планування з датчиками, але він про це мовчить. Після розмови із замовником, де останній хвацько перетасовує ТСО, сяк-так народжується щось схоже на технічне завдання. Це завдання, як правило, дуже відрізняється від свого попередника, на підставі якого проектувальник встигає створити добру частину проекту. Зрозуміло, що проект, що наближається до кульмінації, летить у сміттєвий кошик.
Є такий чудовий вид проектної діяльності – виконавча документація. Це коли об'єкт змонтований і потрібний документ, що відображає дійсну картину охорони об'єкта. Якщо монтажник виконає хоча б сімдесят відсотків приписів, вже йому велике спасибі, за те, що проектувальнику потрібно буде відобразити на папері лише тридцять, що залишилися. Але, крім монтажних робіт, є ще обладнання, яке закуповується на об'єкт. Не завжди марки і тип (і навіть кількість) встановленого устаткування збігаються із зазначеними у специфікації. Одна з причин такої розбіжності полягає у неузгодженості дій проектного відділу та відділу, що займається закупівлями. Якби на етапі проектування, перш ніж вибрати будь-яке обладнання, проектувальник порадився б із фахівцем з маркетингу, багатьох виправлень та переробок вдалося б уникнути.
Список необхідних документів наведено у ГОСТі, і їх обов'язково включають у проект. Але окрім цього, у проекті з'являються інші додаткові креслення, якіспрямовані на полегшення сприйняття проекту монтажниками. Мене завжди цікавило, а хто питав у монтажників, що саме їм варто роз'яснити та які креслення у них викликають першочерговий інтерес? У проектних відділах іноді каменем спотикання стає формат креслення. Якби була моя воля, я б усі документи оформляла б на А4, у крайньому випадку, на А3. Погодьтеся, кому потрібні ці «подковдра» - А1? Гаразд, якщо у великому форматі представлений генплан - це найрозумніше його застосування. Але деякі керівники вимагають всі схеми з'єднань, що існують у проекті, заліпити на один величезний лист. Особисто у мене, коли дивлюся на такі схеми підключень, розбігаються очі, і робиться дуже складним простежити за ланцюгом сигналу. А як за таким кресленням виконувати монтаж? Уявляю монтажника, який водить пальцем по паперу, щоб не втратити потрібне з'єднання. На будівельному майданчику такі формати хороші, хіба що тільки як скатертина.
На жаль, нерідко ГІП і проектувальник, самі того не бажаючи, перебувають по різні боки барикади. Проектувальник зобов'язаний дотримуватися норм і правил, ДІП часто змушений надходити за ситуацією, через економічні або інші причини. Він би і радий дотриматися всіх норм, але специфіка об'єкта не дозволяє (наприклад, замовник не погоджується на риття додаткової траншеї, або ГІП бачить складність у подальшому узгодженні цієї виритої траншеї). Тут починається конфлікт між ДІПом та проектувальником, який дозволяється, само собою, на користь ДІПу. До чого це може спричинити?
Варіант перший. Замовник схаменеться і зважиться на траншею. Добре, якщо це рішення буде оперативно донесено до проектувальника. Як неминучість – переробка проекту. Чим раніше «одумалися» та «донесли», тим менше переробляти, аотже, ближча готовність проекту.
Варіант другий. Замовник від свого рішення не відступив, у проекті не дотримано незручних правил. Якщо проект потрапить на експертизу, все одно його доведеться переробляти, бо той, хто перевіряє глух до чиїхось складнощів. До речі, при виявленні помилок у проекті, організація ризикує втратити ліцензію.
Варіант третій. Проект пройшов перевірку, і всім все зійшло з рук. Добре, якщо так, але нерідко таємне стає явним, і за законом бутерброду недоліки спливають на поверхню в самий невідповідний час. Зазвичай складнощі, що утворилися згодом, лягають на плечі замовника. Багато хто справедливо помітить: «Сам винен, мовляв, за що боровся…». Але, незалежно від того, з чиєї вини було допущено помилку, проектна організація буде згадана недобрим словом.
Який я бачу вихід із ситуації?
По-перше, ГІПам та проектувальникам варто нарешті почати працювати однією командою. Було б набагато ефективніше, якби ще до початку збору вихідних даних ГІПи та представники проектного відділу почали співпрацювати: узгоджували свої дії, спільно опрацьовували загальну концепцію роботи над майбутнім проектом.
По-друге, слід встановити тісний зв'язок між усіма відділами організації (постачальниками устаткування, монтажниками, кошторисниками). Засвоїти, що проект не закінчується випуском паперової підшивки і за його якість відповідає кожен, хто хоч якось був причетний до його створення.
Галина Єгорова, інженер-проектувальник