Archivio tag: public sector

Lo zen e l’arte della committenza dei siti web nella pubblica amministrazione: perché i burocrati dovrebbero sporcarsi le mani con la tecnologia

16 Repliche

Negli ultimi anni ho lavorato per diverse amministrazioni pubbliche. Gran parte del mio lavoro consiste nel concepire e dirigere progetti che si svolgono prevalentemente attraverso canali Internet. Mi sembra venuto il momento di fare qualche riflessione sulle cose che ho imparato. Come sempre, le lezioni più importanti mi vengono dagli errori commessi – e quando si è trattato di fare errori non mi sono mai tirato indietro.

  • Usare software-as-service non è una buona idea, anche se ci sono eccezioni. Il mio gruppo e io abbiamo commesso questo errore con Kublai, decidendo di aprire la nostra piattaforma su Ning. Questo ci ha permesso di essere online in mezz’ora, e non è un vantaggio da poco; ma, in compenso, ha sequestrato il nostro database – costruito a spese e per iniziativa di un Ministero italiano – e lo ha messo in mano a un’azienda privata americana, per sempre. Un anno dopo Ning ha cambiato CEO e modello di business: ha sostituito la licenza aperta della sua piattaforma con una full copyright, sganciato le API e ritirato i tools di migrazione. Per potere fare un’analisi di rete Ruggero Rossi ha dovuto scrivere un web crawler – è un po’ come dovere scassinare la porta di casa propria. Ci è andata ancora bene: il servizio era gratuito (a quel tempo non esisteva il servizio a pagamento su Ning). Se l’azienda avesse chiuso i battenti e formattato l’hard disk con il database di Kublai non avremmo potuto dire niente. Non rispondevano nemmeno alle mail. Non intendo mai più prendere in considerazione soluzioni che non contemplino un database su un server a cui la mia amministrazione ha accesso root.

  • Usare software proprietario non è una buona idea, di nuovo con alcune eccezioni. È costoso ed equivale a una delega perpetua al proprio fornitore, o quasi. Se una grande software house ti scrive un software su misura di cui poi ti vende la licenza nessuno, tranne quella stessa software house, potrà mai farti la minima modifica al codice. Rischi di trovarti in una situazione di totale impotenza, in cui cambiare il colore dello sfondo o il font ti costa molto in termini di denaro (le famose “billable hours” americane, in cui tu chiami e quelli attaccano il tassametro) e attrito amministrativo. Inoltre, è politicamente discutibile: il software proprietario non è riutilizzabile da altre amministrazioni se non pagando per altre licenze, e questo non è bene, soprattutto in tempi di tagli e di (sacrosanta) diffidenza dei cittadini verso la saggezza delle amministrazioni nello spendere.
  • Questo lascia solo il software libero o open source. Dal 2007 uso WordPress in progetti pubblici; per la piattaforma di Edgeryders, più o meno terminata in questi giorni, il mio gruppo di lavoro si è avventurato in Drupal. Lavorare sul software libero può essere faticoso e frustrante. Funzionalità che sulla carta dovrebbero essere disponibili semplicemente installando un modulo o un plug-in risultano non esserlo; i tempi si allungano; la gran parte del lavoro viene assorbita dal debugging. Nel frattempo, il resto delle attività rischia di inchiodarsi. Credo che l’esperienza possa mitigare il problema, ma mai veramente risolverlo. Il software libero è per definizione organico, “sporco”, vive di hacks e non solo di soluzioni eleganti e razionali.

