Каким должно быть идеальное на 100% ТЗ для разработчика?

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

Суть: иногда замечаю небольшое ворчание от технических специалистов, мол не совсем идеальное, точное ТЗ.

Вопрос: как мне сделать ТЗ более идеальными? Вы можете показать примеры идеальных ТЗ?

Под ТЗ - подразумеваю: 1) UX-прототипы и 2) Само ТЗ в документе - пошаговые, точные пункты (где-то тут проблема).

Перелопатил интернет в поисках примеров, что-то, наиболее лучшее позаимствовал, Но всё равно не то.

P.S: чисто хочу улучшить коммуникацию с разработчиками, облегчить им работу :).
  • Вопрос задан
  • 288 просмотров
Пригласить эксперта
Ответы на вопрос 5
saboteur_kiev
@saboteur_kiev
build engineer
Идеальное ТЗ - когда у разработчика не возникает дополнительных вопросов, а результат работы разработчика с первого раза устраивает заказчика.

Такого не бывает, но чем ближе к вышеупомянутому - тем лучше.
Из чужих ТЗ что-либо заимствовать сложно - всегда же есть свои нюансы.
Ответ написан
vetero4eg
@vetero4eg
Пишу, верстаю, правлю.
Вы хотя бы понимаете, что ТЗ необходимо... Это уже уровень выше среднего
Ответ написан
Хреновые разработчики раз просто ворчат, можно на таких не обращать внимания. Нормальные разработчики понимают, что такое работа в команде и дают конструктивные замечания.
Ответ написан
С моей точки зрения, сама постановка вопроса о чем-то 100% идеальном является ошибочной. Теоретически идеальным является только бог (тот, который творец сущего). Вы же работаете с принципиально неидеальными людьми - заказчиками и специалистами. Это и определяет специфику работы.

В ТЗ должны быть освещены все важные элементы. Если у разработчиков возникают вопросы, вы принимаете дополнения к заданию (вместе с ними и заказчиком), и они его воплощают. 100% идеальное ТЗ в пределе предусматривает детальное знание воплощенного идеального конечного результата, что в принципе невозможно, если вы не делаете точную копию чего-то уже существующего.

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

И вообще, хотелось бы увидеть примеры "ворчания".
Ответ написан
zooks
@zooks
Frontend и Django
Детализированное ТЗ без противоречий, написанное грамотным и понятным языком.
Обязательна разбивка по пунктам. Неплохо бы иллюстрировать расположение объектов скриншотами.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы