Pull to refresh
3
0
Вадим @Vadimka_9

User

Send message

Большое спасибо за развернутые комментарий. Это моя первая статья, а в будущих постараюсь учесть ваши рекомендации, спасибо)

Спасибо большое за обратную связь!

А разве цель проекта одновременно не является требованием к этому проекту?
Ведь если проект не отвечает цели, ради которой его создавали, то проект закроют или исправят. Так же как и функционал, который не отвечает требованиям. Более того к формулировке цели есть свои требования. Например, цель должна:

  • Быть достижима в рамках этого проекта

  • Предусматривать итоговый результат

  • Если цель предполагает получение прибыли, то должна быть возможность количественной оценки объемов, сроков и размеров прибыли и т.д.

Давай давай деплой и в этом случае требований нет, есть бизнес необходимость или научный интерес.

А разве бизнес необходимость не является бизнес требованием? Да, соглашусь, что могут быть проекты, где разработка требований будет дороже, чем разработка функционала. Но я убежден, что не существует проектов без требований. Я думаю, что не может быть вторично то, что лежит в основе проекта.

Поясню. Ни что на проекте не делается просто так. Любая задача появляется из-за какого-то требования:

  • Нужна новая кнопка. Зачем? Что бы пользователям было удобнее.

  • Нужен новый дизайн. Зачем? Что бы привлекать больше пользователей.

  • Нужен рефакторинг кода. Зачем? Что бы сделать его быстрее, качественнее, надёжнее и т.д.

Да пусть они не формализованы, не протестированы, может даже не записаны, но все равно это требования и на основе этих требований будет проходить разработка.

А вот формализовать требования нужно, в том числе, что бы не сделать вместо зелёного квадратное в конце проекта.

Information

Rating
Does not participate
Registered
Activity

Specialization

Manual Test Engineer, Quality Assurance Engineer
Senior
Quality assurance