7 шагов разработки веб-сайта: руководство к использованию

Несмотря на общепринятое мнение, центральное место в процессе дизайна и разработки веб-сайтов не всегда занимает фаза написания кода. В первую очередь приходящие на ум технологии, такие как HTML, CSS и JavaScript, и в самом деле создают образ Сети, к которому мы привыкли и определяют способы нашего взаимодействия с информацией. Что обычно остается вне поля зрения, но в то же время является едва ли не самой важной частью процесса разработки, так это стадии предварительного сбора информации, тщательного планирования, а также поддержки уже после запуска сайта. В этой статье мы поговорим о том, как может выглядеть типичный процесс разработки веб-сайта. Можно выделить разное количество этапов, из которых состоит процесс разработки. Обычно это число от пяти до восьми, но в каждом случае общая картина остается примерно одинаковой. Давайте остановимся на среднем значении. Итак, семь основных этапов разработки: 1) Сбор информации, 2) Планирование, 3) Дизайн, 4) Создание контента, 5) Разработка, 6) Тестирование, обзор и запуск 7) Поддержка.

График разработки

Когда вы приступаете к планированию процесса разработки веб-сайта, две главные проблемы, с которыми вы сталкиваетесь, это время и стоимость разработки. Эти два значения во многом зависят от размера и сложности проекта. Для того, чтобы представлять в общих чертах, как будет протекать работа над проектом, вы можете создать график процесса разработки, который будет содержать основные задачи проекта, а также этапы, из которых он состоит. Это позволит удобно следить за общей картиной и всегда быть уверенным в том, что поставленные задачи будут решены точно в срок. Для данной цели мы предпочитаем использовать GanttPRO, удобную диаграмму Гантта для управления проектами и задачами онлайн:

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

Жизненный цикл разработки веб-сайта

Этап 1. Сбор информации: назначение, основные цели и целевая аудитория

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

Приблизительное время: от 1 до 2 недель

Этап 2. Планирование: создание карты сайта и макета

На этой стадии разработки заказчик уже может получить представление о том, каким будет будущий сайт. На основе информации, собранной на предыдущей стадии, создается карта сайта (sitemap). Так, например, выглядит карта сайта XB Software:

Карта сайта описывает взаимосвязь между различными частями вашего сайта. Это помогает понять, насколько удобным в использовании он будет. По карте сайта можно определить «расстояние» от главной страницы до других страниц, что помогает судить о том, насколько просто пользователю будет добраться до интересующей его информации. Основная цель создания карты сайта — создать легкий с точки зрения навигации и дружественный к пользователю продукт. Это позволяет понять внутреннюю структуру будущего сайта, но не описывает то, как сайт будет выглядеть. Иногда, прежде чем приступить к написанию кода или к разработке дизайна, может быть важным получить одобрение заказчика. В этом случае создается макет (wireframe или mock-up). Макет представляет из себя визуальное представление будущего интерфейса сайта. Но, в отличие например, от шаблона, о котором мы поговорим далее, он не содержит элементов дизайна, таких как цвет, логотипы, и т.п. Он только описывает, какие элементы будут помещены на страницу и как они будут расположены. Макет представляет собой своего рода набросок будущего сайта. Вы можете использовать один из доступных онлайн-сервисов для создания макетов. Обычно мы используем Moqups.

Также на этом этапе стоит определиться с тем, какой стек технологий (язык программирования, фреймворки, CMS) будет использован.

Приблизительное время: от 2 до 6 недель

Этап 3. Дизайн: шаблон страницы, обзор и утверждение

На этом этапе веб-сайт становится еще ближе к своей окончательной форме. Весь визуальный контент, такой как изображения, фото и видео, создается именно сейчас. И опять-таки вся информация, которая была собрана на самой первой стадии проекта, крайне важна на этом шагу. Интересы заказчика, а также целевая аудитория должны учитываться в первую очередь во время работы над дизайном. Дизайнером на данном этапе создается шаблон страницы (page layout). Основное назначение шаблона — визуализировать структуру страницы, ее содержимое, а также отобразить основной функционал. На этот раз, в отличие от макета, используются элементы дизайна. Шаблон содержит цвета, логотипы и изображения. Он дает возможность судить о том, как в конечном результате будет выглядеть готовый сайт. После создания шаблон может быть отправлен заказчику. После обзора заказчиком проделанной работы, он присылает свой отзыв. Если его не устраивают какие-то аспекты дизайна, вы должны изменить существующий шаблон и снова отправить его заказчику. Этот цикл повторяется до тех пор, пока заказчик не будет полностью удовлетворен результатом.

Приблизительное время: от 4 до 12 недель

Этап 4. Создание контента

Процесс создания контента обычно проходит параллельно с другими стадиями разработки и его роль не стоит недооценивать. На данном шаге необходимо описать самую суть того, что вы хотите донести до аудитории своего веб-сайта, а также добавить CTA (призыв к действию). Эта стадия включает в себя также создание привлекательных и броских заголовков, написание и редактирование текста, компиляция существующих текстов и т.д. Все это требует затраты дополнительного времени и усилий. Как правило, заказчик предоставляет контент, уже готовый к тому, чтобы быть размещенным на сайте. Важно, чтобы весь контент был подготовлен до или во время стадии разработки.

Приблизительное время: от 5 до 15 недель

Этап 5. Верстка и разработка

Теперь вы наконец-то можете перейти непосредственно к верстке сайта. Все графические элементы, разработанные ранее, используются на данной стадии. Обычно в первую очередь создается домашняя страница, а затем к ней добавляются остальные страницы в соответствии с иерархией, разработанной на этапе создания карты сайта. Также на этом этапе происходит установка CMS. Все статичные элементы веб-сайта, дизайн которых был разработан ранее при создании шаблона, превращаются в реальные динамические интерактивные элементы веб-страницы. Немаловажная задача — проведение SEO-оптимизации (Search Engine Optimization), которая представляет собой оптимизацию элементов веб-страницы (заголовков, описания, ключевых слов) с целью поднятия позиций сайта в результатах выдачи поисковых систем. Валидность кода является крайне важной в этом случае.

Приблизительное время: от 6 до 15 недель

Этап 6. Тестирование и запуск

