Комментарии 8
Пирожок
Как ни начинай — все равно в итоге получится не так, как задумывал. Пожелание левой пятки заказчика зачастую сильнее всех прототипов и ТЗ.
«В ТЗ описываем концепцию проекта» — звучит как «draw the rest of the fuckinh owl».
Из чего состоит в вашем понимании концепция и почему она оказалась в ТЗ?
Из чего состоит в вашем понимании концепция и почему она оказалась в ТЗ?
Под концепцией подразумевается краткое описание проекта: что мы хотим получить, зачем нам это нужно, как мы это сделаем.
Концепция включена в ТЗ, так как предполагается, что ТЗ разрабатывается поэтапно, от верхнеуровнего понимания к деталям. При этом, ТЗ в статье не привязано к определенному формату, это может быть ГОСТ, а может быть договоренность между командой и заказчиком. Если используемый шаблон не допускает описание концепции, то следует проработать её в рамках отдельного документа прежде чем приступить к ТЗ.
Концепция включена в ТЗ, так как предполагается, что ТЗ разрабатывается поэтапно, от верхнеуровнего понимания к деталям. При этом, ТЗ в статье не привязано к определенному формату, это может быть ГОСТ, а может быть договоренность между командой и заказчиком. Если используемый шаблон не допускает описание концепции, то следует проработать её в рамках отдельного документа прежде чем приступить к ТЗ.
Я правильно понимаю, что вы не используете и не предлагаете фиксировать измеримые и конкретные бизнес-цели?
Я правильно понимаю, что вы не используете и не предлагаете фиксировать показатели назначения и, в частности, показатели качества интерфейса, например, как результативность, точность, среднее время выполнения сценария?
Т.е. приёмка системы происходит в режиме «это понравилось заказчику», а не «система работает с заданным уровнем качества и приносит затребованные от неё результаты»?
Я правильно понимаю, что вы не используете и не предлагаете фиксировать показатели назначения и, в частности, показатели качества интерфейса, например, как результативность, точность, среднее время выполнения сценария?
Т.е. приёмка системы происходит в режиме «это понравилось заказчику», а не «система работает с заданным уровнем качества и приносит затребованные от неё результаты»?
Нет, такого смысла я не закладывала.
«Не понравилось заказчику» не означает, что нужно сразу изменить всю логику ТЗ или предложить совершенно новые прототипы. Это обратная связь, которую нужно обработать. Не понравилось — потому что мы что-то не учли? Не учли, потому что упустили важный вопрос при сборе требований или потому что у заказчика изменились цели? Не понравилось — потому что мы не объяснили, какие преимущества получит заказчик от продукта именно в таком исполнении? Вариантов тут очень много.
Безусловно, нужно обсудить, договориться и зафиксировать цели проекта, критерии успешности, ограничения, допущения т.д. Нужны входные и выходные требования к качеству документов, нужны требования к качеству продукта. Нужна проверка документа и тестирование продукта. Однако содержание ТЗ, обеспечение качества — это отдельные большие темы, которые не раскрыты в статье.
«Не понравилось заказчику» не означает, что нужно сразу изменить всю логику ТЗ или предложить совершенно новые прототипы. Это обратная связь, которую нужно обработать. Не понравилось — потому что мы что-то не учли? Не учли, потому что упустили важный вопрос при сборе требований или потому что у заказчика изменились цели? Не понравилось — потому что мы не объяснили, какие преимущества получит заказчик от продукта именно в таком исполнении? Вариантов тут очень много.
Безусловно, нужно обсудить, договориться и зафиксировать цели проекта, критерии успешности, ограничения, допущения т.д. Нужны входные и выходные требования к качеству документов, нужны требования к качеству продукта. Нужна проверка документа и тестирование продукта. Однако содержание ТЗ, обеспечение качества — это отдельные большие темы, которые не раскрыты в статье.
ТЗ — результат этапа анализа, прототипы — как минимум уже этапа проектирования (в зависимости от их типа). Другой вопрос, что часто макеты интерфейса проектируют те же аналитики, причем иногда включают их в само ТЗ.
В моей компании и в университете следующая практика. Сначала пишется устав. После на его основе в ТЗ пишутся функциональные требования. На их основе создается прототип и сдается заказчику вместе с требованиями. Если его устраивает дизайн и расположение, а так же функциональность, то из прототипа делаются скриншеты в раздел «Не функциональных требований» куда дописываются некоторые нюансы по системе.
Итоги.
1. заказчик и команда еще до создания прототипа точно знает всю функциональную начинку проекта.
2. благодоря прототипу мы точно уверены что двигаемся в правильном направлении и больше не паримся с дизайном сайта.
Итоги.
1. заказчик и команда еще до создания прототипа точно знает всю функциональную начинку проекта.
2. благодоря прототипу мы точно уверены что двигаемся в правильном направлении и больше не паримся с дизайном сайта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Курица или яйцо: что раньше, прототипы или ТЗ?