Случается, что сходные по технике RFC получают разные решения: один принимают, а другой откладывают, потому что различаются цена ожидания, риск, срок или владелец выбора. Рассказываем, почему важно сразу сравнить эти условия, а только затем обсуждать качество архитектуры или технологии. Дисклеймер: в статье лишь один из вариантов решения.
Случается, что сходные по технике RFC получают разные решения: один принимают, а другой откладывают, потому что различаются цена ожидания, риск, срок или владелец выбора. Рассказываем, почему важно сразу сравнить эти условия, а только затем обсуждать качество архитектуры или технологии. Дисклеймер: в статье лишь один из вариантов решения.
В этой статье ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Ben Cartwright-Cox, системный инженер и Лондона, в своем блоге Benjojo рассказал, как путь RFC 9687 занял около трех с половиной лет. Он и два соавтора работали над документом после того, как выявили недостаток BGP4, наносящий вред маршрутизации в интернете. Автор заранее ожидал долгого пути, и его ожидание подтвердилось. И хотя он пишет про открытый стандарт IETF, а не корпоративный RFC, вся эта история поднимает вопрос о цене ожидания.
Техническая часть RFC позволяет вашим коллегам проверить реализацию и компромиссы. Первая страница должна также назвать цену бездействия, затронутых людей или системы, риск, срок и владельца решения.
Malte Ubl, разбирая Design Docs Google, описывает структуру с контекстом, «целями и не целями», с альтернативами и компромиссами. Важно, что это не официальная политика Google и не шаблон, который нужно слепо копировать. Но для любого RFC полезен ограниченный вывод: читатель должен видеть, почему выбран этот конкретный вариант.
Запишите дословно, какое решение приняли: отклонить, вернуться после релиза, сначала проверить гипотезу, нет владельца или «приоритет сейчас другой». Затем выпишите возражения без интерпретации.
Например, фраза «у нас нет команды на миграцию в этом квартале» говорит об ограничении по сроку и ресурсу. Причину отказа нужно выяснить отдельно. Два похожих RFC нельзя честно сравнить без контекста: могли измениться приоритеты, бюджет, доступность команды, накопленный риск или состав решающих людей.
В итоге у вас останется список проверяемых условий решения вместо одного объяснения.
Назовите адресата решения: engineering manager, product lead, архитектурная группа или несколько владельцев с разными зонами ответственности. Спросите: «Кто принимает решение и какой риск нужно закрыть, чтобы выбрать вариант?»
Попросите затронутых коллег назвать ограничение, которое RFC не учитывает, вместо сбора личных обещаний поддержки. К примеру, в GitLab роли assignee (обычно автора) и reviewer разделены, а раннее открытие merge request даёт команде время заметить ошибки и проблемы качества. Этот принцип можно применить к RFC, хотя документация GitLab описывает именно merge request, а не универсальный стандарт.
После этого шага должны быть зафиксированы адресат решения и ограничения, которые предстоит подтвердить: срок, люди, бюджет, безопасность, продуктовый риск или зависимость от другой команды. Готовый ответ может не появиться сразу, особенно если владельцев несколько.
Бесплатная альтернатива курсам тоже есть в этом гайде — перед следующим RFC ответьте в первом абзаце на три вопроса.
В первом экране назовите:
Было: «Платёжный модуль имеет высокую связанность. Предлагается выделить сервис расчёта комиссий».
Стало: «Изменение правил комиссий требует правок в трёх сервисах и ручной сверки. В следующем квартале продукт планирует два таких изменения. Предлагаем до 30 сентября вынести расчёт в отдельный сервис; успехом считаем изменение правила без правок в остальных сервисах и без расхождения в сверке».
Это лишь иллюстрация и не факт, что подобный RFC будет принят. Но такой первый экран позволяет обсудить срок, объём, критерий и способ снизить риск. Проверьте, сможет ли человек вне репозитория понять проблему, ставку и следующий выбор, не открывая технические приложения.
Сравните выбранный вариант, разумную альтернативу и последствия отказа от изменений сейчас.
Для каждой строки назовите срок, стоимость команды, риск и то, что останется нерешённым. Если нет точной оценки, дайте диапазон или отметьте, что нужно исследование.
| Вариант | Срок | Стоимость команды | Риск | Нерешённое |
| Выбранный вариант | ||||
| Альтернатива | ||||
| Отказ от изменений сейчас |
В IETF консенсус не сводят к подсчёту голосов: RFC 7282 предлагает разбирать, остаётся ли у возражения существенная техническая причина. Безусловно, компания не обязана повторять процессы IETF, но сам по себе вопрос полезен: «Что делает этот вариант неприемлемым, а не просто менее приятным?»
До общей встречи покажите первую страницу двум-трём затронутым людям: представителю команды-потребителя, владельцу продукта, специалисту по безопасности или эксплуатации. Выбирайте людей, способных назвать ограничение.
Задайте им один вопрос: «Какое условие помешает вам принять это решение?» Зафиксируйте ответ в RFC и укажите, что изменили. Нерешённое возражение не прячьте в личной переписке. На встрече обсудите уже известные разногласия.
Если хотя бы на один вопрос нет ответа, ваш документ ещё рано защищать. Вернитесь к данным или к разговору с владельцем решения.
Вероятная причина: наблюдения ещё не собраны в проверяемое описание проблемы.
Действие: опишите число ручных шагов, время восстановления, количество затронутых сервисов или конкретный инцидент. Не приписывайте проблеме влияние на выручку. Если наблюдений недостаточно, предложите короткое исследование с датой, после которого появится решение.
Вероятная причина: пока не названы условие возврата или ограничение, которое должно измениться.
Действие: уточните, что должно измениться: закончиться релиз, появиться команда, накопиться определённый риск или освободиться бюджет. Зафиксируйте условие и дату возврата. Если их не удаётся назвать, проверьте с владельцем решения критерий и срок следующего выбора.
Вероятная причина: существенные возражения ещё не отделены от предпочтений и неясно, кто примет выбор.
Действие: выясните, какое возражение делает вариант неприемлемым, зафиксируйте его и назовите владельца решения. Не заменяйте анализ рисков сбором подписей.
Вероятная причина: приоритеты меняются без владельца, ответственность размыта, а инициативы исчезают в согласованиях.
Действие: соберите два-три конкретных примера: предложение, предполагаемого решающего, фактический ход событий и сорванный срок. Затем поднимите вопрос о процессе на ретроспективе или с руководителем. Ещё одна версия RFC и курс по коммуникации этот процесс не исправят.
Перед следующим RFC перепишите первый экран по трём вопросам, заранее узнайте существенные ограничения и покажите альтернативы. Если не удаётся назвать владельца, срок и критерий выбора, сначала нужно диагностировать процесс принятия решения.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.