#вопрос_ответ
 
Q: Как обычно выстроен процесс согласования технического контента? 
 
A: Типовая схема согласования:
 
1. ок от непосредственно эксперта-автора – в случае, когда контент генерит деврел/редактор/специально обученные люди
 
2. ок от хэда деврела (или кто лидит эту функцию в компании)
 
3. ок от прямого руководителя эксперта – чтобы был в курсе и подтвердил, что нигде не переврали, ничьи политические чувства не затронуты
 
4. ок от руководителя направления, в котором работает эксперт; например, для доклада по разработке – от СТО; для продуктовых историй – от CPO

5. ок от безопасников
 
6. ок от пиара 
 
===
 
В зависимости от контекста компании и обстоятельств, можно убирать шаги (иногда бывает, что добавлять)
 
Из тех, кто может добавиться – ещё какие-то стейкхолдеры деврела. Например, CEO в этом сезоне хочет держать руку на пульсе технического контента; попросил показывать ему все история для публикации наружу
 
Каждый шаг в схеме требует предварительной договоренности. Например, СТО может в гробу видать согласования контента, тогда нужен будет человек вместо него с достаточными полномочиями.

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

===
 
Задать свой вопрос про деврел – приносите в форму или личку @adolgushev. 
 
===
 
👍 – согласовываем похожим образом
🤔 – согласовываем вообще по-другому
❤️ – о, пригодится такой список, спасибо!
🤬 – не согласен ни по одному пункту
🔥 – я – тот, кому приносят на согласование
🤯 – публикуем всё как есть, без согласований