Что такое пресс-релиз? Пресс-релиз, образец. Пресс-релиз, как писать. Релизы что это


Что такое релизы в 1С?

В наше время программы 1С (бухгалтерия, ЗУП, УТ, КА) – это своеобразный стандарт для ведения управленческого, бухгалтерского и прочих видов учета. Это программное обеспечение устанавливается на всех предприятиях, которые переходят на полную автоматизацию учета. Работодатели требуют знание и навыки работы именно с этой программой. Если возникают вопросы, связанные с системой автоматизации (стоимость, остатки и проч.), как правило, сотрудники предприятия прибегают к помощи базы данных 1С.

Сегодня достаточно часто пользователи сталкиваются с вопросами о том, что такое программные продукты компании «1С» (1С: Предприятие, 1С: ЗУП и т.д.), их структура, а также принципы работы. Кроме того, всем интересно, какую версию обновления нужно установить, чтобы учет на предприятии велся в соответствии с законодательством.

Начнем по порядку.

Платформа

Любая версия программного продукта «1С: Предприятие» (ЗУП, бухгалтерия и др.) имеет такую структуру:

  • Платформа;
  • Конфигурация.

Технологической платформой называется «движок» программы. Именно он создает интерфейс user, обеспечивает ввод, хранение, а также предоставление данных. Платформа дает возможность разрабатывать обновления для программы 1С: Предприятие (ЗУП, УТ и проч.) и осуществлять ранее разработанные операции на рабочем месте. На сегодняшний день существует несколько функционирующих платформ, таких как 7.7 ,8.0.,8.1, 8.2, 8.3, к тому же планируется выход последней платформы 8.4.Работать можно на любой редакции платформы. Выбор зависит от руководства предприятия. Но самой актуальной для user считается версия 8.3.

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

Конфигурация

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

Различают два вида:

  • Типовые. Эти конфигурации создаются разработчиками компании 1С и все их можно найти на официальном сайте компании. Как правило, эти конфигурации более качественные. В них используются только оптимальные решения поставленных задач, быстро исправляются возникающие в процессе работы ошибки;
  • Нетиповые. Этот вид обычно создают компании-партнеры. Нетиповые конфигурации могут быть разработанными для конкретной отрасли с учетом ее особенностей (отраслевые) либо для какой-то определенной фирмы. Выбирая нетиповые конфигурации, требуется понимать, что обычно у фирм-партнеров 1С большая текучка кадров. Именно по этой причине одна конфигурация может быть написана несколькими разными разработчиками. Отсюда и нестабильность работы, зависание программы и проч.

На данный момент существует множество конфигураций:

  • ЗУП;
  • БП;
  • КА;
  • УТ и т. д.

Каждая конкретная конфигурация имеет свой релиз и свою редакцию. Например:

  • Конфигурация ЗУП 2.5 будет работать под платформой, которая имеет редакцию 8.2 и выше;
  • Конфигурация ЗУП 3.0 будет работать под платформой, которая имеет редакцию 8.3 и выше.

При этом каждый конкретный релиз «1С: ЗУП» будет нормально работать только с определенным релизом данной платформы.

Конфигурацию приходиться обновлять для соблюдения законодательства при сдаче отчетности и ведению учета.

Релизы

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

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

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

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

Если проводить аналогию между «1С: Предприятие» (1С:ЗУП, 1С:УТ и др.) и прочими системами, то все программные продукты компании 1С можно сравнить с любой операционкой, установленной на вашем компьютере (это вариант платформы) и различными программами, которыми вы пользуетесь Office, Total Commander, Skype, AdobeReader (это варианты конфигурации).

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

  • Скобки вверху (8.2.13.219) говорит о том, какая редакция программного продукта 1С: Бухгалтерия 8 и платформы была установлена для работы;
  • Скобки внизу (2.0.23.9) показывает: 2.0 – версию конфигурации, 23.9 – где, 23 – это текущий релиз, а 9 – номер сборки.

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

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

blog.it-terminal.ru

Ежедневные релизы — это не так уж страшно / Блог компании DataArt / Хабр

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

Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).

Что такое Continuous delivery и Сontinuous integration?

Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.

Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними. Как работает непрерывная интеграция?

