Тема: Карточка основных технических решений (Прочитано 6049 раз)
0 Користувачів і 1 Гість дивляться цю тему.
Впервые нужно составить карточку основных технических решений. Есть ли какая-то форма этой карточки? Была бы очень признательна за образец такого документа (проектируемый объект — жилой комплекс с паркингом) или за комментарий.
Записаний
saveleva, хм, А что это за зверь такой?
На какой стадии вы проектируете? (ТЕО, П ,Р, РП)?
И кто от Вас его потребовал?
Записаний
Дела не всегда обстоят так, как кажется
На самой начальной стадии, до стадии П. Требует КазаХстан.
Записаний
saveleva, Я имею в виду — экспертиза, Облэнерго или еще какая-то организация?
Дело в том, что термин абсолютно незнаком, может быть, у нас он называется по другому.
Записаний
Дела не всегда обстоят так, как кажется
Записаний
saveleva, на сколько я понял речь идет о задании на проектирование самому себе. Если да, то на сколько я знаю, стандартной формы нет, Составляется в виде таблицы в которой прописываются основные решения которые будут приниматься в проекте: Исполнение ТП (оборудование), способ прокладки и марка кабелей наружных и внутренних сетей, учет, типы применяемых светильников и установочного оборудования ну и т.д
Записаний
Сугор, так и есть. Идеальный пример — от SINEDB. КОПР называется (карточка основных проектных решений).
Записаний
Загрузка документа
«Форма технического решения о продлении назначенного срока службы»
Имя файла документа: 32898
Доступные форматы скачивания: .doc, .pdf
Размер текстовой версии файла: 3,0 кб
Как скачать документ?
Дождаться загрузки ссылок для скачивания, они очень скоро появятся на этом месте
После появления ссылок, скачайте нужный вам формат
Не забудьте «Сказать спасибо», ваш голос помогает формировать нам рейтинг документов
Договор-образец.ру — это база из более чем 5 тысяч типовых образцов договоров и документов, ежедневное обновление и большое сообщество, объединяющее специалистов в юриспруденции. На сайте собраны самые различные договоры, контракты, соглашения, заявления, акты, бухгалтерские и финансовые документы, анкеты, доверенности и многие другие образцы, которые могут потребоваться в жизни каждого человека. Спасибо за ваше участие.
Пожалуйста, обратите внимение, что представленный образец документа является типовым, в нем отражены существенные условия, но без учета конкретной ситуации. Если вам нужен индивидуальный документ под вас, то лучше обратиться к квалифицированным специалистам.
Документы, которые также Вас могут заинтересовать:
- Решение о ликвидации предприятия
- Решение о ликвидации юридического лица
- Решение о выпуске акций
- Решение о создании ООО с единственным учредителем
- Решение собственника о создании некоммерческой организации
- Решение акционера об утверждении (промежуточного, окончательного) ликвидационного баланса
- Решение учредителя о внесении изменений в устав учреждения
- Решение учредителя ООО о создании обособленного подразделения
- Решение учредителя ООО о создании филиала
- Модельное решение представительного органа поселения о передаче осуществления части полномочий органам местного самоуправления муниципального района
- Оборотная сторона решения собственника помещения по вопросам, поставленным на голосование на общем собрании собственников помещений в многоквартирном доме, проводимом в форме заочного голосования (путем обхода квартир) на территории города Фрязино Московской области
- Образец бланка решения заседания Совета Федерального агентства морского и речного транспорта (Росморречфлота)
- Образец бланка решения Совета депутатов города Лобни Московской области
- Образец проекта решения (постановления) Московской областной Думы (вносится советом депутатов г. Коломны Московской области)
- Образец решения об утверждении заключения экспертизы промышленной безопасности проекта противопожарной защиты угольной шахты, опасного производственного объекта угольной промышленности
Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.
Чтобы решить эту проблему обычно Разработчики говорят Заказчику – напиши ТЗ (техническое задание). Чтобы понять что нужно.
Чаще всего это приводит лишь к усугублению проблемы 🙂 Потому что обычно вместо ТЗ пишется некий документ содержащий сочинение на тему желаний. Который затем достаточно сложно реализовать.
Почему так происходит? Смею предположить причина в том что стороны не понимают что такое ТЗ, в чем его смысл, как оно выглядит и что должно быть после него 🙂
ТЗ и ГОСТ
Чаще всего люди идут гуглить что такое ТЗ, налетают на ГОСТ и пытаются делать по нему 🙂 Вот только они не учитывают что ТЗ по ГОСТ было придуман для проектов на 1000 человек, и только одна подготовка такого ТЗ если делать ее правильно может стоить 1-2-10 млн. руб. Не считая работ по его реализации. А пытаются это применять для проектов где работает 1-2-3 человека 🙂 Делается это все без понимания особенностей такого документа и получается как раз то самое собрание сочинений. Бессмысленное и беспощадное.
ТЗ и Бритва Оккама
Бритва Оккама в данном случае говорит о том что наиболее простое решение – наиболее верное. Если нет веских причин для усложнения.
Какое самую простую форму ТЗ можно придумать? Ответ – простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.
Иногда она может расширяться некоторыми полезными артефактами (разделами):
- Цели – описать не только то что надо сделать, но и для чего мы это делаем? Чтобы что? Это бывает полезно для повышения качества результатов.
- Снимки, фото, звуки, примеры – бывает полезно добавить в задание снимок ошибки (например когда мы делаем сайт) или пример/фото того как это сделано у кого-то еще.
Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект – тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе – у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать – не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.
Техническое решение или ТР
А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.
Техническое решение – пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.
Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.
Пример для понимания. Заказчик дает ТЗ “Я хочу есть”, а Исполнитель предлагает ТР “На вот яблоко”. Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения 🙂
Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.
Почему ТР важно?
ТР важно по ряду причин:
- Только Разработчик реально знает как решать задачу (по этой причине Заказчик обычно к нему и обращается), а значит только он может описать детали того как можно получить ожидаемый результат
- У любой задачи может быть 3-4 варианта решения (а часто больше), и тут Заказчик должен убедиться что Разработчик может предложить нечто адекватное
- Задача одна, но несколько вариантов решений часто означает разные цены. причем вилка цен может быть условно от 100 000 руб до 10 000 000 руб. ТР позволяет составить список условий и сузить разброс цен – уложиться в нужный бюджет и срок.
По ходу составления списка решений, предложений и условий – Разработчику надо будет задавать вопросы, обсуждать детали, он просто начнет понимать задачу 🙂
Именно составление ТР – позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте – зачастую приводит к недопониманию и конфликту.
Когда можно без ТР?
Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:
- Если между Заказчиком и Разработчиком есть полное взаимопонимание и доверие, большой успешный опыт совместной работы. Когда Заказчик целиком доверяет Разработчику и полагается на его знания.
- Если мы работаем по Agile и у нас мелкие простые задачи
Исключение из п.2 – даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) – поняли друг друга.
Шаблон
Инструкции и шаблон тут https://docs.google.com/document/d/1ydqe0H-HjzVD4lt6ZbkUdpQNqleJZoTEIqJtTRcu6dE/edit?usp=sharing
Еще проще – идем через спецификацию
В целом все это можно упростить до 1го простого документа – спецификация.
Но писать этот документ нужно через метод WWH.
Шаги такие:
- создаем документ и называем его – Спецификация
- далее 3 ключевых раздела: Что нужно? Почему это нужно и чтобы что? Как это планируем делать?
- После того как сделали документ и описали 3 ключевых вопроса – можно докинуть еще другие разделы по вкусу и по ситуации.
В качестве доп. разделов могут быть дизайн макеты, какие то детали реализации и прочая аналитика.
Важно тут учитывать что докидывать информацию имеет смысл если есть причины. Усложнение без причины – признак дурачины. Избыточная информация также вредна как и ее недостаток.
Итого
Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.
Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.
И даже если Разработчик поймет что такое ТЗ, то для написания ТР снова нужны усилия и ответственность. А если лень то получаем рост Риска получить в результате не то что ожидали + Конфликт.
Потому эти особенности надо запомнить как Заказчику, который хочет получать ожидаемые результаты и на старте оценить адекватность Разработчика. Так и Разработчику, который хочет сделать то что нужно Заказчику, деньги, отзыв и славу 🙂
Основные тезисы:
- Заказчик пишет ТЗ, оно может быть коротким, на салфетке из кафе, и содержать 3-4 пункты ключевых требований
- ТР – пишет Разработчик, оно может быть длинным, его цель сформулировать, согласовать и зафиксировать задание и предлагаемое решение.
- Только пара из ТЗ и ТР позволяет получить взаимопонимание между Заказчиком и Разработчиком.
- Иногда можно отказаться от ТР, но надо хорошо понимать когда это можно делать и последствия
Telegram WordPress
Телеграм канал и чат про WordPress
Будьте в теме и общайтесь про улучшение своих проектов и сайтов на WordPress
Обновлено: 15.04.2023
Отвечаю на вопрос тех, кто собирается строить себе коттедж, и думает о том, как выполнить проект отопления своего чудного домика.
Вопрос заключается в следующем, какие исходные данные нужны проектировщику раздела ОВ. Понятно, как многие злопыхатели тут орут: «АвтАр ты сАвсем сдурел, ТЗ писал всю жизнь проектировщик». Ответ для таких – писать может кто угодно, но согласовывать все это нужно с заказчиком, после этого он должен подписать эти свои «хотелки». Тем самым, в какой-то степени, проектировщик обезопасит себе от кучи БЕСПЛАТНЫХ переделок.
Причем, даже тот, кто самостоятельно будет разбираться, без выше перечисленных данных, не сможет сделать проект. Можно конечно сделать и без расчетов, и без проекта, — я не настаиваю.
Данный файл, кому, это нужно безболезненно найдете в моей группе в ВК.
КАРТОЧКА ТЕХНИЧЕСКИХ РЕШЕНИЙ ДЛЯ ИЖС
(раздел ОВ: отопление, вентиляция, теплогенераторная)
Объект: строительства: жилой дом с бассейном.
1. Указать адрес расположения объекта (город, поселок и т.д.) для определения климатических параметров.
2. Необходимы последние утвержденные варианты планировок. На чертежах должна быть экспликация с помещениями (таблица в которой указаны номера помещений, их названия и площадь) или просто подписаны все помещения (кухня, ванная, санузел и т.д.).
3. Необходима ведомость заполнения проемов, т.е. на планировках должна быть таблица с указанием, какие окна и двери будут применены. Необходимо указать тип стеклопакета (однокамерный, двухкамерный, трехкамерный).
4. На планах с разделе АС (строительная часть) должны быть предусмотрены вент. каналы. Если их нет, то это нужно прописать в задании для того чтобы определиться с их расположением и габаритами.
5. Необходимы разрезы и фасады.
6. Указать конструктив (пирог) стен, пола, крыши, наличие чердака, с указанием значений коэффициентов теплопередач ограждающих конструкций (эти данные должны быть в разделе АС).
Если отсутствует такая информация, то необходимы полное название каждого материала и его толщина.
7. Указать помещения, где нужны теплые полы (обычно теплый пол предусматривается в следующих помещениях: ванные, душевые, санузлы, коридоры).
8. В помещениях, с теплыми полами необходимо примерное расположение мебели, т.к. расположение теплых полов (под мебелью устройство теплых полов не желательно).
9. В помещениях, где будут располагаться теплые полы указать вид финишного покрытия пола (плитка, керамогранит, ламинат, и т.д.)
10. Указать, какое будет оборудование:
тип труб (металлопластиковые, стальные, полипропиленовые и т.д.);
тип радиаторов (алюминиевые секционные, биметаллические, стальные панельные и т.д.)
11. Указать тип проектируемой системы отопления – однотрубная (ленинградка); двухтрубная; коллекторная (лучевая с установкой коллекторных шкафов), свой вариант (предлагает заказчик).
12. В каком объеме будет выполнятся проект (в полном объеме или частично. Например, только планы без схем; только планы, схемы и теплогенераторная, и т.д.).
13. Необходимо ли учитывать фитинги в спецификации.
14. Указать параметры горячей воды для бассейна (температура воды, максимальный расход в час, количество потребления ГВС в сутки). Эти данные обычно предоставляют те, кто будет заниматься поставкой оборудования для бассейна и его монтажом.
15. Указать марку и количество котлов, если они подобраны, или указать предпочтительную марку.
16. Необходима ли разработка проекта внутреннего газоснабжения? Также необходимо согласовать решения по дымоходам:
тип, материал, размещение, количество, фундамент (при необходимости).
17. Необходим ли проект наружного газоснабжения, если да, то нeобходима топосъемка с точкой подключения газопровода и ТУ от ГОРГАЗА .
PS. если на какой-то вопрос заказчик не знает ответа, то любой уважаемый себя проектировщик может объяснить эти нюансы и тонкости.
Сейчас я хочу поговорить о начальном этапе проектирования, даже не начальном, а предварительном – предшествующем началу, скажем так. Возможно, начинающим проектировщикам не особо нужно знать такие тонкости, но время летит быстро, и я уверена, скоро вы дорастете до бюрократических моментов составления договора. Денежными вопросами на этом этапе пусть занимаются ГИПы, я же хочу написать о том моменте, который важен для конструктора. Очень важно иметь наиболее полные исходные данные, чтобы потом триста раз не переделывать одно и то же, меняя шило на мыло. В помощь проектировщику давно придумана и успешно применяется «Карточка применяемых конструкций, материалов и технических решений».Я добавила пример такой карточки во вложении, можете ознакомиться.
Эта карточка составляется проектировщиком (чаще всего – главным конструктором) и включает все возможные решения по выбранному объекту. Из чего мы будем проектировать каждую часть здания, какие материалы применим, какие технических решения лягут в основе проекта. В карточке должно быть все: от материала обратных засыпок до решений по внутренней отделке. Естественно, проектировщик предлагает лишь те варианты, которые реально выполнить. Если вам все равно, какие фундаменты проектировать, предлагайте несколько вариантов: фундаментная плита, монолитные ленточные или ленточные сборные. Только стоит учесть заранее, возможно ли применение всех предложенных вариантов на этом объекте. И по каждому пункту, указанному в карточке, заказчик согласовывает один или несколько выбранных вариантов либо предлагает свой.
- Вы заранее заставляете заказчика обдумать, какой из предложенных вариантов будет ему наиболее выгоден – как финансово, так и технически (объект еще ведь строить придется). В итоге, ни для него, ни для вас не окажется сюрпризом применение определенных решений и материалов.
- Вы перекладываете часть забот на заказчика – пусть он выбирает, из чего будем строить. Да и споры между проектировщиками по поводу выбора между двумя равноценными решениями исключаются (ну, или их станет немного меньше).
- Если потом будут приходить письма от заказчика с просьбой замены материалов и решений, вы без проблем требуете денег за корректировку проектно-сметной документации. Ведь согласованная карточка подшита к договору. Опыт показывает, что согласовав карточку, заказчики становятся на порядок скромнее в своих запросах.
- Составляя карточку, проектировщик осознанно анализирует каждый болтик здания. Поверьте, это дает потрясающие озарения, особенно важные на начальном этапе проектирования.
Еще желательно прописать в договоре, что проектирование стартует только после согласования заказчиком карточки применяемых конструкций, материалов и технических решений. Это настраивает заказчика на рабочий лад и не дает расслабиться.
В общем, если вы еще не применяете карточку, советую не откладывать и начать с ближайшего проекта.
Читайте также:
- Особый вид компьютерной программы 6 букв
- Что означает кнопка перевернутый восклицательный знак на панели задач в программе 1с
- Программа таймер для тренировок андроид
- Как подключить bits stdc h в visual studio
- 1с не открывает файлы pdf