Техническое задание и техническое решение
Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.
Чтобы решить эту проблему обычно Разработчики говорят Заказчику — напиши ТЗ (техническое задание). Чтобы понять что нужно.
ТЗ и ГОСТ
ТЗ и Бритва Оккама
Бритва Оккама в данном случае говорит о том что наиболее простое решение — наиболее верное. Если нет веских причин для усложнения.
Какое самую простую форму ТЗ можно придумать? Ответ — простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.
Иногда она может расширяться некоторыми полезными артефактами (разделами):
Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект — тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе — у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать — не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.
Техническое решение или ТР
А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.
Техническое решение — пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.
Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.
Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.
Почему ТР важно?
ТР важно по ряду причин:
Именно составление ТР — позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте — зачастую приводит к недопониманию и конфликту.
Когда можно без ТР?
Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:
Исключение из п.2 — даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) — поняли друг друга.
Итого
Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.
Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.
И даже если Разработчик поймет что такое ТЗ, то для написания ТР снова нужны усилия и ответственность. А если лень то получаем рост Риска получить в результате не то что ожидали + Конфликт.
Технические проектные решения в строительной сфере: тонкости организации
Согласование технической документации – вопрос, который вызывает массу сложностей, как у новичков, так и у более опытных участников строительного рынка. Причин такой проблемы достаточно – запутанность законодательства и низкая квалификация кадров, из-за чего возникают ошибки и сложности утверждения проекта. Вполне логично, что рассчитывать на положительное заключение и утверждение проектной документации не приходится. В чем же особенности проектирования? Какие разделы находят отражение в проекте организации возведения объекта? Каков порядок рассмотрения, а также последующего утверждения проекта?
Общие положения
Проект представляет собой набор бумаг, разработка которых – задача специализированной проектной организации. В структуру входят технические и экономические вычисления, графики и рисунки здания, план участка и прочие бумаги. Именно эта документация должна быть проверена с обязательным предоставлением заключения экспертов. Без проекта строительная организация не вправе возводить объект.
Не менее важный момент – процесс проектирования. Под этим термином подразумевается комплекс работ, выполняемых группой специалистов. Результатом труда является проектная документация, которая применяется для строительства зданий, сооружений и объектов разного назначения. При этом действующий порядок подразумевает утверждение бумаг и получение заключения со стороны уполномоченной инстанции (об этом уже упоминалось выше).
В роли генпроектировщика, как правило, выступает компания (юрлицо). Такая структура берет на себя функции организации подготовки бумаг для последующего возведения объекта. Генпроектировщик отвечает:
Разработка проекта невозможна без наличия задания на проектирование. Последнее выдается заказчиком при согласовании организации, занимающейся вопросами проектирования. Задание – один из ключевых элементов, от которого зависит успех утверждения и непосредственно заключение (положительное, отрицательное) уполномоченной структуры. В задании должны указываться:
Работы по проекту проходят в несколько этапов. Зачастую этот момент зависит от сложности здания и его функциональных особенностей. Вариантов несколько:
Наибольшую сложность представляет порядок составления и комплектации проектной документации на возведение сооружения. Чтобы рассчитывать на положительное заключение проверяющего органа, в документации должны быть:
Важный момент – порядок утверждения документации. Здесь принцип прост. На каждом из этапов создания проектной документации ведется одновременный процесс разработки и согласования разделов документа с уполномоченными структурами:
Как только разработка техпроекта завершена, готовый документ должен быть согласован.
Особенности проведения экспертизы
Один из ключевых этапов в процессе возведения объекта – организация экспертизы проекта. Именно благодаря этой работе удается снизить общие затраты на возведение объекта, устранить ошибки проектировщиков, исключить явные недостатки документации, допущенные в процессе разработки. При проведении экспертной проверки уделяется внимание следующим нюансам:
Текущий порядок подразумевает, что вопросы экспертизы берет на себя уполномоченный орган с учетом правил, установленных в РФ на законодательном уровне.
Инженерные изыскания
Как правило, положительное заключение можно получить только при наличии грамотно составленных строительных изысканий. В чем же особенности этой работы? По сути, изыскания – это работы, которые затрагивают технический и экономический сектор. Как правило, они направлены на проведения анализа реализуемого проекта со всех сторон. От организации напрямую зависит разработка документов и скорость рассмотрения готовых бумаг.
При этом в экономические изыскания включается ряд аспектов. Главный из них – целесообразность организации строительства на конкретном участке с учетом энергетической и сырьевой базы, особенностей подведения электроэнергии, водных ресурсов, обеспечения кадрами и так далее.
Действующий порядок также подразумевает включение в документы анализа экономических перспектив района и прочих аспектов. При этом заключение выносится только по факту изучения технических и экономических аспектов строительства.
Что касается организации работ по подготовке технических изысканий, то внимание должно быть уделено следующим моментам:
Что касается организации проведения таких работ, то они проходит в несколько этапов:
Что касается упомянутых выше работ, то они выполняются проектной организацией, которая и несет ответственность за результаты заключения.
Техническое задание и техническое решение + шаблон
Техническое задание и техническое решение + шаблон
Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.
Чтобы решить эту проблему обычно Разработчики говорят Заказчику — напиши ТЗ (техническое задание). Чтобы понять что нужно.
Чаще всего это приводит лишь к усугублению проблемы 🙂 Потому что обычно вместо ТЗ пишется некий документ содержащий сочинение на тему желаний. Который затем достаточно сложно реализовать.
Почему так происходит? Смею предположить причина в том что стороны не понимают что такое ТЗ, в чем его смысл, как оно выглядит и что должно быть после него 🙂
ТЗ и ГОСТ
Чаще всего люди идут гуглить что такое ТЗ, налетают на ГОСТ и пытаются делать по нему 🙂 Вот только они не учитывают что ТЗ по ГОСТ было придуман для проектов на 1000 человек, и только одна подготовка такого ТЗ если делать ее правильно может стоить 1-2-10 млн. руб. Не считая работ по его реализации. А пытаются это применять для проектов где работает 1-2-3 человека 🙂 Делается это все без понимания особенностей такого документа и получается как раз то самое собрание сочинений. Бессмысленное и беспощадное.
ТЗ и Бритва Оккама
Бритва Оккама в данном случае говорит о том что наиболее простое решение — наиболее верное. Если нет веских причин для усложнения.
Какое самую простую форму ТЗ можно придумать? Ответ — простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.
Иногда она может расширяться некоторыми полезными артефактами (разделами):
Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект — тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе — у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать — не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.
Техническое решение или ТР
А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.
Техническое решение — пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.
Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.
Пример для понимания. Заказчик дает ТЗ «Я хочу есть», а Исполнитель предлагает ТР «На вот яблоко». Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения 🙂
Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.
Почему ТР важно?
ТР важно по ряду причин:
По ходу составления списка решений, предложений и условий — Разработчику надо будет задавать вопросы, обсуждать детали, он просто начнет понимать задачу 🙂
Именно составление ТР — позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте — зачастую приводит к недопониманию и конфликту.
Когда можно без ТР?
Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:
Исключение из п.2 — даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) — поняли друг друга.
Шаблон
Итого
Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.
Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.
И даже если Разработчик поймет что такое ТЗ, то для написания ТР снова нужны усилия и ответственность. А если лень то получаем рост Риска получить в результате не то что ожидали + Конфликт.
Потому эти особенности надо запомнить как Заказчику, который хочет получать ожидаемые результаты и на старте оценить адекватность Разработчика. Так и Разработчику, который хочет сделать то что нужно Заказчику, деньги, отзыв и славу 🙂
5 оцените контент и участвуйте в выборе трендов