Создание любого сайта
10 ноября 2008 в 14:24

Создание любого сайта

--

189
Комментарии (7)
  • 10 ноября 2008 в 15:13 • #
    Alexander Brovkin

    Ну а как иначе то? Если сайт несложный то достаточно расширяемого меню. А если сайт на CMS то достаточно чтобы у нее было API для пристыковки допмодулей, и все будет ништяк :)

  • 11 ноября 2008 в 08:28 • #
    Эдгар Давтян

    Я не соглашусь и со мной не поспорить ))).
    Любой сайт начинается с идеи и потребности )))... вот так!

  • 14 ноября 2008 в 15:08 • #
    Алексей Мартынов

    Нельзя все проекты загнать под одну методику, так что "создание любого сайта" - некорректная тема. ТЗ, как устаревший документ, уже не подходит для крупномасштабных проектов, хотя для более мелких вполне сгодится. Чем крупнее проект, тем более индвидуальной должна быть методика управления его разработкой и развитием. В большинстве случаев с укрупнением проекта грамотные специалисты приходят к эволюционным моделям, которые к сожалению пока не прижились хорошо среди разработчиков и заказчиков из-за старых привычек (что кстати видно и в данном обсуждении). Так что не всегда надо разрабатывать ТЗ и строить гениальнейшую архитектуру до начала работы, не всё бывает настолько тривиально. В этом нужно быть немного пессимистом и знать: идеально никогда не получится, но хорошо сделать можно.

  • 14 ноября 2008 в 16:55 • #
    Илья Балбашов

    Согласен, мой опыт с крупномасштабными проектами эту концепцию полностью подтверждает. Тем более это касается области переноса на ВЕБ "революционных" идей, вхождения в онлайн принципиально новых областей бизнеса, где возможно только прогнозирование, попытка же создать жесткое ТЗ оказывается лишней тратой ресурсов. В подобных проектах скорее важно наметить планы развития (в плане архитектуры БД, технологий - на основе бизнес-схем), и спланировать ежемесячный (ежегодный) бюджет.
    Вторым шагом является проработка поэтапной схемы внедрения (вхождения в бизнес), целью которой будет запуск первой рабочей версии продукта в максимальной сжатые сроки.
    А дальше - трудовые будни, плановый реинжиниринг и рефакторинг, внедрение появляющихся новых ВЕБ -технологий, добавление модулей-плагинов, итд. Здесь самое важное - схема взаимодействия команды: от инвестора до бизнес-аналитика и от системного архитектора до кодеров, регламенты управления QA, Knowledge Base, релизами, итд.

  • 18 декабря 2008 в 00:12 • #
    Eduard Gusman

    Согласен, что идеальное ТЗ, для крупныных проектов не напишешь! Хотя бы потому, что всегда могут вылезти ньюансы недовольства пользователей (например на этом сайте - рассылка по импортированым контактам) которые придётся исправлять. И постоянно развивающаяся потребность в новых сервисах, тоже заставляет отклоняться от ТЗ, и частенько с переделкой готовых частей скрипта.
    А если пытаться сделать ТЗ на крупный проект, то этим можно заниматься до конца жизни! Так как нет границ желаемому. А под каждое желание надо описать функционал, подобрать технологию, согласовать-проверить на совместимость, и уж тогда готовить ТЗ под функцию. А когда функций 500 и более? :-) Большинство из них, быстрее просто написать- програмер+менеджер, оттестировать, и внедрить! Для этого и нужен менеджер конкретной части - участка проекта!

  • 19 января 2009 в 20:58 • #
    Александр Цыгольник

    - первая встреча с клиентом. выяснение цели и задачи сайта
    - заключение договора
    - взять задаток за иследование
    - произвести иследование по отрасли клиента
    - выдать результаты иследования которое покажет плюсы и минусы конкурентов
    - взять задаток за ТЗ
    - написание и утверждение ТЗ (если клиент и уйдет с вашим ТЗ, то вас успокоит то, что вы уже взяли свои деньги за работу)
    - задаток за дизайн
    - изготовление и утверждение дизайн
    - расчет за дизайн
    - взять задаток за программную часть
    - порезать и подключить ЦМС, протестировать сайт
    - показать сайт клиенту и протестировать с ним или дать ему неделю на тест
    - исправление багов и доработки
    - финальная оплата
    - установка сайта на хостинге клиента
    - сделать клиенту бонус
    - предложить клиенту Upsell
    - наслаждать от сделанной работы :-)

  • 20 января 2009 в 03:53 • #
    Alexander Brovkin

    Жесть. Клиент задолбается платить задатки :) Мы обычно тупо разбиваем проект на 2-3 равные части по оплате, заключаем договор, клиент платит предоплату и понеслась. Если клиент не хочет платить предоплату то это означает что клиент жаден, гемороен, недоверчив и проще от него отказаться чем в итоге получить на проекте великий гимор (обычно такое этим и заканчивается, слава богу что такие клиенты практически не встречаются).