Nonostante i problemi, la mia esperienza di committente di Drupal si annuncia positiva, come lo è stata prima quella con WordPress. Il motivo è questo: queste piattaforme consentono, e anzi richiedono, l’emersione di una figura intermedia di “admin avanzato” tra quella dello sviluppatore e quella dell’utente. Ciò accade perché le interfacce di amministrazione di WordPress e Drupal sono intuitive e potentissime; soprattutto Drupal ti consente un controllo molto preciso sul sito. Puoi fare queries dal database, formattare il risultato e visualizzarlo su una pagina, un blocco o una mail; puoi impostare regole del tipo SE [condizione] ALLORA [azione]. Queste attività non sono programmazione, ma sono al confine. Inoltre – e qui faccio riferimento alla mia esperienza con WordPress – quando l’interfaccia di admin non ti basta più, in rete trovi facilmente tutorial e informazioni per mettere le mani in parti del codice non core: io dal punto di vista tecnico sono uno sprovveduto, ma fino a mettere le mani nel CSS del blog (e, per cose moolto semplici, tipo incollare del Javascript, nei files PHP) ci arrivo. Ci è voluto un piccolo investimento, testimoniato dalla presenza nella mia biblioteca di libri della serie “for Dummies”. Questo ti dà una libertà inestimabile: quella di sviluppare in modo anche grezzo, lanciare e poi continuare a fare piccoli cambiamenti al tuo sito man mano che il progetto evolve. Fidati: ne sentirai il bisogno, fin dal primo giorno.

Il trucco sta in questo: il ruolo di admin avanzato un po’ smanettone è perfetto per un amministratore pubblico che deve commissionare software. Arrivare a conoscere bene l’architettura di queste piattaforme e a personalizzarle in modo avanzato non significa essere sviluppatori, ma significa che puoi dialogare in modo costruttivo con i tuoi sviluppatori, avere un approccio realistico alle cose che si possono e che non si possono fare, quanto tempo ci vuole, quanto costano. Inoltre, l’admin avanzato può provare a concettualizzare i propri obiettivi in termini del software, e quindi esprimere una domanda molto sofisticata nei confronti degli sviluppatori. Per esempio, su Edgeryders è necessario ricoinvolgere continuamente gli utenti nella conversazione; questo si fa attraverso le notifiche email e il feed di attività recenti. In Drupal, queste funzioni vengono svolte da certi moduli non-core. Se l’amministratore pubblico sa questo, può chiedere non “un sito web che dia l’idea di un luogo vivo”, ma “activity stream deve loggare tipi di attività a cui normalmente non è agganciato”, che è tutt’altra cosa.

Quando ho iniziato a andare in moto, mi sono letto Lo zen e l’arte della manutenzione della motocicletta. La lezione di quel testo è questa: l’attività di guidare la moto non è veramente separabile da quella di farne la manutenzione. I motociclisti “romantici”, che non intendono sporcarsi le mani, non lo accettano, e delegano anche la più semplice delle operazioni di manutenzione a meccanici professionisti. Ma pagano il pegno dell’impotenza di quando le loro moto si fermano, e loro non sanno perché, né come fare a ripartire. Questa impotenza può essere disastrosa nella pubblica amministrazione: nei progetti che dirigo io tipicamente il costo della tecnologia incide per meno del 10% del budget, eppure se la tecnologia non funziona blocca l’intero progetto.

Conclusione. Fare committenza è impossibile se non capisci quello che stai comprando. La comunità del software libero, nella mia esperienza, è disposta a condividere la propria conoscenza, le aziende che fanno software proprietario molto meno. Se ti trovi, come me, a commissionare un semplice progetto tecnologico per il settore pubblico ti consiglio di rivolgersi a questa comunità, armarti di pazienza, e investire un po’ di tempo per sporcarti le mani con la tecnologia che poi gli sviluppatori useranno. Installa e configura siti di prova, aggiungi funzionalità, prova a cambiarne l’estetica. Passa un po’ di tempo con gli hackers. Mostrati desideroso di imparare e fai molte domande. Soprattutto, non cedere alla tentazione del “non è il mio lavoro, fallo funzionare e mandami la fattura”. Non è così che funziona. Ti richiederà molto tempo, ma sempre poco in confronto a quello che poi risparmierai una volta in produzione. Il sistema non è perfetto, ma è di gran lunga meglio delle alternative. In realtà, credo che sarebbe molto utile organizzare un corso per pubblici amministratori volto a formare committenti migliori di software libero. Qualcuno là fuori è interessato? Io parteciperei subito.

Thanks Freddy Mascheretti, Ivan Vaghi, Paolo Mainardi and Claudio Beatrice for their patience and suggestions

Ricablare l’economia per produrre nuovi commons (lungo)

2 Repliche

