Тех задание в строительстве

За годы работы я пришел к работающей конструкции в данной части воронки моих продаж — я всегда отвечаю на такие письма — отлично, получил, я вижу ваши пожелания к решениям в письме и, а тз вы забыли приложить?

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

Соглашение о терминологии

1. Артефакт — физическое представление в реальном мире чего либо сотворенного человеком.
2. Замысел — то что находится в голове или головах клиентов.
3. Пожелания — артефакт замысла.
4. Требования — согласованные с реальностью пожелания.
5. Физика окружения — в случае с сайтом это все компоненты из которых он может быть изготовлен согласно консорциому w3c. В случае с мобильным приложением — это apple developer program или andriod development и тд
6. Архитектурное решение — словесно сформулированное предложение о реализации требования, без применения элементов физики конечного окружения (мы говорим про экраны, не говорим про экраны айфона или андроида конкретно).
7. Техническое задание — подробная конфигурация сооружаемой системы с описанием свойств характеристик назначений каждого элемента и компонента, документ задание в производство, а также документ для приемочного тестирования.

Мухи отдельно — котлеты отдельно.

1. Замысел (что) -> хотелось бы вина
2. Пожелания (сформулировано зафиксировано) -> не послать ли нам гонца за бутылочкой винца
3. Требования (контрольная точка) -> красное сухое французское
4. Архитектурное решение -> будем потреблять дома из бутылок а не в розлив из бочки в ресторане.
5. Техническое задание -> в магазине номер 5, выкупить 2 бутылки французского за 5 рублей каждую.
6. Сооружение (производство, выполнение) -> сходили купили привезли показываем
7. Получение (верификация) -> приняли по требованию, детали сверили с тз по необходимости.
8. Ввод в экспулатацию -> открываем бутылки
9. Эксплуатация -> разливаем по бокалам, потребляем блага.

1. Замысел (что) -> хотелось супер сервис который может делать дело
2. Пожелания (сформулировано зафиксировано) -> нам нужен сервис который делает это дело X, Y, Z
3. Требования (контрольная точка) -> сервис должен делать X, Y, а Z не возможно при наличие X и Y, давайте лучше H. ОК.
4. Архитектурное решение -> X мы сделаем как страницу. Y будет как игра, а H будет как запрос через форму.
5. Техническое задание -> X 5 экранов (нарисовано), 24 элемента (отмечены, описаны все данные), назначение каждого (выход от работы), сценарии поведения каждого (нажал увидел победил), действующие лица эксплуатирующие (менеджер, домохозяйка на айпеде), результаты от выполнения такие-то (информация получена, ачивка пройдена, письмо отослано, информация о товаре передана в сборку на систему склада и тд . )
6. Сооружение (производство, выполнение) -> кодинг, сборка, тестирование по тз, прогон сценариев.
7. Получение (верификация) -> деплоймент (развертывание в эксплуатационное окружение, appstore, amazon . )
8. Ввод в эксплуатацию -> принята работа, пошли баннеры реклама, регистрации.
9. Эксплуатация -> сервис работает, конверсии растут, кеш заходит в кассу.

Кто кому что должен?

Говоря о том что обычно может изложить клиент — это всегда пожелания, даже какие-то из них (малая часть) — потому как описать все пожелание человек не специалист не в состоянии просто по определению — не его контекст, и не должен он его понимать.

Зачем нужно техническое задание на строительство или ремонт? Будет полезно и строителям и клиентам !

Как составить правильное Техническое Задание? Образцы и шаблоны | Дневник проектировщика

Для наглядности я изложил одному из клиентов схемку жизненного цикла одного(!) требования и по сей день показываю для ответа на вопрос что делать:

Если есть замысел то его необходимо извлечь из головы чтобы начать работу — поняли что хотим и записали. Это пожелания. Артефакты замысла клиента — это может сделать только клиент, замысел это его часть работы.

Обычно замысел в виде пожелания и высылают на почту ошибочно называя это техническим заданием, а это даже не требования.