Тестирование является, наверное, самой рутинной частью разработки. Каждая ссылка должна быть проверена, каждая форма и каждый скрипт должны быть протестированы. Текст должен быть проверен программой проверки орфографии для выявления возможных опечаток и ошибок. Валидаторы кода используются для того, чтобы быть уверенным, что созданный на предыдущем этапе код полностью соответствует современным веб-стандартам. Это может оказаться крайне важным, если для вас критична, например, кроссбраузерная совместимость. После того, ка вы проверили и перепроверили ваш сайт, он может быть загружен на сервер. Обычно для этого используется FTP-клиент. После загрузки сайта на сервер, необходимо провести еще один тест для того, чтобы быть уверенным, что во время загрузки не произошло непредвиденных ошибок и все файлы целы и невредимы.

Приблизительное время: от 2 до 4 недель

Этап 7. Поддержка: отзывы пользователей и регулярные обновления

Важно понимать, что веб-сайт представляет из себя скорее сервис, чем продукт. Недостаточно просто «доставить» его потребителю. Также важно быть уверенным в том, что все работает, как и было запланировано, а пользователи удовлетворены конечным продуктом. Нужно также быть готовым быстро вносить изменения, если это будет необходимо. Система отзывов позволит вам выявлять возникшие проблемы, с которыми сталкиваются посетители сайта. Самой критичной задачей в подобных случаях будет решение возникших проблем настолько быстро, насколько это возможно. В противном случае, ваши пользователи скорее предпочтут другой ресурс, чем будут мириться с неудобствами. Также не следует забывать о регулярном обновлении CMS. Регулярные обновления избавят вас от ошибок и проблем с безопасностью.

Непрерывный процесс

Бонус. Чек-лист основных этапов разработки

Чтобы быть уверенным в том, что вы ничего не пропустили и завершать всю запланированную работу вовремя, забирайте себе этот чек-лист:

Заключение

Нужно постоянно помнить, что процесс разработки веб-сайта не начинается с написания кода и не заканчивается после запуска сайта. Этап подготовки затрагивает все последующие этапы, определяя то, насколько продуктивным окажется процесс работы над проектом. Основательное и глубокое исследование таких аспектов, как пол, возраст и интересы конечных пользователей может оказаться определяющим. Поддержка сайта уже после его запуска также крайне важна. Вы должны быть достаточно оперативны, чтобы иметь возможность быстро исправлять возникшие ошибки и решать возникшие у пользователей проблемы. Понимание того, что среди этапов разработки веб-сайта нет таких, которые можно было бы считать маловажными или необязательными, поможет вам избежать лишних хлопот и даст вам уверенность в том, что работа над проектом движется так, как и было задумано и вы имеете полный контроль над процессом разработки.

The following two tabs change content below.

Маркетолог XB Software с большим опытом в области интернет-маркетинга. Увлекается юзабилити и стремится создавать полезный контент, отвечающий интересам ИТ-аудитории.

xbsoftware.ru

Процесс разработки сайта в картинках / Habr

Три наших персонажа: программист, дизайнер и клиент.


Шаг 1: Обсуждение

Естественно, любой проект начинается со встречи с клиентом. На первой встрече вам нужно определить основные направления работы – какой продукт необходимо сделать, какими функциями он будет обладать, какие потребуются материалы (тексты, изображения, и т.д).

Шаг 2: Мозговой штурм

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

Шаг 3: Каркасы

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

Каким способом вы будете создавать каркасы – решать вам. Для небольших проектов можно сделать изображения в Photoshop или Illustrator. Для более крупных могут понадобиться каркасы в формате HTML, на которых можно проверить поведение.

Шаг 4: Планирование контента

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

Шаг 5: Первоначальный дизайн

Тем временем, дизайнер может работать над первоначальной версией дизайна – дизайном главной страницы и основных внутренних страниц.

Шаг 6: Отзыв клиента

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

Шаг 7: Доработка дизайна

… которые, вероятно, потребуют внесения изменений в первоначальный вариант.

Шаг 8: Согласование

Пока все довольны.

Эта цепочка «разработка – согласование – доработка» может повторяться на различных этапах проекта. Помимо подготовки информации, утверждение промежуточных результатов является еще одной функцией клиента.

Шаг 9: Дизайн дополнительных страниц и элементов

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

Шаг 10: Утверждение

И вновь все проверяется, дорабатывается и, наконец, утверждается.

Шаг 11: Создание HTML

Теперь можно приступить к созданию HTML-страниц.

Шаг 12: … и CSS

Шаг 13: Презентация

И снова обратная связь с клиентом.

Шаг 14: Тестирование

Завершающий этап разработки – отладка. Работу сайта нужно проверить на всех платформах, устранить технические проблемы, проверить ошибки в тексте.

Шаг 15: Запуск

На картинке написано «Конец» – но, конечно, вы не возьмете чек и не скроетесь за дверью. После запуска за сайтом нужно посмотреть еще дней 10 или около того, и в случае возникновения проблем исправить их.

Перевод оригинала тут.
Оригинал тут.

habr.com

Основные этапы разработки сайта — урок. Информатика, 11 класс.

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

 

Обрати внимание!

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

Чтобы проект был успешным, необходимо как минимум определить:

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

Процесс разработки веб-сайта можно разделить на следующие этапы:

1. маркетинговое планирование,
2. планирование структуры будущего сайта (разделы, навигация и т.д.),
3. разработка дизайна сайта,
4. верстка разработанного макета,
5. «наложение макета» на разработанную нами систему управления контентом,
6. установка программных модулей, отвечающих за расширенную функциональность сайта,
7. наполнение вашего веб-представительства текстами и изображениями,
8. тестирование сайта на соответствие техническому заданию и выкладывание готового проекта в интернет.

Давайте теперь рассмотрим каждый из этих этапов подробнее.

Маркетинговое планирование

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

Техническое планирование

 

Это этап, которым часто незаслуженно пренебрегают. Здесь стоит особое внимание уделить тому, как должна работать навигация (Как посетитель попадет на эту страницу с главной?). Не забудьте и о программных функциях.

Дизайн сайта

 

