Proceso de conversión a productos de software: brinde claridad a lo que está ofreciendo

Cuando pienso en nuestra solución para la información de los pasajeros y su conversión a productos, no pienso en vender el mismo software a todos nuestros clientes. En cambio, veo la productización o conversión a productos como un proceso que nos permite ser precisos en lo que ofrecemos y comunicar claramente las características, funcionalidades y opciones incluidas en nuestra solución de software. En nuestro caso, por ejemplo, las interfaces específicas del cliente u otros módulos específicos del cliente son una parte elemental del software y, en lugar de ofrecer la misma solución para todos, el producto se puede configurar y ampliar según las necesidades del cliente.

El proceso también se refiere a reconocer nuestras fortalezas, construir sobre ellas y desarrollarlas aún más mientras reparamos las debilidades que nos impiden tener más éxito en lo que hacemos. En este blog, comparto algunos de mis aprendizajes sobre cómo se puede lograr esto.

Reconocer las fortalezas (¡y construir encima de ellas!)

A menudo, en nuestro trabajo, nos concentramos en los desafíos y en cómo resolverlos, pero no debemos olvidarnos de las cosas que ya están funcionando bien. En mi opinión, analizarlos y comprenderlos es donde debería comenzar la productización de software.

Por ejemplo, en Teleste hemos estado diseñando y desarrollando software para sistemas versátiles de información de pasajeros durante bastante tiempo y hemos creado muchas soluciones inteligentes a lo largo de los años sin una producción real. Siempre se ha pensado mucho en la reutilización del software, y este suele ser el camino a seguir en el desarrollo de software. La base para la productización se construyó en nuestra empresa mucho antes de que se nombrara al primer gerente de producto SW. Los módulos de software y la arquitectura que ya tenemos brindan un excelente punto de partida para desarrollar nuestras fortalezas, y el papel del gerente de producto es analizar, dirigir y priorizar lo que se debe hacer en cada nuevo proyecto de desarrollo.

Quizás también ya tenga módulos y partes de código que se reutilizan en casi todos los proyectos. Enumérelos, agrúpelos y dibújelos en un diagrama junto con su software específico de proyecto típico. Siga dibujando, reagrupando y reorganizando los módulos hasta que vea una imagen más grande y clara. Agregue las partes que faltan con un color diferente y tendrá la primera entrada para su hoja de ruta de software: ¡un paso adelante es implementar estos nuevos módulos!

Solucione las debilidades (¡pero solo aquellas que limitan su éxito!)

Si ha comenzado la productización de su software reconociendo sus fortalezas, ya debería tener una base sólida sobre la cual construir. Ahora es el momento de invertir algunos pensamientos sobre las debilidades para descubrir qué está limitando su éxito. Para empezar, observe las tareas que consumen más tiempo en sus proyectos de software. En esta etapa, la productización se trata de encontrar una manera de deshacerse de ellos.

En su lista de debilidades, puede haber frutos al alcance de la mano, pero lo más probable es que también haya cosas que requieran mucho esfuerzo para mejorar. Puede, por ejemplo, tener demasiado código específico del proyecto, lo que aumenta la cantidad de trabajo de diseño y provoca retrasos en las entregas. El desarrollo de uno (o más) módulos de software estandarizados y configurables lo ayudará a deshacerse de ellos y mejorar sus plazos de entrega fácilmente. Por otro lado, puede descubrir que tiene deficiencias en la documentación específica del proyecto y hay miles de documentos que son imposibles de mantener actualizados. Resolver tales desafíos puede llevar más tiempo, pero vale la pena cuando piensa en sus objetivos y en dónde desea estar dentro de unos años.

Algunas de las debilidades enumeradas pueden brindarle algunos beneficios menores cuando se deshace de ellas, mientras que otras, una vez resueltas, pueden llevar a su empresa a un nivel completamente nuevo. Solo asegúrese de priorizar y pensar en lo que es posible y lo que podría traer los mayores beneficios. ¿Qué es lo que necesita arreglar lo antes posible y qué tareas pueden esperar un poco más? ¿Y cuáles son las cosas con las que puedes seguir viviendo? Ningún sistema es perfecto y lo más probable es que haya algunas cosas que pueden y deben dejarse sin arreglar hasta más tarde. Los recursos no son infinitos, ¡así que elija sabiamente!

Describa su solución claramente (¡y llévela a nivel de gestión!)

Tener el sistema de software configurable más brillante realmente no ayuda, si no puede describirlo de una manera que la gerencia, las ventas y los clientes de la empresa lo entiendan. Debe ser capaz de describir el significado de cada módulo o capa de su software de una manera simple, a menos que quiera discutirlos solo con expertos en software o con alguien que tenga todo el tiempo del mundo.

Su solución de software puede constar de docenas, cientos o incluso miles de módulos diferentes y es posible que muchos de ellos ya estén estandarizados. Los desarrolladores de software (al menos aquellos que llevan mucho tiempo trabajando en la empresa) pueden incluso conocer muy bien los módulos. Sin embargo, debe poder presentar su solución en un nivel más general para mostrar a la gerencia dónde se encuentra con su software y hacia dónde se dirige. Si no puede, pregúntese si hay fallas en la arquitectura o si simplemente le faltó algo.

Además, su personal de ventas necesita saber qué deberían vender y cómo el software beneficia a los clientes. Los clientes, a su vez, necesitan comprender de qué es capaz su solución, cuáles son sus limitaciones y cómo se puede aumentar con interfaces y módulos específicos del proyecto. Lo crea o no, una descripción de alto nivel puede ser muy útil también dentro del desarrollo de software, especialmente para los nuevos empleados. Ver una imagen más grande primero y luego ir a los detalles es una forma natural de aprender para muchos de nosotros.

Involucre a todos en la productización (¡porque no puede hacerlo solo!)

Incluso los mejores gerentes de productos no pueden hacer todo el proceso de productización por sí mismos. La productización de software no se trata solo de que un gerente diga sí o no a las solicitudes de nuevas funciones, sino de un proceso más grande que involucra a varias partes interesadas dentro de la empresa, incluyendo no solo el desarrollo del software sino también la administración, documentacióny ventas.

Recuerde que no puede pasar sus días en la oficina revisando continuamente lo que están haciendo los desarrolladores o dando instrucciones detalladas a todos. Debe poder confiar en que las personas saben la dirección a la que se dirigen y por qué. Sea abierto e informativo, prepare hojas de ruta, dibuje arquitecturas de alto nivel y, por último, pero no menos importante: ¡pida comentarios y aportes a sus colegas! Puede conocer las necesidades de la industria, pero las ventas conocen al cliente y los desarrolladores conocen su software.

No se olvide del cliente (¡ya que usted no existe sin él!)

La productización de software puede sonar como si se hiciera para generar ahorros para la empresa, y solo conduce a soluciones que no son muy flexibles. Contrariamente a esta creencia, también se puede hacer de forma que beneficie tanto a la empresa como a los clientes. Esto significa que estamos utilizando software y procesos probados y que funcionan bien y que ofrecemos soluciones cuidadosamente diseñadas, probadas a fondo y con mejor calidad de software y actualizaciones ágiles.

Es importante recordar que no existiríamos sin nuestros clientes. Necesitan poder confiar en nosotros y si fallamos en las entregas de software, significa problemas para ellos. Con una oferta más estandarizada, podemos cumplir mejor con los cronogramas y responder a las solicitudes y desafíos de los clientes con mayor rapidez. Cuando también tenemos claro lo que ofrece nuestra solución y podemos documentarlo bien, ¡es cuando a los clientes realmente les empieza a encantar la productización!