Сайт как бизнес

Поисковое продвижение сайтов (SEO), создание сайтов в Минске (Беларусь).


Канал «СТАРТАП ТЕХНОЛОГИИ»: об ИТ-бизнесе, стартапах, инвестициях

Подпишись на рассылку блога об интернет-бизнесе:

Архивы на тему ‘управление проектами’

Средства удовлетворения заказчика

пока комментариев нет

Все люди делятся на 2 роли, заказчики и исполнители. И роли эти зачастую меняются. Будучи по одну сторону прилавка магазина мы являемся заказчиками (покупателями), но стоит нам перелезть через прилавок — как мы становимся исполнителями. 

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

Итак условия задачи: 

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

Дано: заказчик — 1 шт. 

Необходимый результат: удовлетворенный заказчик — 1 шт.

Первый шаг

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

Неверный вопрос заказчику: Необходимо ли вам в поректе древовидная структура наследования объектов. 

Верный вопрос заказчику: Будет ли у вас каталог со вложенными разделами ?

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

Если это надо на самом деле Вам — позаботьтесь самостоятельно об том чтоб заказчик заполнил его. 

Далее важный момент — ТЗ. Не так давно я уже писал о его необходимости. Оно необходимо — и это аксиома! 

Планирование работ: 

Используйте в своей работы инструменты планирования работы с возможностью просмотра стадий, контрольных точек. Даже если вы уверенны что заказчик этим не будет пользоваться, а вы и так гений планирования и все планы готовы предоставить на post-it листочках — не стоит этого делать. Вы профессионал, и надо работать профессионально. Инструменты планирования проектов намного упрощают работу в проекте. А лишняя информативность заказчика никогда не помешает. 

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

Контрольные стадии проекта

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

  • сдача дизайна
  • сдача верстки
  • сдача модуля ХХХ (новости, каталог) 

Презентация конечного продукта

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

Сдал — забыл ??

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

Несколько бесплатных советов

Предоплата — ничто не добавляет уверенности в заказчике как предоплата :) Но если заказчик старый и проверенный друг — думаю вы уже доверяете друг другу. 

Передача исходных кодов — весьма спорный вопрос. Впринципе заказчик заплатил за проект и может расччитывать на обладанием прав на исходный код. Нет никакого смысла его кодировать (Zend Encoder..) т.к. это просто НЕ логично. 

Макеты сайта нарисованные в фотошопе тоже впринципе могут быть переданы заказчику — он заплатил за них.  

Итого

Чтобы получить удовлетворенного заказчика нам надо следовать следующим правилам: 

  1. Заказав сайт заказчик должен получить не только сайт но и заботу. 
  2. Не скупитесь на удобства для заказчика. Отчеты о работе, презениации и системы -все это добавляет вес вам. 
  3. Сдав проект не забывайте о заказчике. Интересуйтесь его делами, пригласите в офис для совместного распития чая
  4. Постоянно работайте над улучшением качество своего обслуживания. Нет пределу совершенства! 

Написал Валерий Хвалев

21 ноября, 2008 в 3:56 пп

Подпишись на обновления блога по e-mail или RSS!

Требования для подготовки контента

пока комментариев нет

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

1. Тексты на статичные страницы

Необходимо ещё раз повторить структуру сайта (даже если она есть в Концепции), указав, для каких из них какие тексты нужны.

Например, для страницы «Услуги компании» требования могут звучать следующим образом:

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

Требования по высылаемым материалам могут выглядеть так:

Текст для каждой страницы должен быть помещён в отдельный текстовый документ. Название документа соответствует названию страницы (по Концепции).

2. Тексты новостей

(аналогично для статей и пресс-релизов)

Надо объяснить Заказчику, что для размещения на сайте новости необходима следующая информация:

  • заголовок новости;
  • дата публикации;
  • имя автора (если это необходимо);
  • краткое описание, для вывода его в общем списке новостей
    краткое описание должно содержать 2-3 предложения, можно использовать первый абзац полного текста новости;
  • полный текст новости;
  • ссылка на источник (если это необходимо).

Требования по высылаемым материалам:

Вся информация по одной новости должна размещаться в одном текстовом документе. Название документа соответствует дате публикации новости и её заголовку.

3. Фотографии

Если обработка фотографий не входит в стоимость проекта, то нужно указать Заказчику:

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

Требования по высылаемым материалам:

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

  • 01 — описание 1
  • 02 — описание 2 и т.д.

4. Каталог

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

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

Требования по высылаемым материалам:

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

5. Сотрудники компании