Разработчики выкачивают исходный код из репозитория, делают какие-либо изменения, а затем отправляют свои изменения обратно в репозиторий. После чего автоматически проходит сборка проекта, прогоняются тесты и отсылается отчет, что в измененном коде всё хорошо, и он сохранен.

А здесь детально показано, что происходит на этапе тестирования после сохранения измененного кода:

Первое, что прогоняется, — jar-файлы, затем параллельно:

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

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

Вот так построен процесс непрерывной поставки. Стоит еще сказать, что практику непрерывной поставки (continuous delivery) не нужно путать с практикой непрерывного развертывания (continuous deployment). Разница в том, что при непрерывной поставке на определенном этапе присутствует ручное тестирование, а непрерывное развертывание выполняется полностью автоматически:

Здесь я рассказываю именно о непрерывной поставке — далее поясню, в чем суть ручного вмешательства в тестирование.

Гибкая методология разработки

В проекте мы используем гибкую методологию разработки — Agile. Гибкая методология предполагает разработку ПО циклами. Каждый цикл представляет собой уменьшенный вариант IТ-проекта: анализ требований, планирование, разработка, сборка, тестирование, развертывание. По окончанию итерации заказчик получает готовую версию IТ-системы, и, если требуется, — дальнейшие приоритеты проекта пересматриваются. Затем цикл разработки запускается снова. В итоге создается решение, которое соответствует требованиям заказчика.

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

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

Процесс разработки нового функционала:

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

Процесс релиза

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

Итак, после того, как флаг включен, и наш функционал доступен на тестовом окружении, прогоняются приемочные тесты. Процесс прогона приемочных тестов повторяется каждую ночь, вне зависимости от того, релизим мы новый функционал или исправленные баги. Набор тестов за ночь прогоняется дважды, чтобы минимизировать случайные падения. Эти приемочные тесты покрывают все высокоприоритетные случаи. Когда QA-команда приходит утром, то просматривает отчеты о ночном тестировании, и бывает так, что всё прошло не гладко: 1 – 2 % тестов упали или были не пройдены. Дабы убедиться, что это были всего лишь случайные падения или, наоборот, что автоматизированые тест-кейсы выявили ошибку, QA-команда перепроходит эти тестовые случаи вручную.

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

После одобрения заказчиком, наше приложение разворачивается на промежуточном окружении, которое очень схоже с продовским, — и тут проводится приёмочное тестирование. Оно проводится и QA-командой, так и Selenium-тестами — ручное и автоматизирование тестирование происходит параллельно. Если всё прошло хорошо, мы сообщаем об этом заказчику и выпускаем нашу версию в продакшн, где проводится smoke-тестирование. Это идеальный вариант развития событий.

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

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

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

В целом процесс релиза выглядит следующим образом:

  • Просмотр отчета прохождения автоматических приемочных тестов на тестовом окружении.
  • Запуск упавших и пропущенных тестов вручную.
  • Приёмочное тестирование в промежуточном окружении, который наиболее схож с продовским.
  • Smoke-тестирование на продовском окружении.

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

Роль и обязанности QA-инженера

У вас может сложиться впечатление, что у нас всё так заавтоматизировано, что QA-инженеру больше нечего делать. Но на самом деле, работы достаточно.

  • Во-первых, выяснение и анализ требования. Этим занимаются QA-инженеры – ведь, когда менеджер проекта составляет требования, зачастую упускается очень многое.
  • Во-вторых, оценивание затраты времени на работу с проектом. Когда менеджер проекта спрашивает, сколько нужно времени на написание тестовых случаев, функциональное тестирование и т. п., нужно всё это подсчитать.
  • В-третьих, работа с тестовой документацией, написание тест-кейсов, составление чек-листов и баг репортов.
  • В-четвертых, в нашем проекте проводится функциональное, регрессионное и кросс-браузерное тестирование (т. к. у нас — веб-приложение, и в каждом браузере — свои ошибки).
  • В-пятых, QA-инженеры занимаются поддержкой релиза: каждое утро перепрохождение упавших ночных тестов, а также acceptance- и smoke-тестирование. Но это не значит, что вся команда занята релизом. Релизом заняты люди, у которых меньше приоритетных заданий — наша команда самоорганизующаяся.

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

Также стоит рассказать, чем именно занимаются автоматизаторы в нашем проекте.

