Comments on: ТЗ для web-разработчика

By: SmeTar

SmeTar — Sat, 04 Oct 2008 13:06:25 +0000

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

By: SAKrisT

SAKrisT — Wed, 17 Sep 2008 17:24:18 +0000

Юзаем MS Visio.

Удобен для создания диаграмм, mock-up`ов, всех структур, и т.д.

Конечно только под Win, если кто-то знает подобный хороший софт для Linux буду презнателен.

By: COTOHA

COTOHA — Fri, 01 Aug 2008 12:24:22 +0000

2 Lester & Dark
тут надо определиться с терминологией просто…
обычно под “макетом” разные люди понимают разные вещи:
- програмист понимает нарезку из html, css и js, которую он наполнит функционалом;
- дизайнер – картинки, из которых клиент выберет то, что ему нравится, чтобы дизайнер сделал “макет” програмисту;
- манагер – общее описание “что и примерно где будет на страницах”, чтобы потом дать задание дизайнеру сделать пару-тройку дизайнерских “макетов”.

так вот тут по доке – это “менеджерские макеты” aka wireframes. это не догма от которой при реализации нельзя отступать, а фиксация нужного функционала (ЧТО), а реализация (КАК) будет меняться на пути от менеджера к дизайнеру к програмисту…

By: Yaroslav Vorozhko

Yaroslav Vorozhko — Fri, 01 Aug 2008 09:50:31 +0000

Спасибо, хороший пост.
Порекомендую его менеджеру как начальное пособие по разработке.
За наводку на axure спасибо, незнал про такой инструмент.
Если не в тему, то прошу игнорировать следующую часть сообщения.
Я сегодня написал про “14 приемов как стать креативным разработчиком” на своем блоге (http://pro100pro.com), если будет интересно, то хотел бы услышать комментарии.

By: Anton Shevchuk

Anton Shevchuk — Fri, 01 Aug 2008 08:59:10 +0000

@lester:
1. Макеты страниц – это может и работа дизайнера (хотя с этим еще можно поспорить), но они должны присутствовать в ТЗ.
2. Структура БД может и изменяться – это понятно, вот только она должна быть описана в документации и поддерживаться в актуальном состоянии, и плох тот менеджер который этого не делает (это касается не только БД, а документации в целом)
3. Кто мешает изменять ТЗ и утверждать изменения с заказчиком?

By: lester

lester — Thu, 31 Jul 2008 21:45:17 +0000

Рисовать макет страниц – это работа дизайнера. Ни менеджер, ни заказчик не обладают знаниями и опытом дизайнера, поэтому вряд ли смогут нарисовать что-то толковое. В ТЗ лучше прописать состав страниц, т. е. какая информация должна быть на странице, а дизайнер уж сам решит как ее лучше оформить и скомпоновать. То же относится и к БД, проектировать БД должен программист, а не менеджер с заказчиком. Структура БД в ТЗ вообще излишне, т. к. порой она меняется даже в процессе разработки проекта и может кардинально отличать от той, что была разработана на этапе проектирования. ТЗ – это документ по которому в конце работы будут сверять полноту выполненной работы. Представьте в какую лужу сядет разработчик, когда менеджер с заказчиком жестко пропишут ТЗ структуру БД, дизайн страниц и т. д.

By: Anton Shevchuk

Anton Shevchuk — Thu, 31 Jul 2008 05:23:11 +0000

@COTOHA:
Вынес диаграмму из “архитектуры” в “писательство”.

By: COTOHA

COTOHA — Wed, 30 Jul 2008 10:46:39 +0000

2 Dark
кстати странно, что эта диаграмма прецедентов отнесена к архитектуре. это же требования к функционалу в чистом виде. особенно с учётом того, что на этой картинке не указаны границы системы и система не выстпает в роли актёра…

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

By: COTOHA

COTOHA — Wed, 30 Jul 2008 10:32:30 +0000

гы. даже по линку на википедию есть табличка, где прямо и написано, то с “и” – повелительное наклонение…

By: COTOHA

COTOHA — Wed, 30 Jul 2008 10:30:40 +0000

2 Артём Курапов
а чё доказывать?
проколИтесь = сделайте так! колись!
прокОлетесь = сделаете так. колешься