Crisis-Care.ru

Crisis-Care.ru

     
     
     

(495)755-2005

Схемы работы

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

  • Какова целевая аудитория сайта?
  • Какое планируется количество посетителей?
  • Каковы планы дальнейшего развития?
  • В каком состоянии находится фирменный стиль вашей компании?

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

Количество посетителей определяет, как будет работать сайт, не откажут ли серверы и каналы связи при появлении 100000 посетителей одновременно. Предусмотреть это заранее и сделать программную и аппаратную конфигурацию, устойчивую к атакам и высоким нагрузкам - целесообразно только если такая нагрузка действительно планируется в сколько-то обозримой перспективе, иначе затраты будут несоразмерны результату.
Если в планы развития включено развитие онлайн-продаж, то стоит заранее предусмотреть поддержку соответствующих модулей системой управления, чтобы потом не переделывать все. На начальном этапе разница между установкой и настройкой,  например Smallnuke (легкая CMS) и Joomla (многофункциональная CMS) невелика.
Сайт может быть сам по себе сколь угодно красив, но если он не соответствует фирменному стилю или этого самого стиля вообще не существует в природе, за исключением нарисованного (уже никто не помнит, кем) логотипа и кучи разномастных визиток, то эффективность сайта в плане продвижения имиджа компании будет крайне низкой.
Подводя итого под этими вопросами и ответами, мы приходим к выводу, что решение вопросов, связанных с созданием сайта, лучше доверить специалисту. Но ситуацию, тем не менее, необходимо держать под контролем, тем более, что интернет-сообщество полнится возмущением заказчиков, которым сделали не то, что заказывали, дороже, чем обещали, а то и вовсе не сделали ничего.
Как же контролировать процесс, будучи специалистами в совершенно другой области?
Существует ряд типовых моделей работы с программными проектами.
Каскадная (линейная) модель. Наиболее простая для реализации, но не самая удачная в случае создания сайта или другого программного продукта. Здесь весь процесс разбивается на последовательность простых шагов, каждый из которых изначально описан и может быть проверен и утвержден. Например, так:

  • дизайн внешнего вида (макет в виде графического изображения)
  • установка CMS
  • создание шаблона на основе утвержденного дизайна
  • установка модулей
  • создание пользователей
  • настройка прав доступа

Все очень просто описывается и каждый элемент более или менее понятен принимающему работу заказчику. Сначала пообщались, посидели, порисовали и утвердили дизайн. Потом программисты и веб-мастера что-то сделали, и появилась такая же картинка, но в окне браузера и почти "живая", только не все кнопочки работают. Сверили с первой картинкой, утвердили и пошли дальше...
Но у такой модели есть и ряд недостатков. Во-первых, работа над проектом движется медленно из-за того, что администратор не может заниматься конфигурированием системы управления, пока не создан дизайн. Ведь еще непонятно, как будут работать модули, где и что будет отображаться. Во-вторых, ни заказчик, ни разработчик, приступая к выполнению работы, не знают, каким именно должен быть конечный продукт. Заказчик - потому что он прекрасно разбирается в своем бизнесе, но мало что знает про архитектуру и особенности сайтов. Разработчик - потому что он знает все про html, php, sql, js, css и много других страшных слов, но в бизнесе заказчика принимал участие разве что в роли покупателя.
Итерационная модель. Все то же самое, но изначально оговаривается возможность в случае обнаружения существенных несоответствий вернуться на любой из предыдущих этапов. Эта модель более гибкая, поскольку появляется возможность пересмотреть, например, эскиз дизайна, если окажется, что он плохо смотрится с установленными и работающими модулями. Тем не менее, такой модели свойственны и недостатки линейной модели.
Модель быстрой разработки (RAD). Здесь процесс создания продукта осуществляется с максимальным акцентом на собственно процесс разработки и выполнением подготовительных работ по планированию и завершающих по тестированию приёмке в минимальном объёме. Такая модель прекрасно подходит для работы команды разработчиков высокого уровня при создании типовых продуктов, не учитывающих уникальные особенности конкретного заказчика.
Структурная эволюционная модель (быстрого прототипирования). При работе с использованием этой модели, в процесс создания конечного продукта вовлекаются и сами заказчики. Сначала проводится первоначальная подготовка и постановка задачи в обобщенном виде.  После этого начинается быстрое создание продукта в грубом приближении - установка сисетмы управления, подключение модулей и шаблонов без тонкой настройки и проработки деталей. Заказчик оценивает общее направление развития проекта и указывает, какие необходимо внести изменения, каким деталям уделить более пристальное внимание. После этого создается следующий прототип, более близкий к завершенному продукту. Заказчик вновь изучает результат и вносит коррективы. Этот процесс продолжается до тех пор, пока продукт не будет уточнён в достаточной степени (Конфликт интересов - разработчику чем проще, тем лучше, а заказчику - чем детальнее, тем лучше. К общему знаменателю их приводят сроки, ведь неработающий сайт не приносит прибыли.), чтобы его можно было использовать. После этого переходят к осуществлению однозначно определенных работ - установке на серверы заказчика, передаче прав управления, подготовке пакета документации, приемке и т.д.

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