Capítulo 6 Cultura de co-creación

Trabajar profesionalmente en ciencia de datos implica que trabajamos en equipo y por ende necesitamos coordinar y comunicar. Estos procesos no se logran fácilmente y si bien muchas veces hay acciones cargadas de buenas intenciones, estas pueden interpretarse mal y causar descontentos entre miembros del equipo.

Estamos lejos de abarcar un tema tan complejo como el de relaciones entre miembros del equipo, pero podemos aportar una serie de pasos aplicados a grupos de trabajo en ciencia de datos.

Lo importante a saber es que cómo equipo en este campo estamos trabajando creando análisis…

6.1 Permiso para equivocarse

Uno de los valores principales en la cultura de un equipo de datos debe de ser el permiso para aceptar que nos equivocamos. Esto depende no solamente de la honestidad de la persona que cometió el error, sino de un equipo que comprenda que los errores pueden suceder y que está para apoyar y ayudar a resolver.

Cuando alguien comete un error no sirve de nada gastar tiempo en “regaños” que no resuelven el problema. En lugar de esto, es más funcional tomarse el tiempo para escuchar cómo ocurrió el error y tomar nota para que en el futuro nadie vuelva a incurrir en el error. Así mismo es necesario tomar el tiempo para ayudar a la persona que cometió el error para enmendarlo.

6.1.1 Recomendaciones antes errores del equipo

Supongamos un error cualquiera que sucede en el equipo. Vamos a plantear un ejemplo simple para hacer énfasis en un mejor acercamiento a la solución del problema.

Contexto

Un equipo de ciencia de datos está trabajando en el proyecto de análisis de canasta para un supermercado. Para esto el equipo tiene su repositorio y un subconjunto de datos como punto de partida para iniciar el desarrollo.

El equipo acordó que la muestra de datos que tienen la van a compartir entre ellos fuera de git durante el desarrollo inicial del código. Lo harán a través de una carpeta compartida por google drive. Esto lo harán así de manera inicial para no realizar pruebas de desarrollo sobre la base de datos, ya que muchos llamados puede provocar incidencias en la base de datos. Cuando el código se encuentre más maduro y preparado para llevar a producción, realizarán los pasos haciendo la conexión a la base de datos.

Advierten al iniciar el desarollo del proyecto que esta muestra de datos no debe de ser incluida en el control de versiones puesto que si se hace de esta manera, el control de versiones y todas las acciones correspondientes al flujo de trabajo se volverán lentas por el tamaño del archivo de datos.

Sin embargo, durante el proceso de desarrollo, a un miembro del equipo se le olvida colocar la carpeta datos/ en el gitignore. Hace un commit y un push de sus cambios, incluyendo los datos.

Resolviendo el problema

Cuando este miembro del equipo le comenta a su supervisor del error, lo ideal es que entre ambos repasen el proceso que culminó en dicho error. De esta manera pueden prevenir a futuro que vuelva a ocurrir. Un equipo solidifica sus procesos en la manera que adquieren experiencia. Los errores son experiencia y si aprendemos a mirarlos como fallos de nuestros procesos internos y no como culpa individual de un miembro tendremos mayores posibilidades de que todo el equipo no cometa el mismo error a futuro.

Tiene que existir un ambiente de confianza para poder alzar la mano y mencionar el error cometido. Esto se da cuando todo el equipo está bajo el entendido que resolver errores es justamente eso: poner manos a la obra para resolver el error.

Una vez resuelto el problema con git y el repositorio, es necesario que procedan a revisar su procedimiento. Tal vez mencionarlo en una reunión de equipo al inicio del proyecto no es suficiente. Una solución sería poner una pauta en la lista de acciones a tomar y que al inicio del proyecto exista un encargado de escribir el .gitignore antes de que cualquier persona inicie su trabajo. Si este paso se incorpora al flujo de trabajo y actual y futuro será más explícito y ya tenemos un encargado de asegurar la acción correctiva.

