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

Каждый веб-сайт уникален. Именно поэтому «в природе» существует огромное число систем управления сайтом (CMS). Как же выбрать ту единственную?… Эта статья дает ответы на самые распространенные вопросы, которые возникают в процессе выбора CMS.

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

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

Например, увольнение веб-мастера, которое на сегодняшнем рынке труда неизбежно происходит раз в 1,5-3 года. Или расширение ассортимента фирмы, и, следовательно, рост штата людей, которые должны наполнять сайт. Легко ли будет найти и нанять новых специалистов? Какой подготовкой они должны обладать? Потребуются ли им платные обучающие курсы? Затраты на контент-менеджера в Москве с учетом налогов и офисных расходов – около 50-70 тыс. рублей. Если CMS за счет простого интерфейса позволит нанять на одного менеджера меньше – это уже 600-840 тысяч рублей экономии в год.

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

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

Полет не по приборам: почему сложно подобрать CMS

Сделать правильный выбор совсем не легко. Во-первых, на рынке представлено множество различных систем управления, только в каталоге CMS Magazine их зарегистрировано более 350. Во-вторых, нет четкого способа заранее сравнить эффективность систем. Чтобы составить  полноценное представление о платформе, специалист должен выполнить на ней хотя бы один-два проекта.

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

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

Классификация CMS
Предупрежден — значит вооружен. Подкованный в вопросах CMS владелец сайта с легкостью сузит поле для поиска с десятков систем до 2-3. Теоретическую подготовку следует начать с классификации платформ.

По виду лицензии CMS разделяются на коммерческие и свободно распространяемые. Коммерческие были созданы предпринимателями для извлечения прибыли от продажи и/или технической поддержки,  а свободно распространяемые (СР, Open Source) — это, как правило, плоды труда энтузиастов, ставшие «общим» достоянием благодаря открытому коду и сообществу профессионалов, которые время от времени этот код совершенствуют. Преимущество коммерческих CMS в гарантиях — всегда есть разработчик, к которому можно обратиться или предъявить претензии. Свободно распространяемые системы отличаются тем, что их ядро бесплатно (но не стоит забывать про затраты на поддержку).

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

Наиболее популярные в России СР системы — Drupal, Joomla, MODx, WordPress. Из коммерческих выделяются 1С-Битрикс, NetCat, UMI.CMS, Host.CMS, Amiro.CMS, ABO.CMS и S.Builder.

По отчуждаемости выделяют три типа CMS. «Коробочные решения» — готовые платформы, которые использует широкий круг веб-разработчиков. «Студийные» или «индивидуальные» системы никем, кроме компании-владельца, не используются. Software-as-a-Service решения (SaaS) — это  онлайн-конструкторы сайтов, такие как UcoZ. Главное отличие трех категорий — в степени зависимости заказчика сайта от владельца системы. Если пути разработчика студийной CMS и его клиента в какой-то момент разойдутся, клиенту, скорее всего, придется менять движок, так как другая компания не возьмется за поддержку сайта на чужой и непонятной системе. В случае с SaaS зависимость от разработчика еще выше, так как речь идет даже не о покупке лицензии, а ее аренде, зато сайт в конструкторе можно сделать очень быстро и совсем небольшими ресурсами. «Коробки» дают владельцу сайта независимость, он может сменить подрядчика по обслуживанию сайта и поэтому в переговорах чаще диктует условия. Как правило создание сайтов производится на «коробочных» CMS.

Классификация по типам проектов не жесткая, так как не все системы, которые позиционируются как универсальные, на самом деле обладают достаточно широким функционалом. Круг универсалов узок, в него входят 1С-Битрикс, NetCat, Drupal, Joomla и, пожалуй, пара других. Остальные системы уступают по инструментарию, и, чаще всего, позволяют решать на высоком качественном уровне всего 1-2 задачи. Впрочем, некоторые CMS настолько укоренилась в узкой нише, что уже могут считаться специализированными. Например, PHPShop считается отличной CMS для интернет-магазинов, DJEM известна как инструмент создания порталов, LiveStreet — социальных сетей, а WordPress популярен среди блоггеров.

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

Быстрый выбор платформы

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

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

Второй, WebIndicator, отслеживает количество действующих установок систем (данные предоставляются компанией iTrack).

Впрочем, не стоит забывать и о студийных CMS. Развитые платформы как минимум не уступают коробкам по удобству интерфейса и функционалу, некоторые обладают уникальными «фичами».

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

Проконтролировать лично

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

Подбор CMS для нестандартного сайта
На что обратить внимание при выборе CMS для нетипового проекта? Без твердой опоры на статистику легко промахнуться мимо цели. Тем не менее, некоторые ориентиры помогают избежать решений, о которых впоследствии придется жалеть. Вот чеклист признаков надежной системы управления сайтом от CMS Magazine и партнеров:

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

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

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

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

Автор: Анатолий Денисов, главный редактор CMS Magazine.

1. тайны, которые веб-разработчики всегда скрывают от заказчиков,
2. каким должен быть продающий сайт,
3. как не ошибиться при выборе компании по разработке сайта,
4. как сэкономить 1000$ на создании сайта,
5. как избавиться от рисков при ведении бизнеса в Интернете,
6. как найти надежных партнеров по бизнесу в Интернете.

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

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

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

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

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

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

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

Первый шаг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

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

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

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

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

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

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

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

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

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

..Навеянно размышлениями о жизни…

Опробовав не одно CMS решение я задумался — какое же оно должно быть то..именно то, что доставляло бы радость при создании новых проектов. Будучи реалистом по жизни я не пытаюсь найти решение которое бы управлялось силой мысли, и могло бы построить то что хочет заказчик исключиельно словами «Трах-тибидох-тибидох…». Читать далее »