Привет! На связи Наталья Нефедова — менеджер продукта и head of сообщества техписателей в Cloud.ru.
В 2024 году у нас в компании произошла реорганизация, после которой мы, техписатели, перестали находиться в матричной структуре, а распределились по продуктовым командам («изюм в булке») и нашими руководителями стали менеджеры продуктов. В этой новой реальности экспертиза и профессия техписателя как таковая стали размываться, нам надо было каким-то образом это остановить. И в этом нам помогло сообщество, которое не только обратно объединило профессию техписаталей, но и влияет на бизнес-цели компании.
Наш опыт создания сообщества оказался объемным и насыщенным, поэтому поделюсь им в трех частях. Материал будет интересен, если у вас еще нет сообщества и вы хотите его создать, или оно уже есть и вы хотите попробовать новые механики, чтобы повысить его эффективность.
В первой части расскажу про минусы «изюма в булке» для нашей компании, а также про дизайн и операционную модель нашего сообщества.
Контекст: что такое «изюм в булке» и почему он не работает
«Изюм в булке» — это метафора организационной модели, при которой специалисты одной профессии («изюм») не объединены в отдельную функцию или департамент, а распределены по разным командам («булки») и находятся в линейном подчинении внутри этих команд. В нашем случае после реорганизации мы перестали быть самостоятельным отделом и «сели» в продуктовые команды. Нашими линейными руководителями стали продакт-менеджеры. Формально профессия сохранилась, но исчез центр.
Такая модель кажется удобной, потому что писатель уже глубоко погружен в продукт, задачи решаются быстрее и нет дополнительного управленческого слоя. Но у «изюма в булке» есть предел устойчивости, об этом расскажу дальше.
Эта часть будет особенно полезна тем, кому предстоит обосновать руководству необходимость сообщества в вашей компании.
Что не так с изюмом
Как у любой медали, у модели «изюм в булке» есть обратная сторона. Перечислю те проблемы, которые коснулись именно нас:
Изолированность специалистов. Находясь в разных командах, мы перестали регулярно взаимодействовать друг с другом. Писатель оказался «один в команде» без профессиональной среды и поддержки. Стало сложно отстаивать свои решения в спорных ситуациях, потому что не на что и не на кого опереться. Со временем мы стали реже обмениваться практиками и появилось чувство профессиональной изоляции.
Некосистентность документации и UX-текстов. Когда нет единой точки истины и стандартов, каждая продуктовая команда неизбежно вырабатывает собственные подходы к документации и UX-текстам: появляются разные стили, терминология и уровни детализации. Мы начали получать фидбэк от пользователей о том, что документация от сервиса к сервису будто написана разными командами.
Компаниям с большим портфелем продуктов, у нас, например, примерно 200 сервисов, особенно важно поддерживать консистентность во всех точках касания и единый пользовательский опыт. Документация — часть облачного сервиса. Если она разрозненная и непонятная — это может восприниматься как небрежность в реализации самого сервиса и влиять на решение о его использовании.
Отсутствие центра экспертизы. У бизнеса часто возникают стратегические вопросы по документации: ее архитектуру, стандарты, инструменты, метрики и вообще роль документации в бизнесе компании. В распределенной структуре непонятно, к кому обращаться, ведь нет единой точки входа (руководителя отдела, как раньше), нет владельца стандартов и прозрачного процесса внедрения изменений. Профессия существует, но она не институционализирована.
Размывание экспертизы. Продакт-менеджеры, как линейные руководители, не всегда глубоко понимают специфику профессии техписателя. Отсюда свои проблемы:
найм происходит децентрализованно;
требования к компетенциям различаются;
отсутствует единая карта навыков;
развитие самих техписателей становится непрозрачным.
В результате в компанию попадают специалисты с неподходящим уровнем hard-компетенций. А развитие и карьерный трек текущих писателей получается случайным и неравномерным.
Сложность внедрения инноваций. Любые изменения — новые стандарты, подходы, инструменты, внедрение ИИ — становятся крайне трудоемкими. Ведь каждая команда живет в своем контексте, логично защищает свои процессы и озвучивает свои причины «почему нам это не подходит». Без центра экспертизы и координации инновации либо тормозятся, либо внедряются фрагментарно.
Всегда ли «изюм» не работает (нет)
Модель «изюм в булке» сама по себе не является ошибочной. Во многих компаниях она работает годами без серьезных последствий. Поэтому ключевой вопрос не в том, «нужно ли сообщество», а в том, «насколько риски изолированной модели критичны для вашего бизнеса?».
Профессиональное сообщество может быть избыточным, если контекст такой:
продуктов немного,
консистентность пользовательского опыта не критична,
домен сравнительно простой,
требования к глубине экспертизы писателей умеренные.
В нашем случае все было иначе. Большой портфель облачных сервисов, высокая техническая сложность продуктов и требования к консистентности пользовательского опыта сделали координацию писателей обязательной. В этих условиях изолированная модель напрямую влияла бы на качество сервисов, поэтому мы выбрали создание профессионального сообщества как системное решение.
Дизайн нашего сообщества техписателей
Наше сообщество построено по принципу экосистемы — это не иерархия и не отдел. Мы поддерживаем распределенную среду, в которой все участники взаимодействуют между собой, объединяются вокруг инициатив и совместно принимают решения. При этом экосистема не равна отсутствию структуры. Чтобы сообщество было устойчивым, ему необходим центр координации и лидерства, который удерживает фокус и ритм, — у нас он называется комитетом.
Ролевая модель
Каждый член нашего сообщества помимо своей основной работы в продуктовых командах может брать на себя одну из дополнительных мета-ролей: head of сообщества, лидер, куратор, участник. Здесь важно понимать, что все роли — это именно мета-роли, а не формальные должности. Каждый остается техническим писателем в своем продукте. Сообщество не создает отдельной управленческой вертикали — оно накладывается поверх продуктовой структуры.
Внутри сообщества есть ядро самых активных участников — комитет, который состоит из head of и лидеров. Комитет— это наш центр координации и стратегического фокуса.
Каждая мета-роль в сообществе включает определенный набор функций, которые она реализует. Этот набор функций не является формальным распределением обязанностей «по статусу», а определяется задачами, которые сообщество берет на себя как профессиональный институт.
Head of сообщества | Лидеры сообщества | Кураторы сообщества | Участники сообщества |
Формулирует стратегию сообщества Налаживает коммуникации и процессы Работает со стейкхолдерами Развивает лидеров и кураторов Лидирует стримы по методологии Участвует в найме техписателей | Помогают head of в процессных и оргвопросах Лидируют стримы по методологии Участвуют в найме техписателей | Лидируют стримы в по методологии Онбордят новичков | Лидируют стримы по методологии Участвуют в активностях сообщества |
Здесь важно пояснить чуть шире. Мы не изобретали эту модель с нуля, в основе дизайна нашего сообщества лежит концепция Community of Practice (CoP) — сообщество практики. Это подход, описывающий группы специалистов, объединенных общим доменом, которые регулярно взаимодействуют для обмена знаниями, выработки стандартов и совместного решения профессиональных задач.
Ключевая идея CoP в том, что сообщество строится вокруг практики, а не вокруг иерархии или просто набора каких-то интересов. Отправной точкой становятся задачи, которые необходимо решать для достижения целей бизнеса и самого сообщества:
если нужно формировать стандарты — появляется лидерство стримов,
если нужно развивать профессию — появляются кураторы и карты компетенций,
если нужно обеспечивать устойчивость — появляется стратегическое ядро сообщества.
Теперь пора рассказать, вокруг каких задач и смыслов выстроена операционная модель нашего сообщества.
Операционная модель сообщества техписателей
Итак, мы объединены в сообщество практики (CoP), то есть решаем конкретные задачи. Эти задачи — не что-то выдуманное или абстрактное, они определяются бизнес-целями компании — это важный нюанс. Для нас модель, при которой задачи магнитятся к бизнес-целям компании, стала самой эффективной с точки зрения достижения осязаемых результатов, замера эффективности сообщества и возможности говорить с бизнесом на одном языке.
Домик ниже иллюстрирует операционную модель нашего сообщества — задачи, процессы и ритмы для достижения бизнес-целей.
Стандарты — задачи, которые работают на увеличение удовлетворенности клиентов документацией (CSAT) через консистентный пользовательский опыт.
Развитие писателей и развитие сообщества — задачи, которые работают на показатели удовлетворенности сотрудников (eNPS) и уменьшение текучести персонала.
Центр экспертизы — задачи, которые работают на показатели удовлетворенности сотрудников и на узнаваемость бренда компании.
Операционная модель вашего сообщества скорее всего будет иной, так как будет основываться на бизнес-целях и специфике именно вашей компании.
Далее разберу подробнее, как именно устроена работа сообщества внутри каждого компонента домика — от фундамента до крыши.
Стандарты
Сообщество здесь выступает как источник правил для работы с Docs-as-a-Code, создания документации и UX-текстов.
Главная цель написания стандартов — поддержать консистентный пользовательский опыт в облаке. Для этого мы ведем стримы внутри сообщества:
по созданию стандартов для пользовательской документации на облачные продукты,
по созданию стандартов текстов интерфейсов,
по инновациям — внедрение ИИ, линтеров, новых инструментов.
У каждого стрима есть своя рабочая группа. Каждая группа работает в почти одинаковом паттерне: созвоны для обсуждения и груминга идей, постановка задачи в публичный бэклог, распределение задач, фиксация статусов и договоренностей.
В рабочих группах можно участвовать в роли слушателя, активного участника или лидера стрима.
Слушателем может быть любой технический писатель. Как правило, это писатели, которые присоединились к сообществу недавно и находятся на испытательном сроке.
Активный участник — любой писатель, работающий в компании более 3-х месяцев. Он выбирает задачу из публичного бэклога сообщества, выполняет ее и презентует решение на рабочую группу. После презентует решение на все сообщество, собирает фидбек, дорабатывает и внедряет изменение.
Лидировать рабочую группу может любой писатель вне зависимости от мета-роли. Главное условие — достаточные hard-компетенции. Лидер рабочей группы фасилитирует встречи, делится экспертизой, следит за фокусом, организует и планирует обсуждения.
Но методологию мало написать — ее нужно внедрить. Так как у нас нет иерархии и стандарты не спускаются сверху-вниз, мы вместе обсуждаем новые правила и дорабатываем их по фидбеку от сообщества. Это всегда дольше, чем спустить сверху-вниз, но качество таких стандартов выше, так как методология учитывает интересы максимального количества писателей из разных продуктовых команд.
Развитие писателей
Как я рассказывала в начале статьи, один из минусов «изюма в булке» — продуктовый руководитель неглубоко погружен в специфику профессии техписателя, поэтому сообщество берет на себя помощь в развитии hard- и soft-компетенций писателей и движении по карьерной лестнице. Если техписатель хочет расти, он проактивно приходит в сообщество с этим запросом. За ним закрепляется ментор — head of, лидер или куратор сообщества— для помощи в оценке по карте компетенций (КК).
После оценки по КК ментор помогает составить индивидуальный план развития (ИПР) и продумать движение по нему, а потом на 1:1 проследить, что движение идет в нужную сторону. Ментор не помогает с решением конкретных задач, но направляет, советует и поддерживает писателя на всем пути до окончания ИПР.
Если ИПР завершен успешно, ментор совместно с руководителем техписателя согласовывает изменение должности.
Развитием в профессии занимаются только head Of, лидеры и кураторы — эти роли проходят обязательное внутреннее обучение по методикам оценки по карте компетенций и составлению ИПР. Как правило, head of чаще всего развивает лидеров и кураторов, а лидеры и кураторы — участников сообщества.
Развитие сообщества
Помним, что сообщество — это экосистема, которая сама себя развивает.
Рост сообщества
Растим численное количество писателей в компании не в ущерб качеству экспертизы. Контроль найма позволяет отбирать только тех, кто подходит нашему сообществу и по hard-компетенциям, и по ценностям. Поэтому комитет сообщества техписателей включен во всю цепочку процесса найма:
обсуждаем с продуктовыми командами потребности и профиль писателя,
помогаем командам в составлении описания вакансии,
отбираем резюме,
проводим техническое интервью,
проводим вторые этапы собеседований совместно с продуктовой командой,
согласовываем оффер.
И да, в найме участвуют только head of и лидеры сообщества.
Рост лидерства в сообществе
Растим слой лидеров в сообществе, чтобы оно оставалось распределенной экосистемой, а не структурой, замкнутой на одном человеке (исключаем bus-фактор).
Head Of на встречах с лидерами и кураторами делится опытом, обсуждает сложные стратегические и коммуникационные задачи, иногда делегирует сложные задачи.
Рост экспертизы в сообществе
Создаем безопасную профессиональную среду для обмена знаниями и опытом. Все члены сообщества могут участвовать в конференциях и проходить профильные курсы. Одно «но»: после мероприятия надо поделиться с сообществом новыми знаниями (sharing knowledge) — так рождаются идеи на развитие документации и профессии.
Центр экспертизы
Сообщество как точка входа и источник экспертности для стейкхолдеров. «Изюм в булке» не предполагает единого центра принятия решений и трансляции экспертности — сообщество стало таким центром.
Работа со стейкхолдерами
Head of и лидеры отрабатывают запросы от стейкхолдеров на улучшение процессов и методологии документирования. Например, чтобы получать централизованный фидбек по доке, мы построили кросс-командный процесс с отделом обслуживания клиентов. Также к нам обращаются команды продаж и эксплуатации облака с запросом на улучшение или создание новой документации. Тогда мы формируем бэклог на доработку платформы документации и контента, опираясь на обратную связь от команд, которые напрямую общаются с текущими и будущими клиентами.
Visibility
Head of, лидеры, кураторы и участники сообщества повышают внутреннее и внешнее visibility сообщества техписателей для трансляции экспертизы и поддержания репутации профессии.
Для этого мы проводим внутренние митапы. Например, в 2025 году провели митап «Продакты — Техписатели», где обсуждали вопросы документирования, роль техписателя в продуктовых командах и способы генерации сложных сценариев использования облака. В течение полугода после митапа мы в разы нарастили количество сценариев в документации.
Другой вариант повышения узнаваемости сообщества — внутренние демо на всю компанию, когда head of и лидеры презентуют стратегию и результаты работы сообщества, делятся планами и собирают обратную связь. Еще вариант — участие во внешних конференциях и публикации на Хабр и VC. Так мы делимся экспертизой наружу и представляем наш бренд.
Влияние
Head of и лидеры расширяют зоны влияния и ответственности за профессию внутри компании. Комитет техписателей задействован во всей цепочке найма — от определения потребности до оффера. Повышение должности писателя возможно только после успешного выполнение плана индивидуального развития и согласования с комитетом сообщества техписателей.
Продуктовые команды согласовывают с комитетом повышенные оценки писателям, активно участвующим в сообществе. Оценка влияет на премию.
To be continued
Операционная модель нашего сообщества техписателей строится вокруг реальной профессиональной практики, сфокусированной на бизнес-целях компании, а не вокруг встреч, инициатив «ради активности» или абстрактных обсуждений. По моему мнению, хорошая операционная модель отвечает на четыре вопроса:
Какие системные задачи мы решаем?
Кто за них отвечает?
Какие процессы помогут в решении задач?
Как это улучшает продукт и профессию?
Когда есть ответы на эти вопросы, сообщество становится рабочим механизмом развития компании.
На этом не конец :) В второй части я разберу механики вовлечения писателей в сообщество и удержания их мотивации. Также расскажу про барьеры, с которыми сталкивается в том числе наше сообщество в своей ежедневной практике, и способы их преодоления.