Один из наиболее сложных этапов. Прежде всего потому, что большинство из нас привыкло оценивать дизайн отдельно от самого сайта, как оценивают картину или музыку в песне отдельно от её слов.
Здесь стоит вспомнить о целях, которые вы поставили перед сайтом (Цель поразить всех красивой картинкой?). Говорит ли дизайн о том, что предлагает ваша компания? Соответствует ли он вашему корпоративному стилю (У вас ведь есть корпоративный стиль?). Четко ли он показывает ваше отличие от конкурентов? Не помешает ли дизайн в дальнейшем эффективно подвигать сайт? И это только часть вопросов, которые надо себе задать.

Верстка

Верстка — это перевод дизайна, до сего момента существующего в виде картинки, в HTML-код.

Здесь есть свои особенности. Хорошо сверстанный сайт будет одинаково работать во всех основных веб-броузерах и на наиболее распространенных разрешениях (Или вы можете позволить себе терять клиентов?).

Система управления сайтом

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

Наполнение сайта

В случае использования CMS процесс наполнения становится довольно прост. Конечно, он все же занимает некоторое время. Единственное, на что стоит обратить внимание — это готовность самих текстов. Очень часто именно этот этап является причиной наиболее значительных задержек, так что лучше всего позаботится об этом заранее.

Тестирование и выкладывание

Несмотря на то, что тестирование происходит на каждой из стадий реализации проекта, окончательное тестирование необходимо. Что надо проверить? Вот несколько самых важных моментов. Во всех ли современных браузерах работает сайт? Все ли необходимые материалы размещены? Все ли программные компоненты работают слаженно и четко?
И вот, когда тестирование закончено, наступает момент размещения сайта. Вопреки расхожему мнению, после того как сайт выложен, работа с ним не заканчивается. Если ваша цель — превратить свой сайт в инструмент маркетинга, то приготовьтесь к тому, что надо будет:

• выкладывать новые материалы;

• продвигать сайт;

• опрашивать посетителей и добавлять новую необходимую им функциональность.

www.yaklass.ru

Этапы создания сайта

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

1. Выяснение требований и определения целей создания сайта
2. Разработка технического задания (ТЗ)
3. Разработка дизайна
4. Верстка
5. Программирование
6. Наполнение
7. Запуск

Теперь опишем каждый этап подробнее:

Этап 1. Выяснение требований и определение целей создания сайта.

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

Этап 2. Разработка технического задания.

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

Этап 3. Разработка дизайна сайта.

После подписания ТЗ начинается разработка дизайна. Дизайн обычно рисуется про прототипу. Прототип – это схема, на которой нарисовано схематично, как будут расположены элементы дизайна на странице сайта. Если делается несколько страниц, непохожих друг на друга, то на каждую страницу рисуют прототип и дизайн. После того как дизайн готов, Вам присылают макет страницы. Здесь можно будет уже видеть, на что реально будет похож сайт. Если есть мелкие правки, то разработчик их делает, но саму структуру расположения элементов на странице менять уже нельзя, после того как вы утвердили прототип. Итог этапа – готовый макет каждой станицы.

Этап 4. Верстка.

На этом этапе сайт верстают. Готовые макеты дизайна «режут» так, чтоб нарисованные элементы могли стать «живыми». На некоторых элементах будут располагаться ссылки для перехода на другие страницы или сайты. Делается так, чтоб будущий сайт корректно отображался во всех браузерах. При необходимости делается так, чтоб сайт корректно отображался на мобильных телефонах.

Этап 5. Программирование.     

Здесь устанавливается CMS и реализуются все технические функции сайта, которые были описаны в ТЗ.

Этап 6. Наполнение

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

Этап 7. Запуск.

На этом этапе готовый сайт просто работает некоторое время (обычно от 2 недель до месяца), для того чтобы выявить все неисправности и обучить пользователей работать с ним. Этот период необходим потому что, очень часто в процессе эксплуатации на сайте начинают появляться ошибки. Чтобы их исправить нужен этот этап. Кроме того здесь выявляются все недоделки веб-студии, которые они должны исправить. Этот этап обязателен при создании сайта, и если веб-студия не предоставляет его, то стоит задуматься, есть ли смысл вообще работать с такой студией.

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

 

 

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

club.cnews.ru

Технология сбора требований в процессе проектирования сайта / Habr

Вступление

Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.

Классификация требований

В нашей компании принята следующая терминология в отношении требований:

1. Бизнес-требования
   Требования самого высокого уровня, которые определяют цель создания сайта и задачи, которые необходимо выполнить для достижения цели. Бизнес-требования определяются следующей метафорой: «Сайт как инструмент бизнеса, как его часть. Сайт – как лицо компании, как инструмент продаж и развития бизнеса».
2. Требования участников проекта
   Требования, которые определяют, как представители компании-заказчика будут взаимодействовать с сайтом, что им нужно от сайта. Метафора: «Сайт как неотъемлемая часть бизнес-процессов в компании. Сайт как помощник сотрудникам».
3. Требования внешних пользователей
   Требования, которые определяют, как внешние пользователи будут взаимодействовать с сайтом, и что им может потребоваться как посетителям ресурса и потенциальным клиентам компании. Метафора: «Сайт как инструмент продаж товаров и услуг компании через Интернет».

Бизнес-процесс по созданию клиентского сайта

Базовый бизнес-процесс по созданию клиентского сайта в нашей компании выглядит следующим образом:

1. После получения заявки на разработку сайта, менеджер связывается с клиентом, уточняет его ценовые ожидания и, если они соответствуют нашим, договаривается о встрече.
2. Перед встречей менеджер подготавливается к сбору бизнес-требований: читает информацию о компании заказчика, анализирует действующий сайт (если он существует), анализирует сайты конкурентов; создает примерное представление о том, какой сайт можно предложить клиенту.
3. Далее следует очная встреча с клиентом, на которой менеджер занимается сбором бизнес-требований и требований участников проекта. На данном этапе главная задача менеджера состоит в том, чтобы максимально подробно расспросить клиента о бизнес-процессах внутри компании, понять их суть, чтобы затем предложить такой функционал на сайте, который бы позволил увеличить эффективность работы сотрудников компании клиента.
4. После очной встречи с клиентом менеджер осуществляет оценку собранных требований на полноту и непротиворечивость.
5. Оценка сделана, и менеджер трансформирует требования в описание примерного функционала сайта как совокупности ряда модулей: «Каталог товаров», «Корзина», «Форум» и т. д.
6. Функционал будущего сайта согласовывается с клиентом как по содержанию, так и по стоимости. Возможны варианты, когда клиент выбирает для реализации лишь часть функционала.
7. Если предварительное соглашение о функционале будущего сайта достигнуто, то менеджер приступает к описанию целевых групп посетителей и описанию сценариев использования сайта посетителями. Данное описание также согласовывается с клиентом.
8. На основании согласованных сценариев использования сайта и функциональных модулей менеджер формирует техническое задание, в которое разработчик добавляет техническую информацию (требования к хостингу, например).
9. Техническое задание подписывается двумя сторонами, прикладывается к договору, договор оплачивается, и начинается работа.

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

