PQFORCE è usato quotidianamente da molti utenti in diversi ambienti di clienti e in numerose località. PQFORCE è usato per pianificare progetti, cercare e assegnare risorse, gestire le assenze e molto altro. Ogni utente ha diverse funzioni e visualizzazioni di dati nel suo ruolo. Quindi è logico che sorgano regolarmente idee su come rendere l'applicazione ancora migliore, ancora più veloce, ancora più facile da usare. Come dovremmo comportarci noi come fornitori?

In INTRASOFT, manteniamo una linea molto diretta con il cliente. Per noi, i clienti non sono semplicemente entità astratte e paganti, ma una moltitudine di utenti individuali con esigenze individuali. Soprattutto nell'attuale fase di sviluppo del mercato, prendiamo molto sul serio queste esigenze dei clienti. Ma cosa significa questo in termini concreti?

Diamo semplicemente un'occhiata al nostro processo di sviluppo. Fondamentalmente, sviluppiamo PQFORCE come un prodotto standard lungo un percorso di rilascio. Non ci sono filiali specifiche per il cliente (vedi anche questo articolo). Le nuove release di PQFORCE vengono sviluppate ogni poche settimane - a seconda dello scopo - e messe a disposizione dei nostri clienti. Lo sviluppo di una release si svolge lungo le seguenti fasi.

Catturare i requisiti: All'inizio c'è l'idea

I nuovi requisiti nascono quasi sempre dalle idee degli utenti. Il nostro principio qui è: solo chi usa PQFORCE su base giornaliera può davvero determinare cosa manca ancora o come ancora di più potrebbe essere preso dall'applicazione. Prendiamo in considerazione queste idee e desideri - tipicamente nel quadro di progetti pilota con i clienti. Questo è il periodo di tempo in cui un team selezionato di utenti pilota utilizza PQFORCE e testa la migliore applicazione possibile per il cliente. Siamo presenti sul posto durante questi progetti pilota, formando e consigliando gli utenti, ascoltando attentamente e raccogliendo così nuove idee. Tali idee vengono poi inserite in una lista. Lì, sono formulati come i cosiddetti requisiti di business sotto forma di casi d'uso che sono il più possibile neutrali rispetto alla soluzione.

Consolidamento e prioritizzazione: soluzioni ampiamente applicabili per tutti i clienti

In questa fase, la grande pentola di nuovi requisiti viene esaminata attentamente. I requisiti individuali sono formulati nel modo più neutrale possibile, e in alcuni casi anche raggruppati e consolidati. Poi, dalla grande lista, viene messo insieme un pacchetto con quei requisiti che saranno implementati insieme in una nuova release. Vengono anche elaborate proposte concrete di attuazione. Questi possono essere disegni di schermate, per esempio, che rappresentano una GUI da rivedere. Tali concetti di implementazione sono sviluppati con un alto grado di flessibilità e sostenibilità in mente e, se necessario, anche sottoposti al cliente (fornitore di idee) per la revisione. L'obiettivo qui non è sempre quello di creare una soluzione precisa per un fornitore di idee, ma piuttosto una soluzione che porta valore aggiunto a tutti i clienti, è "adatta alle masse" e fluisce nello standard.

La lista dei requisiti di business e il pacchetto di requisiti da implementare sono paragonabili al product backlog o allo sprint backlog della metodologia di sviluppo agile Scrum. A differenza di Scrum, però, il proprietario del prodotto non decide da solo, ma sempre in comunicazione con i clienti interessati. Consideriamo la nostra base di clienti come una cerchia estesa di proprietari di prodotti, per così dire. Per soddisfare le diverse e a volte contraddittorie richieste dei clienti riguardo all'urgenza, sono necessari molto tatto e buona comunicazione da parte nostra, e da parte dei clienti anche una disponibilità al compromesso e alla comprensione. Quest'ultimo può sempre essere trovato, tuttavia, perché i nostri clienti ricevono nuove funzionalità come parte della normale quota di abbonamento per il prodotto standard e non pagano extra per loro.

Sviluppo e test: l'implementazione concreta è temporizzata

Questa è una fase puramente interna del processo di sviluppo, cioè senza coinvolgimento del cliente. La nuova release è ora effettivamente implementata dal team di sviluppo. È qui che avviene l'ulteriore sviluppo di PQFORCE in senso stretto. Per questo viene definito un calendario concreto con tre date chiave:

• Disposizione per i test interni(Release Candidate)
• Fornitura del rilascio stabile per il marketing e le vendite(Release for Marketing)
• Fornitura della release stabile per l'uso produttivo del cliente(Release for Production)

Queste tre distribuzioni avvengono tipicamente su base settimanale. Questo ritmo elevato è possibile perché ci sforziamo di definire uscite regolari e piuttosto piccole. In questo modo, i nostri clienti beneficiano di uno sviluppo continuo con innovazioni gestibili. In questo modo, possiamo adattare continuamente PQFORCE alle nuove esigenze e tenere il dito sul polso del tempo.

Release Build & Deployment: la consegna avviene prontamente

Il rilascio per la produzione viene infine generato in un processo di compilazione finale e distribuito ai vari server di produzione. I clienti del cloud condiviso ricevono automaticamente la release nella data precedentemente annunciata. I clienti con server dedicati o abbonamenti on-premise riceveranno la release all'ora preferita. Le note di rilascio corrispondenti sono comunicate a tutti i clienti in tempo utile.

La consegna chiude il cerchio dall'idea originale dell'utente alla funzione finale implementata in poche settimane!