Archivi categoria: organizzazione

Gli open space riducono la produttività

Gli open space riducono la collaborazione, invece di incentivarla. E riducono la produttività, secondo uno studio riportato da The Economist, July 28th 2018: Open office, closed minds.

Peggio ancora le soluzioni di “hot-desking”, dove il personale non ha una postazione fissa ma occupa a rotazione la prima disponibile in ufficio:

“a clear message to low-level office workers that they are seen as disposable cogs in a machine. Combine this with the lack of privacy and the office becomes a depressing place to work.”

Organizzazione settore IT per prodotti o per progetti

L’organizzazione del settore IT all’interno delle aziende può essere basata su approcci diversi.

In “Products Over Projects”, Sriram Narayan illustra le differenze tra l’approccio organizzativo basato su progetti (orientato tipicamente al solo sviluppo, con risorse allocate in modo temporaneo e tratte da reparti corganizzati per tipo di competenza) e quello basato su prodotti, più stabile e multifunzionale.

https://martinfowler.com/articles/products-over-projects.html

Software aziendale fuori dal settore IT

La quantità di software che le aree aziendali acquisiscono al di fuori dal controllo del settore IT continua a crescere, e rende sempre più critica la gestione del parco applicativo aziendale.

In “Bottom-Up Enterprise Information Systems: Rethinking the Roles of Central IT Departments“, gli autori

Modern technology (such as open source software, outsourcing, and cloud computing) enable users to bypass central IT to procure or configure their own enterprise information systems.

Coupled with inherent organizational limitations, the result is bottom-up enterprise information systems becoming a new reality in many organizations. Managing such systems requires central IT to be a collaborative partner that guides functional areas toward effective IT practices. Central IT’s operational role may diminish as the functional areas assume increased duties.

However, when IT roles are distributed across the organization, additional coordination is required by central IT, functional areas, and vendors alike.

Microservices

Introduzione ai Microservices di Martin Fowler. Questi gli spunti più interessanti:

  1. Rapporto tra microservices e SOA (Service Oriented Architecture). I microservices sono solo uno dei modi in cui la SOA può essere organizzata: senza bus centrale (Enterprise Service Bus), autonomi ed indipendenti.
  2. Organizzare lo sviluppo per microservices significa, prima di tutto, definire e attuale un modello organizzativo in cui ogni team lavora in modo indipendente. A occhio, maggiori sono le dimensioni del team di sviluppo, più questo modello organizzativo è sensato.
  3. I microservices hanno senso per fornire servizi di business completi. Avrebbe meno senso definire microservices puramente infrastrutturali.
  4. Per lavorare a microservices bisogna avere già una forte competenza sulla materia, sul dominio applicativo. Se questa manca, meglio sviluppare prima un monolite e poi, se opportuno, ristrutturarlo estrapolandone i microservizi.

Spirito di gruppo

Il lavoro in gruppi multidisciplinari si sta diffondendo in nuovi settori, ma gestire i team può essere difficile, e entrare in conflitto con la cultura organizzativa.

The Economist, Team spirit, Mar 19th 2016: http://www.economist.com/news/business-and-finance/21694962-managing-them-hard-businesses-are-embracing-idea-working-teams

Persone, prima dei processi

Crosstalk, rivista software dei militari USA, notevole.

Sul numero Mar/Apr 2016, in “People-driven vs. Process-enabled Software Development: a 21st Century Imperative”, c’è la motivazione più chiara che io abbia letto sul perché è più importante la scelta delle persone rispetto al processo di sviluppo. Che al massimo può evitare di rendere difficile la collaborazione tra chi partecipa al lavoro.

Lo diceva già il Manifesto Agile del 2001, sono più importanti “gli individui e le loro interazioni, più che i processi e gli strumenti”.

E prima ancora l’ottimo “Peopleware” di DeMarco e Lister (mai tradotto in italiano!) aveva spiegato che il fattore più importante nello sviluppo software sono le persone, e il modo in cui interagiscono tra loro.

 

L’importanza del supporto utente

Mettere al centro il cliente, uno slogan che è di moda da anni, ormai un classico. Ma per passare dalle parole ai fatti bisogna fornire un ottimo supporto utente.

In molte aziende, invece, l’attenzione è centrata sul marketing e sulla vendita, e il supporto viene considerato un male necessario, se possibile da esternalizzare a terze parti. Grave errore, come spiega Gerry McGovern in If the customer really was king.