Бизнес-требования

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

При проектировании с учетом бизнес-требований:

• Заказчик начинает фокусироваться на важных вопросах, касающихся целей и задач сайта, а не на том, «что на сайте будет в левом меню». Повышается мотивация и желание сделать хороший продукт.
• Большинство важных требований, которые не лежат на поверхности, выявляются в ходе последовательного прохода по внешнему окружению будущего сайта. Например: «…да, партнерам было бы хорошо предоставить личный кабинет…», «…далее сайт будет продвигаться и seo-специалистам необходимо следующее…», «…компания крупная и нужен хороший раздел с вакансиями…» и т.д.

Требования участников проекта

— это требования сотрудников компании к сайту.
После сбора бизнес-требований необходимо уделить время анализу требований сотрудников компании к сайту. Если клиент уже на встрече может предоставить список таких требований – это замечательно, однако не стоит останавливаться на этом. Важно продолжить диалог и попросить клиента рассказать о бизнес-процессах внутри организации, которой мы делаем сайт.
Важно на встрече не столько придумать все варианты использования сайта сотрудниками, а сколько понять и запомнить бизнес-процессы, а также функциональные обязанности работников, чтобы потом в офисе, в спокойной обстановке поразмыслить над тем, каким образом сайт может помочь сотрудникам.
Основной момент, который стоит подробнее изучить на встрече, – взаимодействие менеджера по продажам с клиентом и какую роль в этом взаимодействии должен играть сайт. Рассмотрим некоторые варианты практического применения сайта менеджером:

1. Сайт может помогать менеджеру при непосредственном общении с клиентом – например, менеджер с экрана компьютера демонстрирует клиенту продукцию или услуги компании.
2. Менеджер «конструирует» что-то на сайте, например, выбирает для клиента тур в Турцию или рассчитывает стоимость полиса ОСАГО. Частный пример – «конструктор кухонь» на сайте компании Ikea.
3. Менеджер часто выезжает на встречу с клиентом на местах и с планшетного компьютера демонстрирует продукцию, представленную на сайте – (для себя мы сразу делаем пометку, что будет важна мобильная версия сайта и интерфейс работы с устройствами с сенсорным экраном).
4. Сайт служит для сопровождения клиентов в процессе продажи товара и после. Это такие действия как: всевозможные консультации, отслеживание статуса заявки на покупку товара, обмен файлами, техническая поддержка.
5. Во многих случаях менеджеру приходится давать подробные консультации клиентам, и в этом случае на помощь может прийти сайт, где в специальном разделе можно будет разместить справочную информацию. Частный случай: раздел FAQ, где можно посмотреть ответы на основные вопросы и задать свой.

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

Пример из жизни.
В нашу компанию обратился клиент, занимающий оптовой продажей мебельных комплектующих: гайки, стяжки, винты и т.п. Как правило, обычный человек не понимает всей специфики данного вида бизнеса. Поэтому в ходе диалога наш менеджер попросил клиента описать процесс продажи товара подробнее.
Как оказалось, этот процесс очень прост: сначала потенциальный покупатель выбирает через электронные каталоги в формате .pdf товары нужного артикула и в определенном количестве. Далее он звонит в компанию и озвучивает свой заказ менеджеру. Менеджер принимает заявку и ищет требуемый товар у поставщиков. После того, как с поставщиками достигнута договоренность, менеджер связывается с клиентом и озвучивает ему общую стоимость заказа. Как правило, далее следует торг и согласование финальной стоимости.
В данной ситуации, как мы видим, основная работа лежит на менеджере и его действия нельзя заменить каким-либо функционалом на сайте. В связи с эти было принято простое решение: на сайте организуется витрина товаров (все товары переносятся из электронных каталогов на сайт), покупатель выбирает требуемые товары, точно задает их параметры (размеры, материал покрытия, цвет) и количество и далее простым нажатие кнопки отправляет заявку менеджеру.
Вывод из этого примера достаточно простой: не домысливайте за клиента, а просто просите его подробно рассказать о своей работе.

В том случае, если клиент на встрече затрудняется или просто не желает подробно расписывать бизнес-процессы в компании, можно попытаться разговорить его, предлагая те или иные решения на сайте, которые будут полезны сотрудникам.
Например, можно взглянуть на сайт глазами бухгалтера и выдвинуть следующее требование: «Необходим функционал автоматического выставления счета на оплату».

Варианты потенциальных требований со стороны участников могут быть такими:

1. Требования директора по персоналу:
   a. «Управление вакансиями на сайте сделать по аналогии с сайтом SuperJob».
   b. «Создать внутрикорпоративный портал и базу знаний».
   c. «Создать личные странички сотрудников».
   d. «Создать возможность проведения вебинаров для сотрудников через сайт».
   
2. Требования директора по рекламе, маркетолога:
   a. «Создать удобное управление баннерной системой – как для показа своих баннеров, так и чужих».
   b. «Сделать возможность выгрузки данных о товарах и услугах».
   c. «Создать функционал проведения опросов через сайт».
   d. «Создать возможность комментирования и обсуждения товара на сайте».
   e. «Организовать кросспостинг материала в социальные сети».
   f. «Создать рейтинги товаров».
   
3. Требования администратора сайта:
   a. «Создать возможность одновременной работы нескольких человек в административном разделе».
   b. «Создать функционал автоматического архивирования сайта».
   c. «Создать возможность разграничения прав доступа для редакторов сайта».
   
4. Пиар-менеджер:
   a. «Необходимо использовать фирменный стиль в дизайне, подчеркивать бренд».
   b. «Создать функционал «рассылки», «форум», разместить виджеты социальных сетей».
   c. «Создать определённые промо-страницы, промо-блоки, аудио-видео, flash».
   
