Всего-то достаточно ставить хороший прототип и ТЗ, и не менять его в процессе разработки, но чаще всего в голове продумать алгоритм с нуля до конца могут только люди которые и программируют и делают UX, но их программистов воспринимают как людей не шарящих, что нужно пользователю, поэтому к ТЗ их не допускают, а допускают абсолютных гуманитариев. Просто когда скачут с одной идеи на другую, тяжело переключиться на новое и потом возвращаться к старому коду, когда видишь всё что нужно сделать от начала до конца, то и код пишется без ошибок к которым потом надо возвращаться. Моё мнение как программиста умеющего делать полноценные рабочие прототипы в AxureRP
Всего-то достаточно ставить хороший прототип и ТЗ, и не менять его в процессе разработки, но чаще всего в голове продумать алгоритм с нуля до конца могут только люди которые и программируют и делают UX, но их программистов воспринимают как людей не шарящих, что нужно пользователю, поэтому к ТЗ их не допускают, а допускают абсолютных гуманитариев. Просто когда скачут с одной идеи на другую, тяжело переключиться на новое и потом возвращаться к старому коду, когда видишь всё что нужно сделать от начала до конца, то и код пишется без ошибок к которым потом надо возвращаться. Моё мнение как программиста умеющего делать полноценные рабочие прототипы в AxureRP
Если программист пишет продукт не для программистов, то в большинстве случаев это будет рабочий кусок Г, который не продать нормальному пользователю.
О, свидетели неменяющегося ТЗ появились. Я буду рад увидеть хотя бы один пример такого.
Комментарий недоступен
Комментарий недоступен
вы сферического коня в вакууме описываете, должна быть гибкость в разработке, которая позволяет закрывать технический долг без ущерба продукту.