4/5 Producto y procesos
4 buenas prácticas en torno a Productos y Procesos encontradas en las empresas líderes de desarrollo de software.
Intro
Y bueno, si pretendemos un bueno desarrollo de software, no podemos dejar de hablar de lo crítico que resultan las buenas prácticas en torno a un buen desarrollo de producto.
¿Se está construyendo el producto adecuado para los usuarios?
Generalmente estas capacidades son de responsabilidad del profesional que lleva el rol de Product Owner, o dueño del producto. Esto rol típicamente lo desempeña un profesional del equipo Comercial o de Negocios, aunque en ocasiones también lo lidera un profesional del área técnica.
Podríamos decir que capacidades aquí descritas fueron “levantadas” de las mejoras prácticas de un desarrollo de producto “Lean”.
Las principales características y capacidades de un desarrollo de producto son 4:
- Levantar e implementar los comentarios de clientes.
- Visibilizar todos los flujos de negocios.
- Trabajar sobre funcionalidades pequeñas.
- Permitir la experimentación de los equipos.
El análisis de las empresas pioneras en el desarrollo de software encontró 4 características que vemos a continuación.
16. Feedback de los usuarios
Esta práctica implica que la organización o empresa esté activamente buscando el feedback de los usuarios. Idealmente debe ser un hábito frecuente y no aislado, que típicamente se realiza a través de encuestas de satisfacción, focus groups o a través de la mesa de ayuda. Pero existe una cultura —y proceso— que escucha y lleva “ese” comentario de cliente hasta el product owner. Luego se ponderará y priorizará el requerimiento levantado por el usuario de acuerdo a sus méritos.
Por supuesto que lo más importante es que se incorpore la perspectiva de los usuarios en el diseño de los productos. Tampoco se trata de realizar todo lo que pidan los usuarios, pero sí de escuchar, entender y evaluar constantemente al cliente como parte de un proceso de retroalimentación frecuente.
17. Visibilidad de los procesos y flujos de negocio
Los equipos de desarrollo deben tener un completo entendimiento de los flujos y procesos de negocio. Deben conocer —y entender—, todo el proceso por lo que circula un usuario, tanto los procesos actuales, como las ideas futuras del negocio. Por el contrario, muchas veces los equipos de desarrollo desconocen la lógica completa del negocio, o bien no están informados respecto de futuros proyectos. Las decisiones de diseño y construcción de aplicaciones, deben tomarse con toda la información necesaria.
Es importante destacar que los procesos de negocios deben estar escritos y documentados en una plataforma de fácil acceso. Sirve poco, que la información circule en un archivo word. Idealmente la documentación de negocios deberá incluir diagramas o videos que expliquen mejor los procesos actuales, pero también los desafíos o puntos de mejora.
Con información visible y entendible del negocio, será más fácil para los equipos de desarrollo hacer mejor su trabajo, y, por ende, tendremos un producto de mejor calidad.
18. Trabajo en lotes pequeños
Esta práctica implica la necesidad de trabajar en lotes de trabajo pequeños, idealmente en “ramas” de no más de 1 semana. Ello implica que las historias de usuario o funcionalidades que se desean implementar deben descomponerse en pequeñas historias. Por pequeño me refiero, a características que puedan ser desarrolladas en menos de 1 semana. Y luego, habilitando cada uno de estos lotes en producción, nos permitirá generar un loop rápido de retroalimentación de los usuarios.
Es esencial y clave este enfoque, ya que conoceremos rápidamente los resultados de nuestro trabajo, y, si estamos mal, lo podremos corregir cuanto antes. Es como el barco que navega en el mar, que si se desvía tan sólo 1 grado, nunca llegará a su destino. De igual forma, al iterar constantemente nuestros cambios a producción, tendremos antes el feedback de nuestros usuarios, y así podremos ajustar con mayor precisión nuestro desarrollo.
Visto del otro extremo, si nos demoramos 1 año en lanzar nuestra aplicación, 1 años nos tomará conocer comentarios reales de los usuarios. Si nos equivocamos en algunas funcionalidades del producto, “sólo” habremos perdido 1 año.
19. Experimentación en equipo
Esta práctica se refiere a entregar la debida autoridad a los equipos de desarrollo para que puedan crear y cambiar las especificaciones de requerimientos como parte del proceso de desarrollo sin la necesidad de aprobación. Esto es innovación y experimentación, ya que los equipos podrán poner probar ideas en base a sus descubrimientos o a los comentarios de los usuarios de forma rápida.
Por el contrario, cuando se obliga al equipo a construir los requerimientos al “pie de la letra”, muchas veces el resultado son productos poco atractivos. Si no hay espacio para mejoras rápidas, y para todo se requiere reuniones y autorización, se inhibe la iniciativa y decae la motivación.
Tampoco se trata de otorgar libertad total para que desarrollen cualquier cosa que se les ocurra, pero sí una combinación que permita a los equipos de desarrollo tomar decisiones de forma rápida y eficiente.
Contiuación ...
Y el último post de esta serie, son las capacidades para un gestión eficiente... 👇
Nicolás Mella