5. Бизнес-аналитик:
   «Осуществить специальную настройку процесса формирования и отправки заказа, чтобы появилась возможность оценивать конверсию посетителей в покупателей».
6. Юрист:
   «Создать раздел для публикации документов, требующих публичного оглашения».
7. Представитель службы логистики:
   «Создать раздел с подробными картами складов».

Определение целевых групп посетителей и сценарии использования

После того, как были определены бизнес-требования и требования участников проекта, начиная с базовых: «Я как собственник бизнеса хочу начать реализацию товаров и услуг компании через интернет» и заканчивая второстепенными, менеджер нашей компании упорядочивает всю информацию и формирует на ее основе описание основных функциональных модулей будущего сайта.
После согласования с клиентом функционала сайта и бюджета проекта менеджер определяет целевые группы посетителей сайта.
Типичными целевыми группами являются:

1. Покупатели
   a. Первичные.
   b. Вторичные.
   c. Не определившиеся.
   d. Постоянные.
   
2. Соискатели работы.
3. СМИ.
4. Партнеры.
5. Инвесторы.

Далее определяются сценарии использования сайта посетителями. Такими сценариями могут быть:

1. Для покупателей:
   a. Для первичных: покупка товара, ознакомление с ценами, сравнение товара, получений консультаций.
   b. Для вторичных: повторный заказ товара, получение скидки.
   c. Для не определившихся: поиск товара, участие в акциях, связь с компанией.
   d. Для постоянных: покупка одних и тех же товаров, использование скидок, техподдержка.
   
2. Соискатели работы: поиск вакансий, отправка резюме.
3. СМИ: импорт новостей, импорт графической информации.
4. Партнеры: авторизация на сайте, загрузка прайс-листа, чат с персональным менеджером.
5. Инвесторы: информация об акциях компании, графики котировок.

Каждый из этих базовых сценариев подробно расписывается и далее согласовывается с клиентом. Например, сценарий «Отправка резюме» в расширенном виде выглядит следующим образом:
«Для того чтобы отправить резюме, соискатель должен заполнить форму, расположенную на странице с вакансией, и прикрепить к ней сам файл резюме. Описание полей формы приведено в техническом задании».
Даже такие, казалось бы, банальные вещи необходимо описывать, чтобы потом не было претензий со стороны клиента: «А я думал, вы расположите данную форму на всех страницах сайта справа…».

Техническое задание

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

Техническое задание состоит из следующих блоков:

1. Подробные сценарии использования со стороны заказчика (как представители заказчика взаимодействует с сайтом, например, как менеджер обслуживает через сайт заявки, как менеджер по персоналу публикует вакансии и прочее).
2. Описание структуры элементов и набор полей в административной части сайта.
3. Структура сайта и навигация по нему (разделы сайта, порядок расположения элементов на типовых страницах).
4. Сценарии использования основного функционала (как пользователь может отправить заявку, что получит в ответ, как пользователь использует поиск по сайту и прочее).
5. Описание функционала основных модулей
6. Компоновка элементов, дизайн (описываются все требования к дизайну)
7. Описание работы отдельных сервисов (например, использование калькулятора ОСАГО)

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

1. Представитель клиента озвучил следующее требование: «Хочу удобную систему публикации и представления вакансий на сайте, чтобы было удобно создавать новые вакансии, доставать из архива и активировать старые».
2. После беседы с клиентом помимо прочего менеджер выделил функционал «Вакансии», который учел при оценке общей стоимости создания сайта.
3. Далее менеджер определил целевые группы: «Соискатели работы» — со стороны посетителей сайта и «HR-менеджер» со стороны участников проекта.
4. В итоговом техническом задании изначальное требование приобрело следующий вид:
   a. В административном разделе сайта имеется возможность создавать новые вакансии на основе шаблонов, содержащих следующий набор полей: должность/требования/обязанности/зарплата/…
   b. Администратор сайта имеет возможность изменить базовый шаблон или создать новый. Соответственно при публикации вакансии имеется возможность выбрать соответствующий шаблон из имеющихся и создать на его основе вакансию.
   c. Раздел «Вакансии» расположен в основном разделе «О компании».
   d. Список вакансий на странице «Вакансии» имеет табличный вид. Используются поля: «Должность», «Зарплата».
   e. При переходе на конкретную вакансию пользователь видит следующее (см. эскиз дизайна).
   f. На странице конкретной вакансии пользователь может отправить резюме, которое придет на определенный электронный адрес, а также сохранится в базе данных.
   g. Форма отправки резюме имеет следующий вид…
   

Заключение

После того, как менеджеры нашей компании были обучены вести сбор требований по данной технологии, эффективность реализованных в компании сайтов стала выше. Сайты стали приносить больше пользы как сотрудникам компании клиента, так и посетителям.
А все от того, что мы сами начали лучше понимать заказчика, мы начали строить с ним более содержательные диалоги и более полно собирать требования и учитывать их при проектировании сайта.
Раньше менеджер в основном лишь слушал сумбурную речь заказчика о том, как тот видит главную страницу сайта, и что «нужно звездочками показывать рейтинг товара». Сейчас же менеджер целенаправленно обсуждает с клиентом все аспекты создания сайта, начиная с цели, ради которой создается сайт, и заканчивая описанием использования сайта потенциальными посетителями, а также сотрудниками компании.
Надеюсь, и вам данный материал поможет в процессе работы с заказчиком при разработке сайта.

habr.com

8 шагов к созданию собственного сайта / Habr

Я не нашел хороших пошаговых шаблонов к действию для новичков в сайтостроении, поэтому хочу поделится опытом создания собственных веб-сайтов от идеи до запуска.
Минимальные требования: умение верстать HTML-страницы и базовые знания в любом из языков веб-программирования (PHP/Python/Perl/Ruby).
Рекомендуемые: Основы работы в графических редакторах (Photoshop/Adobe Illustrator), навык divной HTML вёрстки, владение хотя бы одним из языков для веб-программирования (PHP/Python/Perl/Ruby…).
Временные затраты: напрямую зависят от навыков и желания. У меня на 1 проект уходило от пары часов до недели (В зависимости от детальности реализации каждого из пунктов).

Идея

