Archivi Mensili: novembre 2012

Le motivazioni come motore del team di lavoro

30 venerdì Nov 2012

Posted by in Senza categoria

≈ Lascia un commento

Gestire un team apre spunti di riflessione non solo sulle modalità di soddisfacimento degli obiettivi di progetto, ma anche su quelli personali del team.

Da qui, è compito del referente di progetto capire le motivazioni del proprio gruppo e di ciascun singolo, ponendosi l’obiettivo di soddisfarli, perché questo si coniuga con l’obiettivo di progetto, perché se il team è motivato farà meglio il suo lavoro!

Partirei da una distinzione fondamentale delle motivazioni: intrinseche ed estrinseche.

Le motivazioni intrinseche sono quelle naturali, basate sulla curiosità e sul il bisogno di esplorare l’ambiente alla ricerca di nuove informazioni e soluzioni. Importante per la motivazione intrinseca è, inoltre, la padronanza, cioè il bisogno di sentirsi sempre più competenti.

Le motivazioni estrinseche sono quelle dettate da un impegno in un’attività per scopi che sono estrinseci all’attività stessa, quali, ad esempio, ricevere lodi, riconoscimenti, buoni voti o per evitare situazioni spiacevoli.

Image

Notate queste caratteristiche trai propri membri del team, non sarà facile trovare il giusto compromesso tra le due; spingiamo su quelle intrinseche che mi ispirano parecchio.

La Self-determination theory (Deci, Ryan 2004) propone queste caratteristiche intrinseche:

Image

Competence: ciò che una persona dimostra di saper fare (anche intellettualmente) in modo efficace, in relazione ad un determinato obiettivo, compito o attività in un determinato ambito disciplinare o professionale [ Centro studi Erickson].

Autonomy: non è da intendere come il dover sapere fare tutto da soli, ma consiste nella capacità di saper ricavare le giuste informazioni dai giusti interlocutori, necessarie a portare avanti il proprio lavoro.

Relatedness: la capacità di sapersi relazionare non solo coi propri colleghi ma anche coi propri clienti,  al fine di riuscire a soddisfare gli obiettivi business e commerciali.

Notare come queste 3 caratteristiche siano strettamente correlate tra loro.

Da queste 3 caratteristiche sono state formulate altre teorie basate sulle motivazioni, sino ad arrivare alla definizione di quelli che sono i 10 Desideri dei membri del team (di cui 3 sono quelli sopra descritti):

Image

Feel accepted: sentirsi parte integrante del team, mediante la collaborazione con tutti e la condivisione delle proprie esperienze e del proprio background professionale;

Curiosity: trovare, anche di fronte ad un’attività noiosa, qualcosa di nuovo che possa stimolare la propria curiosità;

Honor: la squadra deve proporre le proprie regole di gioco (condivise dal referente), così saranno più facili da seguire;

Purpose: avere sempre obiettivi di breve, medio e lungo termine, non solo circoscritti al perimetro dell’attività che si sta portando avanti in quel periodo;

Order: recepire le norme aziendali sufficienti a consentire il buon vivere all’interno della propria organizzazione;

Influence: percepire ciò che sta accadendo intorno a noi, ascoltando ciò che hanno da dire gli altri e aiutarli col nostro contributo e col nostro carisma (avendo la fortuna di averlo;))

Status: capire il proprio valore all’interno dell’organizzazione.

Approccio alle applicazioni orientate ai servizi

22 giovedì Nov 2012

Posted by in Enterprise Architecture, SOA

≈ Lascia un commento

Tag

Questi ultimi anni sono stati caratterizzati dalle nuove tendenze architetturali che hanno visto sulla cresta dell’onda il modello architetturale SOA.

SOA è un’architettura orientata ai servizi e si propone come metodologia per organizzare gli elementi delle applicazioni come servizi. La letteratura presenta però svariate definizioni e il modello di riferimento non è standard.

Per cui tutto ciò lascia spazio ai vendor che “propongono” i loro prodotti e le proposte dei vari fornitori sono dei modelli che non sempre rispecchiano dei principi architetturali corretti e pur dichiarando di implementare SOA, contraddicono regole di buona programmazione enterprise.

Molto spesso l’errore è quello di lasciarsi guidare e partire dalle tecnologie abilitanti una soluzione, senza invece partire dalla soluzione al problema, depurata dagli strumenti atti a realizzarla.

In questi anni abbiamo lavorato a un modello architetturale orientato ai servizi, applicato in seguito in ambito bancario, con le customizzazioni del caso.

Il modello architetturale è stato ideato partendo dall’assunto che i modelli applicativi tipici prevedono l’esistenza di un front-end (illustrato nella parte sinistra della figura sotto); da qui vogliamo poi integrare quello che fa parte del contesto SOA (data la necessità di esporre i sistemi come servizi) con tutto ciò che non fa parte di un contesto a servizio (illustrato nella parte destra della figura sotto).

Image

Ecco i layer architetturali del mondo SOA:

  • Integration: risolve il problema dell’eterogeneità delle tecnologie. E’ lo strato di confine tra il mondo soa e quello non soa, come tale riesce ad integrare le funzionalità dei sistemi esistenti come database o sistemi legacy. Tale layer presenterà una interfaccia che riesce ad interagire col mondo non-soa ed una seconda che interagisce col sistema di riferimento soa;
  • Execution: gestisce la logica di business;
  • Composite: orchestra i servizi di sistema ed espone le funzionalità business mediante dei processi orchestratori del flusso generale;
  • Service: questo livello, ”realizza” le funzionalità business, per cui si vuole separare la realizzazione o implementazione da quello che è la presentazione del servizio. E’ una sorta di delega che espone il servizio business verso l’esterno. La sua utilità è legata anche alla possibilità di presentare un certo sotto-insieme dei servizi che si vogliono esporre in base ai diritti di chi accede al sistema.

Il modello descritto si è prestato a supportare casi reali di nostri clienti, soprattutto di ambito bancario.  Il contesto molto spesso è stato quello di effettuare la migrazione del loro prodotto o di parte di esso verso uno nuovo  che rispondesse ai principi SOA. Non sempre tutti i layer sono stati necessari, la loro introduzione o meno dipende dai contesti in cui si opera.

Il modello permette di rispondere agli obiettivi di integrazione e di facilitare il processo di sviluppo delle applicazioni SOA-oriented. Inoltre, vuol essere un’alternativa ai modelli proposti dai fornitori, sottolineando il fatto che non sempre è necessario utilizzare un ESB per fare SOA.