Клиент начинает изложение пожеланий в любом формате — мы не рекомендуем в этот момент рисовать много чего-то и присылать огромные проекты — все они все равно пойдут в проработку начиная с простого списка требований, и поэтому не стоит просто тратить на это время.

Хозяйке на заметку: ожидания что какая-то компания подрядчик возьмет в производство без переработки ваше тз (если вдруг к примеру есть хорошо проработанное на детали тз — к себе в процесс) всего лишь говорит о качестве процесса в этой компании — если они могут его так извне менять, значит работают они хаотично, на глаз.

Практика показывает что в сложных (от слова сложение, комплексных) проектах (а это любая разработка или внедрение любой бизнес системы — от сайта компании, до комплексных внедрений множественных систем) — именно качество и отлаженность процесса у исполнителя является не только гарантией качества результата, а и в целом получения итогового результата а не зарывания бюджета в провода.

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

Куда важней этот документ для производства внутри компании подрядчика, а также для контроля выходного продукта на соответствие всем заявленным требованиям и ограничениям — так мы получаем качество.

Вот простые правила предъявляемые мною к любому техническому заданию:

1. Техзадание должно быть
2. Оно пишется исполнителем в противовес на согласованные требования и подписывается сторонами.
3. Техническое задание содержит полное и исчерпывающее описание создаваемой системы в терминологии физики решения, в ее эксплуатационном окружении и четко недвусмысленно дает ответы на вопросы:
4. как именно по шагам отвечая на конкретные воздействия пользователя будет работать любой элемент системы.
5. как при этом он будет выглядеть
6. каково его назначение в рамках всей системы
7. как будет обслуживаться данный элемент в процессе эксплуатации и кем
8. и тд.
9. Содержит критерии приемки результата — что именно в рамках физики системы дает ясное понимание что конкретный элемент или сценарий системы работает корректно и успешно.
10. Написано в паре со специалистом (с подтверждаемой квалификацией) в области системной инженерии требований и специалистом по проектированию взаимодействию с системой.

О требованияхТребования — это описание (модель) системы к которому сбоку мы приписываем деонтическую модальность. (Анатолий Левенчук)

Отдельно стоит отметить что Бизнес требования — это тербования к тому как должна протекать деятельность системы.

Требования отличаются от пожеланий по простому принципу: требование = пожелание + обоснование.