При создании сайтов для себя, в первую очередь я решал свои проблемы, так как не находил удобных аналогов. В результате, полезную информацию, которой я сам пользовался я выкладывал для всех на свой сайт.
Выбор тематики
Не стоит создавать ещё один портал про страхование/FOREX, только потому что вы хотите зарабатывать на контексте. Если тема для вас не представляет интереса, и что ещё хуже вы полный профан в выбранной тематике и не хотите это исправлять, в лучшем случае вы создадите ещё один сателлит, пытаясь изначально выжать из него максимум прибыли.
Небольшой пример из жизни: Несколько лет назад, я начал активно посещать бары и рестораны в своём городе, оценивать качество услуг, рекомендовать друзьям, где мне понравилось, что мне не понравилось. В результате я создал сайт рекомендаций для молодёжной аудитории нашего города. На голом энтузиазме я посещал развлекательные и культурные места города, сайт развивался, пополнялся контентом и приносил пользу.
Если теперь вы можете сказать, какую задачу будет решать ваш сайт, и у вас достаточно энтузиазма для реализации — можно приступать к регистрации домена. Если вы уже примерно представляете, сколько вам необходимо места под ваш проект, можно сразу взять и хостинг. В таком случае не забудьте установить «заглушку» для сайта.

Полезные статьи:

Контент

Контент — основа вашего сайта. Будь это авторские статьи или пользовательские статьи — пользователь в первую очередь приходит за информацией, и мы должны в приятной форме её преподнести.
На этом этапе необходимо иметь представление, какие разделы будут на вашем сайте. Например если будет страница «О сайте» — что на ней найдет посетитель?
Перед тем, как я начинаю проектирование интерфейса сайта, я подбираю материал, который по моему мнению будет полезен посетителям. Будь то статьи или видео, перед публикацией я прочитываю и просматриваю, отсеивая бесполезный мусор.
Если нужно срочно опубликовать непрочитанный вами материал, рекомендую проверять на орфографические ошибки (хотя бы при помощи MS Word).
Если ваш сайт не новостной ресурс, и вы готовите место для новостного блока — подумайте ещё раз. Неприятно видеть на сайте последние новости, добавленные несколько месяцев назад. Если вы всё же решились выделить место под новости, попробуйте поместить ленту последних сообщений из твиттера. Таким образом вы не только получите потенциальных подписчиков, а ещё и облегчите функционал сайта.

Полезные статьи:

Интерфейс

Подобрав интересные материалы, стоит перейти к вашему видению интерфейса, с которым будет постоянно взаимодействовать посетитель нашего сайта.
На этом этапе необходимо определится, будет наш сайт резиновым, или фиксированной ширины. В дальнейшем это поможет нам понять, на какое рабочее пространство мы можем рассчитывать и какой размер использовать для превью фотографий.
Обычно я беру ручку и блокнот и представляю себе начиная со стартовой страницы, как бы мне было удобно найти необходимую информацию и в каком виде её получить.
Главное, не углубляйтесь в мелкие детали, как то «тенечка вот в этом углу» или «градиент на этой кнопке». Для начала достаточно будет простых схем, показывающих расположение блоков.

Полезные статьи:

Дизайн

Идеальным будет вариант, если у вас есть знакомый дизайнер, с которым вы договоритесь за небольшое вознаграждение оформить макет с учетом ваших пожеланий.
Если у вас нет друзей дизайнеров, но есть желание и время для создания своего дизайна — рекомендую статью «Используем Adobe Illustrator для создания макета страницы»
При заполнении макета я никогда не использую пустые тексты вроде Lorem impsum… Дизайн наполненный реальной информацией и соответствующими картинками на порядок приятнее и живее обезличенного шаблона.
В идеале вы получите шаблон под требуемое расширение экрана, со слоями для каждого из элементов. Если красивый шаблон у вас создать не получается и финансы не позволяют сделать дизайн на заказ — можно подсмотреть симпатичные шаблоны на templatemonster.com

Вёрстка

О идеальной вёрстке можно говорить бесконечно, напишу о том, с чем я чаще всего сталкиваюсь:
Кроссбраузерность
Обычно я проверяю, как отображается наш сайт в последних сборках Firefox, Opera, IE, Chrome (если вы ориентируетесь только на русскую аудиторию — актуальная статистика по браузерам для рунета). Затем используя multi IE, проверяю как сайт выглядит в версиях до 6 включительно (В 6 версии устраняю только проблемы, из за которых сайт нереально прочитать). После запуска проекта удобно использовать сервис http://browsershots.org/
Рекомендую использовать дивную вёрстку, все стили выносим в отдельный css файл. При этом основной контент сайта должен располагаться как можно ближе к началу исходного кода страницы. Например если у вас страница состоит из двух колонок, одна из которых — основной контент страницы (справа), а другая — сквозной список часто читаемых статей (слева), используйте floatы или отрицательные отступы.
В итоге вы должны получить статичную html страницу + css + jpg/png изображения — образец реальной страницы вашего сайта.

Полезные статьи:

Первая версия

Закрытая среда разработки
При разработке сайта на локальной машине в первую очередь я беспокоюсь о том, что бы исходники не утекли в сеть раньше времени. Даже если ваш сайт доступен только в локальной сети (например по адресу 192.168.1.100), закройте доступ извне. Также я до запуска сайта не устанавливаю счётчики и отключаю в браузере режим «слежения» — например в Google Chrome.
Имея сверстанный шаблон и контент, которую мы собираемся разместить на сайте, самое время проявить наши таланты в web-программировании на вашем любимом языке.
К этому моменту вы должны определится, какую базу данных вы будете использовать, или хранить всё в файлах.
Для своих сайтов я всегда использую MySQL, которая с большей долей вероятности уже установлена на дешевых хостингах, желательно что бы вы уже представляли какие таблицы в базе данных у вас будут.
Если у вас уже есть избранная CMS или Framework, не составит проблем адаптировать html шаблон и приступить к написанию необходимых модулей. Если вы делаете сайт с нуля, и при этом у вас нет наработок прошлых проектов — делаем выбор, будем изучать CMS/Framework или писать свой велосипед, учась на своих ошибках.
Не стоит проводить преждевременную оптимизацию кода (конечно, если у вас уже сейчас код страницы генерируется 5+ секунд, стоит задуматься), лучше займитесь оптимизацией изображений.
Немаловажно определится с кодировкой, в настоящий момент UTF-8 становится стандартом де-факто, так что подумайте перед тем, как выбрать windows-1251, что бы потом не было проблем с переходом.