¿Qué no hacer?

Enfrascarse en discusiones que lleven a argumentos que no aporten a la solución del problema en el momento y a la corrección del proceso. Buscar culpables no tiene sentido si no es para conocer los pasos que tomó y llevaron al error para así tener insumos y aplicar las acciones correctivas.

6.2 ¿Qué tipo de reuniones se requieren para hacer funcionar un equipo de análisis?

Es necesario para el equipo distinguir entre dos tipos de reuniones:

• Reuniones de seguimiento
• Reuniones de trabajo

Es difícil mantener una separación entre ambas si no estamos bajo el entendido de cuál es el objetivo de cada una de estas. Esto provoca pérdidas de tiempo en el avance de los proyectos. Es necesario hacer una cosa a la vez y a grandes rasgos por un lado necesitamos planificar el trabajo y por otro lado ejecutar. No podemos hacer ambos al mismo tiempo.

• Reunión de seguimiento: Nos sirve máximo 30 minutos para completar esta reunión. En esta se revisan el estados de los tiquetes y el avance del proyecto. Se asignan nuevos tiquetes o se reasignan. NO buscamos detalles del trabajo, buscamos visualizar el camino para avanzar con el proyecto.

• Reunión de trabajo: Si hay un tiquete abierto que requiere ayuda de varios miembros del equipo, se calendariza un espacio de mínimo 1 hora para trabajar en resolver dicho tiquete. Esta reunión sí tiene por objetivo mirar detalles del trabajo y resolverlos.

Reunión de seguimiento	Reunión de trabajo
- Logros	- Discuisión temas específicos
- Objetivos de la semana	- Dudas de tiquetes
- Cronograma del proyecto	- Coordinada entre personas necesarias

6.3 Cultura efectiva: dar y recibir feedback

Para mantenerse al día en cuanto a conocimiento dentro del equipo y garantizar la calidad del código es necesario brindar retroalimentación y recibirla. Debemos de ser enfáticos que la retroalimentación hacia nuestro trabajo no es una critica hacia nosotros como personas, sino hacia nuestro trabajo y se busca siempre la manera en que aprendamos a mejorar nuestro trabajo.

De la misma manera al dar retroalimentación nos debemos de asegurar de ser críticos y técnicos. No podemos hacer críticas que sean subjetivas puesto que no ayudan a mejorar a los miembros del equipo.

Sutilesas en el lenguaje pueden ayudar a que esta cultura sea adoptada por el equipo sin incurrir en desmotivar a los miembros. Algunos ejemplos de frases son las siguientes:

Frase no recomendada	Frase recomendada
¡Ese código no funciona!	Me puedes explicar cómo funciona su código
Tienes que corregir ese filtro	¿Qué pasa en la linea 324 cuándo hacer el filtro?
Ud haga esta tarea	¿Me podrías ayudar con la ejecución de esta tarea?
¿Porqué está implementando ese código que está mal?	El código puede mejorar si lo hacemos de esta manera puesto que es más eficiente en tiempo

6.3.1 Revisando código

Usualmente, en revisiones de código, el autor inicia explicando la idea y el desarrollo de su solución. Si interrumpimos con frecuencia es muy probable que cortemos el flujo de la explicación y duremos más tiempo en la revisión. Por ende recomendamos que quién explica el código y la solución tome un tiempo para realizarlo sin interrupciones. Quién está para ayudar a dar retroalimentación, debe de tomar nota de los números de línea en los cuáles han surgido dudas.

Una vez que el autor del código finalizó su explicación, es tiempo para el revisor de hacer las preguntas. Con los números de línea es fácil ubicarnos en el punto exacto de la duda. Este método suele ser más ágil y rápido que si hacemos las preguntas apenas se nos vienen a la cabeza. Así mismo puede ser que la duda que tengamos sea respondida más adelante en la explicación del código.