Роль и обязанности автоматизатора:

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

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

1. Процесс релиза и разворачивания должен быть повторяемым и надежным. Однажды запущенный процесс останавливать больше нельзя — даже если вы ничего нового не выпускаете. 2. Автоматизированные тесты должны покрывать 80 – 90 % функционала — без этого процесс не пойдет. 3. Нужно часто проходить тестами по уязвимым местам. Если вы видите, что в каком-то месте у вас часто падают тесты или много ошибок, это место нужно тестировать почаще и убеждаться, что наступают улучшения и что-то исправляется. 4. Качество нужно строить сразу. Это относится не только к разработчикам, но и к тестировщикам. Бывает, что QA-инженеры проверяют баг-репорты на локальных машинах разработчиков, чтобы не допускать попадания не исправленных багов в общей репозиторий. Тогда разработчик исправляет ошибку у себя локально, это гораздо дешевле и быстрее. 5. Каждый несет ответственность за релиз. Благодаря этому, у нас хорошо налажена коммуникация. Если у QA-инженеров, возникают вопросы, мы можем спокойно написать разработчику, и разработчик тоже может нас о чем-то просить.

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

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

habr.com

Что такое пресс-релиз, и как это работает для продвижения

Тематический трафик – альтернативный подход в продвижении бизнеса

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

Пресс-релиз (press release) – это новость небольшого объема около двух тысяч знаков, содержащая информацию о каком-либо событии, достижении или мероприятии в компании.

 

Больше видео на нашем канале - изучайте интернет-маркетинг с SEMANTICA

Как выглядит пресс-релиз

Для такой новости существует определенная стандартная структура, а сам текст, привязанный к информационному поводу, строится по шаблону. Чтобы представить ее наглядно, вообразите перевернутый треугольник. Так строится изложение – от главного и крупного постепенно переходят к мелким деталям. Шаблон выглядит примерно так:

  • Дата, в которую был опубликован пресс-релиз.
  • Контактная информация о компании.
  • Заголовок.
  • Небольшой анонс из одного-двух предложений, в котором заключается главная мысль материала.
  • Текст новости.
  • Информация о фирме: сведения, ссылки по тематике новости и т.п.

В чем польза пресс-релизов для продвижения

Если вы продвигаетесь пресс-релизами, с большой долей вероятности поисковые боты быстро отреагируют на вашу новость и проиндексируют ее. Сайты, которые размещают подобные материалы, пользуются доверием со стороны поисковиков, имеют высокие показатели тИЦ, PR и большое количество посетителей. Поэтому боты Яндекса и Google часто заходят на такие ресурсы и быстро индексируют материалы на них.

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

Преимущества продвижения пресс-релизами:

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

Помимо положительных сторон, у продвижения пресс-релизами есть и определенные недостатки, а именно:

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

Подробнее о продвижении пресс-релизами написано в этой статье.

Каким сайтам выгодно продвигаться пресс-релизами

Так как пресс-релиз строится на основе информационного поводы, логично, что продвигать ими можно те ресурсы, которые могут эти поводы предоставить. Подходящие инфоповоды – это:

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

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

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

  • Туристические фирмы и агентства.
  • Корпоративные сайты крупных фирм.
  • Популярные интернет-магазины.
  • Веб-студии.

Press Release: как подготовить и где разместить

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

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

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

Разместить пресс-релиз можно на уже упомянутом Subscribe.ru. Дадим еще несколько ресурсов:

semantica.in

Процесс «Управление релизами» — для постпроектной поддержки или развития продукта

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

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

В данной статье кратко раскрываются следующие темы:

  • применимость процесса — когда имеет смысл его внедрять
  • основные этапы процесса, активности, вовлеченные ресурсы и результаты
  • планирование релизов: календарь, объем, параллельное выполнение
  • некоторые проблемы доставки в релизах

Применимость процесса

Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:
  • Начальный период постпроектной поддержки: значительное количество изменений, проблемы с приоритизацией, необходимость эффектично упрявлять ожиданиями заказчика
  • Процесс поддержки продукта: необходимость организовать процесс, оптимизирующий использование всех доступных ресурсов в рамках существующего бюджета.
  • Большой процент запросов на изменения затрагивают пересекающиеся предметные области или приводят к техническим зависимостям — необходимо явно группировать изменения с целью оптимизации работ по разработке или тестированию.
  • Процесс непосредственной доставки разработанных изменений продукта на продуктив — “дорогой”, с любой точки зрения: от координации, до непосредственных расходов на распространение изменений.
