A veces nos preguntan cómo construimos nuevos informes u obtenemos los datos para crearlos, así que pensé en compartir mi perspectiva sobre el proceso.
La creación de un nuevo informe en GitPrime suele comenzar con la solicitud del cliente que se concreta en una típica historia de usuario. O, alternativamente, nuestro CEO Travis dice: «¿No sería genial si pudiéramos ver a partir de los datos…»
Mi formación es en análisis de datos, no en ingeniería de software. Esto puede ser una ventaja porque no tengo ideas preconcebidas sobre los datos que buscamos, y no hay forma de sesgar los resultados que encontramos.
Empezando
Una vez que tenemos un concepto de informe, utilizo varios repositorios de muestra, luego trabajo en RStudio para romper, clasificar y reconfigurar los datos en bruto en archivos y hojas de trabajo csv que me permiten ver los patrones de trabajo de cada ingeniero. Los datos se mantienen anónimos, aislando este trabajo de cualquier detalle sobre los propios desarrolladores. Con estos archivos tomaré promedios, porcentajes y multiplicaré para juntar lo que sucedió en el proyecto durante los últimos seis meses.
Trabajando con los datos (pero sin la historia), intentaré recrear lo que sucedió y descubrir métricas clave que me ayuden a aprender sobre un equipo en particular. Las preguntas de gestión guían el análisis: ¿La gente está reescribiendo un gran porcentaje de su propio código? ¿Esta persona está escribiendo suficiente código para seguir el ritmo del proyecto y del equipo?
Utilizo una variedad de herramientas, incluyendo Excel, RStudio, y una buena pizarra o bolígrafo y papel para tratar de desentrañar descubrimientos, ideas y problemas.
En esta etapa, puedo hablar con un ingeniero de uno de los equipos de nuestra investigación betas para aprender un poco más sobre la base de código para ver cómo los datos que hemos encontrado coinciden con su percepción de la línea de tiempo del proyecto. Aquí es donde ponemos cualquier descubrimiento en contexto, asegurándonos de que nuestras hipótesis sobre los datos se correspondan con la visión de los trabajos de ingeniería reales.
Cuestionando nuestras suposiciones
En cada paso, daré un paso atrás y especularé por qué un ingeniero en particular está superando o perdiendo las expectativas. ¿Se les ha dado una asignación poco clara? ¿Están cerca del final de un proyecto? ¿Estoy simplificando demasiado la pregunta? Estos se refinan en algoritmos que dirigen nuestras visualizaciones de datos, y resaltan si un desarrollador está siguiendo una tendencia o si están cayendo en algún patrón de trabajo discernible.
A menudo una métrica en la que nos hemos centrado mide un aspecto del desarrollo -comprometer rendimiento, productividad neta o enfoque del trabajo- y sólo cuenta una historia parcial. Hay matices que hay que aprender y considerar. Por ejemplo, alguien que se especializa en la corrección de errores escribe menos líneas por cada compromiso, pero a través del proceso de mirar cuántos compromisos se estaban escribiendo podemos ver cuán fuerte e importante es realmente ese desarrollador.
El aspecto más desafiante de trabajar con datos sobre el proceso de desarrollo son los grandes valores que sesgan todo el conjunto de datos. Lo que hace que esto sea aún más desafiante es tener en cuenta el contexto de lo que constituye un atípico: esta noción es inherentemente específica del desarrollador, del proyecto y del equipo. ¿Este enorme compromiso es una importación de la biblioteca, o esa persona realmente revisó algo masivo que escribió? Este proceso de buscar la historia dentro de los datos ayuda a clasificar la señal del ruido a medida que estos valores anómalos comienzan a tener sentido. Esto entonces informa la siguiente pregunta que queremos derivar de los datos.
Ver lo que se pega
Después de muchas notas, hojas de trabajo y archivos, presento mis hallazgos a las pistas del producto para ver si la historia que he podido contar ayuda a resolver algunos de los retos operativos que escuchamos de nuestros clientes.
Si hay una coincidencia, esbozamos las ideas de presentación en una pizarra o con un punzón, apuntando a una versión aproximada de una interfaz que resalte los datos más críticos. Típicamente construiremos una versión de baja fidelidad de esto en Balsamiq para evaluar los flujos, las transiciones y ver cómo se siente.
Si vale la pena continuar con la idea, creamos una versión de alta fidelidad de las composiciones finales en Sketch, a menudo seguida de un prototipo realista en InVision. Cuando está listo, lo socializamos con algunos de nuestros clientes clave para que nos den su opinión. Si pasa la prueba de usuario, ¡tenemos un ganador! El resultado será totalmente especulado, incluyendo toda la funcionalidad del informe, matemáticas complejas, diseño visual, y una cuidadosa consideración de cualquier caso límite que necesite ser manejado.
Tal vez el 20% de las ideas que exploramos alguna vez vean la luz del día. Algunas son caminos falsos y se descartan. Otras parecen conceptos parciales esperando ser incorporados en un gran avance. Algunos son mejoras moderadas y se añaden al atraso. Los excepcionales suben a la cima de la cola para un próximo lanzamiento. Puede ser doloroso tirar semanas de trabajo, pero sabemos que el esfuerzo no es realmente desperdiciado: es todo parte del proceso para construir el reporte más útil y poderoso que jamás haya existido para los equipos de software.