Pull to refresh

Comments 14

Если во время разработки Заказчик захотел дополнительный функционал, как это оформляться? вы переделываете существующее ТЗ или составляете новое?
Мы составляем ТЗ на новую версию, где появляется раздел Доработки. Там мы описываем изменения уже существующих функционала/статики/ап, а если изменения подразумевают новый функционал, то он оформляется как и в изначальном варианте. По одному проекту сегодня дописываю ТЗ уже на пятую версию, никаких проблем пока не встретили.
Мы как раз этот вопрос поднимали в разговоре с шефом. Он сказал, что если что-то, что-то появится, мы будем перезаключать договора с клиентом на новое ТЗ. И будем дополнять старое ТЗ новыми пунктами
На практике составляется «допник» на этот самый дополнительный функционал. А в ТЗ изначально предусматривается возможность этих самых «допников». При этом допник подписывается обеими сторонами.
Насчет допников не слышал, нам, по крайней мере, сказали, что «лучше напишите все, что бы потом ничего не переоформлять».
По моему вы перемудрили. Если нужно написать небольшое ТЗ, то все задачи которые вы описали легко решаются с помощью вариантов и сценариев использования. Которые понятны и заказчику и разработчику и тестировщику и благополучно могут быть записаны в раздел функциональные требования стандартного ГОСТовского ТЗ.
Вы можете вынести все сценарии в приложение к ТЗ и успешно их поддерживать в актуальном состоянии и дополнять по мере увеличения задач.
Небольшое понятие относительное, на последний проект на MVP оно вышло на 60 страниц. Мы не имеем ничего против гостовских ТЗ, ISO/IEEE и других стандартов, и общую структуру мы собираемся привести ближе к ним. Но мы хотели добавить именно конкретики в само описание, которой по нашему мнению там не хватает. ТЗ мы поддерживаем в актуальном состоянии, сливая версии. Следующая версия пишется на основе актуального ТЗ существующего проекта
методом аналогов можно достичь вполне приемлемого понимания ожиданий заказчика. детальная же проработка «образов» (аналогов) вместе со специалистом по ТЗ и рядом правильно поставленных вопросов позволит сформировать ТЗ за несколько встреч (часов)

Описывать внешний вид в ТЗ, не самое правильное решение.


На одной строке должно помещаться 3-4 плитки с превью товара.

Дизайнер прочитал и запилил в мобильной версии 4 плитки в строке.


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

Спасибо, хорошее замечание. Это пример из самого первого ТЗ, в последних проектах мы отказались от подобных формулировок
Ваше ТЗ используется только в проектах, которые вы сами же и разрабатываете или всё таки по ним работают сторонние разработчики?
Здесь больше интересно на сколько реализация отличается от поставленных задач.
Т.е. если разработчики не Вы, то не приходится ли Вам как разработчикам заданий еще оказывать услуги по «объяснению» определенных вами требований.
И если вопросов со стороны разработчиков нет, и реализация соответствует требованиям, то вы нашли интересный способ решения насущных проблем многих проектов :)
Свои проекты полностью делаем сами без привлечения сторонних специалистов. Пока мы только тестировали новый формат на себе и собирали отзывы от заказчиков, но уже скоро упакуем данную услугу и начнем продавать. К этому времени, конечно, подготовим руководство к работе с ТЗ. Уверен, что проблемы с непониманием возникнут, будем думать как их решать по мере поступления)
Очень часто в моих ТЗ встречался пункт описание стандартного функционала (шаблона) то есть заказчик уже получает почти рабочую систему, но вот здесь я такого не увидел может в вашем случае это не нужно?
Не совсем понял суть вопроса. На выходе заказчик получает полностью рабочую систему со всем описанным в ТЗ функционалом.
Sign up to leave a comment.

Articles