Для того чтобы обосновать требование необходимо предоставить артефакты подтверждений что требования определены реальной потребностью и своим выполнением перекроют (согласуется с) миссию всего проекта (http://deppkind.livejournal.com/1863.html)

Все требования записываются списком в одну большую таблицу в три колоночки:

| 1. требование | 2. для чего нужно | 3. возможное решение |

Не существует требований второго порядка, или вложенных — требования это конкретное требование к выдаче от системы во внешний мир — что система должна выдать в конкретный момент времени и места.

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

Самое главное что нужно указать чего это делается (я прошу это указать во второй колонке, и это самое важное что может быть) — так как требования пишутся вместе с клиентом — всегда помогаем это сформулировать, иногда это сложный процесс для многих.

1. Каталог должен показывать (в глаза) товары
2. Логистическая система должна выдавать маршрут (на бумаге, в электроном письме опять же в глаза и мозг) — чтобы выполнение доставки шло согласно плану.
3. SMS о тренировках должны приходить на телефоны (устройства) — чтобы не звонить каждому.
4. Страница товара должна передавать конкретную информацию x y z (в глаза) — для принятия решения о .

В третьей колонке я прошу указать видение решения — как клиент видит что его решение могло бы работать, своими словами — пусть у нас это будет как на этом сайте (обычно так бывает), или мы хотели бы чтобы эта часть открывалась в отдельном окне. Все должно быть синим.

Если какое-то пожелание из видения решения становиться крайне важным — оно перекачивает в раздел документа под названием «Ограничения на решение».

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

Все это позволяет синхронизировать онтологию мира клиента и нашу для более ясного взаимопонимания.

Когда у нас есть требования — дальше все отрабатывается на автомате — процесс просто выполняется. Тут уже дело техники — за хорошим исполнителем как правило не заржавеет.

Требования обязательно и всегда согласуются друг с другом, формулируются обоснования, проверяется их выполнимость, делается трассировка и тд. Требования надо обосновать — что вы все не высосали из пальца. Документы, решения и прочие артефакты всегда кстати.

Трассировка требований — это инструмент, позволяющий показать степень проработки и влияния требования на компоненты системы.

В этот момент можно понять степень влияния требований. Требования поменялись — конфигурация поменялась — еще и указывает трассировку и степень влияния.

Требования подписываются сторонами. Требования легко меняются и дополняются постоянно в процессе работы, это фиксируется и не мешает работе. Требования пишутся клиентом — согласуются исполнителем, подписываются сторонами.

Если говорить о распространенных заблуждениях о том что нужно всегда формулировать выгоду от создания продукта или функции, всегда нужно иметь ввиду что мы говорим только о части работ по возведению системы в жизнь и эксплуатацию, и ни разу не говорили о бизнес стратегоровании или требованиях к бизнесу.Чуть подробнее на поиск решения через Job Stories я писал тут http://deppkind.livejournal.com/3259.html.

Поэтому когда мы говорим про требование и техзадания мы всегда говорим — не выгода а выдача.

Стоит понимать что назначение технического задания — это контрольная точка на вход в производство и выход из него.

Назначение документа-требований — проработка пожеланий и контроль результата.

1. Сесть и писать — ничего в этом сложного вообще нет. Требования это ваши же ожидания.
2. Если совсем сложно — требования можно заказать, кто сколько берет за это (это интервьюирование вас, где и как это делать каждый решает сам — я делаю это только в студии и за деньги), тут помесь работы секретаря + машинистки. Ну и контрольные вопросы конечно же от нас )
3. На собранные требования можно давать решения — а только на каждое решение может быть уже цена и сроки. Можно за 5 рублей а можно и за 50 лямов. Тут кто что вам предложит на рынке, каковы ваши потребности и ситуация.
4. Ждать и требовать подробнейшее тз от исполнителя.
5. Только после четкого понимания пускать в сооружение (разработку) систему.

На этом все, от себя могу добавить что могу с удовольствием проработать с публичным разбором ошибок ваши техзадания и требования бесплатно (или приватно в качестве экспертизы платно).

Источник: spark.ru

Ошибки в техническом задании: кто несет ответственность и как ее можно распределить? Взгляд со стороны заказчика

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

На основании технического задания должна быть составлена техническая документация.

На практике перед сторонами договора подряда нередко встает вопрос: кто из сторон договора — заказчик или подрядчик — несет ответственность за разработку технического задания, технической документации и за ошибки в техническом задании или технической документации?

Подрядчик по договору подряда на выполнение проектных и изыскательских работ несет ответственность за ненадлежащее составление технической документации и выполнение изыскательских работ, включая недостатки, обнаруженные впоследствии в ходе строительства, а также в процессе эксплуатации объекта, созданного на основе технической документации и данных изыскательских работ (п. 1 ст. 761 ГК РФ).

Иными словами, проектировщик отвечает за качество составленной им технической документации не только на этапе строительства здания, но и после его завершения, в процессе эксплуатации объекта. Интересный вопрос, который имеет важное практическое значение: в течение какого времени после ввода объекта в эксплуатацию проектировщик несет ответственность за составленную им техническую документацию? Законодатель не установил определенный срок, а в соответствии со сложившейся правоприменительной практикой ответственность проектировщика распространяется на весь период эксплуатации объекта. То есть если спроектированное здание вследствие ошибок, допущенных проектировщиком при составлении технической документации, обрушилось, к примеру, через пятнадцать лет после ввода объекта в эксплуатацию, проектировщик должен будет нести ответственность за допущенные ошибки.

По общему правилу при обнаружении недостатков в технической документации проектировщик (лицо, составившее техническую документацию) обязан безвозмездно переделать техническую документацию и, соответственно, произвести необходимые дополнительные изыскательские работы, а также возместить заказчику причиненные убытки.

По российскому праву понятие «убытки» включает в себя:

