Uno de los mayores retos a los que se enfrentan los equipos de desarrollo de productos es simplemente cómo decidir qué producto construir. En el caso de los equipos que trabajan a partir de una especificación de producto, sobre todo en el desarrollo de hardware, los ingenieros no suelen estar autorizados a empezar a trabajar hasta que ésta esté terminada y aprobada. Y dado que la mayoría de los plazos de desarrollo son increíblemente cortos, a menudo no hay tiempo suficiente para considerar soluciones alternativas una vez que aparece nueva información.
Una forma de ver este reto se muestra aquí. Puedes imaginar que el círculo es todas las formas posibles en que el equipo podría construir el producto. Y ese pequeño punto azul es la especificación de un producto en particular. Esta especificación del producto define exactamente en qué producto deben centrarse y construir los desarrolladores.
En este post, primero describiré algunos de los métodos comunes utilizados para acordar una especificación del producto. Luego exploraré los problemas con esos métodos y cómo pueden conducir a la construcción de productos a partir de una especificación que en realidad no resuelve los problemas de su cliente.
Debo decir que mi perspectiva proviene de 10 años de experiencia trabajando en la industria de semiconductores analógicos y de señal mixta, primero como ingeniero de aplicaciones y luego como definidor de productos. Ahora, soy consultor aquí en Jama.
Malas formas de crear una especificación de producto:
Pregunte a su cliente lo que quiere que construya
Una forma de empezar es preguntar a sus clientes lo que necesitan. Esto puede hacerse esperando una solicitud de presupuesto (RFQ) emitida por el cliente, o de manera menos formal, a través de reuniones y discusiones. Normalmente, lo que aprenderá con este enfoque es la solución o el producto que utilizan actualmente y lo que les gustaría que cambiara en un futuro muy próximo. En cierto modo, estás actuando como un contratista y tu cliente es responsable de todos los detalles de la especificación.
Dado que este escenario requiere iterar sobre un producto existente, hay una alta probabilidad de que termines con una idea muy específica que definitivamente puedes implementar.
Sin embargo, hay varios problemas con este enfoque:
- Lo que su cliente le está diciendo sobre su estrategia de producto también se lo está diciendo probablemente a su competencia, y un objetivo clave del proyecto es probablemente hacer algo más barato que la solución existente. Te encontrarás en una guerra de precios.
- Su cliente ya está fijado en un tipo de solución, basado en lo que había comprado antes, lo que hace difícil sugerir algo que pueda satisfacer mejor sus necesidades.
- Es probable que el calendario sea extremadamente agresivo, dejando pocas oportunidades para construir algo nuevo, o permitiendo una verdadera innovación.
- Su cliente puede no estar al tanto de las nuevas tecnologías, o simplemente puede no saber lo que necesita.
En este caso, usted confía en que su cliente traduzca sus requisitos internos en una especificación para usted, en lugar de que usted escriba los requisitos para un producto que el mercado más amplio necesita y comprará.
A medida que desarrolla el producto, su equipo inevitablemente tendrá que hacer concesiones por varias razones. La única manera de estar seguro de que se hace la mejor elección es revisar los cambios en la especificación del producto resultante con su cliente. Si no lo haces, corres el riesgo de construir un producto que no acepten. Pero como el equipo de diseño estará sometido a una presión extrema para ejecutar un calendario agresivo, hay muchas posibilidades de que haga concesiones sobre el producto sin tener toda la información necesaria. Esto aumenta aún más el riesgo de construir el producto equivocado.
Este enfoque funciona en el sentido de que se entrega un producto. Si usted está en el negocio de la entrega de componentes básicos, entonces esto está bien. Si usted está buscando una solución única que defiende el margen bruto, entonces este no es el mejor enfoque.
POSTO RELACIONADO: Cómo realizar un mejor análisis de impacto en las relaciones ascendentes y descendentes
2. Hacer que un ingeniero escriba toda la especificación
Otro escenario común es aquel en el que un ingeniero, o algún otro miembro del equipo de cara al cliente, imagina una solución basada en las conversaciones que ha tenido con uno o varios clientes. El equipo se reúne en torno a esta idea y, con un impulso interno, los requisitos se documentan rápidamente y los esfuerzos del equipo se dirigen hacia la redacción de las especificaciones del producto y el desarrollo de la solución.
Una vez que la solución está completa y lista para salir al mercado, algunos equipos validarán su idea con los clientes, pero como el equipo está presentando una solución -no explorando una necesidad- la discusión tiende a ser en torno a los detalles de la especificación del producto. Estos equipos no tendrán la oportunidad de averiguar si la solución está resolviendo un problema.
Típicamente, en este escenario, los requisitos del producto vienen directamente de la cabeza de un individuo y luego se capturan en una larga hoja de especificaciones, y el resto del equipo realiza las transacciones utilizando la especificación documentada. Cada vez que el equipo se encuentra con un conflicto en el que hay que hacer una compensación, la persona que redactó los requisitos tiene que decidir las compensaciones correctas de forma independiente, con poca o ninguna información nueva. Además, si esa persona no ha investigado ni validado los requisitos, el equipo construirá el producto equivocado.
Por qué estos enfoques no conducen al éxito
Lo que ambos enfoques anteriores tienen en común es que el enfoque es llegar a una especificación del producto terminado lo más rápido posible. Los equipos tienen tanta prisa por empezar a construir algo y cumplir con el plazo del cliente, que no se aseguran primero de que ese algo sea el correcto.
Además, el conocimiento de los requisitos lo tiene sólo una persona del equipo. Ese individuo es la persona que interactúa con el cliente patrocinador, o es la persona a la que se le ocurrió la idea del producto. En cualquiera de los casos, el resto del equipo carece de un contexto para la solución, el por qué están construyendo este producto, y por lo tanto no pueden hacer recomendaciones.
El resultado es que a menudo los productos mueren más tarde de lo que deberían, después de que se haya desperdiciado mucho tiempo y dinero, o los equipos crean productos que no tienen éxito o productos «yo-mismo» que compiten en gran medida en el precio. Nada de esto es bueno para el negocio.
POSICIÓN RELACIONADA: 8 cosas que se deben y no se deben hacer para escribir los requisitos
Las mejores formas de crear una especificación de producto:
La mejor manera de construir productos que sus clientes comprarán es salir y hablar con su mercado objetivo mucho antes de empezar a escribir su especificación. En primer lugar, hay que articular el planteamiento del problema.
El planteamiento del problema del producto son unas cuantas frases o párrafos que describen una necesidad del mercado. Se escriben desde la perspectiva de la persona que tiene el problema y -esto es fundamental- no dicen nada sobre cómo resolver realmente el problema. El objetivo de esta etapa de la exploración es transmitir una comprensión del problema y un sentido del valor asociado a la solución del mismo.
Una declaración del problema generalmente se compone de tres partes:
- La primera es el personaje, o una descripción de quién tiene el problema. Es útil describir a la persona con gran detalle por separado y luego hacer referencia a una persona en particular en el planteamiento del problema para no repetir la misma descripción de la persona.
- Luego está la descripción del problema. Cuanto más detallada sea, mejor. Usted quiere asegurarse de que la necesidad es muy clara. También hay que dar un nombre al problema. Esto hace que sea más fácil para los equipos referirse a él durante el proyecto.
- Por último, escriba una descripción de la frecuencia con la que ocurre el problema. Si el problema ocurre rara vez y tiene poco impacto, entonces resolverlo tiene poco valor. Si el problema ocurre con frecuencia y tiene un alto impacto, entonces el valor de resolverlo será alto.
Puede comenzar preguntando a los clientes qué problemas tienen que creen que usted puede resolver, pero tiene que cavar más profundo para llegar a las declaraciones de problemas verdaderamente valiosos o pepitas de oro. Estas pepitas de oro suelen provenir del desarrollo de un profundo conocimiento del mercado y de la recopilación de información de una amplia gama de fuentes.
Si lo hace con éxito, acabará identificando un problema que puede resolver y por el que su cliente pagará.
Durante el proceso, tenga cuidado de no encontrarse con falsos positivos o negativos. Escuchar demasiado a la gente de su empresa o sólo a un pequeño número de clientes puede llevarle a validar o abandonar falsamente un problema. Hable con tantos clientes como pueda y recoja tantos datos como sea posible.
Volvamos a nuestro diagrama de todos los posibles productos que podemos construir.
Esta vez hemos añadido líneas de intersección que representan restricciones. Si pensamos en las declaraciones del problema como líneas que cruzan el círculo, entonces una buena declaración del problema basada en la comprensión del mercado delimitará un área en el círculo que representa todas las soluciones aceptables. Todo lo que se encuentre en esta área resuelve el problema y sería aceptable para el cliente.
Notarás que el tamaño de esta área es mucho mayor que el de los círculos anteriores de peticiones de oferta e ideas de producto. Esto se debe a que estos enunciados del problema y el contexto delimitan intencionadamente la solución de la forma más flexible posible para permitir que surjan nuevas ideas.
La idea es dar al equipo de diseño la máxima flexibilidad para crear la solución más innovadora posible dentro de las limitaciones.
POSICIÓN RELACIONADA: Lista de comprobación: Selección de una herramienta de gestión de requisitos
¿Cómo se llega a un planteamiento final del problema?
Aquí están mis recomendaciones:
- Empiece por asignar a alguien para cada proyecto la responsabilidad de ser la voz del cliente.
- A continuación, encargue a esa persona la identificación de los problemas del mercado basándose únicamente en la información recopilada del mercado.
- Asegúrese de que esos problemas del mercado se documentan y se comparten en un lugar al que todo el equipo tiene acceso.
- Escriba una justificación para cada enunciado de problema de mercado que explique por qué es un problema y lo importante que es resolverlo
- Añada un hito en el plan del proyecto en el que los enunciados de problemas deben ser revisados y aprobados por el equipo junto con un caso de negocio.
- A medida que el equipo comienza a desarrollar una solución, vuelva periódicamente a la lista de enunciados del problema para recordar a todos cuál es el objetivo.
- Para cada problema, capture una lista de las características del producto que resolverán el problema.
- Si algún problema no puede resolverse por completo, vuelva a revisar el caso de negocio para asegurarse de que el producto sigue siendo viable.
Del planteamiento del problema a la especificación
Ahora que tiene sus planteamientos del problema y el equipo se ha familiarizado con ellos, comience a desarrollar de forma colaborativa una especificación del producto. Dado que todos los miembros del equipo entienden el problema que se está resolviendo, todos pueden contribuir a la especificación.
Debido a que ha hecho el trabajo inicial de identificar el problema que está resolviendo, dentro de las limitaciones identificadas, y a que su equipo ha considerado múltiples formas de ofrecer la solución, tiene suficiente información para escribir la especificación del producto.
Liberar la especificación del producto en pequeños lotes
El mejor enfoque aquí es liberar pequeñas piezas de la especificación al equipo tan pronto como sea posible para obtener una rápida retroalimentación. Esto ayudará a evitar la pérdida de tiempo por el camino equivocado y hará que sea mucho más fácil para el equipo proporcionar retroalimentación de alta calidad.
¿No está convencido? Considere lo siguiente: ¿Qué ocurre si recibe una hoja de especificaciones de 200 páginas para revisar? Probablemente, mirará las primeras páginas y luego hojeará el resto.
Ahora, ¿qué sucede si recibe un documento de una página? Probablemente lo revise todo. Doscientos documentos de una página darán lugar a una retroalimentación mucho mejor que un único documento de 200 páginas.
Revise el planteamiento del problema para asegurarse de que va por el buen camino
Además, a medida que desarrolle la especificación, compruebe que el producto sigue siendo una solución válida para el problema. Es fácil quedar atrapado en la compensación inherente al desarrollo de un producto y olvidarse de comprobar si todavía está en el objetivo.
Este enfoque también gestiona las expectativas de las partes interesadas. Como el proceso está controlado, existe un marco y una transparencia que impiden que nadie anule las decisiones. En cualquier momento del proyecto, podrá explicar exactamente qué valor ofrece su producto y por qué necesita tener las características que el equipo ha especificado.
Diseñar productos según las necesidades del mercado es fundamental para el éxito
Reconozco que en algunos sectores esto supone un gran cambio respecto a cómo se han diseñado y construido los productos. Pero a medida que los mercados se vuelven más competitivos y los productos son cada vez más complejos, la mera entrega de otra iteración de algo que se ha construido antes no va a mantener el negocio durante mucho tiempo.
Para obtener más información sobre cómo escribir los requisitos de manera que todas las partes interesadas tengan una comprensión clara de las necesidades de desarrollo, descargue nuestro eBook, Best Practices for Writing Requirements.
Lee el EBOOK