Какую проблему мы решали
Наверное, с этого отзыва о команде началась история о том, как мы начали искать действенные способы уведомить коллег из соседних команд, чем все-таки занимаются технические писатели в нашей компании. Но обо всем по порядку.
Привет, я Лиза, и.о. тимлида команды технических писателей в ЕДИНОМ ЦУПИС. Как и многие технические писатели (далее – TW) я не раз на своем опыте сталкивалась с проблемой, что границы должностных обязанностей TW всегда очень размыты и непонятны даже коллегам из разработки и тем более коллегам из бизнес-подразделений. Но, пообщавшись со специалистами из соседних областей – разработки, тестирования, дизайна, я узнала, что с этим явлением в какой-то степени сталкиваются все. Мало встречается людей, к которым заказчики не приходили с какой-то совсем не профильной задачей и убеждением «ну ты же [подставить название профессии], разве это не твоя работа?». Или как в диалоге выше, коллеги из соседних команд приносили очень абстрактные задачи в духе «сделай красиво», а как это красиво – «ну ты же специалист, ты должен знать».
Конечно, в основном эти проблемы решаются на уровне выстраивания процессов в компании, а в случае TW еще и выстраиванием документационной культуры. Но даже при отлаженных процессах и высоком уровне документационной культуры подобные инциденты случаются. Далее я расскажу на примере команды TW о решении, которое нам помогло частично закрыть эту проблему и принесло неожиданные плюшки. Это решение не так уж специфично, и, на мой взгляд, его могут применять разные команды, не только TW.
Такой диалог с заказчиком стал для нас первым звоночком: кажется, мы очень закрыты для коллег, и они не знают пределов наших компетенций. А потом в процессе сбора обратной связи по команде мы получили отзыв из вступления: «Не всегда понятно, что в целом делает команда, кроме своих задач. Возможно, мало транслирует это вовне». Были, конечно, и положительные отзывы о нашей отзывчивости, скорости, работы с позиции поддержки и т.д., но графа недовольств тоже не пустовала. У нас к командам разработки, которые являются нашими основными заказчиками, тоже к тому времени накопился список «недовольств»: нам приносили абстрактные задачи, задачи не по нашему профилю (для контекста: внутреннюю документацию в компании ведут не только TW, но и все команды, а значит в нашей зоне ответственности находится большая часть документации, но не вся). Часто приносили задачи без описания, хотя у нас есть шаблон, по которому мы просим создавать задачи. А еще наш труд нередко просто оставался «невидимым» для других команд.
Как распутать этот клубок взаимных недовольств? Этот вопрос был вынесен на командное ретро по итогам квартала. Совместно с нашим проектным менеджером решили сделать следующее:
актуализировать внутренние инструкции по стандартам документирования и явно напомнить о них заказчикам;
провести внутреннее обучение для всех желающих на тему «чем занимаются TW в компании»;
актуализировать внутренние инструкции по стандартам документирования и явно напомнить о них заказчикам;
создать памятку для заказчиков о том, с какими задачами они могут к нам обратиться, а с какими мы не сможем им помочь;
регулярно присылать в общий чат новостные дайджесты с результатами нашей работы, новостями команды и актуальными напоминаниями заказчикам.
Но все из этого, кроме дайджестов, – разовые акции, поэтому на дайджесты я сразу возложила большие надежды. А чтобы надежды оправдались, нужно было подойти к написанию дайджестов как следует.
Подготовка и запуск дайджестов
В первую очередь мы еще раз четко проговорили цели этих публикаций:
повысить осведомленность команд-заказчиков о нашей деятельности;
сделать наш труд более «видимым»;
регулярно напоминать о стандартах документирования в компании, не прибегая к административному ресурсу.
Затем мы выбрали формат и периодичность публикации исходя из целей и возможностей команды. Так как в среднем за неделю мы закрываем 12-16 задач, многие из которых объединены общей тематикой (например, 5 задач по проекту N, из которых 3 на внутреннюю документацию, а 2 – на партнерскую), мы выбрали периодичность раз в две недели. В нашей памяти еще будут свежи закрытые за этот период задачи, а объединение задач по тематикам позволит вместо скучного отчета в духе «мы сделали задачи с 1047 по 1065» написать «мы сделали 5 задач по проекту N, над которым, как вы знаете, трудится вся компания». Акцентировать, что наша команда работает над теми же проектами, что и команды-заказчики – это отличный способ выведения работы команды «из тени».
Писать дайджесты мы решили всей командой, но с одним «главным» автором – дежурным по дайджесту, который меняется каждые две недели. Так все члены команды вовлекаются в активное соавторство, а дайджесты получаются разнообразными.
Кроме организационных моментов мы подготовились и в области теории: провели командный шеринг знаний о том, как правильно писать дайджесты. Писать мы, конечно, умеем, но в формате дайджестов никогда не практиковались, поэтому все были заинтересованы в подготовке. Один из членов команды подготовил небольшой теоретический доклад: как должен быть написан хороший дайджест, какая у него может быть структура и т.д. Доклад мы выслушали, обсудили, посмотрели несколько примеров хороших и близких к нашему формату дайджестов. И тут же написали наш тестовый дайджест, который состоял из:
хештега с названием нашей команды, чтобы его можно было легко найти в общем чате;
короткого приветствия и диапазона дат, за которые пишем дайджест;
нескольких пунктов, резюмирующих проделанную работу: «за эти две недели мы сделали а, б, в»;
call to action: закрывающего блока с призывом не забывать пользоваться шаблоном при создании задач для TW (со ссылкой на шаблон).
В процессе этого упражнения мы сразу зафиксировали несколько правил. Например, что использовать специфичные в кругах TW слова по типу «вычитка» в дайджестах не стоит, так как мы стремимся быть понятыми широким кругом читателей, хоть и в рамках своей компании. И что писать надо почти (но не совсем) в стиле SMM-щиков из [одной небезызвестной компании с авиабилетами]. А еще что стоит использовать в качестве буллитов эмодзи – почти во всех примерах современных дайджестов это чуть ли не обязательное условие (если только вы не суперстрогая компания, конечно).
И последние этапы подготовки:
создали отдельный чат для обсуждения дайджестов, чтобы не засорять основной командный чат;
определились с датой и временем публикации: среда – чтобы рабочая суматоха конца и начала рабочей недели не затмевала дайджесты, 14-15 часов – чтобы сообщения приходили в относительно свободное время до/после/во время обеда;
зафиксировали правила и все договоренности по дайджестам в закрепе свежеиспеченного чата;
назначили первого ответственного автора (им оказалась я), время публикации черновика и содержание первого дайджеста:
Что (уже) получилось
Дайджесты в общем чате встречены другими командами очень позитивно, по крайней мере реакций-огонечков они набирают приличное количество. Особенно мое сердце греют огонечки от тех, кто в квартальных отзывах был недоволен нашей командой? Но это просто реакции, а какие улучшения от дайджестов мы получаем на практике?
Выросла статистика посещения страниц с инструкциями по процессам документирования в базе знаний. Как минимум, напоминать об этих процессах заказчикам в формате дайджестов получается. Желаемая программа максимум – чтобы все эти процессы еще и применяли на практике, к этому мы еще стремимся. Но подвижки есть, например, несколько ответственных заказчиков стали применять наш любимый шаблон при создании задач! Это уже сильно упрощает нам жизнь и оптимизирует рабочие процессы.
Улучшились отзывы о команде. В итогах квартала после запуска дайджестов мы не получили от команд-заказчиков негативной обратной связи о том, что команда непонятно чем занимается. Наоборот – почти все отзывы были про нашу вовлеченность и проактивность. На мой взгляд, дайджесты сыграли в этом не последнюю роль.
Повысился командный дух. Это не было изначальной целью создания дайджестов, но стало очень приятным бонусом. У всех членов команды появилась возможность и мотивация посмотреть на работу не только с точки зрения своих задач, а на работу команды в целом. Мне как тимлиду это тоже полезно – теперь вовлеченность в командные дела у всех выше, а значит есть возможность лишний раз посоветоваться по каким-то верхнеуровневым вопросам с командой. Еще плюс – теперь ребята могут посмотреть на работу своих коллег не только с позиции «послушаю на дейлике, кто чем занимается», а непосредственно увидеть результаты работы другого человека, собирая информацию для дайджеста по закрытым на прошлых неделях задачам. Ну и кроме прочего, писать что-то коллективом авторов – это весело! Моя любимая шутка из дайджестов – про удода:
Получается, что у команды есть регулярная рабочая активность, которая больше похожа на игру, но при этом приносит пользу и внутри, и снаружи команды. Win-win.
Какие есть минусы и подводные камни? В первую очередь, самое банальное: тратим время, которое можно было бы потратить на задачи. Но так можно сказать про все организационные и командные активности. Если они приносят пользу и оптимизацию рабочего процесса, то это точно не впустую потраченное время. А второе – дайджесты писать сложно, по крайней мере, без должной подготовки. Читателям может наскучить формат, авторы могут выдохнуться, запал может пропасть, и пользы тогда поубавится. Именно поэтому мы провели такой подготовительный этап и организовали поочередное авторство – все же дайджесты у нас получаются разными, хоть пишем мы об одном командном деле. Кто-то уделяет больше внимания структуре, кто-то добавляет забавные шутки, кто-то (я) больше фокусируется не на проделанной работе, а на теме взаимодействия с другими командами. И каждый наш дайджест получается особенным, с уникальным авторским стилем.
Вывод можно сделать такой: если ваша команда «закрытая», если есть необходимость, чтобы коллеги из соседних команд и/или заказчики знали, чем вы занимаетесь, то дайджесты – это отличный инструмент для решения этой задачи. Он регулярный, он может преподноситься в развлекательной форме, но решать практические задачи, а его создание позволяет команде отвлечься от своих текущих рутинных задач и реализовать свой творческий потенциал. Главное в дайджестах (как и в документации, которую пишут TW) – это целеполагание и понимание своей аудитории.
А какими способами вы выводите свои команды из зоны «невидимости»? Используете ли дайджесты или другие инструменты? Поделитесь своим опытом в комментариях!
