Comments 5
По роду занятий тоже сталкиваюсь с задачей коммуникации об изменениях в системах.
К сожалению, коммуникация по вашему формату может подходить не всегда…
Например в моих релизах для SAP нужно рассказать о 100 ченджах каждый месяц… возникают забавные моменты:
- желательно не рассылать 15 писем на каждую функциональную область — пишем одно письмо на всех, каждый фильтрует ченджи которые касаются только его.
- всю суть каждого ченджа можно описать максимум одной строкой в таблице. Иначе слишком много информации. Так что очень много вопросов остается без ответа..
- И конечно же окончательный список ченджей готов за 16 часов до гоулайва )
Ну и еще я сталкивался один раз с коммуникацией о новой системе, которая строилась поставщиком, а не сотрудниками…
Это было фиаско, братан…
вместо делай-раз-делай-два инструкции для пользователя о том как поднять инцидент в сапорт — получили маркетинговый материал о приемуществах системы.
Так что сотрудники все-таки понимают кому и что надо коммуницировать немного лучше поставщиков.
Видимо вам просто попался человек, который сидел не на своем месте. И такое бывает. вчера был ведущим технологом — сегодня стал ключевым пользователем, который должен налаживать коммуникации. Совсем другая работа!
Спасибо за конструктивный комментарий!
По поводу писем со 100 ченджами, наверное вы имеете ввиду что-то типа Release Notes. Это немножко другое. Release Notes это все же техническая коммуникация для технически-подкованных пользователей. Мы же про то, как объяснить не сильно подвинутому в технологиях ключевому пользователю (кассир, бухгалтер, менеджер…), что в его работе поменялось.
(Плюс не писать про все и сразу нам помогают таргетированные рассылки для пользователей с разными ролями. Технологам — одни, системным администраторам — другие, пользователям — третьи. Ведь каждого из них касается только часть).
Главное помнить, что мы хотим рассказать о ключевых (а в идеале одном ключевом) изменениях, вошедших в релиз, а не обо всех фичах.
Маркетологи здесь могут вам помочь, так как они, во-первых, на это заточены (и тут дело не в рекламе, а в вычленении главного), а во-вторых, человеку, который глубоко включен в проект зачастую это сложно.
Но на наш взгляд идеальная схема выглядит следующим образом — менеджеры проекта готовят драфт, проверяют его на ключевом пользователе, и отдают маркетологам на финальное облагораживание. Понятно, что это требует времени, но ведь для этого релизы и планируются.
Все варианты — трагитрованные рассылки, «причесывание» маркетингом — это требует времени.
а я уже писал, что финальный скоуп релиза готов за 16 часов до гоулайва (в которые хотелось бы поспать сходить ))))
Причины для такого позднего подтверждения банальные: где-то не успели финальный тест доделать напр., где-то наоборот срочный чендж всплыл
Так что нет возможности в такое короткое время выпускать сложную коммуникацию.
В итоге, создаем один шаблон, наполняем его за пару часов и рассылаем на всех пользователей. Чай не детский сад — в экселе могут по одному полю фильтрануть.
Так что, безусловно, для малого объема ченджей можно позволить себе красивую коммуникацию.
И, да, вы правы, я коммуницирую на более прокачанных пользователей — «ключевых пользователей». Если писать на всех юзеров, такой формат не подойдет.
Фичи да — пишите актуальные в Release Notes. Кстати, как мы автоматизировали формирование Release Notes, рассказывали вот тут.
Коммуникация привязана не к фичам, а к ключевому функционалу. Поэтому
- это инструмент далеко не для каждого релиза
- не важно, сколько изменений было в релизе. Мы о главном только пишем.
Поэтому если интересующее нас изменение не случился в этом релизе — значит коммуникация будет ждать того релиза, когда он выйдет.
Не надо усложнять! Или как редполитика помогает продвигать ваши решения пользователям