Collaboration Framework per progetti web

Requisiti per la preselezione

• Ambito del progetto
• Informazioni sul committente
• Scadenze
• Decisione
• Compenso
• Dopo il pitch

Requisiti per la preselezione

• Considerazioni scritte sull’incarico
• 3 esempi di lavori
• Profilo dell’agenzia
• Testo sulle competenze dell’agenzia rispetto all’incarico
• Compenso

Durante la procedura di offerta della prima fase, il fornitore offre già una prestazione al committente presentandosi in dettaglio (presentazione dell’agenzia) e illustrando il proprio approccio risolutivo.
Nella prima fase, il committente non dovrebbe richiedere costi dettagliati per i progetti; le tariffe delle agenzie e le tariffe orarie fungono da valori indicativi. In questa fase non si dovrebbero neppure richiedere approcci strategici alla soluzione o idee creative per il concept.

Requisiti per la selezione finale

• Colloquio di briefing
• Revisione congiunta / rebriefing
• Compenso per la mancata aggiudicazione
• Colloquio conclusivo

Requisiti per la selezione finale

• Briefing
• Revisione congiunta / rebriefing
• Presentazione / pitch

È importante capire qual è la visione dell’applicazione e che cosa dovrebbe ottenere. La visione viene definita sulla base dei seguenti elementi:

• Personas: Chi sono gli utenti dell’applicazione da realizzare? Occorre definirli con precisione sotto forma di personas. Consultate i consigli. È inoltre utile dare priorità alle personas: qual è la più importante per noi?
• Obiettivi: Qual è lo scopo dell’applicazione? Che cosa si vuole ottenere? L’esperienza dimostra che spesso gli obiettivi sono definiti in modo troppo impreciso. Una definizione accurata aiuta però a ottenere un elevato ROI. È importante chiedersi anche: perché il committente si è posto questo obiettivo? Spesso la risposta chiarisce rapidamente la priorità dell’obiettivo e aiuta, a sua volta, a investire correttamente il budget (si veda l’ultimo punto).
• Esigenze delle personas: Quali sono le esigenze delle personas?
• Prospettive: Il committente formula una prospettiva per i prossimi 3-5 anni.
• USP: Il committente definisce come l’applicazione dovrebbe essere percepita rispetto alla concorrenza.
• Sistemi e processi collegati: Si spiega come collegare i processi in background per rendere più efficienti le procedure aziendali e quali sistemi avranno un impatto.
• Priorità: Stabilire quali obiettivi hanno la priorità più alta.
• Aspettative: È consigliabile chiarire in anticipo che cosa entusiasmerebbe o deluderebbe il committente e l’utente finale.
• Workshop: Di solito è più semplice e rapido chiarire la visione in un workshop con il fornitore e il committente, anziché formularla per iscritto. In questo modo tutti i partecipanti comprendono la visione e possono riconoscersi in essa durante lo sviluppo.

Affinché il fornitore comprenda il progetto e possa lavorare in modo efficiente, deve conoscere la «user journey». Si raccomanda di descrivere i requisiti funzionali in base alla «user journey».

Definizione orizzontale e verticale

• Orizzontale: Fornitore e committente descrivono insieme, in modo molto generale (in circa 5-7 punti), le fasi che gli utenti devono seguire nell’applicazione. Ad esempio, potrebbe apparire così:
  Panoramica della home – clic e panoramica delle offerte di lavoro – ricerca con filtri – panoramica dei risultati – clic e dettagli dell’offerta di lavoro – clic e compilazione e invio della candidatura.
  Si tratta dei requisiti generali dell’applicazione (epic).
   
• Verticale: Da questo momento, fornitore e committente approfondiscono insieme i singoli epic e formulano, ma solo laddove sia davvero rilevante per l’attività, ciò che serve esattamente per realizzare l’epic.Ad esempio:
  • Panoramica dei risultati
    • I risultati provengono dal database di un partner terzo.
    • È importante che il branding di ogni azienda che pubblica un’offerta di lavoro possa distinguersi.

Si ottiene così un catalogo dei requisiti che descrive, da un lato, in orizzontale il percorso dell’utente finale attraverso l’applicazione, passo dopo passo da sinistra a destra, e dall’altro, in verticale, come gli utenti approfondiscono ciascuna fase. Si crea così una sorta di mappa dell’applicazione, che permette al fornitore di comprendere i ragionamenti e le esigenze del committente.

È molto importante che il committente trasmetta al fornitore tutte le informazioni possibili. Non bisogna risparmiarsi nella condivisione, altrimenti ne risente la qualità dell’applicazione da sviluppare.

Indicazioni poco chiare

Le indicazioni poco chiare comportano un rischio elevato in fase di sviluppo e spesso non è possibile stimare l’impegno necessario. Possono quindi mettere a rischio il progetto.