реальный ущерб (расходы, которые лицо, чье право нарушено, произвело или должно будет произвести для восстановления нарушенного права, утрата или повреждение его имущества);

упущенную выгоду (неполученные доходы, которые это лицо получило бы при обычных условиях гражданского оборота, если бы его право не было нарушено).

На практике достаточно сложно возместить упущенную выгоду, суды часто отказывают в возмещении упущенной выгоды в связи со сложностью доказывания наличия причинно-следственной связи (см., например, постановления АС Северо-Западного округа от 17.06.2019 № Ф07-4684/2019 по делу № А56-57628/2017, от 12.09.2019 № Ф07-9253/2019 по делу № А42-9872/2018, АС Западно-Сибирского округа от 19.08.2019 № Ф04-3183/2019 по делу № А46-10660/2018).

Правовая норма, устанавливающая обязанность подрядчика возместить заказчику причиненные убытки, является диспозитивной, то есть стороны вправе установить иную ответственность для проектировщика в договоре подряда на выполнение проектных и изыскательских работ. К примеру, стороны в договоре подряда на выполнение проектных и изыскательских работ могут установить ответственность подрядчика в форме штрафа, который заказчик вправе потребовать от подрядчика в случае обнаружения недостатков в технической документации.

Учитывая тот факт, что на практике заказчику бывает достаточно сложно доказать размер убытков и причинно-следственную связь понесенных убытков с действиями проектировщика, установление договорной ответственности проектировщика в форме штрафа позволит снизить риски заказчика в случае выявления ошибок в технической документации.

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

Ответственность за очевидные ошибки в техзадании несет подрядчик

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

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

С какого момента возникает обязательство подрядчика по соблюдению требований, указанных в техническом задании?

Техническое задание становится обязательным для подрядчика:

либо с момента его передачи заказчиком в том случае, если оно было разработано заказчиком;

либо с момента его утверждения заказчиком, если обязанность по разработке технического задания была возложена договором на подрядчика.

При выполнении работ подрядчик обязан соблюдать требования, которые содержатся в техническом задании.

Техническое задание является для подрядчика обязательным документом при выполнении проектных и изыскательских работ. Причем даже в том случае, если техническое задание содержит какие-либо ошибки, этот документ носит для подрядчика обязательный характер, и он не вправе отклоняться от его выполнения. Подрядчик вправе отступить от требований технического задания только с согласия заказчика (п. 2 ст. 759 ГК РФ).

При утверждении полученного от подрядчика технического задания заказчик должен проверить данные и при обнаружении недостатков уведомить об этом подрядчика. Соответственно, если техническое задание было разработано самим заказчиком или третьим лицом по его поручению, то и подрядчик, в свою очередь, обязан также уведомить заказчика об ошибках в техническом задании в случае их обнаружения. Мы рекомендуем включить соответствующие положения в договор подряда.

Согласно п. 1 ст. 716 ГК РФ, если подрядчик обнаружил в техническом задании какие-либо ошибки, он обязан немедленно предупредить заказчика и до получения от него указаний приостановить работу при обнаружении непригодности или недоброкачественности предоставленной заказчиком технической документации. Подрядчик, не предупредивший заказчика о допущенных в техническом задании ошибках или продолживший выполнение работ, не дожидаясь письменных указаний заказчика, не вправе в будущем ссылаться на пороки предоставленной ему документации. Это означает, что если работа выполнена с недостатками, которые возникли из-за ошибок в техническом задании, предоставленном заказчиком, подрядчика можно лишить оплаты. В частности, в ситуациях, когда подрядчик создал объект, не имеющий для заказчика потребительской ценности.

Бремя доказывания недобросовестности со стороны подрядчика в этой ситуации возлагается на заказчика.

При обнаружении недостатков в технической документации подрядчик по договору подряда на выполнение проектных и изыскательских работ обязан по требованию заказчика переделать техническую документацию, а также возместить заказчику причиненные убытки, если иное не установлено законом или договором (п. 2 ст. 760 ГК РФ).

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

Пример из практики

