B>Спроси у проджект. Они должны быть в курсе.

Сдаётся мне, что ты с "проджектом" только что беседовал

VB>Добрый день.

А>>Каков порядок действий дальше?

VB>Почитай про методологии разработки ПО.
VB>Например MSF.
VB>Там все подробно, по шагам и с примерами документов описано.

А ещё сильно решает кунг-фу и карма конкретного менеджера.

Добрый день!

Захотел вот узнать как ведется процесс разработки серьезных web-проектов.
К примеру, предполагается крупный проект под ASP.NET + Silverlight. В команде есть веб-дизайнеры, верстальщики, программисты C# и программисты БД ну и проджект.
Разработка будет с использованием VS2010, ExpressionBlend4 + MsSQL 2008
Вот встретились мы с заказчиком он сказал, что он хочет — мы взяли время на составление ТЗ.
Каков порядок действий дальше?

Здравствуйте, Аноним, Вы писали:

А>Каков порядок действий дальше?

Спроси у проджект. Они должны быть в курсе.

P.S. Ты что, в самом деле надеешься, что парой сообщений между делом
можно рассказать как вам разработать продукт?

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Каков порядок действий дальше?

B>Спроси у проджект. Они должны быть в курсе.

B>P.S. Ты что, в самом деле надеешься, что парой сообщений между делом
B>можно рассказать как вам разработать продукт?

нет. мне не нужно подробностей. интересна вся цепочка основных действий.
Навеяно тем, что открыл Expression blend 4, а в нем прямо можно создавать прототипы Silverlight проектов.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bkat, Вы писали:

B>>Здравствуйте, Аноним, Вы писали:

А>>>Каков порядок действий дальше?

B>>Спроси у проджект. Они должны быть в курсе.

B>>P.S. Ты что, в самом деле надеешься, что парой сообщений между делом
B>>можно рассказать как вам разработать продукт?

А>нет. мне не нужно подробностей. интересна вся цепочка основных действий.
А>Навеяно тем, что открыл Expression blend 4, а в нем прямо можно создавать прототипы Silverlight проектов.

Хм... И что же тебя все же интересует?
Ты спрашиваешь про управление проектами в целом или тебя интересует blend?
Разница примерно как между общими соображениями как построить дом и
особенностями конкретной бетономешалки на базе автомобиля КАМАЗ.

Ты, кстати, задал свой вопрос на форуме "Управление проектами".

Здравствуйте, avpavlov, Вы писали:


B>>Спроси у проджект. Они должны быть в курсе.

A>Сдаётся мне, что ты с "проджектом" только что беседовал

Я он и есть

Здравствуйте, bkat, Вы писали:

B>Хм... И что же тебя все же интересует?
B>Ты спрашиваешь про управление проектами в целом или тебя интересует blend?
B>Разница примерно как между общими соображениями как построить дом и
B>особенностями конкретной бетономешалки на базе автомобиля КАМАЗ.

меня интересует как проходит процесс в обычном режиме с вышеуказанными подробностями.


B>Ты, кстати, задал свой вопрос на форуме "Управление проектами".

да, потому что тут люди которые могут сказать как оно есть на практике

Здравствуйте, Аноним, Вы писали:

> Добрый день!

> Захотел вот узнать как ведется процесс разработки серьезных web-проектов.
> К примеру, предполагается крупный проект под ASP.NET + Silverlight. В команде есть веб-дизайнеры, верстальщики, программисты C# и программисты БД ну и проджект.
> Разработка будет с использованием VS2010, ExpressionBlend4 + MsSQL 2008
> Вот встретились мы с заказчиком он сказал, что он хочет — мы взяли время на составление ТЗ.
> Каков порядок действий дальше?
Уже столкнулся с различным пониманием "крупности" проекта. Вы можете привести хотя бы одну оценку? Ну типа Х человеко часов.
В любом случае нужен опыт создания больших проектов, хотя бы у ПМ. Ну и участники до этого должны были уже работать в команде.
Что до ТЗ, то чаще всего заказчик сам не знает, что он хочет. Поэтому, если не хочется просто "срубить бабла", я бы сделал вначале "пилот проект", иначе говоря обкусанную версию проекта с которой заказчик уже мог бы "играться" и скорректировать требования.
Иначе может получится так, что после сдачи очередного этапа новые требования могут привести к большим изменениям. Хотя в общем, игрушечную версию надо заиметь как можно раньше. Хотя бы просто "пустые" формы с полями и текстом.
Ну а по конкретным действиям. Надо хотя знать для какого направления?

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, Аноним, Вы писали:

>> Добрый день!

