No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso de Engineering Management

Curso de Engineering Management

Juan Pablo Buriticá

Juan Pablo Buriticá

Demo: RFCs

27/28
Recursos

Aportes 34

Preguntas 4

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

<h1>Título (lee el source code del markdown para ver los comentarios)</h1>

Autores:

  • @githubusername

1 TL;DR

<!–
párrafo corto que explica qué estas proponiendo
–>

2 Motivación

<!–
¿qué motiva esta decisión y por qué es importante?
el propósito de esta sección es articular de una manera sencilla el valor de la decision que vamos a tomar
–>

3 Propuesta de implementación

<!–
Este es el núcleo de tu propuesta, y su proposito es ayudarte a pensar en la solución. Esto debe ser un wireframe, no un documento perfecto con todos los detalles.

Escribir es pensar https://medium.learningbyshipping.com/writing-is-thinking-an-annotated-twitter-thread-2a75fe07fade

  • usa diagramas para ilustrat tus ideas o flujos
  • inluye ejemplos de código si estas proponiendo una interfaz o contrato de sistemsa nuevo
  • agrega links con las especificaciones de proyectos

El proposito de esta sección se resume en:
"Esta es la dirección en la que nos voy a llevar, alguién ve huecos en mi propuesta o tiene comentarios sobre cómo mejorarla?

–>

4 Métricas

<!–
Que métricas debemos vamos a instrumentar, o monitorear para observar las implicaciónes de esta decisiòn?
Por ejemplo, cuando interactuamos con un sistema externo que tipo de latencia esperariamos o si agregamos una tabla nueva que tan rápido se llenaría?
–>

5 Riesgos e inconvenientes

<!–
¿Hay razones por las que no deberiamos hacer esto?
¿Qué riesgos estamos tomando? Por ejemplo, no tenemos experiencia con esta tecnología nueva o no entendemos la escala aún.
–>

6 Alternativas

<!–
¿Hay otras formas de resolver éste problema?
–>

7 Impacto potencial y dependencias

<!–
¿Qué otros sistemas se verán afectados con esta propuesta?
¿Qué consideraciones de seguridad debemos tener?¿Como pueden explotar esta parte del sistema?
¿Que impacto tiene esta decision sobre soporte al cliente?

Aquí buscamos ser concientes del ambiente en el que operamos y generar empatía hacia otros que pueden verse afectados por nuestra decisión.
–>

8 Preguntas sin resolver

<!–
¿ Qué preguntas no hemos resuelto?
–>

9 Conclusión

10 El proceso (elimina esta sección)

<!–
Al escribir un RFC, estas incluyendo al equipo en la dirección que estas tomando. En muchos casos puede haber multiples soluciones, y tambien opiniones diferentes sobre como atacar un problema. Es posible que en el futuro esta propuesta no sea la mejor solución posible, pero aprenderemos de ella.

Como proponente, estas tomando responsabilidad sobre la dirección que quieres tomar y con este documento buscas que tus otros miembros de nuestro equipo contribuyan con sus comentarios acerca de tu idea, pero ultimamente esta decision es tuya y te apoyamos.

En resumen, este documento es:

  • un ejercicio de pensamiento, prototipamos con palabras
  • un record historico, y su valor puede disminuir con el tiempo
  • un mecanismo para
  • una forma de transmitir información
  • un mecanismo para construir confianza
  • una herramienta de empoderamiento
  • un canal de comunicación

Este documento no es

  • una solucitud de permiso
  • un documento que requiere aprobación
  • la representación actual de nuestros sistemas o procesos

–>

  • [ ] Copia este template
  • [ ] Bosqueja el documento, piensa que es un wireframe en prosa
  • [ ] Compartelo con personas de tu equipo para retroalimentación inicial
  • [ ] Envíalo como un pull request
  • [ ] Etiquétalo para que sea facil categorizarlo
  • [ ] Compartelo con todas las personas a quien les pueda interesar
  • [ ] Comunica un limite de tiempo razonable dependiendo de la complejidad de la decisión
  • [ ] Pidele a dos personas que entiendan el probelma que lo revisen por tí, o pidele ayuda a tu manager
  • [ ] Hazle merge con dos +1