В рамках судебного разбирательства по одному делу суды рассматривали спор между заказчиком и подрядчиком. Заказчик направил подрядчику иск о безвозмездном устранении недостатков (несоответствие коэффициента пульсации установленных светильников СНиПам и СанПиНам) в разумный срок.

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

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

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

Доказательств того, что ответчик мог предвидеть необходимость проведения экспертизы в ходе реализации проекта, истцом не представлено. Из карт аттестации и протоколов измерений следовало, что проблема со светом была связана с моделью светильников, которые были включены в техническую документацию. Подрядчик надлежащим образом смонтировал светильники в соответствии с требованиями технической документации. В итоге суды отказали в удовлетворении исковых требований заказчика.

Постановление ФАС Поволжского округа от 01.11.2010 по делу № А72-18406/2009

Как защититься заказчику?

По общему правилу считается, что именно подрядчик является профессионалом в сфере строительства и обладает необходимыми знаниями для оценки данных технического задания для качественного выполнения работ. Рассмотрим некоторые неоднозначные ситуации, когда были допущены ошибки в техническом задании, с точки зрения того, как можно защитить интересы заказчика.

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

К примеру, заказчик составил техническое задание с ошибками и не учел какие-то градостроительные ограничения, прохождение коммуникаций на строительной площадке или еще какие-то значимые исходные данные. Подрядчик выполнил работы в точном соответствии с требованиями технического задания.

С одной стороны, в соответствии с нормами гражданского права явных нарушений со стороны подрядчика нет, но при этом результат выполненных работ невозможно использовать. Что в этой ситуации делать заказчику? Мы рекомендуем заранее при составлении договора подряда предусмотреть условия, защищающие интересы заказчика, принимая во внимание, что именно подрядчик является профессионалом в своей сфере и именно он обладает необходимыми профессиональными знаниями, позволяющими ему оценить, будет ли результат выполненных работ качественным, и предвидеть некачественный результат. Для этого в договоре подряда следует предусмотреть следующие положения.

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

Положения, регулирующие доступ подрядчика к месту проведения работ для предварительного осмотра и предоставляющие такую возможность подрядчику. Чтобы у подрядчика была возможность осмотреть место проведения работ, в договоре следует предусмотреть возможность подрядчика попасть на территорию места проведения работ.

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

Положения, закрепляющие цели выполнения работ. Еще одной практической рекомендацией для минимизации рисков заказчика является включение в договор подряда положения о том, что подрядчик изучил техническое задание и уведомлен о целях выполнения работ и желаемом для заказчика результате.

Если же спор между заказчиком и подрядчиком в связи с допущенными в техническом задании ошибками дошел до рассмотрения дела в судебном разбирательстве, то заказчику необходимо будет доказать в суде, что подрядчик вел себя недобросовестно.

Как правило, допущенные в техническом задании ошибки не освобождают подрядчика от ответственности за результаты работ. Тем не менее в судебной практике есть и другой подход в конкретных случаях. В частности, если подрядчик выполнял работы на основании технического задания, которое ему передал заказчик, он, вероятно, сможет доказать, что его вина отсутствует. В таком случае заказчик может попытаться воспользоваться на стадии составления договора ранее рекомендованными положениями.

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

В суде подрядчик вправе заявить ходатайство о проведении экспертизы. Заказчик должен поставить перед экспертами следующие вопросы:

были ли в техническом задании все данные, чтобы выполнить работы?

можно ли определить при первичном анализе технического задания, что оно содержит все необходимые сведения?

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

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

Решение вопроса о распределении ответственности за ошибки в техническом задании является достаточно сложным. Для того чтобы оно было справедливым, необходимо еще на стадии подготовки проекта договора подряда установить, какая из сторон несет ответственность за составление технического задания, допущенные в нем ошибки, и подробно урегулировать обязанности сторон. Механизмы защиты интересов сторон используются и на стадии судебного разбирательства. Но уже при исполнении договора каждая из сторон должна предпринимать меры по устранению недостатков в техническом задании.

Источник: www.eg-online.ru

Техническое задание на проведение строительной экспертизы

Мы проводим судебные и несудебные строительно-технические экспертизы по всей России.

