descarrega la versió pdf d’aquest article
Que vol dir empoderar? Aquesta expressió s’ha d’entendre, no des d’una semàntica de poder, sinó de responsabilitat. La responsabilitat de tots els actors del projecte és clau per a garantir un bon flux de les comunicacions, les relacions i l’acompliment dels objectius del projecte.
Els usuaris clau són un element especialment important per a garantir l’èxit final del projecte i dels seus productes. Un usuari clau que no assumeix les seves responsabilitats en el projecte pot generar seriosos problemes en la comprensió de la necessitat i de la solució, que poden acabar en fracàs o en la cancel·lació del projecte.
Metodologies tradicionals (i pesades) com PRINCE2 fa anys que són conscients de la importància de l’equilibri de responsabilitats entre tots els participants, i estableixen mecanismes de direcció, seguiment, acompliment de la qualitat i acceptació molt estrictes.
Amb l’aparició de marcs de treball àgils pot semblar que aquests aspectes són més laxes, i fins i tot podem pensar que són inútils, però això és un element més de confusió en la voràgine actual d’assimilació desordenada d’Agile.
En aquest sentit és important assegurar que l’usuari clau realment assumeix la responsabilitat que li pertoca. Les responsabilitats no es deleguen; la feina sí que pot delegar-se. És a dir: l’usuari clau ha d’assegurar-se que ell o una altra persona a la qual delegui acompleix les fites que se li encomanen. Però la responsabilitat en l’acompliment de les fites pactades serà de l’usuari clau i no dels delegats.
Una premissa important que proporciona tranquil·litat en la gestió d’un projecte és la tria encertada dels usuaris clau del projecte. Els usuaris clau els tria el negoci i no el projecte; i és responsabilitat seva fer una tria adequada i realista. Un usuari clau és una persona que, a banda de la seva feina habitual, dedica un temps (sovint considerable) en col·laborar en la definició de les necessitats, i en l’acceptació posterior dels resultats.
L’usuari clau és una persona que principalment:
*Coneix el negoci en detall *Ha de disposar d’aquest temps imprescindible per tal de tenir la interlocució necessària amb els equips del projecte
Per poder assimilar tota la informació necessària per a dissenyar una solució completament satisfactòria hem d’assegurar un bon clima de comunicació amb aquests usuaris. Això només és possible si tenim en compte una sèrie de factors que han de quedar clars des del primer moment del projecte:
*La responsabilitat dels usuaris clau en el projecte *Les fites, les tasques, les reunions i, en definitiva, el pes d’aquestes responsabilitats per part de l’usuari clau *L’abast del projecte (que es fa i que no es fa)
En el punt anterior parlàvem que la principal responsabilitat de l’usuari clau és assegurar-se que l’equip del projecte entén la problemàtica a cobrir per la solució. En aquest sentit, hi ha alguns ítems que afecten la forma de comunicar o a “què es comunica” que sovint genera malentesos en l’equip del projecte. Per completar la llista anterior podem afegir que l’usuari clau ha de:
Un projecte és una acció d’equip en la que acostuma a participar un grup heterogeni de persones, amb diferents graus de coneixement o especialitat. És necessari generar un clima de transparència en el treball i assumpció de responsabilitats, per tal d’afavorir la generació d’un clima de confiança que faciliti la construcció de la solució idònia.
Tothom ha d’entendre el mateix respecte a l’abast i respecte al flux del negoci de l’usuari. L’equip del projecte i els usuaris han de parlar el mateix idioma. I l’únic idioma vàlid en aquest sentit és l’idioma del negoci, amb totes les seves particularitats i argot. Només així podem estar segurs que l’abast del projecte és ben entès per a totes les parts
Un cop tenim empoderat a l’usuari clau, el següent pas és incloure’l dins de la dinàmica del projecte, i dotar a l’equip de les eines que facilitin la seva organització interna i la seva coordinació, un marc de treball que els permeti treballar de forma ordenada i racional, i un àmbit de decisió que els permeti ser operatius, eficients i autònoms.
Un equipo es un conjunto de pUn equip és un conjunt de persones que col·laboren per l’assoliment d’uns objectius comuns. Aquesta senzilla definició sovint és oblidada per passar a ser “un grup de persones que treballen plegades”. Perquè un “grup” passi a ser un “equip” cal que:
Para alcanzar este nivel Per assolir aquest nivell de col·laboració, l’equip del projecte ha de disposar d’espais i temps per assolir el clima necessari per arribar a acords interns i treballar col·laborativament i constructivament.
L’equip del projecte són totes aquelles persones amb responsabilitat sobre la infraestructura, l’arquitectura i la qualitat. Tots ells formen part de l’equip del projecte. La complexitat de les organitzacions influeixen també en l’organització interna del departament tecnològic; on es creen subdepartaments especialitzats en certs aspectes del programari, maquinari, seguretat, processos o gestió.
Un element més de complexitat acostuma a ser l’externalització dels serveis, que afecta moltes operatives de l’àrea tecnològica, però especialment al desenvolupament de solucions. Arribant a l’extrem en què en l’àrea tecnològica s’adquireix un rol de lideratge de projecte, amb equips humans i recursos externalitzats.
Tothom ha de tenir una responsabilitat clara en el projecte; i es demana de tothom la màxima implicació en el projecte. Algunes persones pensen que participar en un projecte és “opinar”. Van, diuen el que els hi ve de gust dir, i marxen. S’ha d’evitar aquesta actitud.
Tota persona que participa en un projecte té una responsabilitat, i l’assumpció d’aquesta responsabilitat és deriva necessàriament en l’assumpció d’una sèrie de tasques assignades. Fuig dels opinadors sense feina en el projecte.
Algunes organitzacions dediquen recursos a assegurar que el coneixement funcional i de negoci no es perd; de forma que aquest coneixement està en mans d’un equip de persones que vetlla per transmetre’l quan és necessari, i per la seva coherència situacional i evolutiva.
Aquestes persones també son part de l’equip del projecte. El cap de projecte necessita estar assessorat per algú amb una visió més transversal del negoci que els usuaris clau i que ell mateix. Per tal d’assegurar el millor possible que les situacions descrites són coherents amb aquest coneixement; i que les propostes de solució també són coherents des d’una perspectiva global.
Aquests facilitadors també poden exercir el paper de negociadors en situacions de conflicte. I de donar suport als usuaris clau en la presa de requeriments. Aquest equip requereix una formació molt específica, i de l’assumpció d’un rol molt concret. Aquestes persones han d’ocupar un lloc d’equidistància entre els interlocutors. I han de basar les seves intervencions en funció dels impactes sobre els processos de treball de l’àrea de negoci; o bé si generen conseqüències negatives fora de l’àrea destinatària del projecte. No prenen decisions unilaterals que afecten el projecte, i no són l’advocat de l’usuari.
Un factor molt important correspon al fet que els caps del projecte, a banda del coneixement tecnològic suficient; i els coneixements de gestió del procés del projecte i dels equips; han de tenir un coneixement suficient sobre l’àrea de negoci i sobre l’organització per poder exercir la seva feina. Això implica no només conèixer el flux de negoci del departament en qüestió, sinó també conèixer “com parlen” en aquell departament.
Els caps de projecte són els directors operatius del projecte. Tenen la màxima responsabilitat, i estan per a prendre decisions i cercar consensos. D’aquest fet ha de ser conscients tots els participants. L’objectiu de tot projecte és la creació d’un producte útil. I per aconseguir-ho comporta una acció contínua de negociació i consens, però per sobre d’això, comporta la presa de decisions que no sempre deixa content a tothom.
En aquest sentit el cap de projecte pren decisions en funció dels acords que negoci, interessos de tots els participants, i la mateixa organització. Prendre decisions no necessàriament significa l’establiment d’una jerarquia a l’intern de l’equip, on la figura màxima és el cap del projecte. Més aviat prendre decisions vol dir facilitar el clima òptim en l’equip perquè aquest protagonitzi les decisions i lideri les accions necessàries.
Això representa un canvi en el paradigma tradicional del cap de projectes, que passa a ser un facilitador més que un comandament. Això requereix confiança en l’equip, i proactivitat per part dels integrants. Un equip passiu no és un bon punt de partida per comprometre’s amb un pla conjunt. Cal pedagogia per motivar l’autoorganització necessària perquè l’equip sigui el motor del projecte de forma contínua. Les decisions no es prenen un dia D a una hora H. Es prenen cada dia, quan és necessari.
Relacionat amb el punt anterior, l’única forma de garantir que el projecte realitza les accions, i que aquestes són parelles amb les decisions que s’han pres, és establint un sistema d’informació o seguiment entre les persones que prenen les decisions. Els caps de projecte rendeixen comptes al grup de seguiment directiu que s’hagi establert.
Rendir comptes és l’acció de casar les decisions preses amb les accions realitzades en el projecte. I perquè això sigui coherent, les persones que prenen decisions i que tenen la responsabilitat, han de ser les mateixes que articulen el seguiment.
El cap de projecte no rendeix comptes a ningú més. L’equip directiu els protegeix per evitar que el projecte es vegi influït de forma externa. Sembla una obvietat, però molts projectes pateixen aquest tipus d’interferències i generen conflicte entre el que inicialment es decideix, i el que finalment es realitza.
Per últim, un factor important correspon al control de les variables del projecte. L’atribució principal del cap de projecte és el control d’aquestes variables, i la llibertat suficient per poder prendre decisions. Si no es té aquest control, el cap de projecte no és un gestor, és una altra cosa.
Les variables sota control del cap de projectes són:
Per a què els diferents membres de l’equip assumeixin la seva responsabilitat, i treballin de forma coordinada entre si, cal proporcionar bàsicament quatre pilars:
Per aplicar agilitat en processos complexos, on intervenen sovint un gran nombre de persones, és necessari ser conscients que les operacions de gestió (el management) és massa important per deixar-ho només en mans de gestors. Hem de transmetre la idea que la gestió també és una tasca d’equip, i que el cap del projecte focalitza els seus esforços en crear el clima necessari per al foment de la gestió eficient i la creativitat, (cuida un jardí).
Es tracta de trobar un clima de treball en què l’equip és l’autèntic protagonista sobre el “com” es fan les coses al seu intern. I aquí el cap del projecte és un membre més en l’equip.
Les principals barreres en l’adopció de l’agilisme són diverses, però es poden destacar:
Que és una organització anti-àgil? Una organització anti-àgil és aquella en què els seus elements de coordinació interna i productius s’articulen entorn de dos elements característics: Burocràcia i jerarquia. De forma que, per tal de dur a terme qualsevol acció prevista a l’organització, aquesta és avaluada a través d’un procés formal o informal que la pauta i la delimita (burocràcia), i dona resposta a interessos de grups que coordinen la seva idoneïtat, abast i temporalitat, i que tenen l’atribució a diferents escales de validar o no la seva conveniència (jerarquia). Amb l’existència d’un nucli que centralitza les decisions, i que estén el seu poder a tota l’organització (Taylorisme)
Aquest tipus d’organització són vistos com una màquina; capaç de fer un nombre concret d’accions, i d’una forma determinada, que a més tendirà sempre a ser la més eficient possible. Per assolir aquest màxim d’eficiència, mostra una tendència en especialitzar-se per seccions (o ninxos). Els ninxos actuen com a engranatges independents que tenen visió només d’una part de la cadena de valor de l’empresa, i on s’estableixen vies estrictes de contacte amb altres engranatges.
Quan aquest tipus d’organitzacions és sorpresa amb canvis tecnològics, humans, organitzatius, polítics, pressupostaris, i un llarg etc. que posen en perill el seu statu quo actual, necessiten adaptar-se. L’adaptació en una organització-màquina és possible, però és lenta i sovint desemboca en adaptacions parcials que no cobreixen completament allò que les va forçar a canviar.
Una organització àgil és aquella en què els engranatges tenen tots ells (o gran part) una visió completa de la cadena de valor de l’organització. Són autoorganitzades i tenen capacitat de decisió. El centre de l’organització no és vist com un centre de poder, sinó com una guia en la direcció. La capacitat d’adaptació d’aquestes organitzacions vénen determinades per la seva flexibilitat interna i externa. Els diferents nuclis (o cèl·lules) operatius poden créixer, disminuir i alterar la seva organització interna i especialització. Poden aparèixer noves cèl·lules per a cobrir noves necessitats i adaptar-se als canvis, siguin els que siguin.
Una estructura de relacions documentada és un esforç per explicar de forma gràfica les relacions entre els diversos membres de l’equip, focalitzades en l’assumpció de responsabilitats. Al gràfic següent mostrem una proposta d’estructura de relacions, amb tots els grups i persones que hi intervenen en un projecte:
En aquest gràfic podem descriure els rols següents:
El Cap de projecte correspon a la figura que, en última instància, té la responsabilitat principal d’assegurar el contacte continuat de tots els membres de l’equip. Aquestes responsabilitats les podem resumir de la forma següent:
El Grup de Seguiment és l’òrgan que té la funció principal d’avaluar el seguiment del projecte, en funció a la informació que l’equip, i principalment el cap de projecte li trasllada. Pren decisions i ajuda a la priorització dels objectius, i a la resolució dels problemes i riscos que siguin de la seva competència
Idealment, els membres del grup de seguiment han de veure reflectits tots els interessos del projecte i de l’organització. Així doncs, han de veure’s cobertes les visions tecnològiques, però també la visió del negoci i dels constructors/proveïdors.
La PMO és l’òrgan que dóna suport a l’equip de projecte per tal que s’acompleixin els requeriments de qualitat tant pel que fa al producte del projecte, com per al mateix procés. La seva vinculació amb el projecte no s’ha de confondre amb una auditoria. Son part de l’equip i tenen tasques i responsabilitats assignades. Per tant col·laboren amb l’equip en l’assegurament de la qualitat del projecte.
L’Usuari clau és una figura primordial en l’equip; i té un nivell de participació en què va més enllà de ser un facilitador estàtic d’informació del negoci. Ajuda a l’equip a prioritzar els objectius. Ajuda a definir la profunditat (el detall) dels objectius del projecte i del seu abast. Ajuda a resoldre els problemes, i a preveure’ls, identificar-los i mitigar-los. I per sobre de tot ajuda a validar que el resultat del projecte acompleix les expectatives de qualitat de forma iterativa i incremental. I per això es compromet a treballar amb el producte des del primer moment
Els Facilitadors, tal com hem explicat en seccions anteriors, es constitueixen com un pont en la comunicació entre els usuaris clau i l’equip del projecte. Els facilitadors tenen sentit quan la informació de negoci necessària per a l’execució del projecte és o molt complexa, o molt dispersa. Si no és així, no hi hauria d’haver cap inconvenient en què tecnòlegs i usuaris entrin en contacte directe. Moltes organitzacions han arribat a la conclusió que tecnòlegs i usuaris mai podran entendre’s. És una visió típica dels anys 90, que actualment encara perdura.
Els Caps de Projecte proveïdors són els responsables de l’operativa de la construcció / implantació / adquisició per part dels constructors o proveïdors assignats al projecte. Tenen un paper molt semblant al Cap del Projecte general, però el seu àmbit de responsabilitat se centra en el seu equip de construcció. Sovint l’equip de construcció es troba en les instal·lacions del proveïdor, i és poc conegut i poc accessible per l’equip del projecte. El Cap de projecte proveïdor fa de passarel·la entre els desenvolupadors i la resta de l’equip.
Per últim, aglutinem la resta de membres de l’equip sota l’epígraf de Col·laboradors. Un col·laborador és aquell que dins de l’equip desenvolupa un o més rols que són necessaris per poder executar alguna de les tasques del projecte. En l’àmbit d’un projecte, totes les tasques necessàries necessiten ser cobertes, o bé liderades per un membre de l’equip. No poden haver-hi tasques sense un responsable assignat.
Com hem dit abans, col·laborar implica necessàriament desenvolupar una tasca dins del projecte. Una tasca és un treball que té com a resultat final un subproducte útil per al producte del projecte o per a l’equip (un informe, una acció d’R+D, codi, etc.). No és un subproducte útil per al projecte una opinió no contrastada.
Tampoc és un subproducte útil per al projecte l’auditoria d’una acció ja realitzada en l’intern de l’equip. Un NOK d’un subproducte finalitzat és un trauma en el projecte. Significa que els creadors del subproducte no han entès les regles. Però també significa que els auditors han actuat de forma reactiva en la construcció del subproducte. Si una auditoria ha de formar part de les tasques del projecte, significa que els auditors formen part de l’equip del projecte. I significa que són ells qui lideren les accions necessàries per assolir un OK en el subproducte.
De totes les fites de govern d’un projecte, podem determinar dues que són especialment importants. Aquestes són:
El kickoff és una acció en forma d’una sessió, en què tots els membres del projecte, i les persones impactades o interessades es reuneixen i exposen tots els aspectes clau, amb l’objectiu d’obtenir una llum verda per part de tots els assistents, que permeti l’inici de les accions d’execució del projecte
Però per arribar al dia en què es realitza una sessió, que acaba en l’acceptació de tot allò que s’exposa, el cap de projecte ha de realitzar una feina ingent destinada a assegurar aquest resultat. Aquest procediment, descrit com procediment de Inici del projecte, el veurem tot seguit
De forma resumida, el procés d’inici de projecte té com a objectiu principal definir en detall els objectius, l’abast, i la relació dels membres de l’equip de projecte, i les seves responsabilitats. Un kickoff que defineix amb èxit aquests aspectes és una molt bona manera d’iniciar un projecte. De fet, molts projectes fracassen per:
Per assolir un relat que sigui acceptat per a totes les parts en una sessió d’inici de projecte, cal abans encetar un procés que té com a finalitat determinar els objectius, l’abast, les claus d’èxit, la planificació inicial / desitjada, l’organització de l’equip, les responsabilitats i els riscos
Això requereix reunions amb els usuaris clau, amb els proveïdors i amb altres àrees afectades; i negociar amb ells una visió clara i consensuada del projecte i del producte resultant. Un cop fet això, la sessió de kickoff es converteix en una coreografia de final controlat que té com a únic objectiu explicitar aquest consens entre totes les parts.
Quan podem determinar que un projecte s’ha finalitzat?
Igual que l’inici del projecte és una acció de consens que dóna el tret de sortida a l’execució, la finalització del projecte no pot ser d’una altra manera. Un projecte finalitza únicament en dos escenaris possibles:
El que està clar és que l’únic estament que té la prerrogativa de finalitzar un projecte és el mateix equip del projecte. De forma ordenada, consensuada i documentada. En ambdós casos és necessari exposar la situació final del projecte i del producte del projecte, Les accions de continuïtat, garantia i manteniment que es desprenen, i la valoració respecte a la satisfacció del procés, del producte i respecte a les lliçons apreses.
A tall de resum, les principals fites o “moments” en un projecte poden resumir-se en el diagrama següent:
L’inici del projecte és un procediment que té com a objectiu assentar les bases del govern i de l’execució del projecte. Per aconseguir això cal establir una sèrie de premisses del projecte que podem resumir en la llista següent:
Per la determinació i detall de tots aquests aspectes es treballa amb tots els implicats seguint el flux de treball següent:
Un projecte acaba quan els membres de l’equip determinen que s’han assolit els objectius suficients establerts a l’inici del projecte; o bé quan decideix avortar-lo per causes justificades.
Igual que a l’inici del projecte, la finalització requereix la consecució d’una sèrie d’activitats que tenen com a objectiu el tancament ordenat de les activitats, l’assegurament de l’explotació del producte del projecte, l’avaluació de la satisfacció de tots els implicats, i l’avaluació dels beneficis obtinguts pel producte del projecte
La planificació (PLN) no és una acció única que es duu a terme a l’inici d’un projecte. Aquesta concepció de la planificació com acció única inicial és una forma ineficient d’afrontar el canvi inevitable en les organitzacions actuals.
Es necessita més agilitat en la planificació; i proporcionar un mètode de treball que faciliti una planificació dinàmica basada en cicles iteratius de construcció de valor per a l’organització. Però és important tenir clars i tancats l’abast i els objectius que persegueix el producte del projecte. El dinamisme en la planificació no pot significar incloure o treure arbitràriament aspectes funcionals, operatius o tecnològics considerats crítics.
Si plantegem la planificació com un element viu que apareix de forma iterativa com a fita en cada cicle del projecte, llavors ens veurem abocats a plantejar la construcció de tots els documents d’enginyeria necessaris per al projecte (disseny funcional, tècnic, desplegament, testing, etc.) també de forma iterativa i incremental. I fins i tot plantejarem les accions de posada en productiu i pla de formació de la mateixa manera. Això facilita enormement la tasca d’avaluació contínua i acceptació per part dels usuaris clau i les àrees usuàries a les quals va destinat el producte.
La planificació iterativa té una contrapartida important: Cal ser molt curós a l’hora de mantenir la coherència d’una planificació focalitzada en cicles, respecte al compromís global en l’acompliment d’un abast, uns objectius, un pressupost i un calendari global. Això requereix d’un esforç per a que l’equip mantingui constantment una visió global del projecte. Això és extensible a tots els elements documentals i d’enginyeria necessaris per a l’execució del projecte. Tots els elements que es construeixen incrementalment requereixen d’un esforç addicional per a mantenir la coherència global.
El document que articula la planificació és el document de Planificació (PLN), en què queden definits el calendari, la forma en què s’avalua la qualitat, la forma en què es comunicarà i s’organitzarà el projecte, i la relació de riscos i plans de mitigació
No s’ha d’entendre la reunió de seguiment com a l’òrgan de govern intern de projecte. L’equip de projecte no fa reunions de seguiment programades en calendari. Es coordina cada dia, i avalua els resultats interns, o tracta els problemes cada dia
La reunió de seguiment és una acció que està per sobre de l’operativa diària del projecte, i que té com a objectiu informar als òrgans de seguiment, sobre les accions realitzades fins a la data. Aquestes reunions poden estar planificades, o tenir lloc a demanda (quan apareix una fita clau, o un problema que no es pot resoldre a l’intern de l’equip)
El document que articula la reunió de seguiment és l’Informe de Seguiment (IFS). I es conforma com a acta de reunió on s’expressa la situació general del projecte, la situació dels riscos, i les principals decisions preses. Els informes de seguiment són coneguts per tot l’equip del projecte i determinen la seva priorització a alt nivell. L’equip és autoorganitzat, però no completament autònom. L’òrgan de seguiment té la potestat de marcar la priorització dels grans elements funcionals, però no la forma o l’ordre en què es realitzen les tasques en l’intern de l’equip, ja que hem de respectar la premissa que l’equip és autoorganitzat
La reunió de resultats és la peça que ens ajuda a determinar fins a quin punt som d’àgils en l’execució del projecte. Un projecte amb un nombre elevat de sessions de presentació de resultats i acceptació implica un flux de treball focalitzat en l’obtenció iterativa de producte de valor. És a dir, en la construcció iterativa i incremental del producte del projecte, que és explotat per l’usuari des del primer cicle.
La presentació de resultats i acceptació s’articula directament a través del producte creat, i de com aquest resol els objectius plantejats per al cicle en curs. Sense documents de presentació. Directament amb el producte. En la presentació de resultats també es cerca activament una acció pràctica d’acceptació per part dels usuaris clau. L’acceptació implica obligatòriament l’acceptació de l’increment de producte proporcionat, i l’inici del cicle següent.
