История изменений

Просто надо не метаться по сферам а стараться работать в одном конкретном направлении - тогда в голове всегда будут графы «так хочет заказчик», «вот так на самом деле надо» и «вот так оно в итоге будет работать».

Вот. Согласовать хоть сколько-нибудь сложное ТЗ с заказчиком – это лютый гимор, по трудоёмкости сопоставимый с собственно кодированием. Если не больше. Если это согласование вообще имеет смысл. Потому что у заказчика в голове одна картинка, а в результате получается совершенно другая. Потому что:

1. Картинка в голове заказчика – без ньюансов, и никаким ТЗ ты из него эти ньюансы не вытянешь, потому что он сам не осознаёт их, пока не обнаружит, что программа, написанная строго по его ТЗ, делает не то и не так, что ему на самом деле было нужно. Чтобы не повторяться.

2. Плюс в процессе работы в 100% случаев обнаруживается, что можно сделать лучше (удобнее для юзера, эффективнее, etc.), чем заказчик сформулировал. И в 50% из этих 100% случаев для этого требуется мелкое несущественное (без негативных эффектив) отступление от ТЗ.

Решается только через разбиение на этапы, с поэтапными ТЗ и оплатой, чтобы как можно раньше обнаруживать расхождение между теорией и практикой, и не работать на выброс. То бишь, здравствуй agile.

Просто надо не метаться по сферам а стараться работать в одном конкретном направлении - тогда в голове всегда будут графы «так хочет заказчик», «вот так на самом деле надо» и «вот так оно в итоге будет работать».

Вот. Согласовать хоть сколько-нибудь сложное ТЗ с заказчиком – это лютый гимор, по трудоёмкости сопоставимый с собственно кодированием. Если не больше. Если это согласование вообще имеет смысл. Потому что у заказчика в голове одна картинка, а в результате получается совершенно другая. Потому что:

1. Картинка в голове заказчика – без ньюансов, и никаким ТЗ ты из него эти ньюансы не вытянешь, потому что он сам не осознаёт их, пока не обнаружит, что программа, написанная строго по его ТЗ, делает не то и не так, что ему на самом деле было нужно. Чтобы не повторяться.

2. Плюс в процессе работы в 100% случаев обнаруживается, что можно сделать лучше (удобнее для юзера, эффективнее, etc.), чем заказчик сформулировал. И в 50% из этих 100% случаев для этого требуется мелкое несущественное (без негативных эффектив) отступление от ТЗ.

Решается только через разбиение на этапы, с поэтапными ТЗ и оплатой, чтобы как можно раньше обнаруживать расхождение между теорией и практикой, и не работать на выброс.