Кроме того, при определенных условиях планирования и организации этапов релизов — весь процесс доставки можно максимально приблизить к методике Scrum (регулярная поставка изменений, с наивысшей ценностью для заказчика), таким образом постепенно переходя к использованию гибких подходов в организациях, не очень к этому предрасположенных.

Этапы процесса

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

1. Draft
Активности: Подбор запросов на изменения и инцидентов в список того, что планируется делать, проводится начальная приоритезация, анализ взаимозависимостей и предварительная оценка трудозатрат на анализ и разработку.

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

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

Ресурсы:

  • Аналитики (ведущий аналитик)
  • Заказчики
  • Менеджер релиза
2. Scope
Активности: Проводится детальный анализ и оценка, подготовка спецификаций по изменениям, отобранным на основании приоритетов заказчика Отобранные требования полностью проанализированы и утверждены заказчиком, технические спецификации проработаны, детальная оценка трудозатрат проведена.

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

Ресурсы:

  • Аналитики
  • Заказчики
  • Разработчики (Тех лид)
3. Approval
Активности: Получение подтверждение ресурсов от исполнителей (для разработки) и заказчиков (дляд тестирования). Оценка общего бюджета релиза (если применимо). Финальное согласование с заказчиком содержания релиза, исходя из готовности отдельных запросов, приоритетов, оценённого бюджета, доступных ресурсов.

Результат: Сформировано финальное содержание релиза.

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

Ресурсы:

  • Заказчики
  • Менеджер релиза
4. Work in progress
Активности: Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.

Результат: Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.

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

Ресурсы:

  • Разработчики
  • Аналитики
5. Testing
Активности: Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)

Результат: Содержимое релиза протестировано, принято заказчиком, и готово к распространению.

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

Ресурсы:

  • Заказчики
  • Аналитики
  • Разработчики
6. Deployment
Активности: Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.

Результат: Изменения перенесены в продуктивную среду и доступны заказчику

Ресурсы:

  • Служба эксплуатации
7. Closure
Активности: Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.

Результат: Формальное завершение работ. Улучшения процесса.

Ресурсы:

  • Менеджер релиза

Планирование релизов

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

  1. Если, внедряя релизы, вы планируете также обеспечивать регулярность выхода новых версий — то, скорее всего, и длительность этапов должны быть зафиксированы на некоторых оптимальных значениях.
  2. Если же релизы будут использоваться только как группировка отдельных запросов на изменение, а общая длительность релиза должна быть оценена исходя из объемы работ и ресурсов — оценка длительности этапов ничем принципиально не отличается от планирования любого проекта.
Планирование релизов с фиксированной длительностью
Это планирование проводится в самом начале внедрения процесса, и относится к процессу, как таковому — а не к отдельным релизам, поскольку длительность отдельного релиза меняться не будет.

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

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

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

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

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

Относительно сроков доставки, релизы, планируемые от объемов, также не предлагают заказчику большую определенность по сравнению с проектным подходом:

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

В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.

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

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

  • примерное соотношение между ресурсами аналитиков и разработчиков при работе на одну задачу. Например, «если аналитик потратил на требования 5 человеко*дней, то затраты на разработку и тестирование составят примерно 10 человеко*дней».
  • аналогично — соотношение между анализом требований, и длительностью приемочных испытаний
  • состав команды: количество аналитиков, разработчиков, тестировщиков.
Имея информацию о соотношении затрат и составе команды — можно определить соотношение времен этапов. Хорошей базой для фиксации конечных длительностей может служить фаза разработки (поскольку как раз оценка затрат на разработку является наиболее методологически проработанной) — от нее будут считаться длительности всех остальных этапов.

Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.

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

В любом случае — используйте инструменты, предназначенные для календарного планирования (как, например MS Project). Особенно это важно при создании календаря с пересекающимися во времени релизами, поскольку нужно будет тщательно контролировать загрузку ресурсов.