AN>Уже столкнулся с различным пониманием "крупности" проекта. Вы можете привести хотя бы одну оценку? Ну типа Х человеко часов.
AN>В любом случае нужен опыт создания больших проектов, хотя бы у ПМ. Ну и участники до этого должны были уже работать в команде.
AN>Что до ТЗ, то чаще всего заказчик сам не знает, что он хочет. Поэтому, если не хочется просто "срубить бабла", я бы сделал вначале "пилот проект", иначе говоря обкусанную версию проекта с которой заказчик уже мог бы "играться" и скорректировать требования.
AN>Иначе может получится так, что после сдачи очередного этапа новые требования могут привести к большим изменениям. Хотя в общем, игрушечную версию надо заиметь как можно раньше. Хотя бы просто "пустые" формы с полями и текстом.
AN>Ну а по конкретным действиям. Надо хотя знать для какого направления?

проект ASP.NET.
1 человекогод.
проект — сайт B2C

мне интересно как всё устроено с точки зрения цепочки типа: обсуждение проекта — написание ТЗ — утверждение ТЗ — работа дизайнера — передача макета верстальщикам.
т.е. как что куда "ходит"

> 1 человекогод.
Ну что то похожее подозревалось. По моим меркам это средненький проект ближе к небольшому. То бишь надо за пару/тройку месяцев сделать, судя по количеству названных людей?
> проект — сайт B2C
Просто магазин? Что уже есть из наработок?

> мне интересно как всё устроено с точки зрения цепочки типа: обсуждение проекта — написание ТЗ — утверждение ТЗ — работа дизайнера — передача макета верстальщикам.
> т.е. как что куда "ходит"
Вообще то вначале разговор с заказчиком где он просто рассказывает и показывает, что есть, а также что бы он хотел. Там же выясняются и предполагаемые нагрузки. Потом итерационно пишем ТЗ, до тех пор пока там будут все требования, которые хочет заказчик. Очень важно занести туда ограничения, что не может быть реализовано, а также порядок корректировки. Параллельно можно обсуждать в команде пути решения, что можно/ нельзя, что просто/сложно. В это же время желательно иметь концепт дизайна, хотя бы в виде наброска, который также не забыть как то утвердить. Можно также ER модель базы сделать, будет полезна при обсуждении ограничений и оценок производительности.
Кстати, чем не устраивают уже готовые магазины? Кто будет наполнять базу?
Фактически, нормальное, (и подписанное ТЗ), по которому можно делать проект без сотни вопросов уже окончание первого, самого важного этапа разработки. Но чаще всего хорошее ТЗ не получается Прежде всего потому, что заказчик не может сформулировать свои желания/требования в "понятной для нас форме", а "выбить" бывает также не просто.
Но предположим, что у нас все получилось и известно "точно", что требуется.
Тогда, затем, нужен технический "концепт" проекта, который еще потребуется совместить с дизайнерским. Тут важно, что бы дизайнер знал, что программист может сделать, а программист не делал бы вещей могущих навредить дизайну. Эти две ветки (дизайнерская и программисткая) могут какое то время идти параллельно, не забывая бывать у заказчика. Когда больших изменений больше не предвидится, обе ветки объединяются. Но этом этапе уже получается прототип, без сложных вещей. С прототипом желательно поработать у заказчика. (Самое интересное наблюдать как заказчик делает вещи о которых даже и не думали.) После этого часто требуется сделать хорошую корректировку, а затем уже начинять проект мясом. И не забывать о постоянном тестировании с различных сторон.

Кстати, все личное ИМХО, не претендующее на истину.

Здравствуйте, AlexNek, Вы писали:

>> 1 человекогод.
AN>Ну что то похожее подозревалось. По моим меркам это средненький проект ближе к небольшому. То бишь надо за пару/тройку месяцев сделать, судя по количеству названных людей?
>> проект — сайт B2C
AN>Просто магазин? Что уже есть из наработок?
ничего нет

AN>Кстати, чем не устраивают уже готовые магазины? Кто будет наполнять базу?
а что из себя это представляет? сами наполнять будем

AN>Тогда, затем, нужен технический "концепт" проекта, который еще потребуется совместить с дизайнерским. Тут важно, что бы дизайнер знал, что программист может сделать, а программист не делал бы вещей могущих навредить дизайну. Эти две ветки (дизайнерская и программисткая) могут какое то время идти параллельно, не забывая бывать у заказчика. Когда больших изменений больше не предвидится, обе ветки объединяются. Но этом этапе уже получается прототип, без сложных вещей. С прототипом желательно поработать у заказчика. (Самое интересное наблюдать как заказчик делает вещи о которых даже и не думали.) После этого часто требуется сделать хорошую корректировку, а затем уже начинять проект мясом. И не забывать о постоянном тестировании с различных сторон.

а можно подробней, как это дизайнер и программист паралелльно работают и как потом сливается всё?

Здравствуйте, Аноним, Вы писали:

> >> 1 человекогод.

> AN>Ну что то похожее подозревалось. По моим меркам это средненький проект ближе к небольшому. То бишь надо за пару/тройку месяцев сделать, судя по количеству названных людей?

> >> проект — сайт B2C

> AN>Просто магазин? Что уже есть из наработок?

> ничего нет
Как то мне сложно представить начинать стандартный проект с полного нуля.
Хотя бы управление пользователями должно остаться после первого проекта.

