Юра Римский
Консультант по обслуживанию клиентов.
Построение системы обслуживания клиентов. Поиск уязвимостей в существующей.
Подписаться
Написать
Компании пользователя
Комментарии
Чтобы стать дизайнером электрочайников нужно много учиться и много знать об электронике, об электротехнике, как устроены чайники внутри, об анатомии человека, о физике, процесс парообразования, законы термодинамики и т.д. и т.п.
Чтобы стать дизайнером сайтов нужно освоить фотошоп.
Сложность многих программных продуктов гораздо выше, чем у чайника, есть даже сложнее самолёта или атомной подлодки.
Архитектура - это ПОЛНЫЙ чертёж будущей системы. Вы не можете сделать хороший дизайн UI, если не знаете, как устроена система. Разметка и графические элементы - это не дизайн. Это малярные работы.
"некий документ, который позволяет увидеть картину в целом и покажет всем участникам, что от них требуется" - это архитектура. Все части вашей системы, объединённые в систему. При правильно разработанной архитектуре порядок реализации этих частей не имеет значения. Берёте людей и раскидываете между ними все эти части.
Обычно делают в том порядке, который позволяет увидеть результат на экране как можно раньше. Либо сверху вниз, либо снизу вверх.
"чтобы видеть, что я жду от системы, потому что без такого понимания хорошую архитектуру не сделать" - это требования к системе. Хочу это, хочу то. На их основании потом пишут ТЗ, на основании которого разрабатывают архитектуру. Этап ТЗ можно пропустить, если вы не рассматриваете возможность судебного разбирательства.
Возможно, вы, как в случае с термином "ТЗ" не понимаете термин "архитектура", а возможно вам нужна методика управления проектами. Scrum, Agile - самые популярные. Гуглите и нагуглится.
Всё равно остаётся вопрос: зачем? Чтобы структурировать ваши мысли бюрократия не нужна. Уделите внимание архитектуре. Она обычно в картинках на досках делается. Это гораздо более важно, чем ТЗ.
Отличное детальное ТЗ + плохая архитектура = много геморроя в будущем при отладке, при кодировании и при поддержке. Отличная архитектура + нулевое ТЗ = минимум проблем при отладке, кодировании и наращивании функциональности.
ТЗ придуманы как способ разрешения конфликтов между разработчиками и клиентами. В случае любых разногласий обращаются к ТЗ. Большего смысла, чем прикрыть чью-то задницу, в нём нет. А вы уж сами решайте нужно прикрывать свою задницу от конкретных разработчиков или нет. Они также решат схожий вопрос по отношению к вам.
Фишки, которые забываются просто не нужны. Вероятность, что ими не будут пользоваться в пределах 99%. Если даже вы про них забыли, то пользователи забудут ещё быстрее.
Функциональность не имеет значения. У продукта есть цель - задача, которую он решает. Он либо решает её хорошо, либо плохо. Собственно путь решения проблемы клиентом - это и есть продукт. Если вам нужно ТЗ, чтобы не запутаться в этом пути, то что-то не так. Будьте проще.
Есть принцип, когда меньше 10% дополнительной мощности стоит больше, чем 100% от цены. Новый процессор за 800 долларов мощнее тех, которые за 100 долларов вовсе не в 8 раз, а раза в 1.5.
Для себя вообще не вижу смысла делать ТЗ. ТЗ делают для тех, кому вы не очень доверяете.