Как стать автором
Обновить

Комментарии 6

Спасибо! Очень интересные статьи))
Рад, что понравились! Подписывайтесь на нас в соц. сетях, скоро еще напишем ;)
Спасибо.

Осилил обе части и внимательно почитал ТЗ которое тут привели, как пример. Оно исчерпывающее для дизайнера, много скриншотов, все поля расписаны, класс и даже вполне нормально для frontend разработчика (хотя не совсем), но для бэкенда там ничего. Ни про валидацию серверную, структуру БД, внутреннюю бизнес-логику, workflow, откуда брать справочники, словари и т.д. и т.п.
Бэкенду работать с такой спецификацией очень тяжело будет -)
Возможно это у вас в каком-то еще документе описано, который за рамками ТЗ и не показывается заказчику.
Вообщем, про эту часть было бы интересно почитать тоже.

Еще раз спасибо больше, огромный труд проделали.

P.S. И еще, вы совсем как-то упустили момент в статье, с этого нужно было бы начать, что вы используете подход Outside-in в проектировании (от интерфейса), есть еще Inside-out, для «серьезных» сайтов и систем он, чаще, более предпочтительный.
Это не ТЗ, это описание интерфейса. Там даже нет пунктов, которые описаны в статье. Мы не выкладывали все наработки по этому проекту.
Прекрасный пример проектирования.
К сожалению мои попытки сделать что-то подобное заканчивались тем, что по ходу заказчик выдвигал новые требования и части аккуратно созданного документа отправлялись в урну.
Так смысл в том, чтобы проектировать вместе с заказчиком) Он же носитель идеи! От его мнения мы отталкиваемся, а потом за ручку ведем по этапам проектирования, заставляем утверждать каждый промежуточный этап и в конце он выговаривается полностью, все его замечания учитываются, ничего не нужно выкидывать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий