Редактура и худсовет (в IT)

Спасибо, что на текущий 2023-й момент ощутимое количество людей уже знают, что такое редполитика.

Это базовый документ, в том смысле, что он описывает основные принципы и подходы. Как мы работаем, что мы делаем, чего мы не делаем, как следует строить процесс, чего следует избегать. В каких-то организациях он структурно превращается в свод правил, где-то — в чеклисты, где-то в дизайн-документы. Принципиальная суть примерно одинакова. У кого-то на уровне «кавычки ставим», у кого-то на уровне «мир захватываем».

Примеры русскоязычных редакционных политик для изданий заботливыми руками Ильяхова собраны например тут: http://rdpk.ru/

За редакционную политику отвечает главред. Как правило, РП это не тот документ, который можно придумать и навязать «сверху» (см https://maximilyahov.ru/blog/all/pelevin/), скорее правила и подходы формируются, кристаллизуются и попадают в свод правил по уже построенному процессу работы (главредом), и исходя из практики достижения тех или иных целей. В конкретной конторе.

Тема сама по себе многогранная и познавательная. Любое взаимодействие внутри команды или наружу в рынок — это человеческое общение (в технической форме). Значит, кому любопытно — правила по общению, как явление, неплохо бы изучить на примерах, лишним не будет.

Но мы сейчас про IT.

Если взглянуть практически, роль главного редактора (или выпускающего редактора) в группе разработки выполняют либо один из лидов (дев лид, тех лид), либо ПМ/ПО. Эти люди по достижению промежуточных точек в разработке проверяют, что выпускаем: то ли выпускаем что хотели, то что требовалось, можно ли вообще это выпускать, есть ли несоответствия желаемого с действительным.

• Если есть документ(ы), описывающие требования, методы, и подходы — хорошо. Написанное в них в значительной степени перекликается с составом редполитик; потому что служит схожей цели и задачам. Хотя и не только им, разумеется.
• Если документов нет, то решение принимается на глаз — на выпуклый опытный глаз лида или ПМ/ПО. Фактически, выпускающий выполняет роль главреда по отношению к труду команды.

Даже code review — это во многом та самая редактура (как, почему, почему так, как делаем, как не делаем), прочие инфраструктурные и архитектурные решения тем более.

Дальше результат работы разработки возьмут себе в работу QA, приемка, интеграторы, остальные. Для разработки они выступают аудиторией, а разработка — издательством, в смысле публикации результатов своей работы, как творческого труда.

Отсюда важная мысль первая: принципы и подходы, которые используются в работе с редполитикой — и в работе по редполитике — очень рекомендую изучить как явление, впитать, и творчески осмыслить.

Как я уже писал, важность документа, где написано «надо делать как нужно, а как не нужно — не нужно» не в том, что он перечисляет баяны, а в том, что он формализует принципы и ожидания для людей. Чего Васе ждать от Пети, и как работать Пете, чтобы к нему не было потом вопросов.

Важная оговорка от мэтра, из его издательской среды: если документ не нужен, всё и так работает — значит документ не нужен, не изобретайте себе синтетику. Понадобится, дорастёте — сделаете.

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

Коллизия в чем: очевидно, что стейкхолдерам, руководству и заказчику(-ам) «больше всех надо». По определению. Но в части практической, давать ответ на самые важные вопросы — «что мы делаем» и «не херню ли мы делаем» — высокое руководство не будет давать на каждый вопрос каждой команде, у них обычно своих головняков хватает. Стратегические решения и общую приёмку — возможно, а на тактическом уровне решать бытовые корректировки топ-менеждмент вам не будет.

Решение «группы худсовета» меж тем, достаточно важно принимать быстро, и в процессе (а не по итогам). Чтобы не выкатывать херню на тактическом уровне, и впоследствии резать ее на стратегическом. Тем более, если затронуты какие-то специализированные технические вопросы. Топ-менеджменту обычно искренне насрать, что вы там технически реализуете, если это делается с результатом и в срок. А вот вам с этими решениями дальше жить.

Отсюда важная мысль вторая: удобно и целесообразно иметь рабочую группу умных и опытных людей, которые могут оценить решения, идеи, структуру задач и результатов, где-то на промежуточном уровне для задач и результатов. Эти люди не имеют непосредственно финального права принятия решения — потому что это ответственность лидов и ПМ — но их мнение имеет ценность и вес, а их опыт достаточно ценен, чтобы с ним сверяться.

Опять же, умные и опытные люди имеют обширную эрудицию, технические знания, насмотренность и даже художественный вкус. И чаще всего видели некоторое дерьмо. А также свои знания и опыт уже где-то применяли, чтобы поделиться мнением о подводных камнях, сложных ситуациях, best practices и о возможных «звоночках» технической интуиции (мощнейший инструмент).

Это как раз то место, где должны звучать (аргументированные) мнения «мне кажется, лучше сделать вот так», «мне кажется, вместо АА лучше применить ББ», и «мне кажется, это какая-то херня, потому что ЦЦ».

Хорошей идеей для старта будет собрать в экспертную группу

• технических лидов смежных отделов (они имеют непосредственный технический интерес в решениях),
• ключевых людей от маркетинга и продуктового дизайна (им важен результат и применимость), не обязательно руководство — достаточно уровня лидов,
• ПМ/ПО для координации ожиданий, планов-приоритетов и фокуса разработки,
• людей с релевантным опытом в предметной области, безотносительно положения в структуре компании (мнение о решениях и возможностях надо брать у тех, кто имеет практический опыт и знает грабли)

Но это, разумеется, не догма. Скорее стартовое быстрорастворимое решение.

Аргументацию мнений, кстати, тоже неплохо протоколировать. Чтобы где-то в фоне следом уточнять и проверять. Люди не идеальны, даже умное мнение — всего лишь мнение, а еще опыт бывает нерелевантный и устаревает.

Я для себя в работе разделял референсы и практики примерно так, как делают в доказательной медицине:

• A — проверяемое воспроизводимое рандомизированное контролируемое исследование (обычно: индустриальный стандарт с 10+ случаев использования крупными игроками рынка, и подробно описанными кейсами с примерами),
• B — проверяемое аналитическое исследование из более чем одного источника (обычно: известная описанная практика с 10+ случаев использования, проверяемые результат и методология)
• C — аналитическое исследование или практика с 10+ описанными случаями использования, но не поддающимися воспроизведению, или с нарушениями рандомизации, а также не-формализоваными взаимосвязями (обычно: технология или подход с описанными успешными «рецептами» внедрений)
• D — экспертное мнение, или штучное исследование (обычно это статьи/референсы уровня «я вот такое пробовал, мне помогло, считаю надо брать»)

Чему доверия больше, чему меньше, и так понятно. В классе «экспертного мнения» ничего фатального нет, но проверять мне все-таки нравится больше, чем верить на слово.

Слово «худсовет» имеет невкусный советский привкус, на практике называйте как хотите. Чтобы в процесс не влезли абсурдность и самодурство, достаточно внятно обозначить, что мнение рабочей группы худсовета — совещательное, поскольку ответственность не делегируется напрямую.

Опять же, коммуникация важно. Лучше вы проговорите и осознаете проблемные места в процессе, чем обосрётесь в результате.

Hope that helps.