Проектирование Веб Проектов - от простого к сложному

Познакомившись с MSF вы узнаете как разрабатывать программны (а сайт по сути та же программа) без головной боли, когда в конце отведенного срока оказывается что ничего не готово, не работает или работает не так.

В таком случае вам не стоит смотреть в сторону MSF. Напишите подробное ТЗ (самостоятельно или при участии представителя веб-студии), отметьте контрольные точки и по ним контролируйте ход выполнения задания.

ИМХО, задача заказчика - объяснить что он хочет получить в результате (какой продукт, какие аппаратные и программные требования). Как проект будет реализован - не его забота. Вы же не требуете в ресторане чтобы блюдо было приготовлено с помощью определенных технологических приемов, главное чтобы оно радовало глаз и желудок :)

Deni, именно так. MSF (в отличие от RUP - туда не ходите :)!) это грубо говоря идеология создания любого проекта в IT отрасли. Неважно - вебсайт, софт, прокладка кабеля по зданию для создания сети или поставка оборудования в медицинский центр. По сути нужен не весь MSF, а именно та часть, где описывается самое сложное - взаимодействие команды исполнителя с заказчиком. Тогда вы получите представление об идеальной (с точки зрения майкрософта) модели работы по проекту между заказчиком и исполнителем. Да, там есть и правила для заказчика (утрирую для простоты), без которых сделать проект не удастся.

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

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

Но есть и другие методы и подходы, более специализированные и конкретные, тот же RUP, RAD и т.д. Но в них мало чего говорится (ИМХО) именно о работе с заказчиком, скорее это процессы внутри компании исполнителя.

Была такая книжка, я читал когда готовился к сдаче экзамена по информационному проектированию (70-100 кажется), так там полкниги было в художественной форме рассказано как делался некий вымышленный проект. И взаимодействие с заказчиком, и сложные случаи разные раскрывались. Познавательно, особенно если ты уже знаешь все это изнутри.

ИМХО, все что на западе придумывается - интенсивно проходит обкатку бизнесом и жизнью. Поэтому чего выжило - то стоящее. У нас с этим беда, к сожалению. Все время изобретаем велосипед.

Ну причем тут ТЗ написанное заказчиком ?

Вы хоть читали первый топик?

Можете почуствовать РАЗНИЦУ между ТЗ написанным заказчиком и ПРОЕКТИРОВАНИЕМ Веб Интерфейса профессиональным Веб Разработчиком?

То есть если у меня сломаются ботинки то мне придется поступать в ВУЗ по специальности "Кожевенное производство" ?

Крайне адекватное предложение от Вас поступило :)

Я не понимаю, вы заказчик или разработчик? Если заказчик, то дайте задание и контролируйте его выполнение, не мешая работать разработчику. Вы говорите что делать, профессионал решает как делать.

Поверьте, изучить MSF значительно проще чем создавать технологию с нуля (а вы, как я понимаю, пытаетесь это сделать :)).

Изначально имеется Заказчик и его Идея.

Чтобы довести до других Идею, необходим Бизнес-план.

Не будем касаться общей и экономической частей, что там должно быть и так понятно.

Техническая часть составляется в последнюю очередь и включает в себя

- типы пользователей(гости, пользователи, модераторы)

- схемы использования проекта каждым типом, что может сделать каждый из них(кто может зарегистрироваться, заказать услугу)

- основные сущности проекта, схемы перехода между состояниями(например, личный счет и его пополнение)

- workflow ключевых процессов(выполнение заказа)

- на основе вышеперечисленного разрабатывается дизайн интерфейсов

- количество пользователей, нагрузка, трафик, кол-во операций

- и т.п.

Теперь пришло время составления Технико-Экономического Обоснования.

Смысл его в том, что исходя из начальных требований, мы выбираем и обосновываем

- платформу

- архитектуру системы

- конфигурацию серверов

- готовое или собственное ПО, полностью или частично

- график разработки, тестирования и начала эксплуатации

- необходимые ресурсы для разработки: оборудование, специалисты, ПО, офис

Классическое ТЭО(в промышленности) имеет гораздо большее значение и содержание, фактически является бизнес-планом.

Для более глубого понимания советую обратится к Rational Unified Process, это очень четкая и грамотная схема разработки ПО.

Хотел на этом закончить, но ладно допишу еще ;)

Этапы разработки веб-проекта.

1. Идея

2. БП

2.1 Общая часть

2.2 Маркетинговая часть

2.3 Экономическая

2.4 Техническая

3. Запуск проекта в производство

3.1 Тестирование

4. Эксплуатация

5. Обслуживание/обновление/поддержка

На каждом этапе нужны соответствующие специалисты. Некоторые пункты могут выполняться паралельно.

Какая и насколько подробная должна быть документация - решает заказчик. Естественно, чем подробнее - тем проще будет проходить процесс разработки.

Далее буду иметь в виду, что речь идет о разработке более-менее сложной системы, типа drive.ru или cars.ru

В идеале, заказчик должен отлично разбираться во всех аспектах разработки проекта.

Если нет, то он должен иметь в штате или доле минимум 3 человек:

- технического директора(вся техническая часть и разработка)

- маркетолога(весь маркетинг, дизайн, реклама)

- исполнительного директора(коммерческая эксплуатация проекта)

Желательно, чтобы эти трое полностью разделяли концепции и взгляды заказчика и не менялись на протяжении всего проекта, или по крайней мере одного изолированного этапа. При смене руководителей разработка тормозится: человеку нужно войти в курс дела, он начнет давать свои предложения и исправления, они начинают рассматриваться и вноситься в документацию.

Эти 3 разрабатывают и контролируют соответствующие части проекта.

Можно ли заказать разработку полного комплекта документации? Можно, но будет ли достигнуто необходимое качество?

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

Короче говоря, для разработки проекта нужна только команда. Документация - это побочный продукт и рабочий интструмент команды.

Есть команда - будет проект. При наличии документации - совсем не факт, что проект будет.

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

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

Это заложено здесь

Существуют разные подходу к комплектованию персонала, но это выходит за рамки обсуждения.

Я думаю такие темы обсуждаются, но на соответствующих форумах ;)

А можно поподробнее, почему не надо ходить в RUP? Насколько я понимаю, и MSF и RUP это только методологии, причем непротиворечащие друг другу, а лежащие в разных плоскостях.

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

А я как-то по наивности предполагал, что бизнесплан позволяет контролировать инвестиции в проект и последующую отдачу с проекта. Дабы не пререплатить лишку и сделать все в срок, да и чтобы потом все не разворовали :) Сами в нашей деревне пару раз пользовали, при модернизации коровника и постройке шоссе. Не знаю, как у Вас в городе, а у нас в дерёвне - помогло :)

Может, вы слышали о проекте, который приобрел финам за 20 млн долларов?

Так вот, в нем нет ни единой страницы документации!

И это ему не мешает стоить уже 100 млн.

Охотно верю, но думаю, что этих денег стоит все-таки не предмет нашей дискуссии, а аудитория и контент :)