Одновременное выполнение нескольких релизов
Как видно из описания этапов релиза, на каждом из этапов вовлечены разные ресурсы и профиль загрузки — не однородный:
  • Аналитики — максимально загружены на этапе Scope и Test, менее загружены на этапах Draft и Work in progress. Во время Work in progress аналитики часто вовлечены в работу с Разработчиками, в случае необходимости поясняя требования.
  • Разработчики — максимально загружены в период Work in progress. В зависимости от реализации процесса, на этом этапе ведётся работа по запросам на изменения, вошедшим в утвержденное содержание релиза. При этом в остальное время могут заниматься исправлением дефектов, рефакторингом кода, и прочими полезными делами.
  • Заказчики — вовлечены в период сбора требований (Scope) и приемочного тестирования (Testing). В остальные периоды — вовлечение заказчика незначительное.
Таким образом, ожидаемым шагом по оптимизации загрузки ресурсов — параллельное выполнение двух (или более) релизов, спланированных так, чтобы ресурсы постоянно переключались между одинаковыми этапами последующих проектов. То есть, например, аналитик, завершив стадию анализа для релиза R1, переключался на стадию анализа релиза R2. Аналогично — для разработчиков и заказчиков.

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

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

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

Таким образом, первая оценка содержимого релиза может быть дана в терминах «количество заявок на аналитика в релиз». Наиболее пессимистичная оценка «1 заявка на изменение на аналитика в релиз» — с нее и стоит начинать. После того, как статистика по «производительности» аналитиков набрана — оценка содержимого станет более точной.

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

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

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

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

Фиксация содержимого проекта
Оценка затрат на разработку, доступные ресурсы Разработчиков, доступность Заказчика для участия в приемочном тестировании — все это определяет финальное содержание релиза.

Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.

Известные проблемы

Поделюсь некоторыми наблюдениями о проблемах, сопровождающих процесс релизов. Разумеется, в другой организации, скорее всего, проблемы будут свои и бороться с ними прийдется самостоятельно. Но по крайней мере — какие-то общие моменты необходимо иметь ввиду.
Переключение контекста при параллельных релизах
При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:
  • Аналитик закончил анализ (стадия «Scope») для релиза R1 и переключился на сбор анализ для следующего релиза R2. Ему прийдется переключится обратно в контекст релиза R1 для поддержки приемочного тестирования.
  • Аналогичный шаблон переключений — у Заказчика, особенно, если его запросы на изменения идут в последующих релизах.
  • У разработчиков переключение контекста выражено меньше — только в случае если нужно переключаться между новой разработкой и старыми дефектами.
«Переключение контекста — это плохо». Действительно, это приводит к снижению эффективности, потере фокуса на задаче, и может привести к задержках на ключевых этапах процесса.

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

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

Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.

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

В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.

Реализация «больших» задач
Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.

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

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

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

Устранение дефектов в контексте релизов
Обработка инцидентов и устранение дефектов, очевидно, занимают ресурсы команды (в большей мере — Разработчиков, но иногда и Аналитиков). Кроме того, нередко устранение некритических дефектов, имеющих известные способы обхода (workarounds) могут иметь меньшую ценность для бизнеса, по сравнению с требуемыми изменениями. Отсюда — очевидное желание рассматривать задачи устранения дефектов (или предоставления дополнительных сервисов) в общем контексте планирования содержания релиза — делать то, что важно.

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

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

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

Заключение

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

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

habr.com

Что такое пресс-релиз? Пресс-релиз, образец. Пресс-релиз, как писать

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

Общая информация

В сообщении, как правило, излагается официальная позиция организации в форме реакции на какой-либо информационный повод. Государственные органы управления выпускают иногда пресс-релизы в виде ответов на вопросы. Первое сообщение в истории было выпущено в 1906-м году, 30-го октября. Его автором был отец современного PR Айви Ли. Информация в нем была связана с трагедией, произошедшей на железной дороге в Пенсильвании. Определение, что такое пресс-релиз, становится более понятным при рассмотрении его целей. В первую очередь необходимо сказать, что это главный PR-документ в организации. Именно благодаря ему журналисты получают самую актуальную, важную и интересную информацию о событиях, произошедших в той или иной сфере. Однако пресс-релиз для СМИ не всегда может быть интересен. Журналисты обращают внимание на действительно важные, по их мнению, события. Те или иные происшествия могут быть далее распространены среди определенной целевой аудитории или широкой общественности. пресс релиз образец