> AN>Кстати, чем не устраивают уже готовые магазины? Кто будет наполнять базу?

> а что из себя это представляет?
Покупаете (ищите бесплатный) код, а затем настраиваете под свои нужды.

> сами наполнять будем
лучше промолчу...

> а можно подробней, как это дизайнер и программист параллельно работают и как потом сливается всё?
Если вообще ничего нет, то дизайнер может только в шопе работать. Но для этого и нужны наработки, тогда дизайнеру нужно только шаблоны править.

Здравствуйте, Аноним, Вы писали:

А>Добрый день!

А>Захотел вот узнать как ведется процесс разработки серьезных web-проектов.
А>К примеру, предполагается крупный проект под ASP.NET + Silverlight. В команде есть веб-дизайнеры, верстальщики, программисты C# и программисты БД ну и проджект.
А>Разработка будет с использованием VS2010, ExpressionBlend4 + MsSQL 2008
А>Вот встретились мы с заказчиком он сказал, что он хочет — мы взяли время на составление ТЗ.
А>Каков порядок действий дальше?

Вечная проблема, что куда и как ходит.
Ходит все так как хочет (может) РМ. Формально процесс очень сложен но примерно такой для ИТ проектов
Инициация проекта (обоснование проекта. подготовка бизнес-требований и т.д.)
Предпроектное обследование или анализ или формализация (формирование функциональных требований. выбор технологий и т.д.)
Реализация (составление ТЗ, проектирование. кодинг дизайнинг и т.д.)
Внедрение (тестирование. опытная эксплуатация, документирование, обычение и т.д.)

+ паралельно идет процесс changeManagement — а по управлению требованиями

Добрый день.

А>Каков порядок действий дальше?

Почитай про методологии разработки ПО.
Например MSF.
Там все подробно, по шагам и с примерами документов описано.

Здравствуйте, AlexNek, Вы писали:

AN>Иначе может получится так, что после сдачи очередного этапа новые требования могут привести к большим изменениям. Хотя в общем, игрушечную версию надо заиметь как можно раньше. Хотя бы просто "пустые" формы с полями и текстом.

+1 к тому, чтоб поскорее получить минимальную рабочую версию, но с заглушками нужно без фанатизма — по ним должно быть хорошо видно, что это заглушки. Т.к. людям, далёким от ИТ (заказчикам), очень сложно понять, что если есть формочка с полями и подписями, то оно может ещё не работать, и на то, чтоб оно работало, может потребоваться ещё достаточно много времени.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, AlexNek, Вы писали:

А>проект ASP.NET.
А>1 человекогод.
А>проект — сайт B2C

А>мне интересно как всё устроено с точки зрения цепочки типа: обсуждение проекта — написание ТЗ — утверждение ТЗ — работа дизайнера — передача макета верстальщикам.
А>т.е. как что куда "ходит"

1 ч/год — это крупный??? Это ближе к мелкому.

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, Аноним, Вы писали:

>> Добрый день!

AN>Уже столкнулся с различным пониманием "крупности" проекта. Вы можете привести хотя бы одну оценку?

Могу. Когда к моменту формирования полных требований к системе они уже являются устаревшими.

Здравствуйте, pagrus, Вы писали:

VB>>Добрый день.

P>А ещё сильно решает кунг-фу и карма конкретного менеджера.

Это скорее даже более определяющий фактор, чем методологии и подходы.

Здравствуйте, JazzzMaster, Вы писали:

JM>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, Аноним, Вы писали:

>>> Добрый день!

AN>>Уже столкнулся с различным пониманием "крупности" проекта. Вы можете привести хотя бы одну оценку?

JM>Могу. Когда к моменту формирования полных требований к системе они уже являются устаревшими.
Ну это может быть можно в раздел народные приметы поместить. И как оценивать готовые проекты от который есть только некторые "метрики"?

Здравствуйте, JazzzMaster, Вы писали:

JM>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, AlexNek, Вы писали:

А>>проект ASP.NET.
А>>1 человекогод.
А>>проект — сайт B2C

А>>мне интересно как всё устроено с точки зрения цепочки типа: обсуждение проекта — написание ТЗ — утверждение ТЗ — работа дизайнера — передача макета верстальщикам.
А>>т.е. как что куда "ходит"

JM>1 ч/год — это крупный??? Это ближе к мелкому.
Что то текст неправильно отформатирован, про 1 ч/г это не от меня

Здравствуйте, Аноним, Вы писали:

А>проект ASP.NET.
А>1 человекогод.
А>проект — сайт B2C

А>мне интересно как всё устроено с точки зрения цепочки типа: обсуждение проекта — написание ТЗ — утверждение ТЗ — работа дизайнера — передача макета верстальщикам.
А>т.е. как что куда "ходит"

Если возникают такие вопросы, то лучше не соваться и нанять профессионального ПМ, дабы избежать многих не самых лучших моментов жизни.