¿Qué significa estar orientados a producto?

Es común hablar de orientación a producto a la hora de tratar temas relacionados con la arquitectura de software.

Para entender su significado, utilizaremos la metáfora del edificio, gracias a la cual podremos diferenciarlo de la orientación a proyecto.

En esta metáfora, las aplicaciones de software (o los productos), que cubren ciertas funcionalidades de negocio, aparecen representadas como edificios, y el trabajo necesario para diseñarlos o construirlos y las labores de mantenimiento, como proyectos.

Así, un mismo producto puede tener varios proyectos asociados a lo largo de su vida. Algunos durarán poco y otros se prolongarán más en el tiempo.

Pero a diferencia de los edificios, las aplicaciones de software tienen sus cimientos hechos de conocimiento técnico y de negocio. Este material especial se encuentra fuertemente entrelazado dentro del código y la documentación de la aplicación.

Es importante hacer crecer el conocimiento dentro de nuestros equipos para conseguir desarrollar aplicaciones de software más robustas y flexibles, que consigan adaptarse rápidamente a las necesidades de negocio de nuestra empresa. Porque, a diferencia de los edificios, donde la necesidad de cambio es menor, los productos de software, en especial aquellos con los que una compañía ofrece un servicio diferencial con respecto a su competencia, tienen que poder evolucionar y adaptarse a nuevas necesidades, lo más rápidamente posible y con una baja tasa de errores.

De este modo, vemos que este enfoque da más valor al equipo y lo considera parte inseparable del producto en sí.

 

El edificio y sus funciones: orientación a producto y orientación a proyecto

Siguiendo con la metáfora del edificio, es fácil ponerse en la piel del dueño del inmueble, que quiere lo mejor para su producto y es capaz de definirlo. También lo es interpretar el papel de la empresa contratista, que busca cumplir con los acuerdos del proyecto y garantizar la mayor rentabilidad posible.

Decimos que estamos orientados a producto cuando el centro de todas nuestras decisiones es el producto.

Las empresas que usan para su negocio la funcionalidad de una aplicación de software quieren que su edificio sea robusto, que cubra su funcionalidad, que no tenga demasiadas reparaciones, que tenga buenos cimientos, que los materiales sean de buena calidad para que no se derrumbe y, sobre todo, que se adapte rápidamente a las necesidades de negocio.

Bajo este enfoque, el edificio es lo primero.

Por otro lado, cuando estamos orientados a proyecto, lo que más nos interesa es la rentabilidad. Queremos que las tareas planificadas en el proyecto se realicen de la manera más eficaz y eficiente.

Si no somos los dueños del producto, lo que queremos es definir lo mejor posible el alcance desde un principio para poder demostrar al final del proyecto que todas las tareas acordadas están terminadas y garantizar los resultados y la satisfacción de los clientes.

 

Un edificio hecho de conocimiento

Si modificamos ligeramente la metáfora y le echamos un poco de imaginación, podemos pensar que una aplicación de software es un edificio cuyos cimientos y materiales están, en parte, hechos de conocimiento. Este saber reside en el equipo que lo hizo y se puede transferir mediante el código y la documentación de la aplicación.

De esta manera, los cimientos serán más sólidos si el equipo que lo conoce está presente. El edificio se podrá adaptar a las necesidades de negocio en la misma medida que lo hacen los conocimientos de los que están hechos sus cimientos.

La transferencia de conocimiento es posible, pero tiene que ser un proceso lento y cuidadoso si no queremos minar los cimientos de nuestro edificio.

Es necesario seguir metodologías que permitan compartir este conocimiento y hacer que el producto transcienda a las personas que lo crearon, pero siempre teniendo en cuenta que ese conocimiento forma parte del producto y, por lo tanto, no se puede eliminar de una manera traumática.

Por lo tanto, orientémonos a producto y hagamos crecer el conocimiento, tanto funcional como técnico, de los equipos. De este modo, conseguiremos aplicaciones robustas y flexibles para adaptarse a las necesidades del negocio de nuestra empresa.

 

¿Te gustaría recibir nuestros próximos artículos?