Требования для материала

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

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

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

Отличительные черты

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

Виды пресс-релизов

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

Структура сообщения. Заголовок и первый абзац

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

Как писать резюме?

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

Содержание

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

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

Другими словами, следует придерживаться правила "что, когда, где, сколько и кому". По сути дела, ответы на эти вопросы составляют все содержание сообщения. Разумеется, необходимо правильно указать названия организаций, мероприятий, место и дату проведения, фамилии участников или заинтересованных лиц и прочее. Желательный объем основной части – около половины страницы листа А4. Приблизительно это полторы тысячи знаков. Однако в зависимости от темы объем сообщения может быть различным.

Контактные реквизиты

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

Заключение

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

Пример

Составляя заметку, не следует злоупотреблять рекламой предприятия. Ведь что такое пресс-релиз? Это сообщение, которое должно заинтересовать. Обилие рекламы в нем может сказаться на имидже организации не лучшим образом. В качестве удачного примера составления пресс-релиза можно привести заметки компании "Майкрософт". Ее пресс-релизы в заключительной части всегда содержат краткие сведения о фирме. Здесь же иногда указывается информация об услугах, товарах. К примеру, может проводиться какая-либо акция с определенным программным продуктом. В основной части релиза о нем упоминается вскользь, а в заключительной – как бы вне текста – напоминается коротко о том, что, собственно, собой представляет продукт. Если в сообщении упоминается несколько, например две-три, компаний, заключивших соглашение о взаимодействии, то желательно дать краткую информацию обо всех.

fb.ru

Пресс – релизы, что это?

6 июля 2013 Комментарии отключены

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

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

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

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

Loading ... Loading ...

Рекомендую прочесть

antonblog.ru

Структура современной пиратской (варезной) сцены / Хабр

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

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

Релиз-группы
Релиз-группы — ядро сцены, это люди, которые делают релизы. Состав и количество участников может быть очень разным, в зависимости от того, что именно релизит группа — фильмы, музыку, игры или программы. Например, mp3-группа может легко состоять всего из 1 человека, а в крупной группе, выпускающей софт, может быть несколько десятков человек. У группы обычно имеется свой сервер (dump), на котором они хранят рабочие файлы. На сцене действуют строгие стандарты, или правила, по которым делаются все релизы. Правила меняются редко, обычно это делается собранием совета нескольких топ-групп.

Материал для релизов группа берёт у поставщика (supplier), который может являться участником группы, либо нет. В последнем случае после передачи на сцену поставщик может продать материал (например, снятый в кинотеатре фильм) коммерческим пиратам.

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

Если группа выпускает релиз, который уже был выпущен другой группой, это дубль (dupe). Тогда релиз нюкают (nuke). Это означает, что его помечают как «плохой» релиз. Группы пытаются этого избежать, так как это создаёт им плохую репутацию. Кроме дубля, релиз может быть нюкнут и по другим причинам. Существуют два типа нюков: глобальные и локальные.

Глобальные зависят от самого релиза, то есть с релизом что-то не так. Например: ошибки, дубль, дёргание или застревание картинки, интерлейс, неправильное соотношение сторон кадра, неправильное преобразование телекинопоследовательности или частоты кадров, дефекты звука, кривой рип и т.д. Если группа сама обнаруживает ошибку, они могут запросить нюк.

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

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

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

Безопасность для топсайтов очень важна, они сильно засекречены. Типичный сайт конфигурируется так, что на него могут заходить только пользователи с определённым ident и host (или проверяется диапазон ip), с шифрованием SSL всех сессий. Для скрытия реального IP адреса топсайта используются FTP баунсеры. Большинство пользователей подключаются через прокси. Таким образом на сайте тоже не видно их реального адреса.

