Innovazione
La comunicazione è uno dei fattori di successo più importanti per i progetti e le imprese. Il bene è ciò che porta alla comunicazione. Ma cosa rende buona la comunicazione? E cosa ha a che fare con le API?
La comunicazione è il fattore di successo nella vita. Tutto ciò che facciamo insieme richiede comunicazione. La comunicazione linguistica e simbolica permette la cultura e il progresso.
Quando comunichiamo con successo? Esistono teorie in merito, ma cosa significa nel lavoro quotidiano di un'organizzazione? La comunicazione richiede un'organizzazione che permetta a tutti di non dover parlare di tutto con tutti. L'organizzazione serve a fornire prestazioni complesse e a titolare la comunicazione con la massima semplicità possibile.
Quando tutti coloro che hanno a che fare con gli altri sono vicini organizzativamente (e fisicamente), le distanze si accorciano. Purtroppo, questo non è sempre possibile: i compiti cambiano più frequentemente dell'organizzazione.
È quasi sempre positivo ciò che favorisce la comunicazione e negativo ciò che la rende difficile. Oltre a una buona organizzazione (che comprende anche una chiara separazione delle cose non correlate), il cosa e il quanto sono importanti quanto il come e il quando.
Sono sempre le persone a comunicare, non le organizzazioni. Un buon capo (manager, project leader, team leader) lascia che le persone giuste facciano le cose giuste. Le persone sono più produttive nelle sfide che amano, che non le mettono né troppo né poco alla prova.
Se l'organizzazione non è corretta, la comunicazione è più difficile perché l'organizzazione deve abbattere le barriere che ostacolano la comunicazione.
La comunicazione funziona meglio quando avviene direttamente tra persone che perseguono gli stessi obiettivi, nel momento in cui le persone hanno a che fare con l'obiettivo.
Servizi come Slack soddisfano proprio questa esigenza e sono quindi molto popolari.
Chiediamo ai dipendenti di valutare le conseguenze (impatto) di tutte le loro azioni. Ovviamente questo vale soprattutto per gli sviluppatori. La trasparenza è quindi necessaria: solo chi ha una visione d'insieme può valutare il proprio impatto. Questo include una visione d'insieme e l'accessibilità ai pianificatori, allo stato e alle risorse. L'apertura all'interno dei progetti ha quasi sempre più vantaggi della segretezza.
Ad esempio, la nostra gestione dei problemi con JIRA(apre una nuova finestra) supporta la comunicazione fornendo una panoramica di tutti i problemi e del loro stato in ogni momento. Gli elenchi manuali non aggiornati, invece, ostacolano la comunicazione e portano a un lavoro extra improduttivo.
Se non parliamo la stessa lingua, si verificano malintesi (Lost in Translation(apre una nuova finestra)). Se non vengono eliminate rapidamente, interi progetti possono fallire. Ecco perché sviluppo, sicurezza, project management, marketing e altre parti interessate dovrebbero trovare una lingua comune.
Se gli sviluppatori non hanno idea del dominio e gli esperti di business non hanno idea del software, il progetto non funzionerà nonostante tutti i metodi agili. Tecniche come Domain Driven Design(apre una nuova finestra) possono fungere da traduttore; le storie utente o i casi d'uso da soli non sono sufficienti, perché sono limitati a una sola lingua, quella dell'utente.
Le grandi organizzazioni preferiscono lasciare la comunicazione esterna ai professionisti: il dipartimento di comunicazione deve instaurare un dialogo e riportare le informazioni dall'esterno all'interno dell'impresa. Pertanto, tutti i dipendenti sono anche messaggi e devono curare la loro comunicazione.
Soffriamo di sovraccarico di informazioni e non ci sentiamo ancora abbastanza informati
Poco è spesso meglio. Familiarizzare con un progetto con centinaia di pagine di documentazione non strutturata è solo leggermente più semplice che non documentare nulla. La documentazione ha bisogno di astrazione per evitare di perdersi nei dettagli.
I classici manuali Concepts and Facilities (di IBM e altri per molti prodotti software) sono una documentazione esemplare e ridotta; insieme a un tutorial e a una Guida alla risoluzione dei problemi, spesso sono sufficienti come documentazione.
Con un'interfaccia utente intuitiva, una descrizione dell'interfaccia è del tutto superflua e di solito è comunque superata.
Dovremmo anche evitare costantemente gli artefatti superflui nella pianificazione. Dovremmo creare solo ciò che è sostenibile e che può essere sottoposto a sostentamento.
"Ridurre al massimo" è quindi auspicabile, ma è più difficile che aggiungere un turno di documentazione come decorazione alla torta.
Questo articolo non tratta di tecnologia di comunicazione (il pane quotidiano di Swisscom), tranne che per un argomento: le API. Questo perché le API connettono la comunicazione tra uomo e macchina.
I processori possono tecnicamente gestire dati di grandi dimensioni senza struttura, ad esempio con la memoria condivisa. Quando si parla di big data o di database non SQL, si pensa a dati non strutturati. Ciò che si intende, tuttavia, è che i dati non si adattano facilmente a uno schema e dobbiamo prima riconoscere le strutture.
Le API permettono di scambiare dati e processi attraverso i confini del sistema e dell'organizzazione. Consentono alle persone coinvolte (di solito gli sviluppatori) di comprendere e orchestrare lo scambio senza doversi addentrare nell'altro sistema o organizzazione. Ad esempio, posso avere bisogno di un'API di Twitter senza dovermi preoccupare di come Twitter gestisce il suo servizio (questo è simile alla comunicazione umana: posso parlare con qualcuno di un problema senza sapere come organizza la sua giornata).
Le API sono la connessione centrale del sistema e delle organizzazioni; sono il fondamento della digitalizzazione.
Il feedback è sempre ben accetto!
Head Application and Business Services
Trova il lavoro o il mondo della carriera che fa per te. In cui vuoi contribuire a plasmare e sviluppare te stesso.
Ciò che ne fai è ciò che ci definisce.
