Toma de Decisiones Transparente Entre Equipos usando RFCs
Title
Toma de Decisiones Transparente Entre Equipos usando RFCs
Patlet
Los proyectos InnerSource que buscan alcanzar altas tasas de participación y tomar las mejores decisiones posibles para todos los involucrados. Por ello necesitan encontrar formas de crear sistemas participativos a lo largo de todo el ciclo de vida del software. La publicación de documentos internos de Solicitud de Comentarios (RFC-Request for Comments) permite discusiones desde el inicio del proceso de diseño y aumenta las probabilidades de construir soluciones con un alto grado de compromiso de todas las partes involucradas.
Problema
Para que un proyecto InnerSource prospere, necesita una cantidad sustancial de contribuyentes. Estos contribuyentes (o equipos) pueden tener diferentes requisitos para el proyecto dado. Por ejemplo, pueden querer agregar características al proyecto que no sean compatibles entre sí o que conduzcan a una sobrecarga no saludable en la arquitectura.
Descubrir tales desacuerdos o malentendidos tarde en el proceso, por ejemplo, una vez que el software ya ha sido construido, es muy costoso. Estos desacuerdos pueden llevar a frustraciones por parte de todos los involucrados e incluso pueden ser perjudiciales para la salud de la cultura de colaboración en el proyecto. Una situación común donde surge tal desacuerdo es una solicitud de cambio (pull request) que está abierta durante mucho tiempo porque el autor de la solicitud de cambio y los mantenedores del proyecto esencialmente no están de acuerdo en que el cambio propuesto deba realizarse.
Para un proyecto InnerSource, esta situación ocurre con más frecuencia cuando el proyecto es mantenido por múltiples equipos en la empresa, es decir, propiedad compartida.
Historia
Un proyecto, o aplicación compuesta por múltiples proyectos, es mantenido por varios equipos diferentes, con cada equipo siendo dueño de diferentes áreas del proyecto o aplicación. Estos equipos hacen contribuciones InnerSource a las áreas de los demás, pero los cambios más grandes y transversales solo son impulsados por los líderes técnicos de los equipos trabajando juntos, o no ocurren en absoluto. Esto resulta en que la mayoría de los ingenieros no pueden efectuar cambios a gran escala y transversales, reduciendo la innovación y las oportunidades de colaboración.
Al implementar un proceso y una plantilla para RFCs, los equipos e individuos están empoderados para proponer cambios grandes y transversales a través de un proceso de toma de decisiones transparente, con consultas entre equipos realizadas de manera asincrónica. Esto resulta en una mayor innovación, una colaboración más estrecha y una mayor difusión del conocimiento. Esto depende del compromiso de todas las disciplinas en todos los niveles y de un entorno de seguridad psicológica para que las personas puedan proponer y debatir ideas abiertamente.
Como con cualquier proceso, este debe mejorarse continuamente. Puede ser necesario realizar cambios en la plantilla o el proceso de RFC para garantizar que sea inclusivo, colaborativo y efectivo.
Contexto
propiedad compartida por muchos equipos de un proyecto InnerSource
las decisiones de diseño generales no pueden ser tomadas por un cuerpo central todo el tiempo (por ejemplo, un grupo de arquitectos) ya que no tienen suficiente tiempo ni conocimiento específico del dominio para tomar buenas decisiones en todos los casos
varios tipos de usuarios tienen aportes sobre la dirección que está tomando un proyecto determinado. Dichos usuarios pueden ser: Desarrolladores, Propietarios de Producto, Gerentes de Producto, etc.
las decisiones deben tomarse de manera asincrónica, al menos en parte, ya que no es factible convocar reuniones sincrónicas frecuentes con todos los participantes
hay un deseo de documentar las decisiones tomadas, es decir, asegurarse de que se hagan por escrito, en lugar de solo verbalmente
Resistencias
la mayoría de las veces, las partes involucradas quieren tomar una decisión bastante rápido (por ejemplo, el tiempo de diseño inicial es bastante limitado)
escribir las cosas (sin ya implementarlas) a menudo es una habilidad nueva para muchas de las personas involucradas
Esquema
Soluciones
Elementos importantes de la solución son:
Una descripción de cuándo publicar un RFC (y cuándo no)
Una plantilla para documentos RFC
Debe provocar que el autor del RFC considere su propuesta desde múltiples ángulos
Debe solicitar tanto una visión general accesible de alto nivel como una explicación detallada en profundidad
Un proceso ligero y bien conocido que rodea a los RFCs, por ejemplo
Cómo publicar un RFC y compartirlo con todos los interesados (por ejemplo, Slack, lista de correo)
Cómo recopilar comentarios para el RFC
Cómo trabajar en los comentarios
Cómo llevar el RFC hacia una conclusión o decisión (por ejemplo, mantenedores nominados relevantes para aprobar)
Herramientas apropiadas elegidas (por ejemplo, los no ingenieros pueden no tener acceso a herramientas de control de versiones)
Un compromiso para iterar en la plantilla y el proceso de RFC
Ejemplos/Plantillas
Contexto Resultante
Implementar un proceso similar a RFC ha demostrado ser valioso, ya que hace que el proceso de toma de decisiones entre equipos sea más transparente para todos, permitiendo que todas las voces sean escuchadas.
Efectos positivos observables:
democratización del proceso de toma de decisiones para decisiones que impactan a muchos equipos (también descargando a los líderes de equipo de esa carga)
un método de comunicación asincrónica abierta que funciona bien entre múltiples equipos y geografías
empodera a individuos y equipos para efectuar cambios a gran escala
registro de decisiones tomadas para que las personas puedan consultarlas para obtener contexto
aumenta el impacto de los ingenieros experimentados ya que pueden contribuir a soluciones de manera asincrónica y remota, en lugar de necesitar estar presentes en una reunión
alineación de terminología por ejemplo, al explicar nuestra terminología de pruebas como "¿qué es una prueba de sistema?"
alineación de procesos por ejemplo, al explicar el proceso de soporte fuera de horario
mayor claridad de pensamiento, ya que escribir un RFC hace que el autor se desafíe a sí mismo más de lo que normalmente lo haría
El enfoque de RFC también tiene riesgos que queremos señalar:
¡No siempre funciona! por ejemplo, algunas personas pueden seguir argumentando en contra de una decisión que ya se tomó a través de un RFC. Sin embargo, tener el proceso de toma de decisiones por escrito sigue siendo beneficioso en estos escenarios, ya que puedes señalar cuándo y por qué se tomó una decisión determinada.
Un RFC puede volverse grande y demasiado complicado. Esto a menudo se muestra en largos hilos de comentarios y discusiones que lo rodean. En esas situaciones, podemos decidir complementar el RFC con comunicación sincrónica, como un grupo de trabajo y reuniones en persona. Pero aún se ahorra tiempo, ya que las personas pueden leer el RFC antes de la reunión en lugar de tener toda la información compartida durante la reunión.
Justificación
Instancias Conocidas
Estado
Estructurado
Autor(es)
Tom Sadler
Sebastian Spier
Aliases
Registro de Decisiones de Arquitectura (ADRs) - No necesariamente un alias directo, ya que a veces pueden usarse de manera muy diferente, por ejemplo, RFCs para buscar aportes y construir consenso, ADRs para registrar decisiones y detalles de implementación
Histórico de Traducciones
Última actualización
¿Te fue útil?