Si raccomanda quindi di:

• consentire un accesso trasparente alle informazioni
• prevedere un budget per gli spike o le prove di concetto (proof of concept) – vedi le definizioni.

Risparmiare su questo aspetto è rischioso. Le brutte sorprese nelle fasi successive del progetto finiscono per costare care.

Quali dispositivi utilizza il cliente finale: mobile (app nativa? web app? responsive?), tablet o desktop? Questo determina le modalità di progettazione e programmazione dell’applicazione.

Il committente dovrebbe definire:

1. In quali browser deve funzionare l’applicazione (compresi i requisiti per dispositivi mobili)
2. Su quali versioni dei browser deve funzionare (indicare la versione più vecchia ancora desiderata)
3. Per quali versioni dei browser deve essere garantita una programmazione perfetta (ogni errore deve essere corretto al pixel);
4. Per quali versioni dei browser deve essere garantita una programmazione ottimale (sono ammesse alcune incongruenze)

Oggi la maggior parte delle aziende di sviluppo web non offre più servizi di hosting, perché richiedono competenze specialistiche elevate, anche in materia di sicurezza e tempi di attività. Il committente può comunque indicare:

• i fornitori di hosting di cui si fida
• il pacchetto di servizi adeguato offerto dal provider di hosting in base ai requisiti dell’applicazione
• gli ambienti di sviluppo ideali, affinché lo sviluppo funzioni al meglio nei diversi livelli e non si verifichino problemi né durante il collaudo da parte del committente né al go-live.
• Cloud sì o no

Il livello di sicurezza definito dal committente dipende in misura molto ampia dall’obiettivo dell’applicazione. A seconda dei casi, la questione rilevante per la sicurezza riguarda anche il collegamento in rete dei sistemi che si trovano dietro l’applicazione utilizzata dall’utente (spesso accade nei siti aziendali con accesso ad altri servizi).

Attenzione: Dal 25 maggio 2018 il GDPR (Regolamento generale sulla protezione dei dati) dell’UE è applicabile negli Stati membri. Può applicarsi anche a imprese con sede in Svizzera, per esempio se offrono beni o servizi a persone che si trovano nell’UE oppure ne monitorano il comportamento nell’UE. Consultate l’articolo di Wikipedia sul GDPR.

L’accessibilità è un’opportunità: un’applicazione accessibile offre di per sé una migliore esperienza utente (user experience) ed è quindi migliore per tutti gli utenti.

Ulteriori informazioni sono disponibili nell’articolo di Wikipedia sull’accessibilità di Internet e standard e informazioni concrete sul sito dedicato all’utilizzo accessibile della tecnologia.

Il committente deve quindi decidere se desidera il livello A, AA o AAA (per gli enti pubblici il livello AA è obbligatorio).

La velocità di un’applicazione può essere fondamentale per il successo aziendale. Oggi, naturalmente, gli utenti sono abituati a tempi di risposta dei sistemi più rapidi rispetto a qualche anno fa. In funzione dell’obiettivo dell’applicazione, occorre definire che cosa significhi per l’azienda una risposta rapida del sistema.

L’architettura scelta per l’applicazione e i sistemi a essa collegati hanno un’influenza enorme sulle prestazioni dell’applicazione.

SEO e analytics sono importanti per il successo e dovrebbero essere presi in considerazione fin dall’inizio. Un workshop è utile per definire orientamenti e obiettivi misurabili.

Oggi gli utenti sono abituati ad applicazioni come Airbnb, YouTube e altre simili. Offrono tutte una navigazione semplice e intuitiva, che ormai rappresenta lo standard. Una navigazione ben progettata e, soprattutto, testata è indispensabile. Influisce direttamente non solo sul successo dell’applicazione, ma anche sulla reputazione del marchio.

Una buona esperienza utente si definisce attraverso metodi che comprendono anche la ricerca sugli utenti e i test con gli utenti.

Le applicazioni con una buona esperienza utente si definiscono soprattutto sulla base di criteri oggettivi (come ricerche, test ecc.).

Nello sviluppo del design visivo la domanda da porsi è: «Di cosa ha bisogno la mia persona?» Le potenziali clienti di un prodotto di lusso si aspettano un design visivo diverso da quello richiesto dagli addetti al magazzino che utilizzano un’applicazione per consultare informazioni logistiche.

È consigliabile discutere la qualità del codice e le richieste relative alla documentazione ed eventualmente concordarle (tramite una «Definition of Done»). Perché?

• Il committente potrebbe voler affidare l’ulteriore sviluppo di un’applicazione a un nuovo fornitore.
• In qualità di agenzia, sottolineate l’importanza che gli sviluppatori si prendano il tempo necessario per scrivere codice pulito. In questo modo si riducono i costi di correzione degli errori e di manutenzione.

Come si garantisce una buona qualità del codice?