Для определения возможности проведения строительной экспертизы в АНО «Бюро судебных экспертиз» нашим экспертам необходимо получить информацию об объекте строительной экспертизы.

Вы можете скачать и заполнить техническое задание для строительно-технической экспертизы.

После обработки полученной информации наши эксперты свяжутся с вами в удобное для вас время.

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

Тип назначаемой экспертизы: судебная или досудебная;

Наименование объекта экспертизы: жилое/нежилое, частный дом, завод, склад, квартира, жилой дом и т.д.;

Характеристики объекта: этажность, объем, общая площадь объекта или площадь/объем, подлежащие исследованию;

Задача эксперту (вопросы на экспертизу): определить объем и стоимость фактически выполненных работ, определить процент износа, определить техническое состояние объекта и т.д.;

Состояние объекта экспертизы: незавершенное или завершенное строительство, сдан в эксплуатацию, самовольное строительство и т.д.;

Местонахождение объекта экспертизы: населенный пункт;

Имеющаяся документация на объект: проектная, договорная, сметная, отчетная или исполнительная документация.

Источник: sud-expertiza.org

Техническое задание на сайт: образец от digital-агентства

Решили заказать сайт (он же лендинг)? Как показывает практика, это не так просто. Сотни заказчиков, увидев свой готовый сайт, обнаруживают, что он им не подходит: дизайн не тот, расположение хромает, тексты мимо, прикрутили кучу ненужных функций.

А дальше — начинаются долгие разборки с разработчиками, по мере которых сроки изготовления, бюджет проекта и градус нервного напряжения растёт до неопределённых масштабов.

Чтобы таких последствий избежать, Вам необходимо техническое задание на разработку сайта.

чТО ЭТО И ЗАЧЕМ НУЖНО

Неважно, кто будет исполнителем сайта — Вы сами, Ваш родственник, фрилансеры за скромную оплату, специализированная компания за огромную сумму денег.

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

Техническое задание (коротко “ТЗ”) — это документ, который максимально подробно и однозначно отражает требования к Вашему будущему сайту.

Сайт создают именно на основе ТЗ. Чем более подробным и однозначным оно будет, тем больше Ваш новый сайт будет соответствовать Вашим ожиданиям.

ТЗ на создание сайта — как закон, не должно допускать трактовок и разночтений.

Всё, что не прописано в ТЗ разработчик делает на своё усмотрение. И, как показывает практика, его усмотрение сплошь и рядом не будет совпадать с Вашим.

1. Кто пишет ТЗ

Кто должен составлять техническое задание на разработку сайта? На этот вопрос есть только два варианта ответа: заказчик или исполнитель.

И это логично, кроме одной тонкости — смысл в составлении ТЗ для Вас и для разработчика разный, а от этого разные подходы и требования к нему.

1. Понять, какой именно сайт Вам нужен;
2. Зафиксировать бюджет (иначе Вам потом выставят счёт, мама не горюй);
3. Контролировать разработчика (сроки, объём работ, функционал, переделки и т.д.).

1. Понять и с первой попытки удовлетворить заявленные Вами пожелания;
2. Избежать бесплатных доработок и корректировок.

Таким образом, Вы оба — и заказчик, и исполнитель сайта, заинтересованы прийти к максимальному пониманию.

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

2. Бриф на разработку сайта

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

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

ТЗ на разработку сайта можно составить только на основе Ваших пожеланий и никак иначе.

Самый простой и эффективный способ выяснить эти пожелания, к которому чаще всего и прибегают, — предложить Вам заполнить бриф на разработку сайта, который в дальнейшем преобразуется в техническое задание.

Конечно, подробно заполненный бриф, подписанный двумя сторонами, может заменить техническое задание.

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

Если отдельные пункты вызывают затруднения, то не стесняйтесь задавать разработчику вопросы по типу “Что это значит?”, “Как это повлияет на работу моего сайта?”, так как не все разработчики под одним понимают то же самое, что и Вы.

Либо в графе “Дополнительная информация” обязательно укажите все Ваши пожелания, не вошедшие в ответы на вопросы. Если эта графа отсутствует, просто допишите их в конце брифа. Главное не оставлять недосказанности.

