PQFORCE es utilizado diariamente por muchos usuarios en diversos entornos de clientes y en numerosos lugares. PQFORCE se utiliza para planificar proyectos, buscar y asignar recursos, gestionar las ausencias y mucho más. Cada usuario tiene diferentes funciones y vistas de datos en su rol. Así que es lógico que surjan regularmente ideas sobre cómo hacer que la aplicación sea aún mejor, más rápida y más fácil de usar. ¿Cómo debemos afrontarlo como proveedores?

En INTRASOFT, mantenemos una línea muy directa con el cliente. Para nosotros, los clientes no son simples entidades abstractas que pagan, sino una multitud de usuarios individuales con necesidades individuales. Especialmente en la fase actual de desarrollo del mercado, nos tomamos muy en serio estas necesidades de los clientes. Pero, ¿qué significa eso en términos concretos?

Veamos simplemente nuestro proceso de desarrollo. Básicamente, desarrollamos PQFORCE como un producto estándar a lo largo de una ruta de lanzamiento. No hay sucursales específicas para clientes (véase también este artículo). Las nuevas versiones de PQFORCE se desarrollan cada pocas semanas -según el alcance- y se ponen a disposición de nuestros clientes. El desarrollo de un comunicado tiene lugar a lo largo de las siguientes fases.

Captación de necesidades: Al principio está la idea

Los nuevos requisitos casi siempre se originan en las ideas de los usuarios. Nuestro principio aquí es: sólo aquellos que utilizan PQFORCE a diario pueden determinar realmente lo que todavía falta o cómo se podría sacar aún más de la aplicación. Tenemos en cuenta estas ideas y deseos, normalmente en el marco de proyectos piloto con clientes. Es el periodo de tiempo en el que un equipo selecto de usuarios piloto utiliza PQFORCE y prueba la mejor aplicación posible para el cliente. Estamos presentes en esos proyectos piloto in situ, formamos y asesoramos a los usuarios, escuchamos atentamente y así recogemos nuevas ideas. Estas ideas se introducen en una lista. Allí, se formulan como los llamados requisitos de negocio en forma de casos de uso que son tan neutrales como sea posible.

Consolidación y priorización: soluciones ampliamente aplicables para todos los clientes

En esta fase, se examina cuidadosamente el gran bote de nuevos requisitos. Los requisitos individuales se formulan de la forma más neutra posible, y en algunos casos también se agrupan y consolidan. A continuación, a partir de la gran lista, se elabora un paquete con los requisitos que se implementarán juntos en una nueva versión. También se elaboran propuestas concretas de aplicación. Puede tratarse de diseños de pantalla, por ejemplo, que representan una interfaz gráfica de usuario que debe ser revisada. Estos conceptos de aplicación se desarrollan teniendo en cuenta un alto grado de flexibilidad y sostenibilidad y, si es necesario, también se presentan al cliente (proveedor de ideas) para su revisión. El objetivo siempre es no crear una solución precisa para un proveedor de ideas, sino una solución que aporte valor añadido a todos los clientes, que sea "apta para las masas" y que fluya en la norma.

La lista de requisitos de negocio y el paquete de requisitos a implementar son comparables al product backlog o sprint backlog de la metodología de desarrollo ágil Scrum. Sin embargo, a diferencia de Scrum, el propietario del producto no decide solo, sino siempre en comunicación con los clientes pertinentes. Consideramos nuestra base de clientes como un círculo ampliado de propietarios de productos, por así decirlo. Para satisfacer las diferentes y a veces contradictorias demandas de los clientes en cuanto a la urgencia, es necesario mucho tacto y buena comunicación por nuestra parte, y por parte de los clientes también se requiere voluntad de compromiso y comprensión. Sin embargo, esto último siempre se puede encontrar, ya que nuestros clientes reciben las nuevas funciones como parte de la cuota de suscripción normal del producto estándar y no pagan extra por ellas.

Desarrollo y pruebas: La aplicación concreta está programada

Se trata de una fase puramente interna del proceso de desarrollo, es decir, sin la participación del cliente. El equipo de desarrollo ya ha puesto en marcha la nueva versión. Aquí es donde tiene lugar el desarrollo posterior de PQFORCE en sentido estricto. Para ello se define un calendario concreto con tres fechas clave:

• Disposición de pruebas internas(Release Candidate)
• Suministro de la liberación estable para la comercialización y las ventas(Release for Marketing)
• Suministro de la versión estable para uso productivo del cliente(Release for Production)

Estos tres despliegues suelen realizarse semanalmente. Este elevado ritmo es posible porque nos esforzamos por definir lanzamientos regulares y más bien pequeños. De este modo, nuestros clientes se benefician de un desarrollo continuo con innovaciones manejables. De este modo, podemos adaptar continuamente PQFORCE a las nuevas necesidades y mantener el pulso del tiempo.

Construcción y despliegue de la versión: La entrega se realiza con prontitud

La versión para producción se genera finalmente en un proceso de compilación final y se despliega en los distintos servidores de producción. Los clientes de la nube compartida reciben automáticamente la versión en la fecha previamente anunciada. Los clientes con servidores dedicados o suscripciones locales recibirán la versión a la hora que prefieran. Las correspondientes notas de la versión se comunican a todos los clientes con la debida antelación.

La entrega cierra el círculo desde la idea original del usuario hasta la función final implementada en pocas semanas.