Полезные статьи:

Запуск

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

Полезные статьи:

Поддержка

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

• серверных скриптов (в моём случае PHP)
• статики (javascript, css, изображения)
• таблиц в базе данных (в моём случае MySQL).

В любой момент времени есть возможность в один клик обновить информацию на сайте/добавлять новые фичи с предварительной проверкой функционала на локальном сервере. Также перед загрузкой новой версии, советую использовать инструмент для проверки таких банальных вещей, как — отсутствующие title и изображения, битые ссылки и страницы с рекурсивным редиректом.
В дальнейшем нам предстоит множество развитий сайта, начиная от оптимизации скорости загрузки, пополнением контента, SEO оптимизация, но эта тема выходит за рамки статьи…

Полезные статьи:

UPD: Уверен, большинство опытных хабраюзеров не узнают ничего нового, но хабр читают и начинающие вебмастера.

UPD(2): Обновил некоторые устаревшие ссылки на материалы.

habr.com

Самоорганизация в web-разработке / Habr

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

Я лично для себя никогда не ставил целью стать менеджером. Однако, будучи разработчиком-фрилансером столкнулся с необходимостью правильно распределять свое время и уметь продавать свою работу.
Далее…

0 Этап

Любой проект начинается со звонка: либо вы ищите заказчика, либо он вас (лучше последнее *-)).

Лично я пока клиентов не ищу. В настоящий момент мне приходиться работать в институте (пишу дисер), в связи с чем нет возможности нормально организовать работу на весь день. Кроме того, у нас в городе/области большой дефицит специалистов и приходиться делать все самому, в связи с чем, большой поток работы попросту не осилить. Хотя, самой работе это не мешает, т.к. клиенты сами меня находят по рекомендациям.

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

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

Часто у клиентов бывает «горячка», когда нужно срочно, «по-быстрому что-то сделать». Здесь главное не попасться, т.к. не всегда известны причины этой спешки (т.к. клиент молчит о реальных причинах) и может получиться так, что вы проработаете в авральном режиме впустую.

В результате предварительного разговора определяется дата/время первой встречи с заказчиком. Дата определяется загодя и подготовиться к встречи должны и вы и заказчик.

С вашей стороны нужно подготовить примеры и все необходимые документы (для составления договора) + технику для демонстрации и работы (ноутбук).

Не знаю как обстоит ситуация в больших городах, но на «периферии» нужно таскать «ноутбук с интернетом» собой. Для таких целей новомодные eeePC и клоны являются идеальным вариантом, т.к. их не напрягает таскать с собой.

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

К сожалению, часто возникают ситуации, когда предварительные встречи повторяются. Этого нужно старательно избегать, т.к. часто «пред-игра» заводит в тупик.

1 Этап

Основная задача этого этапа — разложить с клиентом все по полочкам (в форме Технического задания) и заключить (и подписать) договор. По этой и ряду других причин встречу желательно проводить на «территории» заказчика. При этом, все лица, косвенно участвующие в работе со стороны заказчика должны быть в зоне досягаемости. Кроме того, то, что вы приедете сами, может расположить к вам заказчика.

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

В идеале, менеджер должен быть в курсе работы программистов и быть «в теме». В таком случае, легче будет вести диалог. Если вы работаете один — это как раз тот самый вариант.

Диалог начинать нужно будет опять с выяснения задач сайта, т.к. часто бывает, что у клиента появляется «что-то новое» или он о чем-то умолчал. На основании задач определяется характер сайта (портал, магазин, промо-сайт…) и структура его разделов. Последнее необходимо определять максимально четко.

Естественно, нужно понимать, что заказчик изначально не в курсе всяких там usability и он мало задумывается об оптимизации контента. Ваша задача «честно» объяснить заказчику что к чему и что стоит делать, а что не стоит. Вообще, я стараюсь в разговоре с заказчиком придерживаться максимально «честного» разговора. Понятно, что раскрывать все особенности вашей «кухни» не нужно. Однако, что правильно, а что нет и почему нужно говорить всегда. При этом нужно делать упор на то вы лишь заботитесь о качестве продукта (каким является сайт) и все ваши действия направлены на то, чтобы сделать его лучше.

Задачи сайта и его структура «забиваются» в Техническое задание.

Далее, имея структуру перед глазами нужно четко определить с заказчиком функциональность каждого раздела, что там должно быть и в каком виде (форме). Это очень важный момент, т.к. даже такую простую функцию как новости все воспринимают по своему. Весь функционал также важно прописать в ТЗ, т.к. если этого не сделать может оказаться, что заказчик «имел в виду совершенно другое» или у него «появились новые идеи».

Реальность такова, что большинство заказчиков считает, что за обозначенную вами сумму он покупает вас, а не конечный продукт. Задача ТЗ – помочь вам исправить это ошибочное мнение.

Если у заказчика «горячка» и нужно успеть к какому-то определенному сроку можно разбить работу на этапы и выделить первостепенные задачи/разделы.

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

В конечном итоге определяем порядок оплаты и сроки сдачи работ в рамках проекта (желательно, поэтапно) и прописываем все в договоре. Кроме того, нужно обязательно определить кто будет с вами взаимодействовать напрямую. Этот человек должен иметь «право подпись». Если этого не сделать, то «недо-отвественность» со стороны заказчика может вылиться вам боком и вы окажитесь «виноватым» в конечном итоге.

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

На этом же этапе, после определения ТЗ желательно обсудить пожелания заказчика насчет дизайна. К сожалению «заказ на дизайн» сложно формализовать (да и не имеет смысла), поэтому все придется записать в свободной форме и виде эскизов-набросков. Желательно сразу пресекать пожелания вроде «фона из логотипов» и т.д. (естественно, объясняя почему).

2 Этап

Имея на руках ТЗ и заказ на дизайн можно приступать к работе. В процессе разработки можно предусмотреть промежуточные этапы сдачи работы: прототип сайта для уточнения функциональности, макеты дизайна для утверждения и д.р. Приемку всех этапов работы нужно в обязательном порядке визировать двухсторонним актом приемки. Я не раз был свидетелем того, как заказчики прыгали и скакали, заявляя, раз он этого не подписывал — этого не было.