Основа технического задания

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

Имейте ввиду, что у Вас получится только основа, набросок технического задания.

Оно обязательно должно вызвать у потенциального разработчика массу вопросов, отвечая на которые, Вы будете вносить в ТЗ подробности и нюансы.

В последствии техническое задание будет неоднократно редактироваться обеими сторонами. Это нормальный рабочий процесс.

Предпроектное проектирование

Этот пункт является неотъемлемой частью технического задания на создание сайта, хотя фактически он к нему не относится.

Дело в том, что после того как Вы заполнили бриф, подписали техническое задание и разработчик изучил всё это (включая рынок и конкурентов), то он делает предпроектное проектирование.

Предпроектное проектирование — это создание прототипа Вашего сайта, его скелета, который потом будет обрастать дизайном, контентом и функционалом с фишечками.

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

А так как этот процесс занимает не один день, то логично, что компании, которые делают проектирование до договора, просто показывают Вам шаблон в формате “как у всех”.

И да, сам прототип можно сделать с помощью обычных листов бумаги и цветных фломастеров.

Каждый лист — отдельная страница сайта (или экран одностраничника). Либо можно воспользоваться простыми офисными программами вроде Microsoft World или Microsoft Excel.

Лично мы при разработке landing page используем специальные программные продукты.

С их помощью можно быстро и легко составлять проекты даже сложных сайтов — это, например, Balsamiq. Впрочем, как мы делаем весь прототип уже рассказывали в статье.

По теме:

Предпроектным проектированием можно заняться совместно с разработчиком или полностью переложить это на его плечи. Главное, не забудьте, потом его согласовать и подписать двумя сторонами.

Интересно. Не забудьте установить на сайт систему комментирования. Так пользователи смогут делиться своим мнением и даже подталкивать к покупкам других посетителей (а еще это положительно влияет на SEO). Кликайте и узнавайте подробнее -> Сackle

ЛАЙФХАКИ ПО СОСТАВЛЕНИЮ ТЗ

Эти пункты в равной степени относятся как к заполнению брифа, так и к составлению технического задания. И в них я открою Вам небольшие хитрости, как составить тз для сайта и облегчить, и без того сложную жизнь предпринимателя:

1. Где взять сайты-образцы

Хорошим помощником могут стать широко представленные в сети рейтинги и ТОПы Интернет-ресурсов.

Например, ресурс allawards.ru подойдёт для этих целей. Здесь собирают лучшие, с точки зрения юзабилити, дизайна, креатива и эффективности сайты.

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

allawards.ru

Хорошая практика — посмотреть иностранные сайты по Вашему направлению, потому что технологии интернет-маркетинга за рубежом слегка опережают в развитии наши, и там можно будет найти интересные фишки.

Но слепо не копируйте, наш российский менталитет всё-таки отличается и это не просто слова.

2. Как определить цветовую гамму

Задача облегчается, если у Вас есть готовый бренд-бук или чёткий фирменный стиль.

В обратном случае не стоит руководствоваться исключительно собственными эстетическими предпочтениями, иначе Вы рискуете стать его единственным пользователем.

Не лишним будет немного изучить вопрос восприятия цвета в рекламе. Или обратиться в Google за помощью.

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

Цветовые подборки

Секрет. Подкрутит первые отзывы, оценки и прочие поведенческие факторы на Вашем сайте и тогда остальные пользователи будут к Вам более лояльны. Рекомендуем для накрутки TaskPay, сами им пользуемся. Кликайте -> TaskPay

3. Как подобрать шрифты для сайта

Не следует забывать, что шрифт играет не последнюю роль в восприятии текста. Пишите конкретные названия предпочтительных шрифтов.

Только не смотрите коллекцию шрифт Microsoft World, их уже на сто рядов все используют. Лучше воспользуйтесь библиотеками шрифтов в интернете, например, allfont.ru.

allfont.ru

ОШИБКИ ПРИ НАПИСАНИИ ТЗ

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

