Tabla de contenidos
Para la mayoría de las empresas que cambian a la metodología Agile, el concepto de product owner en el desarrollo de software es algo nuevo. Sin embargo, cada mes se observa un crecimiento significativo en la demanda del mismo. ¿Por qué? Lo discutiremos en este artículo, centrándonos más en el rol del Product Owner en el desarrollo de software.
¿Quién es el “Product Owner”?
Un gran Product Owner básicamente es un emprendedor de su producto. PO es miembro de un equipo ágil responsable de la entrega de productos digitales de alta calidad. En simples palabras, PO define las historias de los usuarios y prioriza los atrasos mientras mantiene la integridad conceptual y técnica de las funciones para el equipo.
El papel del Agile Product Owner en el control de calidad es enorme. PO es un miembro crítico, que acepta historias como hechas. Según nuestra experiencia, trabajando con empresas de diferentes industrias, si no hay PO en una empresa, en la mayoría de los casos el proceso de desarrollo se convierte en un caos, cuando no se cumplen los plazos y el producto se entrega con funcionalidades que realmente no son necesarias .
Pero debo decir que para lograr todo lo que se necesita hacer durante un proyecto ágil de desarrollo de software, en mi opinión, el product owner en el desarrollo de software debe tener algunos conocimientos técnicos para ser más efectivo. ¿Por qué? Porque el Product Owner debería poder hablar con el equipo técnico y comprender los conceptos vitales para hacer avanzar un proyecto. Además, el PO debe ser capaz de explicar los conceptos de tecnología a otras partes interesadas. Es como un intermediario entre el equipo de desarrollo y los interesados. Pero aparte de tener conocimiento tecnológico, el PO debe estar bien informado sobre un producto desde la perspectiva del usuario final. Eso significa que el PO también debe tener antecedentes comerciales.
Desafortunadamente, en este momento, hay muy pocas personas en el mundo que realmente coincidan con este criterio de «candidato ideal», por lo tanto, muchas universidades y academias comienzan a abrir cursos para hacer crecer a los Product Owner. En nuestra opinión, creemos que es mucho más fácil convertir a una persona de tecnología, un desarrollador o un CTO en un PO que una persona de negocios. En realidad, tomando Barcelona como ejemplo, la mayoría de las OP aquí son ex ingenieros.
Veamos las principales áreas de responsabilidad de un PO.
Rol del Product Owner en proyectos de desarrollo de software
Crear y mantener la acumulación de productos
Nada es constante en el mundo del software y es importante que el product owner en el desarrollo de software adapte el Retraso del Producto según las necesidades del cliente y del mercado. Además, un buen PO sabe cuándo y cómo decir NO. Este es probablemente el más obvio, pero también el más difícil de dominar. Decir que sí a una nueva idea o función es fácil, es solo otro elemento para la acumulación de productos. Sin embargo, una buena gestión del backlog abarca la creación de un backlog de producto manejable con elementos que probablemente se realizarán. Agregar elementos a la acumulación de datos sabiendo que nada sucederá con ellos solo crea «desperdicio» y falsas expectativas. Para evitar la situación cuando todo el proceso de desarrollo lleva demasiado tiempo, el proyecto pierde el foco y la solución desarrollada podría no resolver realmente el problema comercial, la OP debería decir NO a algunas características y cambios. Pero en estos casos, el product owner en el desarrollo de software debe explicar por qué se generará o no un elemento de retroalimentación y mover al equipo hacia conversaciones y soluciones productivas.
Priorizar la acumulación de acuerdo con el valor comercial o ROI
Cada historia de usuario debe ordenarse por importancia relativa. No debe haber 5 con “alta prioridad”. Es importante saber qué historia de usuario es # 1, que es # 2, etc. Y eso no solo es desde el punto de vista comercial, PO debe tener en cuenta la parte de desarrollo, así como algunas características simplemente no pueden desarrollarse antes de hacer X tarea. Por lo tanto, PO debe analizar los requisitos de ambos lados y proponer la mejor solución, la mejor priorización para agregar más valor al producto desde el principio.
Historias de usuarios
Un product owner en el desarrollo de software debe saber cómo escribir historias de usuario. Un ejemplo simple es: como usuario, quiero <algún objetivo u objetivo>, de modo que <beneficio, valor>. Aquí tienes un artículo que explica eso.
Transmitir la visión y los objetivos al comienzo de cada Sprint
Esto ayuda a mantener al equipo en el camino correcto. El product owner en el desarrollo de software representa la voz de los clientes y crea una visión del producto junto con los interesados. Cada decisión se toma teniendo en cuenta la visión del producto. Esto garantiza el desarrollo sostenible de productos, proporciona claridad para el equipo de desarrollo y aumenta las posibilidades de éxito del producto.
Involucrar al cliente y a las partes interesadas para garantizar que el equipo esté creando el producto correcto
El equipo de desarrollo no debe dedicarle tiempo a explicarle al cliente cuestiones técnicas, este es un trabajo de PO. En otras palabras, el product owner en el desarrollo de software es la voz del Equipo para el mundo exterior y debe asegurarse de que todos los canales de comunicación estén abiertos y de que los proyectos cuenten con la cantidad adecuada de asistencia necesaria para tener éxito. El PO es responsable de definir los límites y las limitaciones para lograr los objetivos. Pueden incluir fechas de finalización del plazo, limitaciones de costos, límites de memoria y mínimos de velocidad.
Participar en las reuniones diarias de Scrum, Sprint Planning Meetings y Sprint Reviews and Retrospectives.
Es de vital importancia para el Product Owner que posea buenas habilidades de comunicación y se puedan adaptar a diferentes equipos y tipos de personalidad. El Product Owner debe actualizar las partes interesadas con el estado actual, los avances, las posibles dificultades y problemas.
Control de calidad
Normalmente, el PO es el único miembro del equipo que puede aceptar historias como hechas. Esto incluye la validación de que la historia cumple con los criterios de aceptación y tiene las pruebas de aceptación adecuadas y persistentes, y que de otra manera cumple con su Definición de Listo.
ROI
El product owner en el desarrollo de software es responsable de proporcionar el mejor retorno de la inversión. Son responsables de todas las decisiones económicas durante la publicación del sprint y el nivel de producto. El presupuesto, el tiempo y la calidad se pueden ajustar de acuerdo con la necesidad, el costo y el beneficio de cada acumulación de productos también se puede utilizar para priorizar las historias de los usuarios.
Resolver conflictos
Cualquiera que no pueda manejar conflicto no debe ser Product Owner. En el desarrollo de productos digitales, tener fuertes habilidades de resolución de conflictos es importante para evitar que las disputas se intensifiquen y se centren en lo que realmente importa. A veces, PO debe pasar por algún conflicto para llegar a una solución.
El tiempo de entrega
El Product Owner es responsable de garantizar que el equipo cumpla con los plazos y los objetivos. PO está a cargo de entregar un software de trabajo óptimo según los hitos.
En conclusión, decir que en Apiumhub creemos firmemente que el rol del product owner en el desarrollo de software es vital.
Si deseas agregar algunos puntos a la lista, siéntete libre de hacerlo en la sección de comentarios a continuación.
Si quieres trabajar en Apiumhub como PO, envía tu CV aquí. Si, de lo contrário, buscas contratar un PO, contáctanos!
Y no te olvides de suscribirte a nuestro boletín mensual para recibir las últimas tendencias e información sobre el rol del Product Owner.
Si este artículo sobre role del product owner en el desarrollo de software te gustó, te puede interesar:
Beneficios de la metodología ágil
Los beneficios de la tecnología Scrum
Beneficios de la integración contínua
¿Porque debería usar Docker en mi proyecto de desarrollo?
Beneficios de la pruebas unitarias
La importancia de las retrospectivas en la metodología Ágil
Simular respuestas del servidor con Nodejs
Principio de responsabilidad única
Arquitectura de microservicios
F-bound en Scala: traits genéricos con higher-kinded types
Scala Generics I : Clases genéricas y Type bounds
Scala Generics II: covarianza y contravarianza
