Сегодня проведение любого мероприятия (масштабного и не очень) сопровождается рекламой последнего в средствах массовой информации. Поэтому не только журналист, но и любой сотрудник компании, и уж тем более копирайтер, должен четко представлять, что пост-релиз – это рабочий PR-термин, который обозначает информационный материал, написанный и опубликованный по окончании мероприятия. То есть вначале пишется пресс-релиз, например о предполагаемом приезде знаменитости в какой-то город, затем готовится и рассылается пост-релиз о произошедшем событии. Тому, кто хочет составить хороший пост-релиз по мероприятию, пример можно поискать самостоятельно. Будет полезна в таком случае и эта статья.
Для кого предназначен пост-релиз
Вам будет интересно:Публикация — это не только источник информации, но и средство, позволяющее манипулировать мнением общества
Подготовленный материал может быть разослан тем средствам массовой информации, чьим представителям удалось побывать на мероприятии (для них это облегчит работу), и тем, у кого не было возможности лично присутствовать. Но, вероятно, пост-релиз – это тот материал, который их заинтересует и будет ими опубликован. Либо он ляжет в основу уже подготовленного ими текста. Для некоторых представителей СМИ это даже норма: не прийти на мероприятие, но зато после наверстать упущенное и опубликовать материал, составленный с учетом предложенной информации. Если по какой-то причине пресс-релиз не привлек внимание, то пост-релиз может это компенсировать.
Требования к написанию информационного материала
Разберем по пунктам, как писать пост-релиз, чтобы его захотелось опубликовать:
- Прежде всего, текст должен быть информативен. Обязательно перечисление в нем даты прошедшего мероприятия, значительных персон, которые на нем присутствовали (с указанием их должностей). Не следует забывать о подведении итогов.
- Требование информативности применимо не только к тексту, но и к фотографиям. Вряд ли неинтересные, нечеткие снимки привлекут внимание аудитории, на которую ориентирован материал. Вывод: фото должны быть качественными и содержащими пояснения к изображенным на них людям, объектам и т. д. Кстати, фотографии напрямую влияют на повышение статуса сообщения. И еще: желательно постараться, чтобы в кадр попал человек. Пусть речь идет о производстве зажигалок, все равно в кадр должен попасть кто-то из работников предприятия на удачно подобранном фоне (им может стать конвейер), либо покупатель, держащий в руке зажигалку.
- Описание формата события и обстановки.
- Адаптация текста для широкой аудитории. Отсутствие в нем сухих цифр, общих, ничего не значащих фраз. Непременное цитирование самых ярких реплик и высказываний выступающих.
Для написания материала используется фирменный бланк и определенный шаблон.
Пост-релиз – это определенный шаблон
Есть ряд обязательных требований:
- Наличие заголовка, который поможет понять, что именно происходило и о чем далее будет сказано.
- Наличие лида (вступительного абзаца), являющегося кратким итогом мероприятия и содержащего лишь самое основное.
- Наличие основного текста. Эта часть содержит подробное описание события, его деталей.
- Наличие контактов лица, за которым было закреплено проведение мероприятия и у которого будет возможность дополнить информацию в случае, если приведенной в пост-релизе окажется мало.
Сроки подготовки
Пост-релиз, пример которого можно часто увидеть в рекламных изданиях, пишется по горячим следам, без откладывания в долгий ящик. В противном случае надобность в нем отпадет, и у СМИ не будет желания размещать материал. Ведь для современного мира катастрофическое устаревание новостей – это нормальное явление.
Итак, грамотный пост-релиз – это детализированный, конкретный материал, для составления которого можно воспользоваться приведенными требованиями и шаблоном.
Источник
Уверен, наука о PR в социальных сетях имеет будущее и кому, как не нам формулировать ее законы. «О сколько нам открытий чудных…».
Публикую свой перевод статьи Мухаммада Салима «How to Write a Social Media Press Release».
Нет более сложной задачи, чем заинтересовать аудиторию социальных сетей пресс-релизом и дело здесь вовсе не в том, что им неприятно слышать о событиях вашей компании, просто традиционный стиль написания пресс-релиза неприемлем для социальных медиа. Вот несколько классических подходов к написанию пресс-релиза:
1.[название компание/брэнда] объявляет о выпуске [продукта/услуги]
Такой пресс-релиз скучен и может быть воспринят как спам, поскольку слишком явно видна цель — продвижение нового продукта.
2.[название компании/брэнда] объявляет [финансовая новость компании]
Обычно в таких пресс-релизах содержится объявление о том, что компания объединяется с другой, получила дополнительное финансирование и т.д., при этом, пресс-релиз такого типа не содержит никакой полезной информации для конечного пользователя (если конечно в пресс-релизе не содержится информация о том, что Google приобрел YouTube).
3.[название компании/брэнда] планирует [событие]
В пресс-релизах данного типа содержится информация о том, что компания планирует сделать то-то и то-то, например, медицинская компания планирует изготовить лекарство от болезни ***”. Большинство пользователей социальных сетей посчитает такую информацию неинтересной и лишней для себя.
4.[название компании/брэнда] завершил(а) [проект]
Единственная цель такого пресс-релиза — хвастовство компании своими достижениями. Пользователь вправе заметить: “Конечно, замечательно, что у Вас появился 100 000-й подписчик, но мне -то что до этого???”.
Почему стандартные пресс-релизы обречены на провал в социальных сетях
Существует 3 основные причины, по которым стандартные пресс-релизы имеют нулевые шансы на успех в социальных сетях:
- Они неверно сфокусированы, в центре внимания таких пресс-релизов сама компания.
- Они написаны официозным языком, что само по себе вызывает недоверие.
- Они безличны и рассчитаны на слишком широкую аудиторию.
- Конечно же, в желании всячески продвигать свою компанию нет ничего плохого — в конце концов, все мы должны зарабатывать себе на жизнь. Однако учтите, аудитория социальных сетей крайне негативно относится к попыткам явной продажи чего-либо, а также к прилизанным маркетинговым текстам.
Лучше всего представить пресс-релиз как историю, интересную, в-первую очередь, читателям. Кроме того, такая форма подачи значительно увеличивает вероятность того, что пресс-релизом заинтересуются и журналисты.
Пресс-релиз, рассчитанный на успех в социальных медиа, должен не только заявлять о запуске каких-либо новых сервисов, либо достижении результатов, в нем должна быть (это важнее всего) информация о том, с помощью каких технологий был (или будет) достигнут успех, почему эти технологии сработали, а также чем результаты могут быть полезны для аудитории.
Правила написания «альтернативного пресс-релиза»
Надо сказать, что правила написания эффективного пресс-релиза во многом схожи с правилами блоггинга: правильная структура заголовка, интригующее начало, использование графики, ну и содержание, в котором используются все основные законы блоггинга. Однако ниже я публикую золотые правила написания пресс-релиза, оптимизированного именно под социальные медиа:
- Заголовок оптимизирован под все три типа читателей (постоянные, пришедшие с поиска и из социальных сетей).
- Основной смысл материала должен быть понятен даже после беглого прочтения.
- Форматирование текста должно быть привлекательным.
- Никакой воды — только самая суть.
- Постарайтесь кратко изложить технологию достижения успеха для того, чтобы другие смогли почерпнуть, что-то полезное для себя.
- Пресс-релиз, основное внимание в котором посвящено не открытой рекламе компании, а интересам читателя, даст гораздо больший отклик в социальных медиа, нежели стандартно написанный пресс-релиз, который никто не станет читать. Если вы будете больше заботиться об интересах читателя, то и читатели заинтересуются тем, что вы делаете.
Перевод: Дамир Халилов
Методические требования к информационным материалам СМУиС ЧР, предоставляемым в пресс-центр, в редакции СМИ
Основная форма информационных материалов, которые готовятся и предоставляются членами СМУиС ЧР в пресс-центр бюро Совета и в СМИ – пресс-релизы.
Общая информация
Пресс-релиз — надежный способ увидеть в прессе материал таким, каким его хочет увидеть ваша организация. Он готовится руководителем пресс-центра (или же другим, заменяющим его, лицом) и пересылается адресату (в редакции СМИ или же в пресс-центр). Пресс-релиз пишется в газетном стиле и должен быть сосредоточен на одном вопросе. Пресс-релизы используются для сообщения об организации, ее мероприятиях и программах, конкретном событии; доведения до сведения общественности точки зрения руководителя СМУиС ЧР по отдельной проблеме; с целью поддержки определенных действий или лиц.
ВАЖНО: Все пресс-релизы должны тщательно проверяться и согласовываться с руководством СМУиС ЧР.
Основные правила подготовки пресс-релиза
(те, которым нужно следовать при подготовке материалов для отправки в местные СМИ или в пресс-центр СМУиС ЧР)
Две основных разновидности пресс-релиза, которые пригодятся в работе – анонс и пост релиз, к ним применяются как общие для двух видов, так и отдельные правила.
Что должен содержать анонс:
1. Название – содержательное, дающее представление о событии.
Комментарий: Пример отрицательный: «Возьмемся за руки, друзья!».
Пример положительный: «Активистка СМУиС ЧР стала Лучшим молодым предпринимателем года».
2. В анонсе необходимо привести основную информацию: какое мероприятие планируется провести, когда, кто его проводит, где, для кого оно предназначено, кто приглашен, кто планирует принять участие.
Также, при наличии таковой информации, в анонсе можно привести конкретные события мероприятия, например, если это семинар – из каких пунктов состоит его программа: круглых столов, тренингов и т.д.
Приветствуются и дополнительные материалы: комментарии руководства, других, значимых для анонсируемого мероприятия, лиц, в которых можно привести причины, почему это мероприятие является значимым, достойным внимания.
3. В анонсе желательно привести контактную информацию оргкомитета мероприятия, лиц, которые отвечают за его проведение.
4. К пересылаемому анонсу стоит приложить Программу мероприятия, дополнительные документы, которые могут пригодиться адресату для работы с информационным материалом.
Что должен содержать пост-релиз:
1. Название – содержательное, дающее представление о прошедшем событии.
2. В пост-релизе необходимо привести основную информацию: какое мероприятие состоялось, когда, кто его провел, где, для кого оно было предназначено, кто присутствовал.
Пост-релиз предусматривает наличие более конкретного описания события. В материале можно рассказать не обо всех пунктах мероприятия, а о наиболее важных и интересных, более чем желательно привести цитаты участников, комментарий организаторов.
Комментарий: высказывания руководителя СМУиС ЧР или других участников по поводу прошедшего мероприятия должны быть содержательными.
Пример отрицательный: «Я очень счастлив, что такое мероприятие прошло у нас. Буду рад встрече с его участниками снова…»
Пример положительный: «Благодаря прошедшему мероприятию мы смогли решить несколько задач, …»
3. Пост-релиз должен содержать какой-либо вывод из информации, полученной в ходе мероприятия.
Например: «Прошедший круглый стол позволил его участникам получить представление о том, какое количество научных мероприятий было организовано молодыми учеными в данной организации. Было принято решение оказать финансовую поддержку следующим научным школам…»
4. К пересылаемому пост-релизу стоит приложить Программу мероприятия, дополнительные документы, которые могут пригодиться адресату для работы с информационным материалом.
ВАЖНО: перепечатывание программы мероприятия и простое упоминание его пунктов в прошедшем времени не является пост-релизом и даже его частью!
Общие правила
Информация в пресс-релизе должна быть содержательной, точной, конкретной, актуальной, достоверной, этичной.
ОЧЕНЬ ВАЖНО: Информационный материал должен иметь непосредственное отношение к молодым ученым и специалистам.
Пример отрицательный: Краткая информация о том, что руководитель или активист СМУиС ЧР посетил музыкальный концерт, сходил на хоккейный матч и т.д., не имеющее хотя бы опосредованного отношения к нашей главной теме, – не является новостью!
Оперативность – одно из главных требований к информационным материалам! Новость должна предоставляться в СМИ и в пресс-центр СМУиС ЧР в кратчайшие сроки – до 12 ч. следующего дня.
Пресс-релиз должен обязательно содержать указание на автора материала и/или же организацию, которое его предоставило, контактную информацию для обратной связи.
Также обязательны ссылки на источники информации (СМИ, сайты организаций), если таковые использовались при подготовке материала.
Обязательно наличие фотоматериалов/баннеров/других видов визуальной информации, сопровождающих материал.
ВАЖНО: В теме присылаемого в редакцию СМИ или пресс-центр СМУиС ЧР сообщения должно быть указано, что письмо содержит пресс-релиз/новость/анонс!
Пост-релизы
30 ноября – 1 декабря 2017 г. в ПНИПУ состоялась III Международная научная конференция «ОТ ОБРАЩЕНИЯ С ОТХОДАМИ К УПРАВЛЕНИЮ РЕСУРСАМИ».
С приветственным словом на пленарном заседании конференции выступили:
|
Представители органов власти в своих выступлениях уделили особое внимание экологической обстановке г. Перми и подчеркнули важность проведения подобных мероприятий, направленных на формирование экологической ответственности и грамотности населения. Организаторы конференции, в свою очередь, рассказали о собственном опыте реализации проектов в сфере обращения с отходами.
В рамках пленарного заседания в первый день конференции выступили участники из разных городов России, Германии и Литвы, а также представители кафедры – организатора конференции. Обсуждались вопросы управления отходами, технологии их утилизации и обезвреживания, а также результаты исследований ученых из российских и зарубежных вузов и примеры внедрения технических решений бизнес-структур в сфере обращения с отходами.
Во второй день конференции состоялось пять секций:
- Управление отходами в условиях переходной экономики;
- Ответственные исследования и инновации в контексте устойчивого развития;
- Проектирование, строительство и эксплуатация экологически безопасных полигонов захоронения отходов;
- Воздействие отходов на биосферу. Технологии обращения с отходами;
- Молодые исследователи.
В рамках секций обсуждались инновации в обращении с отходами, современные технологии мониторинга природных и техногенных объектов, результаты внедрения экономики замкнутого цикла, экологическое образование, территориальные схемы обращения с отходами, наилучшие доступные технологии, устойчивое развитие городов, интеграция концепции RRI (ответственных исследований и инноваций) в инженерную практику с целью обеспечения устойчивого развития, результаты научных работ молодых исследователей в сфере обращения с отходами. После каждого доклада спикерам задавались интересные вопросы, проходили активные дискуссии.
Отдельно хотелось бы отметить тот факт, что в конференции принимали участие пермские школьники. Они поделились результатами проведения собственных научных исследований, имеющих прикладное значение.
По окончании конференции была проведена торжественная церемония награждения авторов наиболее интересных докладов, организациям-партнерам конференции были вручены благодарственные письма.
Организаторы получили множество положительных отзывов от гостей и участников об интересном содержании и высоком уровне проведения конференции.
Организаторы конференции — кафедра «Охрана окружающей среды» ПНИПУ и Региональное представительство Международной рабочей группы по управлению отходами в России и странах СНГ (IWWG – RUNISRB), благодарят всех участников за неоценимый вклад в работу конференции, за активность и неравнодушное отношение к вопросам охраны природы.
Отдельную благодарность выражаем ООО «Буматика», ГП «Пермская целлюлозно-бумажная компания» и Naue GmbH & Co за помощь в организации конференции.
А.В. Цыбина, старший преподаватель кафедры «Охрана окружающей среды» ПНИПУ
С.В. Полыгалов, ассистент кафедры «Охрана окружающей среды» ПНИПУ
1 и 2 декабря 2015 года в Пермском Политехе прошла II Международная научная конференция «ОТ ОБРАЩЕНИЯ С ОТХОДАМИ К УПРАВЛЕНИЮ РЕСУРСАМИ», посвященная 40-летию кафедры «Охрана окружающей среды» ПНИПУ.
|
В первый день конференции в рамках пленарного заседания выступили гости из Германии, Австрии и разных городов России. Обсуждались вопросы управления отходами, технологий их переработки и обезвреживания, а также результаты исследований ученых из российских и зарубежных вузов, достижения бизнес-структур и проблемы муниципалитетов в области эксплуатации и консервации полигонов захоронения твердых коммунальных отходов. Сюрпризом первого дня конференции для гостей ПНИПУ стало выступление творческого коллектива Пермского Политеха — фольклорно-этнографической студии «Радольница», посвященное русским традициям. Во второй день конференции все доклады были разделены на четыре секции, на которых обсуждались: инновации в рециклинге отходов; современные подходы в проектировании, строительстве и эксплуатации полигонов ТКО; экологическое образование, формирование экологического имиджа предприятий, зеленая экономика; роль молодых исследователей в обращении с отходами. Никто из выступающих не остался без внимания: после каждого доклада задавались интересные вопросы, проходили активные дискуссии. Отдельно хотелось бы отметить, что в конференции приняли участие школьники из городов Пермского края: Соликамска и Лысьвы. Они поделились результатами проведения экологических мероприятий в рамках проекта «Экономь ресурсы». |
Всего в конференции приняли участие более ста человек из Москвы, Оренбурга, Ижевска, Энгельса, Екатеринбурга, Саратова, Соликамска, Уфы, Санкт-Петербурга, Перми, а также Вены (Австрия), Дрездена, Гамбурга и Аахена (Германия). Участники конференции обменялись опытом, наладили ценные деловые контакты, а также получили множество положительных эмоций.
Организаторы конференции — коллектив кафедры «Охрана окружающей среды» Пермского Политеха благодарят всех за неоценимый вклад в работу конференции. Мы надеемся на дальнейшее сотрудничество и взаимодействие при решении объединяющих нас проблем обращения с отходами и управления ресурсами!
А.К. Шутова, И.Д. Мубаракова,
магистры кафедры «Охрана окружающей среды» ПНИПУ
И.Н. Ташкинова,
доцент кафедры «Охрана окружающей среды» ПНИПУ
В 60-й юбилей ПНИПУ (19-20 ноября 2013 г.) состоялось уникальное для Уральского региона событие в области охраны окружающей среды и обращения с отходами – I Международная научная конференция «ОТ ОБРАЩЕНИЯ С ОТХОДАМИ К УПРАВЛЕНИЮ РЕСУРСАМИ».
Организаторами конференции выступили кафедра «Охрана окружающей среды» ПНИПУ и НП «Уральская ассоциация экологически ответственных предприятий», г. Екатеринбург.
Своими знаниями в области передовых технологий переработки и захоронения твердых бытовых отходов (ТБО) поделились шесть ведущих зарубежных ученых из Германии (профессор Керстин Кухта и доктор Марко Ритцковски — Гамбургский технический университет, доктор Кристоф Вюнш — Дрезденский технический университет), Австрии (доктор Эрвин Биннер и профессор Марион Хубер-Хумер — Университет естественных и прикладных наук г. Вены) и Украины (Юрий Матвеев — Институт технической теплофизики Национальной академии наук Украины).
|
Участниками конференции стали зарубежные специалисты, преподаватели и студенты ПНИПУ, а также представители более 15 городов России (Миасс, Москва, Уфа, Иркутск, Санкт-Петербург, Хабаровск, Нижний Тагил и др.), занимающиеся вопросами проектирования полигонов твердых бытовых и промышленных отходов, санитарной очистки городов и технологий переработки отходов. В рамках конференции докладчики рассказали о теории и практике проведения исследований по изучению состава и свойств ТБО; современных технологиях сбора, транспортировки, сортировки и переработки ТБО; проектировании, строительстве и эксплуатации полигонов захоронения отходов; рекультивации и постэкплуатационном обслуживании объектов захоронения ТБО. Участники конференции посетили новый Комплекс глубокой оптико-механической сортировки потоков отходов и материалов ПНИПУ, ознакомились с его современным оборудованием. |
Ценными и познавательными для студентов и молодых ученых кафедры ООС стали мастер-классы наших европейских коллег.
Благодарим всех, кто принимал участие в нашей конференции и мастер-классах зарубежных ученых!
Ташкинова Ирина Николаевна,
старший преподаватель кафедры ООС ПНИПУ
Большое руководство, как написать пресс-релиз
Брайан Дин, известный маркетолог и эксперт по SEO, составил подробную инструкцию, как написать хороший пресс-релиз для СМИ и где его распространять. Мы в Pressfeed перевели это руководство. Советы и рекомендации универсальны в части, касающейся написания релизов, так что вполне подходят для работы как с западными, так и с российскими СМИ. Если же ваша компания планирует выходить на западный рынок и публиковаться в местных изданиях, вам будет полезно также узнать, как и на каких площадках размещать пресс-релизы.
Часть 1. О пресс-релизе
Что такое пресс-релиз
Пресс-релиз (его также называют медиа-релизом или новостным релизом) — это информация о последних новостях компании, предназначенная специально для СМИ.
Если говорить проще, то пресс-релиз — это то, что компания хочет рассказать о себе общественности.
Зачем рассылать пресс-релизы в 2019 году
Зачем вообще писать пресс-релизы? Вот несколько основных преимуществ, которые получает компания благодаря пресс-релизам:
- растет охват аудитории в СМИ и блогах;
- генерируется дополнительный трафик на сайт компании;
- название компании появляется в Google News;
- повышаются позиции в выдаче Google;
- формируется доверие к бренду.
Сразу поясним: пресс-релиз не поможет бренду волшебным образом оказаться на обложке Forbes или Fast Company. Но если вы все делаете правильно, то релиз становится действительно мощным инструментом для продвижения. С его помощью можно рассказать о значимых вещах, которыми занимается ваша компания.
Универсальный шаблон для создания пресс-релиза
Давайте разделим шаблон на несколько составляющих и разберем каждый этап по созданию хорошего пресс-релиза более подробно.
Часть 2. Пишите только о том, что заслуживает внимания
Первый шаг — придумать инфоповод, который будет интересен журналистам и блогерам. Они должны сами ЗАХОТЕТЬ рассказать об этом. Другими словами, это должно быть то, что действительно заслуживает внимания.
Итак, как же найти такой инфоповод?
Правда о «достойных новости» материалах
Найти «достойную» историю не так сложно, как кажется. Это может быть новость об организации мероприятия, сообщение о редизайне сайта или назначении нового директора по маркетингу.
Например, я недавно разослал такой пресс-релиз, чтобы рассказать о новом посте в блоге.
Ваша новость не обязана быть потрясающей и экстраординарной. Считайте, что если вы просто делаете что-то новое, то у вас уже все хорошо.
Вот 4 темы, на которые всегда обращают внимание и которые можно без проблем использовать для вашего следующего пресс-релиза.
Новое исследование отрасли
Ни для кого не секрет, что исследования всегда выглядят интересными и важными. На самом деле большинство компаний проводят исследования и опросы именно для того, чтобы затем разместить их в СМИ. Возможно, это связано с тем, что 39% журналистов честно заявляют, что хотят получать только «эксклюзивные исследования и данные».
Речь о таком:
Я и сам много раз использовал этот прием и могу заявить со знанием дела: исследования — это идеальная тема для пресс-релизов. Почему же? Прежде всего, потому что исследование демонстрирует нечто новое, подтверждает какие-то факты и при этом подкрепляется данными из реальной жизни. Кроме того, в отличие от большинства скучных пресс-релизов, исследование обычно посвящено чему-то любопытному и актуальному, так что журналисты точно захотят рассказать об этом.
Например, несколько месяцев назад я объединился с BuzzSumo, чтобы сделать такое исследование.
Чтобы о нем узнали как можно больше людей, я написал и разослал пресс-релиз.
Этот релиз привлек внимание к нашему исследованию со стороны блогеров и журналистов (то есть это был целевой трафик).
Он понравился и деловым изданиям (типа The Drum).
В итоге релиз повлиял на SEO моего сайта. Хотя в оригинальном тексте релиза стояла закрытая ссылка, некоторые блоги использовали мой релиз и поставили в свою публикацию хорошую открытую ссылку на мой сайт.
Отлично.
Запуск продукта
Если ваша компания запускает новый продукт или вводит новую услугу, пресс-релиз может рассказать об этом. Однако чтобы СМИ забрали ваш релиз и напечатали новость, продукт должен быть очень интересным.
Например, вот пресс-релиз о новой блокчейн-платформе для трейдинга:
Вполне вероятно, что эта платформа не станет новой Coinbase. Но все равно стоит сообщить о ней миру в пресс-релизе.
Мероприятие
Ваша компания организует какое-то событие, например, благотворительный завтрак или закрытую вечеринку? Если это так, то у вас есть отличная тема для пресс-релиза.
Например, этот пресс-релиз говорит о «самом крупном событии, связанном с кошками, в мире».
Релиз не сообщает: «Мы проводим такое-то мероприятие». В нем всегда есть некий акцент, что-то привлекательное, ведь нам нужно убедить людей прийти на это мероприятие (подробнее о таких акцентах расскажу дальше).
Редизайн сайта или ребрендинг
Если вы не Google или Facebook, то об обновлении вашего сайта не будет говорить весь мир. Но если вы ищете тему для пресс-релиза, редизайн может быть хорошим инфоповодом. Ведь всегда можно подать новость о редизайне так, что об этом захотят прочитать многие.
Например, Shots.net представил новый дизайн в рамках обновлений условий использования сайта (теперь работает без paywall).
Если бы они написали что-то вроде: «Shots изменил дизайн сайт», то никто бы не заметил эту новость. Но они подошли к инфоповоду с другой стороны и сменили акценты: теперь у пользователей будет бесплатный доступ к сайту, а такой подход уже заинтересовал журналистов.
Теперь поговорим о таких акцентах, «зацепках» для читателя.
Часть 3. Создайте акцент
Тогда когда вы нашли хороший инфоповод, необходимо добавить в новость некоторые детали, которые и станут цепляющим акцентом (иногда такие акценты также называют «углом зрения» — это то, как именно вы подаете свою новость).
Если акцент (фишка, зацепка, крючок) действительно волнует общество, то вы получаете «сильный акцент».
Пример сильного акцента
Вернемся к исследованию, которое мы уже упоминали выше.
Цель этого исследования — привлечь специалистов по SEO и контент-маркетингу. Например, в тексте исследования использовались такие термины, как «получение обратной ссылки».
Этот термин понимают только маркетологи. И я знал, что если использовать такие выражения в пресс-релизе, журналисты бы не стали делать новость на его основе.
Поэтому для релиза мы использовали другой «крючок», который привлек широкую аудиторию. В релизе мы перевели акцент на ответ на вопрос — почему же люди обмениваются контентом в интернете?
Другими словами, мы взяли узкую тему, которая понравилась бы только профессиональным маркетологам, но подали новость так, чтобы она стала актуальной для всех. И это сработало!
Как я уже сказал, эта история приглянулась многим СМИ.
Некоторые из СМИ впервые увидели это исследование в нашем пресс-релизе.
И я уверен, что наш пресс-релиз не сработал бы, если бы мы пошли к СМИ с заходом вроде: «Длинные материалы лучше всего подходят для получения обратной ссылки».
Вот 3 беспроигрышных акцента, которые вы можете использовать в своих пресс-релизах.
Связка с горячей новостью
Обычно какая-то актуальная новость и становится акцентом. Люди уже говорят об этом, а ваша новость просто добавит масла в огонь.
Например, медицинская компания из Огайо связала свое мероприятие с блокчейн-трендами.
Это превратило скучную новость о Дне здравоохранения в штате Огайо в нечто весьма интересное. Это был умный ход.
Местная история
Большинство региональных новостных сайтов или блогов с нетерпением ждут историй, о которых они могли бы написать.
И в отличие от таких мегабрендов как TechCrunch вам не нужно ломать голову, чтобы попасть в местную повестку. Компания не обязательно должна находиться в определенном регионе, чтобы новость сработала.
Например, несколько месяцев назад я наткнулся на список «самых грязных городов Америки»:
Компания, которая провела исследование, расположена в Иллинойсе, но о ней написали местные сайты из Балтимора, Питтсбурга, Сан-Франциско и многих других городов.
Все потому, что в пресс-релизе упоминались все эти города, так что информация была актуальна для каждого города.
Нестандартный подход
Ваша компания делает то, что не вписывается в общепринятые стандарты или нормы? Тогда считайте, что вы уже нашли свой «вечный источник» тем для пресс-релизов.
Например, посмотрите этот релиз о винных этикетках, которые переводятся сами.
Эта компания Third Aurora не делает ничего такого, что обычно обсуждают или о чем активно спорят. «Мы разрабатываем этикетки для вина, которые сами себя переводят» — новость не взбудоражит клиентов, но этот факт все равно отличает пресс-релиз от обычных релизов о продукте. Этого достаточно, чтобы выделиться и получить публикации в СМИ.
Часть 4. Заголовок пресс-релиза
Следующий этап — пишем заголовок для пресс-релиза.
Будьте крайне внимательны: заголовок играет огромную роль в пресс-релизе. Дело в том, что большинство журналистов сначала посмотрят на заголовок, а от заголовка будет зависеть, будут ли они вообще читать этот релиз. Если заголовок выглядит неубедительно, например, «Acme Inc нанимает нового директора департамента скучных объявлений», то дела плохи.
И в этой части я расскажу о том, как написать цепляющий заголовок в два шага. Это не сложно, просто действуйте поэтапно, и все получится.
Два шага, чтобы написать цепляющий заголовок
Шаг 1. Определите главный акцент. Тот «крючок», который мы разобрали в части 2.
Шаг 2. Используйте этот акцент в заголовке.
Без шуток, вот и все!
Например, в релизе об исследовании, посвященном контенту, я использовал такой акцент: «В интернете люди предпочитают делиться лонгридами».
И я указал на это в заголовке:
Заголовок во многом зависит от главной мысли релиза.
Вот отличный заголовок о новом продукте:
Структура и формулировки могут быть разными, но все хорошие заголовки пресс-релизов все равно построены по единой схеме:
Пример заголовка, который составлен по такому принципу:
Имейте в виду, что заголовок не начинается с названия компании и не говорит о том, как хороша эта компания. Такое начало сразу оттолкнет журналистов. Вместе этого, на первом месте в заголовке упоминаются криптовалюты, а это уже актуальная тема.
Далее идет акцент на то, как продукт связан с современными трендами.
И только тогда, когда читатель уже заинтересовался материалом, в заголовке появляется название компании.
Как написать подзаголовок для пресс-релиза
Чаще всего при размещении пресс-релизов на специальных сайтах (релизоприемниках) к заголовку можно добавить подзаголовок.
И я настоятельно рекомендую это делать. Почему? Потому что подзаголовок раскрывает пресс-релиз, добавляет подробности, которые могут убедить вечно занятого журналиста все-таки прочитать вашу новость.
Например, в моем пресс-релизе подзаголовок раскрывает некоторые детали, для которых не хватило места в заголовке.
В подзаголовке были указаны некоторые цифры, которые доказали главную мысль из заголовка.
Часть 5. Лид в пресс-релизе
Пора приступить к тексту релиза. Начинаем с лида.
Лид — это 1-3 предложения, с которых начинается релиз. Лид может сделать пресс-релиз выигрышным, а может, наоборот, испортить весь материал. Поэтому я объясню, как писать лид.
Почему лид — это ключевая часть
В большинстве случаев лид не менее важен, чем заголовок.
Допустим, журналист отложил свои текущие дела и начал читать релиз. Его уже привлек заголовок, что хорошо. Но он не возьмет вашу новость в работу, если его не зацепят первые 2-3 предложения релиза. Именно в этот момент лид и играет свою роль.
Что включить в лид
Правило №1 — лид должен содержать что-то супер важное.
Например, не нужно писать в лиде, какая большая у вас компания.
Похвала в сторону компании только раздражает журналистов. Вместо этого, включите в лид:
- статистику;
- цифры;
- открытия;
- подробности о запуске продукта;
- сообщение о мероприятии.
Суть в том, что лид должен выделить самую интересную часть релиза.
Например, в своем релизе я привел статистику, которая, как я и предполагал, привлечет всех, кто интересуется соцсетями и контент-маркетингом.
После того, как я привел убедительную статистику, я упомянул о том, как именно проводилось исследование, и указал на еще одну любопытную деталь.
Также в первом абзаце я вставил ссылку на наше исследование.
Таким образом, журналисту не пришлось самому искать ссылку на исследование. Она была в лиде — прямо перед его глазами
Часть 6. Основной текст релиза
Итак, мы написали отличный заголовок, подзаголовок, лид. Теперь нужно приступить к основной части.
Давайте обсудим четыре основных момента, о которых стоит помнить при написании текста пресс-релиза.
Пишите от третьего лица
Не используйте «я», «мы» или «вы». Вместо «Мы запускаем новый продукт» пишите «Acme Inc. запускает новый продукт».
Старайтесь повторить стилистику СМИ
Желательно, чтобы ваш пресс-релиз был похож на статью в газете (сайте). Тогда журналисты смогут просто копировать текст и вставлять части вашего релиза в свой материал без необходимости редактировать что-либо.
Например, однажды я попросил кое-кого помочь написать пресс-релиз для нас. В итоге текст был переполнен пустыми, но громкими фразами.
Это плохо. Ваш текст должен звучать объективно.
Вот пример одного из наших последних релизов:
Форматируйте, чтобы можно было пробежаться по тексту
Имейте в виду, что никто не будет читать ваш релиз от и до. Поэтому обязательно отформатируйте текст так, чтобы его можно было прочитать «по диагонали».
На практике это выглядит так.
Короткие абзацы:
Выделенные жирным начертанием фразы:
Высказывания без лишней «воды»:
Используйте статистику и цифры
Добавьте данные, которые журналисты смогут легко включить в свою историю. Статистика идеально подходит для этого.
Например, статистика в моем релизе относилась непосредственно к исследованию.
Добавьте цитаты (по возможности)
Если вы хотите добавить в текст цепляющую и при этом убеждающую информацию, то один из вариантов — вставить в текст несколько цитат.
Хотя я считаю, что использовать цитаты необязательно (исключениями являются, пожалуй, красивые фразы, указывающие на достижения компании).
Так что если вы и используете цитаты, то пусть они будут небольшими, — максимум 1-2 предложения.
Вот пример хорошей цитаты в релизе:
Эта цитата добавляет некоторые уточнения и устраняет возражения, которые могут возникнуть у журналисто
Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».
В данной статье кратко раскрываются следующие темы:
- применимость процесса — когда имеет смысл его внедрять
- основные этапы процесса, активности, вовлеченные ресурсы и результаты
- планирование релизов: календарь, объем, параллельное выполнение
- некоторые проблемы доставки в релизах
Применимость процесса
Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:
- Начальный период постпроектной поддержки: значительное количество изменений, проблемы с приоритизацией, необходимость эффектично упрявлять ожиданиями заказчика
- Процесс поддержки продукта: необходимость организовать процесс, оптимизирующий использование всех доступных ресурсов в рамках существующего бюджета.
- Большой процент запросов на изменения затрагивают пересекающиеся предметные области или приводят к техническим зависимостям — необходимо явно группировать изменения с целью оптимизации работ по разработке или тестированию.
- Процесс непосредственной доставки разработанных изменений продукта на продуктив — “дорогой”, с любой точки зрения: от координации, до непосредственных расходов на распространение изменений.
Кроме того, при определенных условиях планирования и организации этапов релизов — весь процесс доставки можно максимально приблизить к методике Scrum (регулярная поставка изменений, с наивысшей ценностью для заказчика), таким образом постепенно переходя к использованию гибких подходов в организациях, не очень к этому предрасположенных.
Этапы процесса
Процесс состоит из последовательности этапов. В разных реализациях процесса некоторые этапы могут быть объединены, или могут называться по другому — но общий принцип сохраняется
1. Draft
Активности:
Подбор запросов на изменения и инцидентов в список того, что планируется делать, проводится начальная приоритезация, анализ взаимозависимостей и предварительная оценка трудозатрат на анализ и разработку.
Результат:
Все требования содержат высокоуровневую оценку сложности и рекомендации по группировке в релиз на основании области изменений и/или технических зависимостей.
С учётом этих оценок и рекомендаций, на основании бизнес-приоритетов заказчика и доступных ресурсов исполнителя, к анализу принимается группа запросов на изменения и инцидентов. Не вошедшие в этот список обращения возвращаются в общий пул и будут оценены в рамках следующих релизов
Ресурсы:
- Аналитики (ведущий аналитик)
- Заказчики
- Менеджер релиза
2. Scope
Активности:
Проводится детальный анализ и оценка, подготовка спецификаций по изменениям, отобранным на основании приоритетов заказчика Отобранные требования полностью проанализированы и утверждены заказчиком, технические спецификации проработаны, детальная оценка трудозатрат проведена.
Результат:
Полностью проанализированные запросы на изменения подготавливаются к финальному подтверждению содержания релиза. Запросы, для которых анализ или согласование не завершено — возвращаются в общий пул. Они — кандидаты на анализ (окончание анализа) в рамках следующего релиза
Ресурсы:
- Аналитики
- Заказчики
- Разработчики (Тех лид)
3. Approval
Активности:
Получение подтверждение ресурсов от исполнителей (для разработки) и заказчиков (дляд тестирования). Оценка общего бюджета релиза (если применимо). Финальное согласование с заказчиком содержания релиза, исходя из готовности отдельных запросов, приоритетов, оценённого бюджета, доступных ресурсов.
Результат:
Сформировано финальное содержание релиза.
Все запросы на изменения, входящие в финальное содержание релиза передаются в разработку. Остальные запросы на изменения возвращаются в общий пул. Поскольку эти изменения имеют высокую степень готовности — они кандидаты в следующий релиз
Ресурсы:
- Заказчики
- Менеджер релиза
4. Work in progress
Активности:
Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.
Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.
Если разработка для какого-то изменение из содержания релиза не завершено, то на основании анализа технических зависимостей рассматриваются вопрос либо о переносе изменения в следующий релиз, либо к задержке выпуска текущего релиза.
Ресурсы:
- Разработчики
- Аналитики
5. Testing
Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)
Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.
Если приемка какого-то изменение из содержания релиза не завершено, то на основании анализа технических зависимостей рассматриваются вопрос либо о переносе изменения в следующий релиз, либо к задержке выпуска текущего релиза.
Ресурсы:
- Заказчики
- Аналитики
- Разработчики
6. Deployment
Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.
Результат:
Изменения перенесены в продуктивную среду и доступны заказчику
Ресурсы:
- Служба эксплуатации
7. Closure
Активности:
Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.
Результат:
Формальное завершение работ. Улучшения процесса.
Ресурсы:
- Менеджер релиза
Планирование релизов
Как и любую активность, релизы нужно планировать. К счастью, управление релизами — это процесс, и поэтому при планировании можно рассчитывать на то что этапы, их взаимосвязь не меняются. Однако для планирования расписания релиза необходимо принципиально определиться с подходом к доставке:
- Если, внедряя релизы, вы планируете также обеспечивать регулярность выхода новых версий — то, скорее всего, и длительность этапов должны быть зафиксированы на некоторых оптимальных значениях.
- Если же релизы будут использоваться только как группировка отдельных запросов на изменение, а общая длительность релиза должна быть оценена исходя из объемы работ и ресурсов — оценка длительности этапов ничем принципиально не отличается от планирования любого проекта.
Планирование релизов с фиксированной длительностью
Это планирование проводится в самом начале внедрения процесса, и относится к процессу, как таковому — а не к отдельным релизам, поскольку длительность отдельного релиза меняться не будет.
Принципиальная стабильность календаря релизов в этом случае позволяет осуществлять параллельное исполнение нескольких релизов со смещением относительно друг друга. В этом случае, основная задача календарного планирование этапов релизов — это соблюдение баланса между скоростью доставки изменений заказчику и обеспечение оптимальной загрузки ресурсов команды.
Что будет меняться определенно — это ресурсы, доступные на каждом из этапов, в разных релизах (люди болеют, ходят в отпуск). Но с учетом перечисленных ограничений планирования это будет сказываться только на объем доставляемых изменений, а не на календарный план.
В целом, планирование релизов с фиксированной длительностью, и зависимостью объема доставки от наличия ресурсов — задача относительно несложная. В результате, процесс получается максимально предсказуемый и ритмичный, во многом близкий к 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) могут иметь меньшую ценность для бизнеса, по сравнению с требуемыми изменениями. Отсюда — очевидное желание рассматривать задачи устранения дефектов (или предоставления дополнительных сервисов) в общем контексте планирования содержания релиза — делать то, что важно.
С другой стороны, устранение дефектов может быть утверждено заказчиком в качестве априорно наиважнейшей задачи — таким образом, ресурсы на устранение дефектов прийдется выделять в приоритетном порядке.
В любом случае, необходимо учитывать наличие дефектов при оценке доступных ресурсов, которые можно выделить на содержимое релизов.
- В качестве первого варианта можно оценить потенциальный объем дефектов за релиз и ресурсы затрачиваемые в среднем на один дефект. На эту оценку уменьшаются ресурсы, выделяемые на новые запросы на изменения.
- Альтернативным подходом может служить выделение группы ресурсов, отвечающих только за устранение дефектов. Но скорее всего — это целесообразно только в случае большого количества серьезных дефектов
Вне зависимости от подхода к оценке необходимых ресурсов, включение задач по устранению дефектов в содержимое релизов может оказаться полезным при анализе технических зависимостей всех изменений, над которыми работает команда.
Заключение
Серьезным преимуществом процесса релизов (особенно, при релизах с фиксированной длительностью) в глазах заказчика является заранее объявленное дата выпуска, обычно привязанная к определённым календарным точкам (например — ежемесячно, ежеквартально). Это позволяет строить прозрачный и ритмичный процесс, с ожидаемыми по срокам контрольными точками (переходами между этапами) и ожидаемыми результатами на каждой точке. Кроме того, заказчик непосредственно вовлечён в определение содержимого релиза путём определения приоритетов.
Для команды, поддерживающей продукт, процесс предоставляет возможность реализовать оптимальную загрузку своих ресурсов, и управлять объемом работ, доставляя изменения в срок и качественно. Также, после нескольких завершенных релизов, на базе собранной статистики, команде будет проще обосновывать запросы на дополнительные ресурсы в ответ на растущие запросы заказчика.
Как организовать релиз / Хабр
Релизить продукт — это самая важная часть работы любой софтверной компании. Но если вы боитесь делать релиз, то возможно вы что-то делаете не так. Я расскажу как обычно организовываю релиз. Данная статья не претендует на исчерпывающее руководство поскольку в индустрии разработки программного обеспечения все индивидуально.Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Release notes
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Внутренний анонс
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Во время релиза
Создать релизный бранч
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Отправить уведомление
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Сделать тэг
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
Сделать сам релиз
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Релиз одной кнопкой
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Если все пошло не так, как планировалось
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
После релиза
Мониторить
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Сообщить об успехах и неудачах
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Провести ретроспективу
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Заказать пиццу и отпраздновать
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Начать подготовку к следующему релизу
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Как проводят релиз другие компании?
Spotify
Спотифай релизит часто, основываясь на практике Release train. Как намекает название этой практики, релиз очень похож на поезд: кто не успел закончить свою работу, ждет следующего релиза. Плюсы такого подхода в том, что не успевающая команда не задерживает доставку продукта и не пытается втолкнуть недоделанные таски. И как следствие, у девопсов ночами не разрываются телефоны, а дежурная команда на утро не появляется на работе с мешками под глазами. Безусловно такой подход не подойдет аутсорсинговой компании: клиент не станет платить за недоделанную работу. Скажу прямо: мне нравится культура компании, советую посмотреть видео (https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) о том, как она работает.
Booking
Эти ребята тоже очень крутые. Релизы у них основаны на A/B тестах. Допустим, есть текущая стабильная версия — версия А, и есть версия, которую только что закончил разработчик, — версия B. Если в версии B KPI лучше, то стоит увеличить процент пользователей для этой версии. Если же версия B хуже, то тут есть два варианта: версия B просто не стабильна или просто фича никому не нужна. Такой подход подойдет компании, которая бережно относится к своему работающему продукту, но революции она скорее всего не сделает. Если вам интересно узнать больше про бережливое производство, прочтите книгу Lean Startup (http://theleanstartup.com/).
Когда я начал свою карьеру в качестве QA, я работал с компанией, которая предлагала свои продукты в качестве SaaS. Производственные релизы были критически важны, и была возможность повлиять на функциональность для живых клиентов.
По мере роста нашей клиентской базы для управления рисками и минимизации влияния релиза на живых клиентов команда QA приняла после тестирования релиза.
Все это было для меня новым, и у меня было так много вопросов и сомнений:
- Что такое тестирование после выпуска?
- Я все правильно протестировал, зачем нам тестирование после релиза?
- Я проверяю все заново? Что именно я делаю в проверке после выпуска?
- Что произойдет, если я найду проблему? И т.п.
Я с радостью признаю, что нашел все свои ответы в своих первых нескольких производственных выпусках.
Здесь я делюсь этими знаниями со всеми вами. Я решил написать статью в формате вопросов и ответов, чтобы показать вам, как я нашел ответы.
Что такое проверка выпуска после производства?
По определению, Post означает После , Production Release относится к развертыванию в LIVE / производственной среде и . Проверка включает , чтобы убедиться, что выпущенные функции соответствуют требованиям .
Рекомендовано к прочтению => Как эффективно подготовить «тестовую среду» перед началом тестирования
Цель состоит в том, чтобы проверить выпуск в производственных / LIVE-средах.
Но тогда возникают вопросы:
- Почему мы должны проводить тестирование после выпуска, когда я все тестировал в среде QA?
- Почему мы ожидаем возникновения проблем на производстве, хотя мы тщательно протестировали релиз в тестовой среде?
Есть много причин, по которым у нас могут возникнуть проблемы с производством, даже если бы мы следовали полному процессу обеспечения качества (т.е.е. планирование тестирования, проверка плана тестирования, цикл тестирования, регрессионные тесты и т. д.)
Причины возникновения проблем на производстве:
1) Выпуск данных — Доступные данные в производственных и тестовых средах могут различаться. Это может привести к тому, что в тестовых средах будут пропущены некоторые проблемы.
2) Проблема развертывания — Если в вашей компании есть процесс развертывания сборки вручную, ваш выпуск может быть более подвержен проблемам развертывания. Некоторые распространенные сценарии могут быть: отсутствие конфигурации или настроек сайта, отсутствие сценариев БД, несоблюдение порядка развертывания (сначала код, затем БД и т. Д.).), неправильно установлены зависимости и т. д.
Также прочитайте => Что должен знать QA-тестер о процессе развертывания
3) Области воздействия не определены — Могут быть некоторые сценарии, для которых области воздействия могут быть не определены правильно и полностью командой.
Например, рассмотрим среду SaaS.
Если группа не определила влияние перефакторизованной таблицы БД на клиента с использованием более старой схемы таблиц (например, потеря данных, необходимость переноса данных перед выпуском и т. Д.) и т. д. Эта проблема менее вероятна для хорошо спланированных проектов с точными требованиями. Но возможность все еще существует.
4) Неизвестные области воздействия — Это может произойти, если область действия и области воздействия не известны. Например, в компании с несколькими программными продуктами, использующими общую базу данных и архитектуру, даже небольшое изменение может нарушить функциональность многих продуктов.
Какие задачи и действия включены в фазу проверки после выпуска?
Задачи и действия после выпуска производства обычно включают в себя:
- Проверка после выпуска производства
- Отчет о результатах проверки
- Сообщение о любых проблемах, обнаруженных в производстве
- Очистка данных проверки после выпуска
- Мониторинг после выпуска (если применимо)
Нужно ли проверять все заново?
Не обязательно.Это зависит от выпускаемой сборки и анализа воздействия.
Детальное тестирование должно проводиться во время обычного цикла контроля качества. Проверка после выпуска должна проводиться в соответствии с планом тестирования проверки после выпуска, который должен быть производным от полного плана тестирования для этой версии.
Как сформулировать стратегию проверки после выпуска?
Планирование проверки после выпуска продукта должно быть выполнено аналогично обычному планированию тестирования.
Стратегия должна быть в тех же строках, что и тестовый поток, выполняемый в течение цикла QA. Важно включить наиболее важные и важные этапы, обеспечивающие максимальный охват функциональности.
Хорошая стратегия выпуска после выпуска должна:
- Включать шаги для тестирования новых функций, а также основных существующих функций
- Проверка основных областей влияния
- Разрешить максимальный охват функциональности
- Необязательно: Включить все обнаруженные критические ошибки в тестовой среде
- Необязательно: укажите приоритет тестовых случаев
Кто создает план тестирования после выпуска?
Это будет варьироваться в зависимости от компании и будет зависеть от организационной структуры.
Давайте рассмотрим пример организации команды QA.
В этом сценарии QA, работающий над конкретным проектом, сформулирует первоначальный план тестирования после выпуска.
Кто утверждает план испытаний после выпуска?
Это будет варьироваться в зависимости от компании и будет зависеть от организационной структуры.
Опять же, учитывая ту же организационную структуру, которая показана в предыдущем вопросе, план тестирования после выпуска должен быть рассмотрен и утвержден руководителем тестирования или менеджером по обеспечению качества.
Когда я создаю план проверки после выпуска?
План тестирования после выпуска может быть создан в любое время в течение цикла разработки программного обеспечения после того, как требования, область разработки и области воздействия определены и заблокированы. Обычно QA легче создать план тестирования после выпуска на полпути в спринте. Это гарантирует, что у вас будет достаточно времени для рассмотрения и одобрения.
Рекомендуется включать этот план тестирования вместе с любыми официальными документами о подтверждении качества до того, как проект вступит в фазу развертывания и выпуска.
Я завершил проверку выпуска после выпуска. Что дальше?
После того, как проверка после выпуска завершена, следующие шаги будут
1) Передача результатов проверки — Результаты проверки должны быть сообщены заинтересованным сторонам, включая любые проблемы, которые могли быть обнаружены на производстве.
2) Сообщение о любых проблемах, обнаруженных на производстве, в инструменте управления дефектами — Для упрощения анализа и отслеживания первопричин.
3) Очистка данных проверки после выпуска — Очистка данных должна быть выполнена после завершения проверки.
Например, рассмотрим выпуск для приложения электронной коммерции и скажем, что вы создали тестовый заказ на производстве. Этот тестовый заказ должен быть отменен после завершения проверки.
4) Мониторинг после выпуска (если применимо) — Некоторые выпуски требуют мониторинга на производстве.
Например, если команда внесла улучшения, чтобы улучшить время загрузки страницы в Приложении, это необходимо отслеживать в течение некоторого периода времени, чтобы убедиться, что улучшение действительно было видно после выпуска.Ответственный за мониторинг должен быть четко определен и доведен до сведения.
Что произойдет, если я обнаружу проблему?
О любых проблемах следует сообщать в инструменте управления дефектами и сообщать заинтересованным сторонам. Если в производстве обнаруживаются какие-либо критические проблемы, передача результатов должна происходить немедленно, поскольку необходимо будет принять решение, если необходимо откатить сборку для дальнейшего изучения проблемы.
Важно, чтобы все обнаруженные проблемы сообщались в инструменте отслеживания дефектов.Рекомендуется поднимать их как отдельный тип проблемы (например, Ошибка после производства), чтобы показать отделение от обычных ошибок цикла QA. Эти проблемы могут быть легко отфильтрованы, если требуется для анализа первопричин.
Что еще мне нужно знать о процессе проверки после выпуска?
Помимо фактического процесса, плана и стратегии проверки после выпуска, ниже приведены несколько указателей:
- Важно установить четкие ожидания относительно объема и цели проверки после выпуска.Заинтересованные стороны (внутренние и внешние) должны быть осведомлены о следующем.
- Команда не может протестировать все на производстве
- Команда не может сжать дни испытаний на несколько часов, отведенных для проверки после выпуска
Таким образом, тестирование на производстве будет основываться на утвержденном плане испытаний после выпуска.
Ограничения:
Необходимо соблюдать осторожность при определении объема тестирования после выпуска.Существуют ограничения на то, что и сколько мы можем реально протестировать на производстве. Производственная среда содержит оперативные данные о клиентах и требует очень осторожного обращения. Дополнительное планирование должно быть выполнено для изменений, которые включают миграцию данных, обновление, удаление и т. Д.
Пример # 1): Для компании eSurvey, если тестирование подразумевает ответ и отправку опроса, QA необходимо отправить запрос на удаление запроса. тестовое обследование после проверки, чтобы не повлиять на данные сбора клиентских опросов и их статистику.
E xample # 2): Для компании, занимающейся электронной торговлей, предположим, что задание SQL для обновления цен запускается ежедневно в полночь и загружает окончательную цену на веб-сайт. Мы не можем запускать этот SQL по требованию несколько раз с целью проверки после выпуска, поскольку это может привести к тому, что незавершенные данные будут отправлены в производство.
Более того, это может увеличить вероятность взаимоблокировок БД и высокого потребления ресурсов ЦП и памяти в часы максимальной нагрузки, что может повлиять на производительность клиентских приложений.
- Усилия, необходимые для тестирования после выпуска и всех связанных с этим мероприятий, должны быть встроены и включены в план проекта. В зависимости от бизнес-правил и специфики проекта это может рассматриваться как накладные расходы проекта или включаться в цикл QA или включаться как часть плана управления выпуском.
- Для проблем, о которых сообщается во время проверки после выпуска, следует провести анализ основных причин, чтобы выяснить причину, по которой проблема не была обнаружена на ранней стадии, и что можно сделать лучше в следующий раз, чтобы избежать возникновения проблемы.Анализ первопричин может помочь команде извлечь уроки из прошлых проблем и устранить любые пробелы в реализации. В зависимости от организационной структуры тест-лидер или менеджер по обеспечению качества могут выполнить анализ первопричин с помощью команды проекта. Некоторыми распространенными основными причинами могут быть проблема кодирования, проблема требований, проблема дизайна, проблема с данными, ограничения третьих сторон, отсутствующий сценарий тестирования и т. Д. Соответствующие корректирующие и предупреждающие действия могут быть созданы и отслежены.
- Серверные журналы также можно использовать для мониторинга сборки после выпуска.Журнал сервера может содержать события или проблемы, которые могут быть не видны клиенту, но могут вызвать проблемы в бэкэнде. Этот мониторинг может быть назначен как элемент действия для лидера Dev и команды DevOps.
Пример:
Обзор проекта:
Необходимо внести следующие изменения в приложение для социальных сетей, в частности в процесс регистрации
- Необходимо удалить проверку поля фамилии. Ранее оно было реализовано как «Фамилия должна содержать не менее 4 символов» (Улучшение для существующего поля).
- Включить переключатель рядом с адресом электронной почты, чтобы пользователь мог установить параметры конфиденциальности для адреса электронной почты, который будет отображаться в их профиле (запрос новой функции).
- Пользователь должен иметь возможность выбирать свой аватар (запрос новой функции)
- Сокращение вызовов API во время процесса регистрации для повышения производительности приложения (Улучшение)
Проверка после выпуска выпуска План:
Вывод:
С большинством из компаний-разработчиков программного обеспечения, применяющих в настоящее время методологию Agile, увеличилось количество производственных выпусков
Например, при использовании модели «Водопад» рабочая группа может выпускать производственную версию каждые 1,5 месяца, однако при использовании гибкого процесса одна и та же команда может выпускать производственную версию каждые 2-3 недели.
С каждым производственным выпуском у нас есть возможность сознательно или неосознанно влиять на функциональность живых клиентов. Принятие проверки после выпуска сразу после выпуска может придать дополнительную уверенность в выпуске и в то же время обеспечить безопасность для отката выпуска до того, как наши клиенты столкнутся с некоторыми проблемами.
Для проектов с высоким уровнем воздействия / риска план проверки после выпуска может быть структурирован на основе приоритета тестового сценария. Сначала может быть выполнен тест критического приоритета, а заинтересованным сторонам отправлено сообщение о результатах и любых проблемах. Если критических проблем не обнаружено, то проверка после выпуска может быть продолжена, в противном случае необходимо принять решение об откате, чтобы минимизировать время простоя приложения и влияние на действующих клиентов.
Кроме того, тестирование после выпуска может быть автоматизировано , и сценарии тестирования могут запускаться по требованию после каждого выпуска в качестве регрессионного теста.Опять же, следует соблюдать осторожность при запуске сценариев автоматического тестирования на производстве, так как это может повлиять на данные и функциональность действующего клиента.
Проверка после выпуска продукта — это последняя линия защиты для любой компании-разработчика программного обеспечения. Если мы не уловим проблемы, наши клиенты будут, и это может иметь разрушительные последствия для репутации любой компании-разработчика программного обеспечения.
Для поддержания надежности продукта важно, чтобы мы сразу же после развертывания проверили изменения, внедренные в производство.
Об авторе: Эта полезная статья написана Нехой Б. В настоящее время она работает менеджером по обеспечению качества и специализируется на руководстве и управлении внутренними и оффшорными командами обеспечения качества.
Поделитесь своей стратегией / советами / опытом тестирования после выпуска с нашими читателями.
.Маркетинг с помощью пресс-релиза является одним из старейших методов в книге. Это также очень неправильно понято. Слишком много людей путают пресс-релизы и гостевые посты и пытаются представить одно вместо другого.
Пресс-релизы, даже те, которые направлены на маркетинг, являются очень специфическим видом документа. Пресс-релиз не может быть просто постом в блоге в необычном костюме; он должен соответствовать нескольким целям и соответствовать известному формату, который будет принят на большинстве сайтов распространения пресс-релизов.
Смысл пресс-релиза в том, чтобы быть одним документом, который вы отправляете в самые разные источники. Если все эти источники публикуют документ, это нормально, это, безусловно, пресс-релиз, который не должен быть уникальным. Однако настоящая цель заключается в том, чтобы журналисты на этих сайтах — будь то газеты или онлайн-журналисты, такие как HuffPost или Forbes — освещали вашу тему. Вы привлекаете внимание к своему бизнесу, повышаете осведомленность и заставляете людей проверять, какой новый продукт у вас появился.
Хороший пресс-релиз
Хороший пресс-релиз должен обладать определенными качествами, если вы хотите, чтобы его читали, не говоря уже о журналистах. Что делает хороший пресс-релиз?
# 1: пресс-релиз должен быть достойным публикации. Подумайте об этом с точки зрения незнакомца, друга или члена семьи. Если вы расскажете им о том, о чем пишете пресс-релиз, они будут взволнованы? Хорошо, так что член семьи может быть не лучшим тестом; они могут быть взволнованы для вас, несмотря на то, что вы не поняли ни словаТем не менее, новостная ценность невероятно важна.
# 2: в пресс-релизе должны использоваться ваши соответствующие целевые ключевые слова. Пресс-релизы — фактически одна из немногих областей, где плотность ключевых слов имеет значение, где вы можете хотя бы подумать о том, чтобы вставить их больше, чем ваш обычный пост в блоге. В конце концов, вы хотите, чтобы люди поняли, что делает ваша компания и о чем ваше объявление, поэтому им не нужно копаться, чтобы найти тему. Избегайте чрезмерно наполненных абзацев, конечно; это не звучит достаточно естественно.Люди читают это, в конце концов.
# 3: пресс-релиз должен иметь соответствующие ссылки с хорошим якорным текстом. Не используйте типичный якорь «нажмите здесь», вам нужно что-то целевое, чтобы точно сказать людям, для чего нужна ссылка.
В отличие от постов блога или гостевых постов, каждая ссылка, включенная в пресс-релиз, должна вести на ваш сайт. Это один из немногих видов контента, который вы можете распространять, который является полностью саморекламой и, как ожидается, будет. Ссылка на вашу домашнюю страницу со ссылкой на то, кто вы есть, ссылка на вашу целевую страницу для вашего нового продукта или услуги, и, возможно, ссылка на один флагманский контент при обсуждении его актуальности.Кроме того, вам не нужно больше ссылок.
# 4: пресс-релиз должен включать СМИ, если это разрешено. Некоторые распространители пресс-релизов предпочитают просто продвигать текст, в то время как другие разрешают размещать в них сообщения со СМИ. Если вы обнаружите, что многие сайты, которые вы хотите использовать, не хотят, чтобы вы добавляли мультимедиа, вы можете включить ссылку на «пресс-кит», который содержит ваши санкционированные мультимедиа.
# 5: Пресс-релиз должен быть написан официально. Это, по сути, профессиональное раскрытие информации, а не случайные посты, создающие бренд-пост.Вы также пишете для людей, которые могут не знать вашу отрасль, поэтому сведите к минимуму отраслевой жаргон или дополнительные предположения или данные. Если вам нужно ссылаться на конкретные статистические данные, обратитесь к анализу тематического исследования на простом английском языке, который поддерживает вашу точку зрения. Во всех случаях вы должны писать от третьего лица.
Распространение пресс-релизов
Вы можете отправлять пресс-релизы на самые разные сайты. Вы всегда можете отправить их напрямую на чаевые для таких сайтов, как Forbes, Fast Company, HuffPost или BuzzFeed News.Однако чаще вы хотите отправлять их на сайты, которые, в свою очередь, рассылают их по всем своим спискам заинтересованных сторон. Зачем отправлять пресс-релиз на один сайт, если вы можете отправить его на один сайт, который затем отправляет его на 100?
Список, который я собрал ниже, полностью сфокусирован на сайтах, на которые можно свободно размещаться. Как вы можете ожидать, есть много сайтов, которые будут рекламировать ваш пресс-релиз, если вы платите им, но не принимаете бесплатные материалы. Возможно, я расскажу об этом в другом посте.
У бесплатных сайтов есть свои недостатки. Во-первых, они часто наводнены другими компаниями, которые представляют свои собственные пресс-релизы. Сложно найти хорошие сайты, которые принесут вам любую прибыль с вашими пресс-релизами бесплатно. Тем не менее, вы всегда должны записывать и измерять свои результаты с любым видом охвата, и представление пресс-релиза не является исключением.
Рекомендую сделать электронную таблицу. В одну колонку поместите ссылку на свой пресс-релиз или хотя бы заголовок выпускаемого вами релиза.В другом случае укажите название и ссылку сайта, на который вы отправляете пресс-релиз. Оттуда выясните, какие показатели вы можете записать — отдельные отслеживаемые ссылки для каждого сайта могут быть полезны — и запишите ваши доходы. Если вы отправляете пресс-релиз на сайт, который возвращает практически нулевой трафик, вы можете исключить этот сайт из списков будущих рассылок. И наоборот, сосредоточьтесь больше на сайтах, которые показывают лучшие цифры.
Все это говорит о вот список из 50 или около того сайтов, где вы можете представить свой пресс-релиз бесплатно. Я постараюсь отметить несколько существенных деталей о них, где есть что-то, что выделяет их. Кроме того, дайте мне знать в комментариях, если вы обнаружите, что какой-либо из этих сайтов исчез. Я бы хотел, чтобы этот список был отфильтрован и обновлен в максимально возможной степени. Аналогично, если у вас есть сайт, с которым у вас была хорошая производительность в прошлом, не стесняйтесь рекомендовать его.
Список бесплатных пресс-релизов
- PR Срочно — известно, что публикации на этом сайте доходили до Новостей Google.Они имеют несколько ограничений по содержанию и не допускают изображения в своих пресс-релизах.
- Онлайн PR Новости — Бесплатные материалы на этом сайте остаются в сети в течение трех месяцев. Платные представления имеют дополнительные преимущества и увеличивают время жизни.
- PR Журнал — Бесплатные материалы включают в себя распространение, разрешить ссылки и могут быть помечены с отраслевыми и местными тегами
- PR — Бесплатное представление работает, но снижается в соответствии с представлениями от платных членов.
- PR Внутри — очень голый сайт, который, тем не менее, получает некоторое воздействие.
- 1888 Пресс-релиз — Бесплатная подача пресс-релизов очень ограничена, без активной рекламы.
- 24-7 Пресс-релиз — При бесплатной регистрации ваш релиз отправляется журналистам, зарегистрированным на их стойке СМИ.
- Free-Press-Release — Бесплатная регистрация получает некоторые основные преимущества с этим сайтом.
- Market Press Release — Количество бесплатных заявок ограничено одним в день.
- OnlyWire — технически не пресс-релизы, это представляет ваш контент в различные социальные сети.Бесплатные аккаунты ограничивают социальные профили.
- OpenPR — бесплатные материалы рассматриваются только в рабочее время. Этот сайт также имеет немецкую версию.
- PR9 — Этот сайт посвящен различным темам, но не имеет большой конкуренции.
- PR Free — В дополнение к бесплатному представлению пресс-релизов, вы также можете распространять контент на этом сайте, если хотите.
- Pressbox — пресс-релиз, посвященный материалам в Великобритании, но открытый для глобальных выпусков.
- Пресс-релиз — Этот сайт может быть или не быть активным; кто-то попробует и дайте мне знать в комментариях.
- PR Mac — в прошлом материалы собирались крупными новостными сайтами. Некоторый уклон к новостям Apple.
- BizEurope — сеть подачи пресс-релизов, ориентированная на Европу.
- UK PR Wire — Этот сайт для пресс-релизов, посвященный Великобритании, имеет бесплатную регистрацию только для зарегистрированных благотворительных организаций и благотворительных организаций.
- NPR — Национальное общественное радио всегда принимает материалы, достойные новостей, хотя глобальные новости всегда будут в центре внимания.
- BusinessWire — ориентированный на бизнес новостной сайт, который принимает пресс-релизы, хотя вам необходимо подать заявку на членство для отправки.
- MediaPost — медиа-ориентированный сайт, принимающий пресс-релизы.
- TMCNet — специализированный сайт, который принимает пресс-релизы, а также освещает некоторые темы, которые другие сайты не имеют, например, криптовалюты.
- PR Sync — на этом сайте есть опция испаноязычного в дополнение к английскому.
- MeriNews — новостной сайт, на котором вы можете отправлять темы для обсуждения, последние новости, достойные фотографии или даже просто статьи. Сосредоточена на Индии.
- Free PR Now — очень простой агрегатор пресс-релизов, который публикует все релизы на своей домашней странице.
- Pitch Engine — технически не бесплатно, вы получаете 14-дневную бесплатную пробную версию их обслуживания.
- BriefingWire — Не совсем бесплатно, но плата в 3 доллара практически ничего.
- Пресс-релиз Ping — Еще один базовый сайт подачи пресс-релизов.
- ClickPress — сайт, на котором вы можете отправлять как новости, так и пресс-релизы.
- Transworld News — этот сайт использует сторонний сайт FindIt для управления отправками.
- Бесплатный центр пресс-релизов — простой сайт пресс-релизов, который примечателен тем, что на нем были созданы как PDF-релизы, так и публикации в блогах.
- Сообщение для пресс-релиза — Сайт с небольшим трудом для чтения и бесплатным распространением пресс-релизов.
- PR Fire — еще один сайт пресс-релизов, посвященный Великобритании, с широким спектром категорий.
- NewPressRelease — еще один сравнительно небольшой агрегатор пресс-релизов.
- EWorldWire — служба распространения пресс-релизов с размещением пресс-релизов.
- ArticleCirculation — Очень маленький и довольно новый сайт.
- SubmitPressRelease123 — Нет, сейчас я не просто придумываю имена.У этого есть бесплатный аккаунт, но в основном платные услуги.
- Easy Press Release — относительно небольшой и медленный сайт пресс-релиза.
- The Open Press — довольно мягкий сайт пресс-релизов с географическими тегами.
- Пункт пресс-релиза — сайт пресс-релиза, на котором есть списки сайтов пресс-релизов.
Дополнительные нишевые PR-сайты
Это дополнительные места для размещения пресс-релизов для конкретных узких ниш. Отлично, если ты уместен, бесполезен, если нет.
- Nanotech Now — Представление пресс-релиза для новостей конкретно о нанотехнологиях.
- Beta News — новостной сайт, в основном посвященный техническим новостям, с формой для отправки пресс-релиза.
- RTIR — нестандартная форма представления пресс-релиза, она связывает вас с радио и телевизионными интервью.
- Томас — не просто какой-то парень по имени Том, этот сайт посвящен проектированию и анализу данных.
- Yumpu — не строго пресс-релизы, этот сайт позволяет создавать журналы, которые могут получить разоблачение на их странице.
- Местные новости — Заслуживает внимания тот факт, что является .biz, который не является вирусом, и посвящен Южной Флориде.
- ScoopAsia — сайт пресс-релизов, посвященный азиатским странам, с большим количеством английского контента.
- BusinessPortal24 — европейский портал пресс-релизов с версиями для нескольких стран и языков.
- Web Know How — своего рода комбинация хоста пресс-релиза и учебного сайта в стиле eHow.
- Венгрия News Wire — Для тех из моих читателей, которых я знаю, живут в Венгрии.
Итак, поехали. 50 бесплатных пресс-релизов сайтов. Из них, ну, вы можете догадаться, что только дюжина из них стоит использовать, но эй; это то, за что вы платите. Если вы хотите хорошие сайты, вам придется платить за экспозицию.
Одной из странных практик «обычной» разработки программного обеспечения, с которой я когда-либо сталкивался, является цикл тестирования после выпуска. Это то, что сбило меня с толку с тех пор, как я впервые увидел это; вы проходите нормальный цикл разработки, включая тестирование, затем развертываетесь в рабочей среде, а затем снова тестируете его. Иногда с тестовыми примерами, которые не были сделаны во время разработки. Зачем?
Это не ракетостроение.Есть простые шаги, которые вы можете предпринять, чтобы устранить необходимость в «тесте взлома» после развертывания.
(Предостережение: этот совет предназначен для размещенных или серверных приложений — тип, который входит в одну контролируемую среду, а не тот, который попадает на настольное или мобильное устройство)
Разверните ту же сборку приложений в своих предварительных тестовых средах, которые вы внедрили в производство.
Если это та же сборка, то шансы на то, что у вас появятся ошибки во время пост-релизного тестирования, намного меньше.У вас та же логика приложения — отличается только конфигурация среды.
Наличие согласованной сборки означает, что вам нужно вывести внешнюю конфигурацию — у вас нет сборки UAT по сравнению со сборкой с системным тестом или со сборкой prod — у вас просто есть сборка prod (и, возможно, сборка разработчика, которая поддерживается скаффолдингом) ).
Предварительная версия тестовой среды
Конечно, если вы собираетесь создавать согласованную сборку с помощью предварительных тестовых сред, вам необходимо иметь предварительные тестовые среды.Это шаг, который ни одна профессиональная команда разработчиков программного обеспечения не должна пропустить — но потом я продолжаю слышать, как большой процент команд разработчиков также не использует контроль версий.
Предварительные тестовые среды должны быть сопоставимы с производственной средой. Та же ОС, та же версия сервера приложений, если возможно, тот же тип памяти и оборудования, и аналогичная топология сети для взаимодействия с другими сервисами. Это не обязательно должно быть в точности — особенно для больших кластерных сред.Но это должно быть сопоставимо.
В этом вам помогут виртуальные серверы, по крайней мере, если вы готовы смириться с накладными расходами на управление средой виртуальных серверов. Кроме того, если вы используете облачные серверы для производства, то использование облачных серверов для тестирования системы и UAT — это довольно просто.
Есть сервер сборки
Чтобы получить согласованную сборку для запуска тестовых сред до выпуска, вам нужно , чтобы иметь сервер сборки.Без сервера сборки вы получите непоследовательные сборки. Удалите потенциальный источник ошибок с помощью автоматизации. (Это будет общая точка, поэтому я надеюсь, что вы обратили внимание)
Использовать тестовые данные типа prod
И лучшими тестовыми данными, подобными продукту, являются производственные данные (конечно, должным образом очищенные от идентифицирующей или конфиденциальной информации). Вы не можете превзойти реальные производственные данные, чтобы обнаружить неожиданные проблемы.
Автоматизировать процесс развертывания
Один из доводов, которые я слышал в поддержку тестирования после выпуска, заключается в том, что «вам нужно убедиться, что все правильно развернуто».Оказывается, это не так. Что вам нужно сделать, это автоматизировать процесс развертывания. Это можно проверить столько, сколько необходимо — в предварительной версии. Но в производстве вы должны ожидать, что это сработает.
Используйте инструменты и оснастку для проверки производственной среды
Еще один аргумент, который я немного уважаю, заключается в том, что если приложение будет взаимодействовать с другими службами (и давайте посмотрим правде в глаза, это становится все более распространенным в наши дни), вам необходимо убедиться, что вы можете общаться с этими службами.Но использование производственного приложения для этого — неправильная идея.
Хотите узнать, имеет ли ваше приложение правильное сетевое подключение для связи с другим приложением? Используйте тестовый жгут — с рабочего сервера — для отправки запросов другому приложению. Хотите убедиться, что ваше приложение взаимодействует с удаленным сервисом по правильному протоколу? Опять же, используйте тестовые ремни.
Подобные тестовые комплекты не должны быть написаны с нуля. Они должны быть выведены из той же кодовой базы, что и ваше приложение; с хорошим дизайном кода, вы должны быть в состоянии взять любую критическую часть вашего программного обеспечения и обернуть вокруг него тестовый набор.Особенно это касается фасадов для внешних систем. Делая это таким образом, если ваш тестовый комплект работает, вы должны ожидать, что реальное приложение будет работать.
Автоматизировать любые тесты после выпуска релиза
Если вы действительно думаете, что должен выполнить тест после релиза, то автоматизируйте его. Это означает, что вы получите непротиворечивый тест, вы сделаете его быстрее, и у вас будет больше уверенности в том, что он тестирует то, что вы хотите. Ручное тестирование после выпуска подвержено ошибкам, особенно если вы выпускаете релизы в нерабочее время.
Кроме того, если вы сделаете это, вы должны сделать это так, чтобы вы могли запускать его в любое время, а не только после выпуска. Эти автоматические тесты на дым должны быть вашими первыми, когда вы увидите непредвиденные проблемы в производстве.
Автоматизируйте ваши предварительные регрессионные тесты
Существует абсолютно нулевая точка в наличии комплекта ручного регрессионного тестирования . Автоматизируйте много. Если вам понадобится в десять раз больше времени, чтобы автоматизировать его, чем тестировать вручную, вы окупите его примерно до десятого выпуска.
Ручное тестирование должно быть зарезервировано для поисковых испытаний.
Использовать динамический мониторинг работоспособности
Хорошая надежная система должна иметь мониторинг работоспособности. Вы должны быть в состоянии получить информацию о том, как работает приложение — может ли оно увидеть базу данных? Может ли он подключиться к внешнему провайдеру платежей? Есть ли ошибки в журналах? Удовлетворяет ли это цели производительности и реагирования или SLA?
Такие системы мониторинга занимают немного времени для сборки.Они платят за себя, уменьшая частоту и продолжительность неожиданных простоев.
Мониторинг приложения после выпуска
Когда вы начнете работать, вы увидите проблемы, о которых раньше не думали. Вы получите сумасшедшие входные данные, медленные клиентские сетевые соединения, ошибки ввода-вывода, которых вы не видели раньше, и так далее. Вы хотите очень внимательно следить за своим приложением после выпуска, чтобы убедиться в отсутствии проблем.
Мониторинг — это не то же самое, что тестирование. Все дело в том, что вы отслеживаете то, о чем не думали.Если вы могли подумать об этом в первую очередь, протестируйте его в предварительной версии.
Никогда не запускает тест впервые в производстве
Если у вас должен быть пост-релиз тест, и он должен быть ручным, пожалуйста, пожалуйста, не оставляйте его до пост-релиза, чтобы запустить его. Если вы не запускали этот тестовый пример в предварительной версии, не запускайте его в prod.
Если вы не уверены, что это сработает, не выпускайте его
А если ты уверен, зачем тестируешь?
Нравится:
Нравится Загрузка…
Похожие
Автор: Роберт Уоткинс
Меня зовут Роберт Уоткинс. Я являюсь разработчиком программного обеспечения и работаю уже более 20 лет. В настоящее время я работаю на людей, но мои мнения здесь никоим образом не поддерживаются ими (что круто; их мнения не поддерживаются и мной). Мои основные профессиональные интересы — разработка Java с использованием Agile-методов, с историческим акцентом на создание веб-приложений. Я также фанат Mac и люблю свой iPhone, для которого я сейчас учусь программировать.Я живу и работаю в Брисбене, Австралия, но я вырос в Северной Территории и все еще нахожу Брисбен слишком холодным (после 22 лет здесь). Я женат, у меня двое детей и один кот. Моя политика склонна к социализму, моя религиозная принадлежность атеистична (иначе говоря, «ничего из вышеперечисленного»), мое отношение снисходительно, и мое моральное положение ложится. Посмотреть все сообщения Роберт Уоткинс
,Как написать пресс-релиз, который конвертирует
Создание и распространение жизненно важных новостей вашего бренда — важная часть того, как вы остаетесь актуальными в умах средств массовой информации и широкой клиентской базы. Но пресс-релиз может сделать гораздо больше, чем просто рассказать кому-то о вашей компании.
В этой статье мы обсудим четыре ключевых элемента для написания пресс-релиза, который конвертирует:
- Анонс новостей
- Мультимедийные вложения
- Качественные ссылки
- И социальные сети
1.Определите ясное и интересное объявление о новостях
Цель вашего пресс-релиза — напомнить СМИ, вашим клиентам и другим предприятиям, почему ваша компания актуальна. В анонсе новостей это должно быть с самого начала выпуска.
Чего достигла ваша компания за последнее время? Какие новые продукты или услуги вы предлагаете? Как вы были признаны лидером в своей отрасли? Эти вопросы могут указать направление вашего пресс-релиза, чтобы объяснить, как и почему ваша компания влияет на вашу отрасль.
Если конкретное новостное объявление сложно зафиксировать, начните с основ:
- Кто является центром новостей? Какая организация или частное лицо является источником этих новостей?
- Что такое новостной анонс? Какое событие, веха или изменение компании происходит? Вы предоставляете советы или анализ?
- Где эта новость происходит? Если вы проводите мероприятие, где оно будет проходить? Если вы анонсируете новый сайт, где люди могут найти вас в Интернете?
- Когда эта новость происходит? Это сегодня или на следующей неделе? Если это наступает, почему читатели должны заботиться об этом сейчас?
- Почему важна для вашего читателя? Как это влияет на них?
Самый важный аспект, который нужно помнить при создании вашего новостного объявления, заключается в том, что речь идет не только о вас или вашем бренде.Ваша аудитория должна с самого начала понять, почему ваш пресс-релиз важен для них. Так что пишите свой релиз с учетом вашей аудитории.
2. Используйте мультимедийные активы для привлечения своей аудитории — и избегайте скучных их
В эпоху контента страницы результатов поиска (SERP) завалены потенциальными ссылками, по которым пользователи могут щелкнуть. В 2016 году HubSpot сообщил, что 43 процента читателей просматривают онлайн-контент. Это означает, что двое из пяти читателей могут даже не прочитать ваш пресс-релиз в полном объеме.Так как же вы их поддерживаете? Используйте мультимедиа.
Мультимедиа может быть разных форматов:
- Логотипы компании обеспечивают визуальное представление вашего бренда.
- Фотографии вашей компании на различных мероприятиях буквально отражают лицо вашей торговой марки.
- Инфографика демонстрирует опыт вашего бренда в вашей отрасли.
- Видеоролики обеспечивают привлекательный визуальный и звуковой клип, чтобы рассказать вашей аудитории, что им нужно знать о ваших новостях.
В том же отчете HubSpot указано, что пользователи с большей вероятностью используют видео в полном объеме (55 процентов), чем любой другой вид онлайн-контента. Так зачем играть в СМИ или потенциальному клиенту, читающему весь ваш пресс-релиз? Добавьте видео, чтобы закрепить ваше новостное объявление.
3. Оптимизируйте свой выпуск с помощью высококачественных ссылок
Несмотря на то, что новостное объявление является наиболее важной частью качественного пресс-релиза, одного этого может быть недостаточно для привлечения журналистов и читателей к вашему бизнесу.Встроенные гиперссылки и обычные текстовые URL-адреса могут предоставить дополнительную информацию, которую вы можете не найти в коротком пресс-релизе.
Призыв к действию (CTA)
CTA является сердцем вашего освобождения. Вы не хотите, чтобы люди читали ваш релиз. Вы хотите, чтобы они приняли действенное решение в поддержку вашей компании. Включите ссылку на призыв к действию, которая выполняет следующие действия:
- Приходит сразу после первого абзаца или леде. Не хороните эту ссылку в конце выпуска.
- — это простой текстовый URL: http://www.myawesomewebsite.com/why-you-should-go-here. Интернет-пользователи, как правило, доверяют обычным текстовым URL-адресам больше, чем встроенным ссылкам, поэтому, если вы просите кого-нибудь нажать на вашу ссылку и предпринять какие-либо действия, скажите им, куда они идут.
- Попросите своего читателя предпринять конкретные действия: поделиться, написать в Твиттере, подписаться, зарегистрироваться… Что бы вы ни хотели, чтобы ваши подписчики сделали после того, как они прочитали ваш релиз, спросите их напрямую. Не просто дайте им ссылку и надейтесь, что они пойдут по ней.
Информационные ссылки
Если у вас есть другие информационные веб-страницы или статьи, на которые вы хотите направить читателей, вы можете использовать их в основной части своего выпуска. Придерживайтесь от одной до трех информационных ссылок, чтобы избежать бомбардировки вашего читателя потенциальными кликами.
Boilerplate Link
Включите одну ссылку на домашнюю страницу вашего бренда в шаблон выпуска. Почему только один? Потому что направление пользователей на вашу домашнюю страницу только говорит им, где они могут вас найти.Это может быть полезно в будущем, но не требует от них принятия конкретных мер. Вот почему мы размещаем ссылку CTA в начале выпуска.
4. Поделитесь своим пресс-релизом в социальных сетях, чтобы расширить охват
Следует понимать, что качественный пресс-релиз направлен на то, чтобы привлечь внимание журналистов и других представителей СМИ. Однако это также возможность оставаться в курсе событий у потребителей или журналистов, которые уже следят за вашей компанией.
Размещение вашего релиза на различных платформах вашей компании в социальных сетях может привести к вовлечению вашего релиза в виде лайков, публикаций или ретвитов, тем самым увеличивая потенциальное влияние и аудиторию пресс-релиза.
Помните, что разные части вашего пресс-релиза могут служить различным целям социальных сетей:
- Разместите свои изображения на Facebook, Twitter и Pinterest.
- Делитесь видео на YouTube, Facebook и Twitter.
- Чирикать ссылки на инфографику, чтобы предоставлять управляемую данными информацию для ваших подписчиков.
Благодаря хорошо продуманному новостному сообщению, стратегически размещенным мультимедиа и ссылкам, а также соответствующим кампаниям для публикации ваших новостей в социальных сетях ваш пресс-релиз будет готов привлечь СМИ и других читателей. Таким образом, структурирование пресс-релизов принесет больше внимания, чем просто привлечет внимание к вашему бренду. Каждый аспект релиза должен быть включен в конечную цель ваших читателей , предпринимающих действий .