Поэтому выделяю самые основные из списка, те, что у Вас с вероятностью в 80% будут, если это Ваша первая разработка тз.

Важно. Допиливать сайт до идеала, конечно, хорошо, но многие забывают про самое главное — систему оплаты. И наш выбор — Yookassa. Внедряется легко и есть решение для отправки чеков в налоговую. Кликайте -> Yookassa

1. Нет ограничений во времени

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

Это чревато тем, что в итоге они могут затягиваться до бесконечности. Дедлайн проекта можно включить в техническое задание отдельным пунктом или включить прямо в шапку бланка.

Особо педантичные заказчики выставляют сроки разработки по каждому разделу сайта.

2. Утрата данных доступа

Как правило, на разработчика прицепом ложится регистрация доменного имени и хостинга для сайта.

А дальше в 9 из 10 случаев эти данные просто теряются: разработчику они больше не нужны, а заказчик про них благополучно забывает.

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

Поэтому запомните, что данные доступа к хостингу и доменному имени — это Ваши личные данные.

Распечатайте их и бережно храните вместе с важными документами. А лучше после разработки поменяйте все доступы, ведь всякое бывает, в той компании тоже существует человеческий фактор.

Кстати. Интегрируете CRM-систему с Вашим сайтом, чтобы посетители сайта сразу попадали к Вам в базу, так Вы не потеряете ни одного клиента. К тому же там много фишек, которые помогут сделать из сайта просто бомбу продаж и еще автоматизировать бизнес-процессы. Кликайте -> Мегаплан

3. Отсутствие наглядности

Принцип “лучше 1 раз увидеть, чем 100 раз услышать” работает здесь на полную. В одни и те же слова заказчик и исполнитель могут вкладывать разный смысл.

И наверное эта ошибка вообще должна стоять на первом месте нашего хит-парада, так как такая картина происходит постоянно: “Хочу абстракцию”, — пишет заказчик, подразумевая нечто подобное (пример на картинке ниже)

Абстракция — вид заказчика

“Ок, держите”, — говорит разработчик. И предлагает заказчику абстракцию следующего вида.

Абстракция — представление исполнителя

И попробуй потом докажи, что Ваша абстракция абстрактнее его. Каждый прав, никто не виноват.

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

4. Качественные прилагательные

Вспоминаем разряды прилагательных из школьной программы… Шучу 🙂 Если слово обозначает качество, которое может проявляться сильнее или слабее, то оно смертельно опасно для технического задания.

Например, красивый (кто-то может быть ещё красивее или страшнее), умный, современный и т.п. Это слова-табу. Их нельзя однозначно понять. У каждого субъективное представление о красоте и современности.

Только конкретика. Например, “На два тона светлее”, “Смещаем на 5 сантиметров” или “Острые углы у кнопки”.

5. “На усмотрение разработчика”

Об этот коварный пункт спотыкаются многие. Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

Вы должны понимать, что “На усмотрение разработчика” означает “что хочу, то и ворочу” или же “Всё, что не оговорено, выполняется на усмотрение исполнителя”. И поверьте, это не просто лазейка, а целое окно в Европу для разработчика.

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

Но тут возникает другая проблема, он может сделать реально как надо, а Вам не понравится чисто субъективно. И всё будет как в известном для многих разработчиков анекдоте:

Шутка

КОРОТКО О ГЛАВНОМ

Вы точно не пожалеете о времени, потраченном на составление и согласование технического задания для создания сайта или лендинга.

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

Но при этом, даже составив и утвердив максимально подробное техническое задание, Вы не полностью застрахованы от разницы между ожиданием и полученным результатом.

Поэтому не забывайте о промежуточном контроле. Не стесняйтесь по ходу работы лишний раз попросить отправить Вам на согласование готовые элементы, чтобы убедиться, что всё выполняется в соответствии с ТЗ.

Кстати. Создайте собственный сайт через конструктор за один день и без программистов. В арсенале готовые шаблоны, мобильная версия, корзина, платежи и еще +10 инструментов. Кликайте и тестируйте -> InSales (по промокоду «inscale» +30 дней бесплатно).

Источник: in-scale.ru