Сайты имеют быстрое подключение к сети и большой объем дискового пространства. Часто они находятся в школах, университетах, у людей на работе, или в датацентрах. Некоторые страны предпочтительнее: Нидерланды и Германия — там быстрый интернет и это в центре Европы. В Швеции тоже хорошая скорость, к тому же там это очень дёшево. Такие сайты называют легальными, в том смысле, что владелец компьютера знает, что на нём располагается сайт, в отличие от pubstro (см.ниже). Если у вас быстрый интернет и вы согласны держать сайт, найдутся люди, которые будут рады купить и отправить вам компьютер для сайта, при этом они не будут получать от него никакой коммерческой выгоды. Владельцы же сайтов иногда продают доступ за деньги, но это нечастое явление. На сайте устанавливается FTPD и бот, который будет объявлять на IRC канале, когда на сайте создаётся директория и когда завершается закачка релиза. Также он сообщает информацию о «гонке» — курьеры пытаются как можно быстрее перелить релиз на другие сайты. Так они зарабатывают рейтинг.

Все, кто есть на сайте, зарегистрированы на IRC канале сайта. Чаще всего они располагаются на частных и очень защищённых серверах, подключение идёт через SSL. Есть и другие меры безопасности. На канал нельзя просто так зайти, надо себя пригласить с помощью специальной команды, в то время как вы находитесь на сайте. Таким образом те, кого нет на сайте, не смогут зайти на канал. Либо используется пароль. Часто каналы защищены плагином для IRC шифрования FiSH. Для того чтобы читать сообщения, нужен будет соответствующий fish ключ. На IRC канале операторы сайта и участники могут общаться между собой. На этом же канале присутствует бот, объявляющий о релизах. На большинстве сайтов есть отдельный канал для объявлений.

Все люди, присутствующие на сайтах, делятся на сайтопов, курьеров и аффилиатов.

Сайтопы (операторы сайтов) это администраторы. Обычно на сайте от 2 до 5 сайтопов. Один из них часто владелец сайта, другой тот, кто его нашёл и помог установить. Остальные — их друзья и люди со сцены. Один из них или несколько — нюкеры. Их работа заключается в удалении фейков и дублей.

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

Аффилиаты — это представители релиз-групп, которые публикуют свои релизы на сайте. У каждого из них есть доступ в личную скрытую директорию на топсайте. Туда закачиваются новые релизы перед тем, как они станут доступны другим пользователям. Когда новый релиз полностью закачан на все топсайты, с которыми сотрудничает группа, выполняется специальная команда, которая одновременно копирует релиз в директорию, доступную всем остальным и даёт объявление на IRC канале. Эта команда называется PRE. PRE-сообщения могут также передаваться на внешние каналы для объявлений, чтобы сообщить другим курьерам/пользователям сайтов/fxp, что новый релиз доступен для гонок.

На сайтах также действует система рейтинга. Сайтопы и аффилиаты — исключение из этого правила, они могут скачивать свободно. Самая распространённая система 3:1, то есть если вы закачали 3ГБ, можете скачать 9ГБ (или FXP-нуть на другой сайт). Если участник не выполняет обязательный ежемесячный план по аплоаду, его аккаунт автоматически удаляется. За закачку плохого релиза (если его нюкнут) рейтинг может быть уменьшен, причём даже с повышающим коэффициентом. (прим.перев. то есть если вы залили какую-нибудь полную лажу, вам могут засчитать её в минус в 5-кратном размере, такая практика пришла еще со времён BBS)

FXP-форумы
FXP обозначает File eXchange Protocol. На самом деле это не протокол, а просто метод передачи файлов, использующий уязвимость в протоколе FTP. Он позволяет передавать файлы между FTP серверами. Первому серверу выдаётся команда, и он вместо того, чтобы передавать файлы клиенту, передаёт их другому серверу. Обычно скорость перекачки файлов очень высока.

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

Задачей сканера является прочёсывание IP адресов, где могут быть малозащищённые компьютеры с широким интернет-каналом (обычно это университеты, компании и т.д.). Это либо подбор паролей, либо сканирование портов. Сканеры часто используют для этого другие, медленные, ранее захваченные компьютеры (они называют их scanstro), на которых они устанавливают программы для удалённого сканирования. Когда результаты получены, сканер публикует их на сайте. В дело вступают хакеры.

