Опубликовано

Продвигаем сайт статьями

Продвижение сайта статьями

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

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

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

Робот поисковой машины, «читая» такую статью, видит ссылки на продвигаемый сайт и повышает его оценку ссылочной популярности.

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

На этом данную публикацию можно было бы закончить. Однако, вот здесь то и наступает момент, когда нужно сказать главное. А главное состоит в том, что, ЕСЛИ ВЫ ДЕЙСТВИТЕЛЬНО СЕРЬЕЗНО ЗАНЯТЫ ПРОДВИЖЕНИЕМ САЙТА, ТО ПИСАТЬ ВЫ ДОЛЖНЫ НЕ ДЛЯ РОБОТОВ, А ДЛЯ ЛЮДЕЙ… ну, и – все-таки немного для роботов.

Что это значит? Вот несколько рекомендаций:

СТАТЬЯ ДОЛЖНА СОДЕРЖАТЬ ДЕЙСТВИТЕЛЬНО ПОЛЕЗНУЮ, ИНТЕРЕСНУЮ ЛЮДЯМ И ОРИГИНАЛЬНУЮ ИНФОРМАЦИЮ по какой либо теме. Но не прямую рекламу себя или своей компании. Соблюдение этого условия позволит вам разместить статью на разных сайтах, т.е. сделать ее более доступной и известной.

РАЗМЕЩАЙТЕ СТАТЬЮ НА ТЕМАТИЧЕСКИХ САЙТАХ И ПОРТАЛАХ, А ТАКЖЕ В КАТАЛОГАХ СТАТЕЙ (БИБЛИОТЕКАХ), которые предлагают авторам специальные сервисы публикации статей по одному или разным тематическим направлениям. В последнее время в рунете таких сайтов появилось достаточно много.

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

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

ПОМЕСТИТЕ В ТЕКСТЕ СТАТЬИ ПАРУ-ТРОЙКУ ССЫЛОК НА ВАШ САЙТ. Но делайте это аккуратно – ссылки должны быть уместны и вести именно на ту страницу вашего сайта, которая соответствует теме статьи. Не все каталоги статей разрешают делать ссылки по тексту. Но при этом всегда есть раздел «об авторе», «источник», или «примечание», в которых ссылки допустимы. Разместите свои ссылки в этих разделах.

ПИШИТЕ СТАТЬИ ОТ СВОЕГО ИМЕНИ ИЛИ ОТ ИМЕНИ НЕКОЕГО ВИРТУАЛЬНОГО ПЕРСОНАЖА ВАШЕГО САЙТА. В первом случае вы одновременно решаете задачу позиционирования себя как автора и эксперта в данной предметной области. Второй способ хорош тем, что позволяет организовать коллективную работу по написанию и размещению статей (например, менеджерами вашей компании). При этом вы позиционируете бренд — имя виртуального персонажа, который однозначно связан с вашим сайтом. Немаловажно также, что таким образом вы обеспечиваете себе (своему сайту) независимость от отдельного автора.

ЕСЛИ У ВАС УЖЕ ПОДГОТОВЛЕНО НЕСКОЛЬКО СТАТЕЙ – НЕ РАЗМЕЩАЙТЕ ИХ ВСЕ СРАЗУ. Лучше публиковать их по одной, выдерживая паузу в несколько дней или даже больше (в зависимости от интенсивности публикаций на данном сервере).

Опубликовано

Приемо-сдаточные испытания

Приемо-сдаточные испытания

Для того, чтобы сделать процесс сдачи проекта (этапа) более четким и однозначным, должны быть введены четкие приёмочные критерии, при выполнении которых заказчик обязан «принять» этап.

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

Изначально, на старте проекта, с заказчиком необходимо обговорить процесс сдачи каждого этапа и проекта в целом.

Таким образом, для каждого этапа набор работ будет следующим:

1. Составление перечня приемочных тестов

• QA анализирует требования к новому этапу.

• QA cоставляет список приемочных тестов для данного этапа. Лучше всего выделить эту группу в тест плане по версиям.

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

• QA утверждает список у PM-а.

2. Написание приемочных тестов

В отдельной тест кейс спецификации QA описывает запланированные на предыдущем шаге приемочные тесты.

