No existe el tamaño perfecto para un circuito de retroalimentación
Cuanto más redactaba esta publicación, más sentía que debería estar escribiendo algún tipo de TL; DR para ciertas personas que leen esto. Entonces, en un esfuerzo por ahorrar tiempo, aquí está:
Estoy escribiendo esto para aquellos que son nuevos en el trabajo por cuenta propia, la gestión de proyectos o, en general, tienen menos experiencia que aquellos que preguntan "¿Por qué estás escribiendo esto?" En última instancia, es algo que la mayoría de nosotros aprendemos en algún momento de este industria, pero si podemos ayudarnos unos a otros a acortarlo más temprano que tarde, todos saldremos beneficiados.
Si aún está interesado después de leer la nota anterior, supongo que está buscando mejorar en este aspecto de la comunicación. Lo cual es bueno, porque yo también lo soy 😏, y usar un pequeño circuito de retroalimentación es una forma en la que descubrí hacerlo.
Cada industria tiene un poco de su propia jerga y muchos de nosotros nos reímos de eso, sin embargo, todos seguimos usándola en un entorno profesional. Somos divertidos de esa manera.
De todos modos, en nuestra industria, una de las frases que usamos mucho, incluido yo mismo, es "ciclo de retroalimentación". La primera vez que me encontré con la frase fue con respecto a la retroalimentación de los amplificadores. No tenía nada que ver con el software. No obstante, en lo que hacemos generalmente lo usamos para referirnos a él como:
- enviar una solicitud, comentario o información general a un cliente,
- recibir una respuesta del cliente respecto a dicha información.
Y para aquellos que no están acostumbrados a la idea (porque hay quienes hacen "lanzamientos big bang" de los que hablaré en un minuto), los bucles de retroalimentación generalmente se consideran pequeños o grandes.
Cuanto más he trabajado en software, más busco siempre un pequeño ciclo de retroalimentación sin importar qué.
El ciclo de retroalimentación perfecto
Un ciclo de retroalimentación pequeño significa que existe una comunicación frecuente entre una empresa y el cliente (por lo tanto, naturalmente, un ciclo de retroalimentación grande es cuando hay una comunicación menos frecuente).
Si vas a usar jerga, al menos piénsalo de alguna manera divertida, ¿verdad?
¿Pero conoces toda esa jerga que mencioné al comienzo del artículo? En una conversión normal, solo diría:
Cuando se trata de trabajar en un proyecto, prefiero una comunicación más frecuente.
Y la razón por la que prefiero esto e incluso lo prefiero es porque cuando se trata de crear una solución, independientemente del tamaño, para otra persona, siempre hay partes móviles que considerar.
Cuando hay múltiples partes en un proyecto, hay múltiples puntos de lugares donde algo podría necesitar ajustes o cambios (o que pueden afectar el sistema en general) y hacerlo bien temprano en lugar de tarde ahorra mucho tiempo (y por lo tanto dinero) y estrés para la mayoría de las partes involucradas.
¿Y qué?
Sin embargo, ¿por qué molestarse en escribir sobre esto? Para mí, la razón es que cuanto más tiempo dirijo una tienda pequeña, más escucho de los clientes sobre los problemas que surgen con la falta de claridad, comunicación y gestión de proyectos en proyectos anteriores.
Gorrón. No quiero ejecutar ese tipo de operación. Así que es algo fácil de arreglar, ¿verdad?
Además, la industria del desarrollo está llena de personas que tomarán los requisitos de un proyecto, asumirán que entienden todo lo que se necesita y luego regresarán solo para haber construido algo que no solo no cumple con el objetivo sino que se parece un poco a lo que el cliente pretendía.
Esto no es necesariamente un golpe para los programadores, pero todo ese "[perder] el objetivo" se puede arreglar si simplemente nos comunicamos con aquellos con los que estamos trabajando con un poco más de frecuencia.
No asumas que sabes lo que quieren.
En su lugar, haga preguntas, aclare el requisito, trabaje en la función y luego preséntelo al cliente en un entorno de prueba. Sabrán si has construido lo que te han pedido. Si es así, entonces a la siguiente función. Si no, hay más trabajo por hacer. Operar de esta manera agiliza gran parte de los puntos de tensión que surgen en los proyectos.
Y sí, hacer muchas preguntas puede volverse tedioso e incluso molesto. Vaya cosa. Mencione desde el principio que va a hacer muchas preguntas para comprender completamente el problema antes de intentar resolverlo. Da una razón de por qué estás haciendo lo que estás haciendo. Tiende a pagar bien.
Lanzamientos de Big Bang
Anteriormente en la publicación, mencioné "lanzamientos big bang" y esto generalmente se refiere a la idea de un cliente que le proporciona requisitos, usted vuelve a trabajar en él durante semanas seguidas, luego regresa y dice "Oye, yo Ya terminé, ¡échale un vistazo! solo para descubrir que está muy lejos.
Si tuviera que contextualizar esto dentro de un tipo de ciclo de retroalimentación, diría que no hay uno. Ni siquiera es grande porque no se solicitó ningún comentario. Es simplemente:
- Estos son los requisitos para el proyecto,
- He terminado con el proyecto.
Muchas veces, esto lleva a que los desarrolladores malinterpreten los requisitos, que los clientes no conozcan el progreso y que el proyecto en general se desvíe. En pocas palabras, no lo hagas de esta manera.
¿El tamaño perfecto?
No sé cuál es el tamaño perfecto de un circuito de retroalimentación. Hay algunos clientes con los que he trabajado donde hay registros diarios, hay algún lugar donde hay registros semanales, y hay algunos que han dicho "simplemente complete esto y avíseme cuando haya terminado".
Los registros semanales, compromisos, lanzamientos, etc. tienden a ser mis favoritos, pero eso se debe al tamaño del proyecto y al tamaño del equipo con el que trabajo. Diariamente tampoco está mal dependiendo de la tarea.
Nunca hago el estilo big bang incluso si un cliente dice que está bien. Todavía me gusta tener puntos de control para mi propia cordura. Entonces, cualquier tipo de circuito de retroalimentación que funcione mejor para usted, su equipo y su cliente tendrá el tamaño perfecto.