Nu siempre ha sido una empresa que prioriza a las personas, asegurándose que su experiencia sea eficiente, sencilla y transparente. En esta misión, los celulares y los productos que diseñamos nos ayudan a crear una relación cercana con nuestros clientes. Por esta razón, todos nuestros productos tienen dos cosas en común: fueron diseñados para ayudar a nuestros clientes a comprender y tomar el control de sus vidas financieras, y deben funcionar perfectamente en los teléfonos celulares de las personas. De ahí la relevancia del desarrollo móvil en Nu.
Es aquí cuando nuestros #CodeStars entran a escena, ya que el equipo de desarrollo móvil está profundamente involucrado en las decisiones relacionadas con nuestros productos y, a medida que crecemos nuestra cartera, también aprendemos algunas cosas sobre el crecimiento de nuestro equipo móvil.
Irvin Canche, Software Engineer y #CodeStar en Nu, nos habla de cómo funciona esta parte fundamental de la Ingeniería en nuestra empresa y de aquellos retos de los que ha compuesto la escalada mobile dentro de nuestra operación.
¿Cómo trabajan los equipos en Nu?
La estructura en Nu se compone de equipos autónomos llamados Squads, que son creados para abordar los diferentes objetivos comerciales.
“Un Squad es un equipo multifuncional y autoorganizado. Tienen la responsabilidad de un extremo a otro de las cosas que construyen: diseño, código, implementación, mantenimiento, operaciones, etc.
Cada escuadrón tiene una misión a lo largo de un plazo y define sus propios OKRs cada trimestre. La autonomía básicamente significa que los escuadrones deciden qué construir, cómo hacerlo y cómo trabajar juntos, mientras lo hacen. Hay algunos límites: misión del equipo, estrategia general del producto y objetivos a corto plazo. Uno de los más grandes beneficios con esta metodología para los desarrolladores, es que al tener autonomía los miembros del equipo se sienten comprometidos con los objetivos del squad en cuestión”.
Irvin Canche
Si bien, gran parte de la empresa trabajaba en Squads, hasta el año pasado, nuestros ingenieros móviles eran un equipo orientado a la actividad (o equipo de servicio), compartido en toda la organización, ya que la cantidad de desarrolladores móviles no era suficiente para tenerlos en Squads.
Nuestro jefe de producto era responsable de la priorización en los Squads y mantenía una lista de características por desarrollar. Los ingenieros móviles luego se moverían al Squad en la parte superior de la lista y trabajarían con ellos hasta que se enviara la función. Al trabajar de esta manera, Mobile Engineering se estaba beneficiando de la cercanía de los miembros de su equipo, lo que facilitaba compartir conocimientos, tener discusiones sobre tecnología y organizar sesiones de pizarra para resolver problemas.
Además de eso, tener un equipo especializado en desarrollo móvil hizo posible mantener la coherencia del código en todos los productos en nuestra base de código.
¿Conoces las posiciones de desarrollo que están abiertas en Nu? Da clic en los siguientes enlaces y aplica para transfórmate en un #CodeStar:
Principales desafíos al tener ingenieros de desarrollo móvil como equipo de servicio
Asignación
Las decisiones sobre la asignación de especialistas siguieron aumentando y haciéndose más complejas. También fue problemático satisfacer las necesidades del desarrollo móvil (el nuevo iPhone está disponible; se lanzó otra versión de Android; es necesario corregir fallas, etc.), decisiones de productos (¿Esta función es específica de la plataforma? ¿Tenemos que lanzarla en ambas plataformas simultáneamente? ?) y otras variables.
El número de desarrolladores asignados a cada proyecto dependería de las respuestas a esas (y muchas otras) preguntas.
“La distribución del equipo depende mucho del número de desarrolladores móviles especializados en cada plataforma (iOS y Android), esto puede llegar a representar un verdadero reto si no se cuenta con el número adecuado de ingenieros especializados en dichas plataformas”.
Irvin Canche
Cabe mencionar que en Nu se tomó la iniciativa de migrar la aplicación móvil a flutter. Con flutter no solo solucionamos la problemática de la especialización y el número de ingenieros requeridos en cada Squad, de igual manera se obtienen otros beneficios, como nos explica nuestra #CodeStar Stephany Juárez en esta entrada del #BlogNu: “Escalando el desarrollo móvil en Nu”.
Propiedad del código
Quien haya desarrollado cualquier característica / biblioteca seguirá siendo responsable de ese código incluso después de mudarse a otro Squad. Eso planteó dos desafíos: estábamos especializando a nuestros desarrolladores aún más y concentrando el conocimiento de las bibliotecas compartidas en solo unas pocas personas. También significa que volvieron a trabajar en proyectos antiguos, teniendo que cambiar de contexto constantemente.
“Actualmente en Nu se tienen sesiones donde los ingenieros de desarrollo móvil comparten conocimiento y se proponen temas de arquitectura, esto permite que los squads tengan bases de código muy similares y que el cambio a un nuevo equipo no represente un reto. Con esto los ingenieros tienen mejor capacidad para adaptarse a diferentes equipos y optimizar tiempos de desarrollo ya que se tiene una arquitectura establecida para los diferentes paquetes que conforman nuestra base de código”.
Irvin Canche
Sentido de pertenencia
Hay unidad dentro de un escuadrón. Sus miembros comparten un objetivo y una visión de dónde llevar su producto. Esta unidad motiva y hace que los equipos se enfoquen en sus objetivos.
El desarrollo móvil iba y venía, sin participar en las discusiones y definiciones de los objetivos a largo plazo del Squad, lo que les dificultaba conectarse con los Objetivos y Resultados Clave del Escuadrón (OKR) y evaluar cómo su trabajo impacta los objetivos de la empresa.
Rehacer
Los desarrolladores se unían a los escuadrones en etapas aleatorias del ciclo de vida del desarrollo del producto, lo que obligaba a volver a discutir lo que “ya estaba decidido”. Cuando llegaban los ingenieros móviles, a menudo debían refactorizar las API o revisar, volver a probar o incluso descartar animaciones que pesaban demasiado en los dispositivos de nuestros clientes. Esto también afectaría las fechas de entrega.
Todos estos son efectos secundarios bien documentados de trabajar como equipo de servicio. Sriram Narayan, en su libro “Agile IT Organization Design”, afirma:
“Por definición, los servicios compartidos son utilizados por equipos responsables de diferentes resultados comerciales. El equipo compartido en sí mismo no es responsable de esos resultados. No es de extrañar, entonces, que a veces tengamos la sensación de tratar con mercenarios cuando interactuamos con un equipo de servicio compartido. No parecen tener su piel en el juego. Los servicios compartidos luchan por encontrar un propósito. Un diseño de organización que tiene como objetivo las condiciones de autonomía, dominio y propósito debe esforzarse por minimizar los servicios compartidos y eliminarlos de las corrientes de valor de misión crítica “
Desarrollo móvil: Nuestro enfoque al problema
Para cambiar las cosas, sabíamos que teníamos que tener desarrolladores móviles como una parte integral de Squads, alejándonos del modelo de Equipo de Servicio, trabajando en Productos en lugar de Proyectos.
Esta nueva estructura de equipo requiere una mayor cantidad de desarrolladores que necesitábamos contratar a un ritmo mucho más acelerado, lo cual hicimos. A medida que contratáramos más desarrolladores, los asignaríamos a escuadrones de acuerdo con la lista de prioridades.
También teníamos que mejorar la productividad de los desarrolladores y la calidad de vida en general. Para eso, creamos un equipo de “productividad” llamado Plataforma Móvil que comenzó mejorando las canalizaciones y herramientas móviles. Este equipo asumió la responsabilidad de crear, implementar y distribuir la aplicación a nuestros clientes.
Dado que el Escuadrón de Plataforma Móvil era responsable del lanzamiento de nuestras aplicaciones, fue posible implementar un tren de lanzamiento, con lanzamientos siguiendo su propio cronograma, independientemente del ciclo de producción de cada Escuadrón, evitando cuellos de botella.
Otro gran beneficio de mejorar nuestras herramientas y formar equipos de productos es la mayor capacidad de respuesta: los desarrolladores con conocimientos de tecnología y contexto empresarial pueden tomar mejores decisiones, con resultados más predecibles y en un período de tiempo más corto.
“Sentir autonomía al construir un producto hace que los desarrolladores tengan motivación y libertad, cada persona decide cómo organizarse y trabajar los features, esto permite que los equipos logren tener una comunicación efectiva y la productividad no se pierda en el ciclo de desarrollo.
Al trabajar con este modelo, las decisiones sobre la priorización permanecen en cada escuadrón y, por lo tanto, están menos centralizadas. Pero incluso estas situaciones ahora son más fáciles de sincronizar, ya que cada equipo maneja sus propias prioridades y puede sopesar mejor cómo encajan dentro de los objetivos generales de la empresa”.
Irvin Canche
Es importante mencionar que todavía nos estamos adaptando a esta regla, ya que viene con su propio conjunto de dificultades, pero ya vemos mejoras en todos los equipos para asegurarnos de que su código estará en el próximo tren de lanzamiento.
¿Quieres conocer a fondo las vacantes disponibles en Nu? Da clic en los siguientes enlaces:
Las dificultades actuales del desarrollo móvil
Si bien trabajar como equipos de producto tiene algunas dificultades, es importante señalar el lado positivo mientras los equipos se acostumbran a su nueva composición y flujo de trabajo.Usamos solicitudes de extracción para revisiones de código.
Un PR podría no representar toda la discusión detrás de ese cambio y las compensaciones que hicieron los desarrolladores, especialmente cuando el revisor está en otro Squad y no tendrá el contexto completo en torno a ese PR.
Sin embargo parte del trabajo de los desarrolladores es documentar adecuadamente todo tipo de cambio así como las nuevas características que se agreguen a nuestra base de código, una práctica que se sigue en Nu es la de crear un archivo README en cada paquete de nuestra aplicación en el cuál se explica el objetivo del paquete, se agregan diagramas, temas de arquitectura, links a otros documentos, diseños, etc. Esto permite que otros desarrolladores que trabajan por primera vez en cada paquete tenga un contexto adecuado.
Otro problema que se planteó fue la subutilización de los desarrolladores móviles, a lo que una gran respuesta es esta cita del libro “Agile IT Organization Design”, de Sriram Narayan:
“¿Se infrautilizarán los especialistas dedicados a los equipos de productos? probablemente, sí. Aquí es donde el caucho se encuentra con el camino en términos de sacrificar la rentabilidad por el bien de la capacidad de respuesta. Más allá de un cierto umbral de utilización, la capacidad de respuesta disminuye a medida que aumenta la utilización. Este es un efecto bien conocido de la teoría de las colas. Sin un poco de holgura, no podemos tener capacidad de respuesta. Una carretera totalmente utilizada es un estacionamiento”.
Es importante notar que la subutilización de los desarrolladores en cada Squad es lo que les permite tener reuniones frecuentes para compartir la arquitectura de código entre productos, hablar sobre nuestros pipelines de compilación y discutir el desarrollo de funciones, la contratación y las mejoras técnicas, para reducir el impacto causado por las dificultades enumeradas anteriormente. Esta vez es importante para comprender el panorama general y mantener la unidad de los desarrolladores móviles, ya que todos tenemos que enviar un binario juntos.
“Estamos en constante crecimiento y eso trae cambios en organización de equipo, flujo de trabajo, mejor organización en nuestro código, etc. Así mismo, cada vez aprendemos y compartimos más conocimientos de las diferentes experiencias que vivimos en el día a día en la construcción de nuestros productos”.
Irvin Canche
Nuestra estructura actual les dio a los equipos la autonomía y la capacidad para actuar en todo su flujo de valor, y los desarrolladores están encontrando un sentido de pertenencia y contribuyendo mucho más a sus nuevos escuadrones. Un calendario de lanzamientos facilita la planificación de funciones y los clientes reciben una aplicación de mejor calidad.
Si alguno de estos desafíos hace eco en tu cabeza y es algo en lo que te gustaría trabajar, recuerda que siempre estamos contratando. 😉
Atrévete a formar parte de esta revolución morada, checa aquí las vacantes para unirte a nuestro equipo de ingeniería. Aplicas dando clic sobre cada una de las posiciones:
Si quieres conocer más sobre la ingeniería de software móvil en Nu, habla con Irvin, haz clic aquí para contactarlo.
Este contenido es parte de la misión de Nu para devolver a las personas control sobre sus vidas financieras. ¿Aún no conoces Nu? Obtén más información sobre nuestro servicio y nuestra tarjeta de crédito sin complicaciones, da clic aquí.