Mas leido
Building Stories
Modo Rua: Redefiniendo el desarrollo de aplicaciones mediante iteración centrada en el usuario Ago 23
Building Stories
NuStories: Adaptación de productos para clientes fanáticos en varios países Oct 30
Culture & Values
Cómo los valores y la cultura de Nu dan forma a los productos que creamos Ago 7
Carreras
Reunimos a grandes mentes de diversos orígenes que permiten la discusión y el debate y mejoran la resolución de problemas.
Conoce más sobre nuestras carreras
Contribución: Arthur Kamienski, Caique Lima, Sarah Malaman, Vitor Pinheiro
Introducción
Los profesionales de la Ciencia de Datos (DS) y el Aprendizaje Automático (ML) dependen de muchas herramientas, aunque esto no siempre sea inmediatamente obvio. Siempre que importamos una biblioteca a un cuaderno de Python o ejecutamos comandos como grep, find y sed en sistemas tipo UNIX, estamos usando y beneficiándonos de una herramienta que otra persona escribió.
Pero también podemos escribir nuestras propias herramientas. Las herramientas suelen surgir cuando alguien detecta una funcionalidad repetida en múltiples productos o proyectos. El instinto natural del programador es extraer el comportamiento común en un lugar separado para evitar la duplicación y facilitar los cambios futuros. Así nace una biblioteca de software.
El uso de herramientas como bibliotecas (pero también aplicaciones, plataformas y aplicaciones de línea de comandos basadas en UI) en toda una organización es algo común en las empresas de tecnología modernas. Esta estrategia suele denominarse abastecimiento interno. Si bien ofrece ventajas considerables, también conlleva desafíos que requieren una cuidadosa consideración.
En esta publicación enumeraremos las lecciones que aprendimos a lo largo de los años utilizando herramientas internas en Nubank. Estas lecciones no se refieren sólo a puntos técnicos, sino también a cuestiones subjetivas a las que se debe prestar atención para garantizar el éxito de estas herramientas, tratándolas como productos internos.
El artículo está dirigido a equipos que crean y mantienen herramientas internas para que las utilicen otros equipos, especialmente aquellos que tienen en mente casos de uso de DS y ML.
Comenzaremos resumiendo los porqués de crear herramientas internas con una breve descripción general de los tipos principales, luego enumeraremos las lecciones que consideramos más importantes, sin ningún orden en particular.
Descubre las oportunidades
¿Por qué crear herramientas internas?
Construimos herramientas porque nos hacen más efectivos y eficientes. Esto es cierto a nivel individual y especialmente a nivel organizacional, ya que hay muchos fenómenos emergentes y no lineales que solo tienen lugar una vez que se alcanza cierta escala.
Las herramientas impulsan la estandarización
Las herramientas aumentan el impacto de las soluciones locales
Las herramientas codifican el conocimiento tácito
Las herramientas reducen riesgos y errores
Las herramientas disminuyen el TTM
Tipos de herramientas internas
Al fin y al cabo, las herramientas de software son sólo otra pieza de código. Pero si miramos más de cerca, existen diferentes tipos de herramientas con respecto a la interfaz que exponen a los usuarios y las capacidades que brindan. Cada uno de ellos desempeña un papel separado en una organización tecnológica.
Una distinción clave es la de herramientas tacticas vs estratégicas: aquellas que generalmente se utilizan como máximo en 1 o 2 equipos y aquellas que pueden ser compartidas por toda la organización — convirtiéndose potencialmente en un activo clave para una empresa.
Los tipos principales: Aplicaciones, Bibliotecas y Plataformas basadas en UI y de Línea de Comandos.
Es fácil ver la diferencia entre las aplicaciones basadas en UI y las de línea de comandos, pero este no es el caso entre las bibliotecas y las plataformas: Una diferencia clave es que las plataformas generalmente requieren que uno haga todo lo posible por ellas. Normalmente no puede elegir qué partes de una plataforma quiere usar — o las usa todas o no. Compare esto con las bibliotecas: puede usar varias bibliotecas al mismo tiempo, mezclándolas y combinándolas de varias maneras, pero una vez que elige una plataforma, se queda con ella.
Otra diferencia es que una plataforma suele ser obstinada; se toman decisiones de diseño claras y usted debe aceptarlas si decide utilizarlas. Por esta razón, las plataformas son excelentes para imponer la estandarización y los patrones organizativos que todos los equipos deben seguir.
Una vez terminada la introducción, profundicemos en el meollo del artículo.
Las herramientas internas son productos y deben gestionarse como tales.
Las herramientas internas son productos y deben gestionarse como tales. Hay que pensar en los usuarios internos como clientes — lo que a veces resulta difícil debido a la proximidad y la informalidad de las operaciones del día a día.
Lo ideal sería contar con gerentes de producto dedicados que comprendan e interactúen con los usuarios y establezcan prioridades en función de lo que necesitan. Si eso no es posible, al menos debería haber personas con habilidades de gestión de productos en el equipo.
Lo mínimo que necesita para gestionar un producto interno es: una hoja de ruta clara, comentarios estructurados de los usuarios y un buen canal de soporte.
Los ejemplos y una buena documentación ayudan a reducir la necesidad de soporte personalizado. Además, asegúrese de que los usuarios sepan cómo buscar en Slack respuestas a preguntas frecuentes.
La evangelización es clave
Casi nadie quiere aprender otra herramienta más — especialmente si las ventajas no son evidentes de inmediato. Debemos practicar activamente la evangelización, promoviendo la herramienta entre los posibles usuarios.
En algunos casos, la adopción de una herramienta puede exigirse a través de enfoques de arriba hacia abajo, como incorporarla en Objetivos y Resultados Clave (OKRs) u otros marcos corporativos de establecimiento de metas. En estos escenarios, probablemente no haya mucha necesidad de evangelizar. Pero ese no es nuestro enfoque aquí: preferimos crear herramientas que los usuarios quieran usar, porque ven valor en ellas — no porque se les imponga.
Desde el punto de vista de los clientes, utilizar una nueva herramienta significa tener que aprenderla y tal vez cambiar algún aspecto de su trabajo.
Esto puede ser una barrera importante, porque las personas generalmente se resisten al cambio, especialmente cuando implica modificar un flujo de trabajo al que están acostumbrados y en el que son competentes. Aquí entran en juego varios factores: percepciones sobre la seguridad laboral, problemas de ego y pérdida percibida de influencia. Las personas no quieren dejar de lado algo que pasaron dos años dominando, especialmente si creen que eso les confiere estatus dentro de la organización.
Según nuestra experiencia, es mejor mostrar valor primero. Si lo hace bien, la decisión de adoptar su herramienta será obvia y sencilla. Aquí es cómo:
Registro, instrumentación y comentarios de los usuarios
Al crear herramientas internas, existe un riesgo real de que simplemente asumamos que sabemos qué necesitan los usuarios y cómo utilizan nuestras herramientas.
Utilice datos en su lugar. Sin datos, la gestión de productos se reduce a una toma de decisiones basada en corazonadas, lo que la convierte en una tarea puramente política donde gana la opinión de la persona mejor pagada (HiPPO).
La recopilación de información permite al equipo de mantenimiento comprender cómo los usuarios utilizan las herramientas: ayuda a medir la satisfacción del cliente, pero también a detectar áreas de enfoque en las que se deben concentrar los esfuerzos, lo que hace que el mantenimiento sea más efectivo.
Vemos dos formas principales de recopilar información: implícita y explícitamente, a través de instrumentación del sistema y encuestas, respectivamente. Cada uno proporciona información desde un ángulo diferente y ambos tienen ventajas y desventajas, como veremos a continuación.
Dos formas de recopilar datos de uso de herramientas: implícitamente (registros, instrumentación, paneles) y explícitamente (encuestas de usuarios)
Recopile datos implícitamente mediante registros e instrumentación. Todos los lenguajes de programación admiten el registro, que luego se puede visualizar en herramientas como Splunk o Grafana. La principal ventaja de la retroalimentación implícita es que es imposible fingir — pero requiere trabajo para configurarla.
A continuación se muestran algunos ejemplos de la información que se puede obtener mediante el registro:
Por otro lado, las encuestas a los usuarios son buenas para obtener comentarios explícitos, -– siempre y cuando los usuarios se sientan cómodos con ello. El principal riesgo es que los clientes internos eviten dar comentarios honestos y, a veces, negativos por temor a la política de la oficina y a las represalias. Las encuestas de usuarios deben ser anónimas para evitarlo.
Al elegir encuestas al estilo Google Forms, tenga en cuenta el tiempo de sus clientes: Incluya todo lo posible en un formulario breve — las personas tienen mejores cosas que hacer que responder una encuesta de 20 páginas sobre su producto.
Prefiera preguntas con respuestas clasificadas numéricamente (por ejemplo, escala Likert) para permitir comparaciones a lo largo del tiempo y ser lo más específicas posible: “En una escala del 1 al 5, ¿cuánto diría que la herramienta X ha aumentado su productividad al realizar la tarea Y?”.
Finalmente, asegúrese de incluir 1 o 2 preguntas abiertas para permitir opiniones y consejos generales de los usuarios.
Los ejemplos son el mejor tipo de documentación.
Tener documentación es un requisito común para las herramientas internas — especialmente cuando es necesario atender a usuarios no técnicos.
Sin embargo, redactar una buena documentación cuesta mucho y, sobre todo, mantenerla. Agregar funciones a las herramientas siempre tendrá prioridad sobre la actualización de los documentos. Entonces las herramientas evolucionan y la documentación se queda atrás.
El camino habitual para la documentación de herramientas es volverse obsoleto con el tiempo y morir lentamente, llegando finalmente al punto en el que ya nadie confía en él. A veces incluso llega a ser completamente engañoso: instrucciones que ya no tienen sentido, referencias a características que han sido modificadas, etc.
Además, nadie quiere leer la documentación. Los usuarios quieren hacer las cosas lo más rápido posible. La forma más rápida suele ser mirando ejemplos e intentando descubrir cómo adaptarlos a su propio caso de uso. Facilíteles las cosas teniendo un conjunto de ejemplos canónicos como parte de la documentación oficial.
Además de los beneficios anteriores, un buen conjunto de ejemplos también ayuda a reducir el esfuerzo de soporte. Evita que los equipos de soporte tengan que abordar preguntas que podrían responderse señalando un ejemplo.
Los ejemplos pueden incluso funcionar como pruebas de integración para herramientas — asegurando así que los ejemplos siempre se validen con nuevas compilaciones, como parte de su flujo de CI/CD. Su documentación ahora se puede probar, lo cual es lo mejor de ambos mundos, ya que evita que quede obsoleta.
Finalmente, los ejemplos ayudan a evitar que las “malas prácticas” se propaguen entre la base de usuarios. Le sorprenderá saber cuántos usuarios copian y pegan el código de otras personas en un intento de que todo funcione.
Los ejemplos son el mejor tipo de documentación, especialmente para herramientas internas que utilizarán personas técnicas como los profesionales de datos. Son más fáciles de crear, validar y mentener que el texto escrito; están más cerca de la fuente de la verdad (el código fuente) y son más rápidos de consumir. Los ejemplos ocupan el segundo lugar después del código en sí.
Mantener la Coherencia
Cuando alguien usa una herramienta, necesita construir un modelo mental de cómo funciona. Un ejemplo sencillo es la configuración de los pedales en los coches manuales.
Las marcas de automóviles varían mucho con respecto a los colores, los tamaños e incluso el lado en el que se ubica el volante, pero son consistentes con respecto a la disposición de los pedales: una vez que haya creado un modelo mental de cómo usarlos, podrá confiar en él sin importar qué auto conduzca.
Ahora imagine si cada marca de automóvil diferente tuviera una configuración de pedal diferente. Al conducir un auto nuevo, nunca sabría qué esperar y tendría que construir un modelo mental completamente nuevo y volver a aprender a conducirlo.
Los autos difieren mucho en cuanto a colores, estilos y tamaños, pero son consistentes en cuanto a la configuración de los pedales: el modelo mental (embrague, freno y acelerador) no suele variar.
Las herramientas internas como bibliotecas y plataformas también son así. Cuanto más consistente sea una herramienta — usando los mismos patrones, nombres, estructuras y convenciones en todas partes, — más rápido los usuarios podrán construir un modelo mental y más intuitiva se sentirá la herramienta.
Esto ayuda a prevenir errores, reduce la necesidad de soporte y, lo más importante, disminuye la carga cognitiva de su herramienta. Usar una herramienta consistente significa que una vez que has aprendido cómo realizar una tarea específica, las has aprendido todas, como es el caso de los autos y las configuraciones de los pedales.
Todos conocemos herramientas que parecen fáciles e intuitivas y aquellas que nunca recuerda bien cómo usarlas (y necesita buscar ejemplos constantemente en Google). Pandas y Matplotlib son ejemplos que me vienen a la mente aquí: aunque son muy buenas bibliotecas, hay algunas inconsistencias en los nombres, el orden de los argumentos y la semántica de las funciones.
Una buena regla general a tener en cuenta es el principio de mínima sorpresa, según el cual usted, el mantenedor de la herramienta, siempre elige estructurar las cosas de una manera que resulte más natural o menos sorprendente para el usuario.
La mayor ventaja de la coherencia es disminuir la carga mental de los usuarios, pero hemos descubierto que incluso ayuda a la capacidad de descubrimiento: los usuarios pueden explorar mejor sus herramientas si las cosas tienen nombres y estructuras consistentes.
A continuación se ofrecen algunos consejos prácticos sobre cómo lograr coherencia en las herramientas internas:
Cuidado con las Dependencias
A medida que las personas comiencen a utilizar las herramientas que usted crea, inevitablemente comenzarán a depender de ellas para realizar su trabajo. Si las herramientas cambian de forma inesperada, esto afectará a los usuarios y les impedirá trabajar.
Esto en realidad, es un buen problema que tener; significa que las personas están extrayendo suficiente valor de sus herramientas para incorporarlas a sus flujos de trabajo. Las únicas herramientas que no tienen problemas de dependencia son aquellas que nadie utiliza.
Pero las dependencias son un problema porque limitan la capacidad de cambiar y mejorar las herramientas: las actualizaciones pueden interrumpir los flujos de trabajo que actualmente dependen de las herramientas.
Como cualquier software, las herramientas internas deben cambiar y evolucionar a medida que se agregan más funciones. Sin embargo, cuanto más acoplados estén los flujos de trabajo de los usuarios con sus herramientas, más difícil será agregar funciones y realizar los cambios necesarios para combatir la entropía y la descomposición del software.
Debe limitar el acoplamiento entre usuarios y herramientas, de modo que cuando llegue el momento de agregar nuevas funciones y refactorizar, pueda hacerlo de forma segura.
Más específicamente:
La ley de Hyrum es una interpretación extrema del problema de la dependencia; afirma que los clientes dependerán, no sólo de la API pública que expone su herramienta, sino de cualquier comportamiento observable que pueda inferirse o verse desde el exterior.
Originalmente, la ley se refería a las dependencias entre módulos de software, pero la analogía sigue siendo válida; es simplemente imposible garantizar que nunca habrá cambios importantes a medida que actualice sus herramientas. Pero aún así, hay mucho que nosotros, los mantenedores de herramientas, podemos hacer para reducir los riesgos manteniendo las APIs estables y al mismo tiempo asegurándonos de que la herramienta se actualice según sea necesario.
Pensamiento 80/20
Las buenas herramientas no intentan abarcar el mundo. Logran un equilibrio entre cuánta libertad y cuántas restricciones exponen a los usuarios: muy pocas restricciones hacen que las herramientas estén demasiado desestructuradas y sean difíciles de usar; demasiados y los casos de uso avanzados quedarán fuera.
Debe concentrarse en asegurarse de que el 80% de las tareas comunes funcionen de manera natural, intuitiva y eficiente. Pero también debe dejar espacio para los casos de uso avanzados — el 20% restante. Esto significa admitir cierto nivel de personalización para atender a usuarios avanzados que tendrán casos de uso complejos y, a veces, poco ortodoxos que nunca antes había considerado.
Los usuarios siempre encontrarán una manera de hacer su trabajo. Si no pueden adaptar su herramienta a su caso de uso, no la usarán. Punto final. Es su trabajo como mantenedor de la herramienta escribir una herramienta que solo funcione para los casos de uso simples pero que aún pueda personalizarse para los avanzados.
Las herramientas de código interno son de código abierto dentro de la organización; por lo tanto, la primera forma de fomentar la personalización es seguir buenas prácticas de SE y escribir código limpio, de modo que los usuarios puedan comprenderlo por sí mismos y, eventualmente, contribuir con Pull Requests (PR) a la base del código.
Tres estrategias nos han resultado especialmente útiles:
La orientación a objetos permite anular fácilmente la funcionalidad predeterminada
La programación orientada a objetos no es adecuada para todos los casos de uso, pero funciona bien cuando se desea exponer componentes que los usuarios pueden ampliar si es necesario. Esto es aún más fácil en lenguajes dinámicos como Python (la lengua franca del mundo DS/ML), donde puede ampliar las clases principales y anular el comportamiento predeterminado en tiempo de ejecución simplemente agregando métodos.
Esto ha resultado útil en múltiples ocasiones; muchos usuarios avanzados pueden codificar para lograr lo que quieran creando subclases ligeramente modificadas en su propio código.
Valores predeterminados sensatos
La mayoría de las herramientas tienen opciones de configuración; Puede ser un archivo de configuración, pantallas de “configuración” de una aplicación o algo así. Las opciones de configuración permiten la personalización del usuario, por lo que definitivamente las necesita. Pero no desea que los usuarios tengan que establecer opciones de configuración para cada tarea.
Las opciones de configuración deben tener valores predeterminados sensatos que se adapten a la mayoría de los casos — al tiempo que permitan la personalización cuando sea apropiado. Decidir qué valores predeterminados usar requiere que comprenda a su usuario promedio y cómo usa su herramienta. Descúbralos entrevistando y estudiando sus necesidades.
Facilidad de uso por encima de la elegancia del código, siempre
Cuando necesite elegir entre facilidad de uso y elegancia del código interno, favorezca la facilidad de uso — incluso a costa de cierta deuda técnica.
Es más difícil recuperarse de la pérdida de usuarios que de una pérdida temporal de la calidad del código, lo que debería ser fácil de solucionar si aísla el código de unión de cara al usuario de las reglas comerciales centrales, como sugerimos en la sección Cuidado con las Dependencias desse blog post.
Conclusión
Como vimos en la publicación, hay muchas formas de evitar — o al menos mitigar — problemas al crear y mantener herramientas internas, especialmente para usuarios técnicos como científicos de datos e ingenieros de aprendizaje automático.
Si tuviéramos que resumir las lecciones en un breve TL;DR, diríamos:
Descubre las oportunidades