Comments 10
А как вы подходите к ситуации, когда вам нужно создать математические алгоритмы, которые вы еще не делали, но можете сделать, и вам уже нужно оценить сроки и стоимость?
Ох уж эти идеальные составители тз в идеальном мире...
В случае, если задача требует разработки математических алгоритмов, с которыми мы не работали ранее, мы привлекаем сторонних специалистов с почасовой оплатой для работы над проектом. Однако на данный момент в нашей практике таких ситуаций еще не возникало.
По нормативным документам Заказчик пишет Технические требования - ТТ. Техническое задание - ТЗ, по выставленным ТТ пишет Исполнитель. Те и те документы согласуются и утверждаются Сторонами.
На свежий взгляд кажется странным - тот, кто выполняет работу, пишет задание самому себе (всегда бы так!). Поэтому чаще в лексике упоминают именно ТЗ, как директиву.
На самом деле, частый случай, что заказчик не хочет писать ТЗ. Он может рассказать об этом, а затем исполнитель уже пишет функциональные и нефункциональные требования, из которых собирается ТЗ (по умолчанию — вместе с use case и user story). Обсуждение и утверждение сторонами документов — это отдельная процедура, чаще всего называемая валидацией требований. Параллельно происходит верификация внутри команды. Короче говоря, процесс составления ТЗ и сбора требований сильно декомпозируется и часто сопровождается различной терминологией))
Сам себя не похвалишь...)
Перечень вопросов стейкхолдеру, каким образом формируется? Ориентир только на предметную область проекта или еще до встречи есть какие-то "точки опоры"? Имею ввиду, что на чем в целом основан список вопросов.
Почему мы не просим ТЗ от клиента, а составляем его сами