Информация о сотрудниках компании может использоваться на странице о руководстве или структуре компании. В этом случае будет нужна следующая информация:

  • фамилия, имя, отчество;
  • занимаемая должность;
  • контактный телефон;
  • контактный e-mail;
  • фотография.

6. Сервисы на сайте

Если на сайте будут предусмотрены онлайновые сервисы, позволяющие общаться посетителям сайта и сотрудникам компании, то понадобится следующий список:

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

7. Интекрактивная карта

Это может быть карта дилеров компании, её офисов или клиентов, может быть карта построенных домов или, например, АЗС. В этом случае вся информация для карты должна быть представлена в следующем виде (на примере дилеров, расположенных в разных городах):

  • название компании дилера;
  • город;
  • адрес;
  • логотип;
  • контактный телефон;
  • контактное лицо;
  • схема проезда.

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

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

Взято с http://habrahabr.ru/blogs/webdev/44886/

Написал Валерий Хвалев

18 ноября, 2008 в 3:27 пп

Подпишись на обновления блога по e-mail или RSS!

Техническое задание на разработку сайта — бюракратия или жизненная необходимость

пока комментариев нет

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

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

- «Вот смотрите, мы хотим чтоб было все! Что б все было классно, чтоб было не как у всех, чтоб мы были в первой строчке выдачи всех поисковиков! » — типичные слова 50% заказчиков. Безусловно мы не имеем морального права спорить с заказчиком, ибо он прав по умолчанию, но речь идет именно о взаимных интересах. Веб студия зачастую ничего не знает ни о бизнесе заказчика, ни о его процедурах, его преимуществах перед конкурентами, не тем более о вкусах ответственного за выполнение работы со стороны заказчика.

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

Как известно заказчик платит именно за время, потраченное на разработку проекта, или работает по fixed price (оговоренная сумма за конечный продукт). ТЗ на 99% процентов закрывает вопросы по оценке проекта (всегда известно что надо делать), всегда служит доказательством того что вы правы то что сделали — заказчик не упрекнет вас в том что вы что то не сделали или сделали не так — т.к. все что вы должно — описано в ТЗ. Да и в любой момент можно найти на возникающие вопросы — как где и что должно быть и работать на сайте.

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

Итак что же должно включать в себя техническое задание?! Вот мое примерное видение того что должно быть оговорено в ТЗ:
1. Наименование предприятия Заказчика Системы и его реквизиты — раздел, дающий общую информацию о предприятии. Контакты и т.д. Зачастую инмеенно отсюда вся информация попадает в раздел Контакты на сайте
2. Назначение проекта — описание функционального предназначения сайта. По функциям сайт может делиться на информационный сайт, портал, магазин, и т.д.
3. Задача проекта — кратко сочинение на тему того, для чего вообще создается сайт — для отмывания денег, для рекламы, для продвижения продукта.
4. Целевая аудитория проекта — несколько слов о том какого вы выидите конечного пользователя — возростная категория, социальный статус и даже цвет кожи могут играть роль
5. Требования к стилистическому и шрифтовому оформлению — всего скорей созрев до сайта у заказчика уже есть так называемый фирменный цвет. Было бы не плохо описать его здесь
6. Требования к графическому дизайну — здесь главное не увлекаться описанием и не начинать вольных сочинений на тему «красненькую точку надо разместить 33 пикселя от правой границы окна браузера…» Общих фраз типа легкий, изящный, тщательно проработаный детальный..
7. Требования к контенту и наполнению — структура сайта — далеко не сам сайт. Самое дорогое далеко не система управления, бизнес логика или дизайн — самое дорогое — тщательно проработаный контент. Опишите ваши требования, кто в каком виде предоставляет материалы
9. Структура сайта — один из ключевых разделов. Здесь описывается структура сайта, в виде разделов, их описаний и данных, которые будут представленны на этих страницах
10. Приложения к заданию — собственно говоря наша смета. Смета должна покрывать те пункты, которые описаны в задании. Если это пункт, говорязий что у нас на сайте будет авторизация и регистрация — значит в смете должен быть этот пункт.

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

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

Резюме: если вы заказчик — не соглашайтесь начинать работу и какие то отношения с исполнителем не получив от него письменного подтверждения того что получите в результате. Если же вы исполнитель — перестрахуйтесь от двойной, тройной (n-ной) работы и бесконечных переделок с того как я вижу на то как надо — составьте ТЗ и будет взаимное счастье.

Написал Валерий Хвалев

15 ноября, 2008 в 12:33 пп

Подпишись на обновления блога по e-mail или RSS!