Хакеры взламывают эти компьютеры. Существует очень много уязвимостей (дыр в безопасности), которые легко использовать. Для того, чтобы получить доступ к компьютеру, используется скрипт — так называемый эксплойт. Какой именно эксплойт запускать, конечно зависит от уязвимости, которую обнаружил сканер. Получив доступ к системе, хакер устанавливает руткит (обычно это модифицированная версия Serv-U). Чаще всего он также устанавливает программу для удалённого управления (обычно Radmin), чтобы потом было проще заходить на этот компьютер. Когда сервер готов, хакер публикует логин на своём FXP форуме. Такой захваченный компьютер называют pubstro или stro. В зависимости от скорости подключения и места на диске, его затем использует либо филлер, либо сканер.

Филлеры занимаются наполнением захваченных серверов свежим варезом. Филлер берёт варез с других pubstro, наполненных другими людьми. Иногда филлеры имеют доступ к топсайтам, и перекладывают релизы оттуда. Таких людей считают нарушителями, и если сценеры узнают об этом, их банят на сцене. Sceneban — одновременный бан на всех сайтах сцены. Говорят, что такое случается довольно часто. Переложив файлы, филлер публикует данные на своём FXP-форуме, чтобы другие могли скачивать. Каждый старается первым объявить о релизе, это гонка, такая же как на сцене — кто выиграл, тот получает прибавку к рейтингу.

пример объявления на сцене о нарушителе, который переливал релизы на FXP

Пабы/Pubbing
Эта техника в наши дни потеряла актуальность. Методы прошлых времён, аналогичные вышеописанным scan/hack/fill, когда у многих университетов и компаний на ФТП серверах был разрешён анонимный доступ, в том числе на запись. Поэтому, вместо того, чтобы взламывать систему, можно было просто закачивать варез туда и публиковать IP адреса. Когда-то такая практика была очень популярна, но по понятным причинам постепенно вымерла. Делалось это так: сканировались ФТП сервера с анонимным доступом на запись (их называли «pub»). Найденные пабы помечались (создавалась директория с именем «tagged.by.name»). Это делалось для того, чтобы уже «помеченный» паб никто больше не использовал. Видимо, некоторое время это работало, и люди уважали такие «метки», но недолго.

Затем люди стали менять метки на свои, что называлось retagging. Против этого стали использовать dir locking, чтобы никто, кроме того, кто первым пометил pub, не смог зайти в эту директорию. Использовались разные методы. Самый простой — создание «лабиринта» — это сотни поддиректорий, чтобы трудно было найти, где находится варез. Другой метод — UNIX тэги. Магический символ ÿ (alt+0255), который в UNIX-машинах был специальным кодом. Если в имени директории будет такой символ, оно будет отображаться не так, как на самом деле. Только создавший директорию может туда зайти, так как он знает настоящее имя. Были методы и для NT систем.

News-группы, IRC-обменники и сценовые трекеры
Протокол NNTP — один из самых древних в интернете. Изначально он использовался для общения по интересам на манер досок объявлений (как на BBS), но люди очень быстро поняли, что с его помощью можно обмениваться файлами. Сообщения хранятся на news-сервере определённое время, обычно небольшое, но есть серверы (как правило, платные), которые хранят данные очень долго. Свежие релизы со сцены распространяются через ньюсгруппы и сегодня, в то же время там можно найти и очень старые релизы, которые больше нигде не сохранились.

На IRC серверах существуют варезные каналы, поддерживаемые людьми, имеющими доступ к релизам. Это могут быть люди с FXP, платных сайтов, либо сценеры. Есть два типа каналов. Первые — Fserve-каналы (user-to-user). Они используют определённые скрипты и функции IRC по передаче файлов между пользователями напрямую. Вторые — XDCC-каналы (server-to-user). Обычно они ближе к сцене. Сервер (обычно iroffer) устанавливается на взломанном компьютере, чтобы потом раздавать оттуда варез. Одновременно релиз может скачивать лишь ограниченное число пользователей, поэтому организуется очередь.

Существуют специализированные закрытые торрент-трекеры, на которых раздаются исключительно релизы напрямую со сцены. Их называют сцен-трекеры или 0day-трекеры. Количество пользователей на них невелико, причём обычные пользователи не могут приглашать новых участников, этим занимается администрация. Они следуют тем же принципам, по которым действует сцена: никакого бизнеса — доступ должен быть бесплатным, а релизы, скачанные с трекера, запрещено где-либо распространять. На таких трекерах нет никакой рекламы, расходы на хостинг оплачиваются за счёт донейтов.

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

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

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

habr.com