<h3>Recomendaciones</h3>
  • Utiliza la etiqueta [WIP] si aún estas refinando detalles
  • Utiliza la etiqueta [newbie] si tienes una propuesta en la que tienes poca confianza por tu conocimiento actual
  • Si hay areas específicas en las que quieres atencion, etiqueta a personas que consideras que saben algo al respecto y preguntales directamente. “María, impacto crees que va a tener este API sobre tu base de datos?”
  • Si tienes dudas, pídele ayuda a tu manager o lider de tecnología
  • Es tu decisión
  • Ten en cuenta la prioridad de las propuestas que estas haciendo, los RFC no son documentos para proponer rearquitecturas o proyectos “cool” que no se alinean con los objetivos a corto plazo de la empresa

Hice un RFC de mejoras en Platzi., si quieres probar tus pull request, hazlo aquí.

Gracias por compartir tan interesante método.
Por si se lo preguntan, TL;DR significa: Too Long, Didn't Read

Muy interesante esta forma de trabajar en equipo y lo voy a poner en práctica en mi dirección.

Yo utilizo correos y reuniones. Pero como lo comentas es complicado tener una buena decisión de esta forma. El líder del proceso es que debo escoger la solución basada en todas las recomendaciones que da el equipo y en mi rol hay que estar pendiente que no vaya a afectar los lineamientos organizacionales.

creo que usar Slack y crear un canal para poder recibir feedback acerca de alguna decisión que se deba tomar, también estaría muy bien, aunque el uso de git y el template de los RFCs esta mejor para un equipo de ingenieros.

Creo que esto está muy bien para equipos enormes con problemas complejos porque es una herramienta efectiva de comunicación. Sin embargo, dependiendo del proyecto, los roles y la envergadura se puede cambiar por otras herramientas de comunicación. Mi industria es el hardware.

Datos:
- Fechas
- Autores
- Backers

1. Summary
2. Motivation
3. Detailed design
	a. Clients
	b. API
	c. …
4. Drawbacks
5. Alternatives
6. Unresolved questions

Hola, apenas me estoy introduciendo al mundo de GitHub y me quede con la duda de a que se refiere Juan Pablo en el punto “Hazle merge con dos +1”

Request for Comments: son una serie de publicaciones del grupo de trabajo de ingeniería de internet que describen diversos aspectos del funcionamiento de Internet y otras redes de computadoras, como protocolos, procedimientos, etc. y comentarios e ideas sobre estos.​​
By: https://bit.ly/3dkK5WH

wooow este sistema es super eficiente evita hacer reuniones constantes con cada problema o propuesta excelente, a partir de ahora intentare adoptar esta buena practica en mi startup.

Super Útil para poner al día a los ingenieros nuevos con la estructura de la infraestructura y los sistemas de la empresa.

Buenisisima la forma de trabajar donde todos interactúan y forman parte de la decisión yo usualmente uso google docs pero eso es muy bueno

Donde guardar los RFCs, en el mismo repo de codigo, o un repo de codigo aparte, o en alguna herramienta aparte que no sea un repositorio?

El proceso que usan en mi empresa no es nada aprecido ya que la responsabilidad cae en el supervisor de area y m uchas veces son peronsas que o bien no buscan la solucion o no saben hacerlo y eso limita al equipo…

Esto me parece super interesante, es volver un estándar un proceso que he ido realizando con el equipo.
Con el equipo vamos desarrollando ideas en un documento y uno es encargado de recoger todos lo comentarios e ir mejorando para las siguientes reuniones.

La filosofía de RFCs me encanta y me hubiera gustado que más exjefes lo hayan implementado en nuestros equipos.

Este sería el repositorio de RFC’s de Rust

Me encanta la estrategia de repositorio de RFCs porque deja un buen historial de discusión y luego consultarlo.

¿ Alguien ha implementado esto usando Jira ó alguna otra herramientas que no sea un versionador?

Wow, ahora si me siento Junior después de ver este ejemplo

Gracias

Excelentes recomendaciones

Excelente manera para ponerlo en práctica.

Super interesante la demo, muchas gracias!

Buena aportacion

Aprendí algo nuevo.

Habilidad desbloquada

Duda, en dónde se deberían guardar los RFC? cuál sería la mejor opción?

Super interesante estos modelos de trabajo.

No entendi muy bien quien toma la decision final de implementar o no algo?

hay muy buen material de apoyo en el repositorio del profe, gracias.

forked 🤘

A ponernos al día …