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