3. Утверждение набора приемочных тестов

PM утверждает спецификацию приемочных тестов у заказчика.

4. Проведение приемо-сдаточных испытаний на стороне заказчика

При сдаче этапа (проекта) PM или QA на стороне заказчика демонстрирует успешное прохождение каждого утвержденного теста.

Опубликовано

Процесс сборки билдов и релиза

Процесс сборки билдов и релиза

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

В один момент времени может быть до 2х веток кода:

  • Основной branch – функционал, подлежащий сдаче в ближайшем деливери (текущем этапе).
  • Вторичный branch – функционал, подлежащий сдаче через деливери (следующем этапе).
  • 0й – разработка
  • 1й – тестирование, fix, разработка, сдача этапа (деливери)
  • 2й – тестирование, fix, разработка, сдача этапа (деливери)
  • 3й – тестирование, fix, сдача проекта (релиз).

Кратко процесс можно описать так:

  • 1. Для ближайшего деливери PM планирует объем необходимого функционала {Ф}.
  • 2. Реализуется весь заданный функционал {Ф} (о чем свидетельствует PM).
  • 3. Собирается билд для QA. QA приступает к тестированию функционала для ближайшего деливери {Ф}.
  • 4. PM планирует объем функционала {Ф} для следующего деливери.
  • 5. Разработчики приступают к разработке нового объема функционала {Ф}, параллельно исправляя дефекты, найденные в готовящемся деливери.
  • ! У дефектов приоритет всегда выше, чем у нового функционала!
  • 6. По мере исправления дефектов, имеющихся в готовящемся деливери, QA собирает промежуточные билды для тестирования.
  • 7. QA сигнализирует о том, что весь необходимый для деливери функционал реализован и дефекты отсутствуют. PM собирает деливери.
  • ! Деливери собирается и отправляется только после одобрения QA!
    • Деливери отправляется заказчику вместе с сопроводительной документацией.
  • 8. PM инициирует слияние двух веток.
  • 9. По мере реализации нового функционала для следующего деливери, QA собирает промежуточные билды для тестирования.
  • 10. Процесс повторяется до выпуска финальной версии.
Опубликовано

Контроль версии

Контроль версии

Каждая версия (сборка) должна идентифицироваться чётким образом. Легче всего применить следующий формат версии:

XX.YY.revision , где

Revision – номер внутренней сборки (Build number). Соответствует номеру последней ревизии в SVN, вошедшей в данную версию.

YY – номер поставки заказчику (Delivery number), обнуляется при увеличении XX.

XX – номер релиза (Release number).

1. Build для тестирования

Как правило, очередной build собирает QA. Версия равна XX.YY.revision.

2. Объединение веток (merging)

Ветки объединяет руководитель проекта или техлид. Версия равна XX.YY.revision.

3. Сборка Delivery

Деливери собирает также руководитель проекта или техлид.

Версия устанавливается вручную в XX.YY (ревизия отбрасывается, YY увеличивается).

Также, рекомендуется для каждого билда писать примечание к версии (Release notes), что облегчит работу как с заказчиком, так и QA инженерами.

Опубликовано

Как проверить сайт.

Как проверить сайт

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

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

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

Не стесняйтесь напоминать о себе исполнителю, чем чаще, тем лучше. Ведь о Вас могут попросту забыть.  А еще лучше требуйте посмотреть промежуточный результат.

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

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

Как известно, скупой платит дважды, в редких случаях трижды. Заложив в бюджет создания сайта работу по описанию требований и их тестированию от 20% до 30% стоимости всей разработки, позволит Вам избежать многих подводных камней на пути к успеху.

Опубликовано

Услуги от SEOLUX.

Услуги от SEOLUX представляют комплекс мероприятий предназначенных укрепить и развивать интернет бизнес клиентов.

Наши услуги:

  • Продвижение сайтов в Интернет.
  • Контекстная реклама.
  • Копирайтинг, рерайтинг.
  • Создание сайтов визиток, каталогов, интернет магазинов.
  • Выполнение QA (Quality Assurance) процедуры наших проектов и аудит внешних проектов.
  • Выполнение системного и бизнес анализа ИТ проектов и бизнес процессов компаний.

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

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