Kha zar

+2
с 2021
0 подписчиков
27 подписок

Конечно постановка задачи и описание результата это разные вещи. Поэтому обычно есть некая документация на входе (называйте как хотите: ФТ/ТТ/ТЗ), до заключения договора, в которую, так же как и договор, обе стороны в рамках своих компетенций могут вносить и согласовывать правки. А уже после заключения договорных обязательств, исполнитель в рамках проектирования детально описывает как будет реализовывать проект, уже как "профи", который умеет писать ТЗ/ЧТЗ, хоть одним куском за раз, хоть итерационно под спринты (зависит от методологии и условий договора). 
А исполнитель, который жалуется на избыточные входные данные, которые не может проанализировать и "причесать" на этапе пресейла, а на выходе выдающий вместо нормально документации "хорошо структурированный код", думаю, достоин продолжать жрать кактус.
Что бы вам дома так строили, без всей проектной документации, главное, что бы кирпичи хорошо структурировано уложены были.

А есть ли /должен ли быть какой-то проектный документ, который содержит исчерпывающее описание итогового проекта? Если - да, то когда он появляется и кто его готовит? 

Вообще не понял комментарий. Если договор поделить на этапы: 1. Проектная документация, 2. Разработка, 3. Тестирование. По итогу закрытия этапа выставлять акт и счёт за весь этап, в чем растягивание то?
Лет 10 назад занимался супер бюджетными проектами, и там стремились к максимальной унификации документов. Да, на старте пришлось потрудиться и сделать максимально подробную документацию, но в последствии под каждый проект требовалось минимум усилий на составление документов: убрать лишнее, добавить уникальный кастом (для бюджетных проектов в большинстве случаев это минимум). Зато на выходе от клиента было минимум вопросов, и разговоры были не на уровне "ну мы же обсуждали", а на уровне "какому пункту документации не соответствует итоговый продукт".

Я как раз из ИТ, и веба в том числе. К сожалению, в большинстве случаев у компаний, которые позиционируют себя не как интеграторы, а как "просто веб-студии", нет культуры ведения проектов со всеми присущими ИТ проектам артефактами, на близкой дистанции это кажется экономией в части работы аналитика и менеджера (а зачастую это совмещённая позиция, что есть страшная дикость), но в долгую как раз приводит вот к таким случаям, когда приходится судиться и доказывать, что ты не баран и сделал все хорошо и правильно, а ещё зачастую приводит к издержкам, когда клиент говорит на любую неточную формулировку: "а я не это имел в виду - переделывайте". Ну а договор - это просто формализация того принципа управления, который исповедует компания.

1

Не очень понятно какой изначально заложен жизненный цикл разработки. Кто и на каком этапе писал ТЗ? Если очень утрировать:
1. В большинстве случаев заказчик не в состоянии написать ТЗ, и в основу договора кладутся общие функциональные / технические требования, уже на основе которых в рамках договора подрядчик пишет полную техническую документацию ТЗ/ЧТЗ.  Это первый этап договора, по итогам которого ТЗ направляется на согласование (сроки и количество итераций согласования обычно так же прописываются в договоре), по итогам согласования заказчик или согласовывает или не согласовывает документацию, ссылаясь на несоответствие ФТ/ТТ, подрядчик в свою очередь устраняет замечания в заявленный договором срок. Тут уже вопрос к подрядчику - умеет ли он писать грамотные ТЗ.
2. По итогам согласования ТЗ можно пускаться в разработку, но параллельно с разработкой готовится ряд артефактов, которые используются для приемки работ: руководства администраторов/операторов, программа и методика испытаний. Эти документы в обязательном порядке согласовываются с заказчиком, и опять же, приёмка той же методики испытаний должна быть согласована заказчиком с возможностью апелляции только к ТЗ. По итогам согласования методики и реализации проекта уже можно приступать к этапу приемосдаточных испытаний.
3. Приёмка/обучение/тестирование должно происходить на основе не ТЗ, а ПМИ и руководства.
Повторюсь, это очень утрировано, но это базис, без понимания которого вот эти все сборы рабочей переписки в качестве каких-то доказательств - просто пшик. И да, это применимо не только в классическом кас каскаде, но, хоть и с натяжкой, и в ныне модном аджайле.

1