Программная часть сайта

Подавляющее большинство разработчиков создает сайты на основе CMS, собственного или стороннего производства. Это удобно, т.к. есть базис и его нужно лишь развивать. При этом, однажды разработанные решения могут быть использованы повторно экономя массу времени. Кроме того, в большинстве своем CMS используют шаблонную систему, что позволяет вести работу над программной частью независимо от дизайна.

Лично я использую свою CMS, т.к. хорошо зная ее архитектуру я знаю что можно сделать (и как), а что нельзя. Хотя, это сила привычки и в некоторых случаях возможно лучше использовать готовые сторонние решения.

Если возникает необходимость написания нового модуля (или адаптация существующего) необходимо четко распланировать его архитектуру. Я долгое время работал над CMS и ее модулями в режиме «текучки», постепенно развивая и расширяя задачи. В результате, когда возникла необходимость объединения нескольких модулей, пришлось все переделывать по-новому.

Планирование архитектуры лучше всего начинать с TODO на модуль: какими данными он должен оперировать и что должен уметь делать. Например, в настоящий момент я пишу модуль блога и чтобы самому не запутаться расписал в виде плана что нужно сделать. На основе TODO разрабатывается схема базы данных (точнее, совокупности таблиц модуля) и как она интегрируется в общую базу CMS, а также интерфейсы управления и взаимодействия с модулем. Последнее является очень важной частью разработки модуля, т.к., в отличии от кода и структуры БД она не «скрыта от пользователя». Поэтому интерфейсы управления должны быть понятны конечному пользователю, а не программисту.

Для набросков интерфейсов достаточно хорошо подходит расширение <a
href=«addons.mozilla.org/sq/firefox/addon/8487?lang=ru»>Pencil

.
К сожалению, при первичном планировании TODO учесть все аспекты не всегда удается, поэтому TODO, структура таблиц и GUI (функциональные элементы интерфейсов) могут меняться по ходу разработки.

При разработке модулей и вей системы в целом нужно учесть еще два момента: bug-report и наличие документации. У мня все ошибки системы на основном сайте тщательно журналируються и отсылаются на мой почтовый ящик. Если что-то слетает журнал всегда поможет найти ошибку.

Вполне логично, что работать на «живой» системе не очень правильно. Для разработки прототипа, как правило, используется локальная (на вашем рабочем компьютере или корпоративном веб-сервере) версия сайта. Ее же (или копию) можно показывать заказчику. Только после приемки работы (рабочей версии сайта) его имеет смысл переносить на основной сервер.

С документацией все немного сложнее. Как уже неоднократно отмечалось (ссылка) многие программисты не любят писать документации. Тем более это касается документации для простых пользователей а не манов для других программистов. К сожалению от этого никуда не деться. Даже если вы используете готовую стороннюю систему («Битрикс» и других) документацию скорее всего придется переписывать и адаптировать ее для нормальных людей. Документация позволит значительно сэкономить ваше время в будущем, когда пойдут звонки от клиентов с вопросами. Если у пользователя что-то не получается всегда можно будет отправит его к нужной странице, к нужному пункту и выяснить что не так.

Конечно, нужно учитывать, что в большинстве своем пользователям самим лень читать документацию и делать все в соответствии с ней. Я регулярно тестирую пользователей (у меня есть такая возможность, т.к. преподаю на курсах переподготовки учителей) на предмет того, как они используют документацию и результаты, как правило, весьма забавные: пользователь доходит до 3-го, 4-го пункта, а дальше поступает по своему, считая, что остальные пункты не важны и написаны «до кучи».

Дизайн

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

1. Если заказчику нужно сделать все по быстрому

В такой ситуации можно предложить готовое дизайн-решение – шаблон. Его можно купить, найти бесплатный или воспользоваться своими старыми заготовками (если таковые имеются). В этом случае нужно объяснить заказчику, что такое шаблон и чем он отличается от «эксклюзивного» дизайна.

2. Утверждение дизайна заказчиком

Еще на стадии заключения договора нужно четко определить количество разрабатываемых дизайн-макетов. Если этого не сделать, то работа дизайнера превратиться в бесконечное переделывание в попытках угодить сиюминутным капризам заказчика («Сделайте мне еще что-нибудь…»). Если дизайн утвержден я, как правило, требую от заказчика подписи на распечатке макета.

При этом, «успокоить» заказчика можно тем, что сайт работает на шаблонах и в будущем, если возникнет такая необходимость (и если это позволяет CMS) можно будет изменить дизайн. Но, за отдельную плату и по отдельному договору (или приложению к текущему договору).

3 Этап

Показываем прототип заказчику. Желательно сразу «прикрутить» к нему дизайн, т.к. иначе заказчику будет сложно понять (и утвердить), что и как будет работать на его сайте.
На этом этапе, как правило, вносятся коррективы в дизайн, функциональность и в структуру в целом. Главное, при этом, четко следить, чтобы коррективы не привели к разработке нового сайта, совершенно отличного от того, что был обозначен на первом этапе (и прописан в ТЗ). Если заказчик стоит на своем и требует внести новую «фичу» — оформляем работу новым договором или приложением к текущему. Главное ни в коем случае не идти на поводу, т.к. однажды согласившись потом будет уже сложно сказать «нет».

4 Этап

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

1.Как пользоваться админкой CMS

Руководство должно быть максимально «человечным» и быть выстроено в виде структурированных вопросов/ответов с подробным, пошаговым описанием всех необходимых действий (желательно, еще и со скриншотами).

2.Руководство по подготовке и оформлению материалов для сайта

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

3.Техническое руководство для администратора

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

5 Этап

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

Не забываем напомнить заказчику об оплате ваших услуг.

6 Этап

Прописываем сайт в поисковиках и проводим его начальную поисковую оптимизацию. На этом этапе не редко возникает новые проблемы с заказчиком, а именно, требования с его стороны о размещении сайта на первых строчках Google и Яндекс. Претензии в основном звучат как «Сайт, который сразу не находиться в Яндесе нам не нужен». Здесь нужно набираться терпения и спокойно объяснять заказчику каким образом сайты туда попадают и что очень многое зависит от его (заказчика) контента и частоты его обновления.

habr.com