La vittoria di CriticalCity a TechGarage ha dell’incredibile. Intanto per le proporzioni schiaccianti: i ragazzi di Milano hanno vinto tutto (il primo premio, il premio di Wired e il premio del pubblico, con una colletta da 100mila euro improvvisata per fornire loro i fondi di startup. Non sto scherzando: leggete il racconto di Marco, che era presente). E poi perché il loro progetto è esplicitamente sociale e not-for-profit (“non vogliamo monetizzare l’impegno per migliorare le città dei nostri giocatori”, dicono), mentre TechGarage è un luogo consacrato all’impresa pura e dura, for profit, promossa dall’azienda di venture capital Dpixel e frequentata dal gotha degli investitori in hi-tech di casa nostra. In qualche modo, queste persone hanno percepito CC come un’idea troppo bella per non essere realizzata.

Questa storia ha dell’incredibile anche per una terza ragione. CC non esce dal vivaio di uno dei tanti progetti di incubazione di startup promossi dal settore privato, tipo Working Capital (di Telecom). Esce, invece, da un ambiente di progettazione creativa di una pubblica amministrazione italiana, cioè da Kublai, che ho l’onore di avere ideato e di dirigere per conto del Ministero dello Sviluppo. Anche Gianluca, presidente di Dpixel e artefice dell’operazione TechGarage, ha incontrato CC da membro della giuria che ha assegnato il Kublai Award a gennaio. Questo, secondo me, vuol dire due cose.

1. Le communities, se orientate nel modo giusto, sono tendenzialmente in grado di riconoscere le buone idee. Quelli di Kublai sono progetti creativi, non video di gatti: quindi sono complessi, vanno valutati su più dimensioni. Il documento di progetto di CriticalCity, per esempio, è lungo oltre 30 pagine con gli allegati. Il consenso creatosi all’interno della community kublaiana su CC ha predetto con grande precisione ed energia quello verificatosi a TechGarage e in altri contesti.

2. Il settore pubblico, per tradizione più orientato ai beni collettivi di quello privato, si trova oggi in una posizione assolutamente strategica. Oggetti come Wikipedia, Delicious, Flickr, Twitter hanno natura di beni pubblici, risorse a disposizione di tutti. Anche CriticalCity potrebbe diventarlo. Ora, i beni pubblici sono una gran bella cosa, ma se sono pubblici vuol dire che il loro consumo non è escludibile, quindi sono per definizione molto difficili da monetizzare – e infatti molte bellissime idee del web 2.0 hanno problemi sul modello di business. Questa è una grande opportunità per il settore pubblico, la cui missione è proprio quella di produrre beni pubblici. Dopo la tragedia dei commons messa in moto nel settecento, le tecnologie digitali consentono oggi di invertire la tendenza e di creare nuovi commons. E chi vince la gara dei commons vince la gara della competitività globale.

Si è aperta, mi pare, una finestra di opportunità straordinaria, che non credevo avrei visto nella mia vita. Abbiamo democratizzato la creatività, per cui concepire e tentare di realizzare progetti ambiziosi come CriticalCity fa ormai parte dell’orizzonte del possibile per ragazzi  e ragazze normali come Augusto, Duccio, Chantal e gli altri; abbiamo nel web 2.0 uno strumento potentissimo per aggregare idee e persone, e ormai forse anche per selezionarle; ormai cominciamo anche ad avere una prima generazione di persone che stanno nelle pubbliche amministrazioni, capiscono questo linguaggio e sanno usarne gli strumenti.

Questa prima generazione ha oggi una nuova missione: ricablare l’economia per permettere la produzione di commons. Wikipedia e gli altri possono avere modelli di business instabili, ma il loro contributo al benessere collettivo e alla competitività globale è indiscutibile. Un governo degno di questo nome deve promuovere queste cose. E può farlo, perché ha risorse enormi, normalmente impiegate in attività a produttività bassissima: tutti i progetti presentati a Public Services 2.0, messi insieme, costavano quanto un unico progetto del programma europeo e-participation. Si tratta di ricablare l’economia, per convogliare attenzione e un po’ di denaro verso le persone come i ragazzi di CriticalCity, che sognano di costruire risorse a disposizione di tutti, e proprio per questo difficili da monetizzare. E’ difficile, ma non impossibile, e assolutamente necessario. Io ci provo. Spero, e credo, che non resterò solo su questa strada.