Di solito il committente non è uno sviluppatore e ha quindi difficoltà a verificare la qualità del codice. I seguenti requisiti permettono di assicurare il rispetto dei processi necessari per ottenere una buona qualità del codice.

• Code review da parte di un altro sviluppatore. In questo modo si individuano errori che lo sviluppatore potrebbe non aver notato durante il lavoro.
• Test automatizzati: Occorre far comprendere al committente che sono indispensabili per la sostenibilità dell’applicazione e dell’investimento.
• Test manuali: ogni requisito realizzato dal fornitore deve essere verificato e approvato dal committente poco dopo lo sviluppo.

È importante che il team sia eterogeneo, ovvero:

• una buona distribuzione di profili senior e junior. È importante includere nel team professionisti senior affinché le esperienze maturate possano essere ripetute, oppure evitate. È altrettanto importante includere profili junior, che spesso portano idee innovative.
• un team interfunzionale (ad es. sviluppatore, specialista in user experience, responsabile di progetto, specialista di analytics, visual designer ecc.). La collaborazione tra diversi esperti consente di realizzare una soluzione completa per l’applicazione.
• un team fisso, almeno per tutta la durata del progetto. In questo modo non si disperdono le conoscenze durante lo sviluppo. Inoltre, il team mantiene l’attenzione sull’obiettivo dell’applicazione.
• diversità di genere, nazionalità e altri criteri. Per un’applicazione accessibile conforme allo standard AAA, è importante che almeno un membro del team presenti personalmente la condizione di svantaggio. Analogamente, per un negozio che vende abbigliamento femminile è importante avere un’elevata presenza di donne nella progettazione e nello sviluppo. I team diversificati realizzano applicazioni migliori perché, nel loro insieme, rappresentano il microcosmo dell’applicazione.

Non si sottolineerà mai abbastanza l’importanza di una comunicazione chiara e senza ostacoli tra il team che realizza il progetto e il committente. Innanzitutto, la comunicazione via e-mail non basta. I progetti web richiedono strumenti di comunicazione pensati per le esigenze di questo tipo di progetti e semplici e rapidi da usare per tutti. Questi strumenti consentono anche di documentare decisioni determinanti per il successo dell’applicazione, che restano una base di conoscenze anche dopo la conclusione del progetto. Perciò e-mail e telefono non sono sufficienti. Si raccomandano i seguenti strumenti:

• Atlassian Confluence: per documentare concept, requisiti non funzionali, Definition of Done, organizzazione del progetto ecc.
• Atlassian Jira: per documentare l’intero catalogo delle attività. Sia il fornitore sia il committente vi hanno accesso. Qui vengono definite, discusse e commentate le singole attività parziali e infine approvate.
• Slack o uno strumento di chat simile: consente uno scambio molto rapido tra il fornitore e il committente. I partner dovrebbero accordarsi su alcune regole per evitare interruzioni continue del lavoro. Nonostante questo rischio, i vantaggi sono maggiori.
• Riunioni regolari, durante le quali si prendono decisioni importanti e si concordano le fasi successive del progetto tramite confronto diretto (si veda anche «Procedura»).

In linea di principio esistono due metodi: waterfall o agile

Secondo il Trends & Benchmarks Report 2016 di Swiss Q, il 60 % dei progetti agili ha successo, contro il 45 % dei progetti basati sul metodo waterfall.

La maggior parte dei progetti di sviluppo software è complessa e quindi non può essere pianificata in anticipo. Il metodo waterfall non è adatto ai progetti complessi.

Il metodo agile, anche se all’inizio può sembrare un po’ insolito, promette maggiori probabilità di successo del progetto, un migliore ritorno sull’investimento, un ingresso più rapido sul mercato, una migliore qualità del codice e un’applicazione più adatta agli utenti.

Come già detto, la maggior parte dei progetti di sviluppo software è complessa, presenta molte incognite e richiede quindi il metodo agile.

Già durante la procedura di selezione del fornitore è possibile definire i successivi servizi di supporto e manutenzione. Si chiarisce così anche come verrà documentata l’applicazione durante lo sviluppo: solo un’applicazione ben documentata può essere trasferita correttamente al supporto. Più l’applicazione è complessa, maggiori saranno i costi di manutenzione.

Punti importanti da definire nell’SLA:

• Come vengono gestiti gli aggiornamenti delle versioni?
• Come vengono gestiti gli orari di intervento (reperibilità nel fine settimana o solo durante l’orario d’ufficio)?
• Come vengono definiti i criteri per il supporto (criticità dei malfunzionamenti)?
• Come vengono gestiti gli interventi di ampliamento, minori o maggiori dell’applicazione?

Già nella fase di offerta, il fornitore dovrebbe presentare al committente un modello di contratto di supporto e manutenzione e poter fornire una stima approssimativa dei costi.