descarrega la versió pdf d’aquest article
Un cop totes les persones que hi intervenen en un projecte estan convenientment empoderades, coneixen les seves responsabilitats i compten amb el suport de l’organització adequat al seu nivell de responsabilitat, cal que treballin com un equip. Per treballar com un equip és un bon punt de partida, la bona voluntat i el constructivisme. Però no és suficient. Calen eines i mètode.
Les eines i fluxos de govern no són una invenció per a ser ignorada. Són un compromís de tots els equips de projecte per a tots els projectes
El cap de projecte vetlla per assegurar que aquests fluxos són compresos i utilitzats per tot l’equip. L’equip per la seva banda vetlla perquè les litúrgies establertes en aquests fluxos, així com els documents i les eines són útils per la seva feina, la faciliten i estan enfocades en la consecució d’un producte de qualitat.
Els fluxos de gestió i execució del projecte, les eines i plataformes de suport per a l’equip del projecte, la documentació i els marcs de treball s’han de constituir com un estàndard en la gestió de projectes de l’organització
Però hem de ser conscients que són simples eines. Un projecte no consisteix en l’ús obsessiu de plantilles i aplicacions de gestió, sinó en la consecució d’uns resultats de qualitat. Les eines ens ajuden a assolir això, però mai són la finalitat del projecte. Els caps de projecte tenen la responsabilitat de conèixer i fer conèixer els marcs i els fluxos de treball. Defensar-los i utilitzar-los de la forma més convenient per al projecte. Les normatives no són un llibre d’instruccions pas-a-pas, ni els caps de projecte són uns robots d’informació d’aplicacions de gestió.
Si l’organització no contempla en la seva normativa la gestió àgil, i l’equip del projecte troba adequat aplicar agilitat al projecte, res ha de frenar una via per canviar les normes. Els equips de projecte són la porta d’entrada de noves formes de fer, i vetar això és empobrir l’organització.
Però no tot val. Un cop el projecte ha pres algunes decisions sobre com treballar, els canvis sobtats en l’organització del projecte no són positius. Ens hem d’assegurar que les regles de gestió i les normes de qualitat en el treball i els productes són compresos i acceptats per tot l’equip, perquè això marcarà el dia a dia en el treball intern, l’avenç del projecte i les acceptacions internes.
El flux de gestió del projecte és l’eina que serveix a l’equip del projecte per determinar:
Una bona pràctica en la gestió del projecte és situar els riscos com a peça central de la gestió. Implantar un mètode de vigilància activa de riscos, que sigui comuna i que faciliti la detecció primerenca de problemes o perills del projecte, així com planificar i articular les accions de mitigació. Sense oblidar les accions que ens permetin realitzar el seguiment de la situació dels riscos de forma periòdica dins de l’equip i amb els òrgans de seguiment.
Focalitzar-se en els riscos ajuda a l’equip a preguntar-se constantment que pot sortir malament. La gestió centrada en riscos requereix d’un flux de gestió que permeti aclarir en tot moment la situació d’un risc, el pla de mitigació, la situació de les accions del pla i, per sobre de tot, qui són els responsables de les accions de control i mitigació.
La identificació dels riscos són una font de problemes entre els diversos participants del projecte. La descripció d’un risc ha de ser concreta, entenible per a totes les parts, sincera i no alarmista. S’han de comunicar de forma eficaç, primerenca i segura. S’han de documentar per poder fer un seguiment efectiu de la forma més semblant possible a una auditoria. Els riscos cerquen millorar el projecte o el negoci, i no poden ser mai un acte agressiu contra persones o el mateix projecte.
Però en la descripció del risc no s’ha d’eludir la problemàtica que genera el risc. Els riscos que no tenen solució no són un risc, són una alteració de l’abast. Els riscos aplicables a persones no són un risc; són un element del qual s’ha de prendre una decisió i actuar.
Un altre element important per la correcta aplicació dels fluxos de govern del projecte correspon a les eines i repositoris que permeten registrar, emmagatzemar i validar els elements o subproductes necessaris per a la construcció del resultat del projecte. Aquests són: codi, paquets de test, documentació d’anàlisi i disseny, informes de seguiment, actes de reunió, etc
El repositori ha de ser accessible per tots els participants del projecte, i per totes aquelles comunitats que tenen un interès a conèixer la situació, abast o objectius del projecte. Tots els projectes repossitats han de compartir una estructura comuna que faciliti la cerca de documents.
Pel que fa als documents; els formats, continguts i mínims de qualitat documental han de ser coneguts per totes les parts. Els documents passen per un flux de revisió i acceptació igual que qualsevol altre lliurable del projecte.
L’ús de plantilles, guies d’ús i estàndards documentals són molt recomanables per aconseguir un nivell documental de qualitat acceptable per a totes les parts del projecte. Tenir una documentació de qualitat no significa fer documentació excessivament extensa i exhaustiva fins a l’avorriment. Hem de trobar l’equilibri per aconseguir una documentació útil per a l’equip, i sense que la creació de la documentació es converteixi en l’objectiu principal del projecte (els mitjans per sobre de la finalitat).
Fabricar la documentació del projecte té una part mecànica, per la qual les plantilles i altres eines ens poden ajudar. Però també té una part que depèn de la nostra habilitat per plasmar la informació necessària en el document, i ressaltar allò veritablement útil per al projecte. La capacitat de síntesi, la claredat en l’expressió, l’ordenació dels continguts, l’ús d’eines d’enginyeria per sobre de l’ús excessiu de la narrativa, són claus per la construcció d’una bona documentació del projecte.
L’execució del projecte és molt més exigent en temps i dedicació del que ens podem imaginar. Qui pensi que és el moment de “passar la pilota” al proveïdor i que ja ens avisarà quan hagi acabat, és que no entén la idea de projecte i de treball en equip.
No només el constructor, sinó tothom. Però és especialment important per a l’equip que és protagonista de les accions de desenvolupament, implantació o adquisició seguir aquest flux. Perquè serà aquest equip qui principalment vagi alertant sobre les fites establertes.
En l’execució tot el protagonisme està centrat en la construcció o implantació del producte, les seves acceptacions, els seus problemes i la seva qualitat. És responsabilitat de l’equip del projecte alertar sobre els problemes, presentar els resultats parcials i informar sobre l’evolució a mesura que el projecte avança.
Per a fer això possible hi ha dues eines que són crucials:
Per aconseguir això la paraula proactiu és la clau. Ser proactiu implica tenir sempre present el flux de treball. Fer allò que toca a cada moment, i alertar sobre desviaments. Només quan tothom té el flux al cap, les persones treballen de forma eficient i aporten valor.
Els usuaris clau no “desapareixen” durant la construcció del producte que després ells explotaran. Just al contrari. Els usuaris clau han de col·laborar en la validació dels lliuraments parcials que se li entreguen, proposar solucions als problemes que apareguin, ser conscients de l’evolució del projecte, i alertar sobre gestions del canvi que apareixen en el negoci, i que poden impactar sobre el resultat del projecte que s’està construint.
Hi ha moments en què l’usuari clau és necessari, sobretot en aquells moments en què és imprescindible la seva acceptació en la presentació de nous increments del producte. Òbviament no és el mateix participar i acceptar productes a petites dosis, que acceptar al final el producte complet. Aquesta és la principal diferència i la finalitat dels marcs de treball àgil front a mètodes tradicionals.
És possible que algunes organitzacions prefereixin un enfocament en cascada per tal de defugir d’un seguiment i avaluació continuats; pel temps, dedicació i assumpció de responsabilitat que representa. Això és un greu error. I acostumen a ser organitzacions on els projectes necessiten grans esforços en la documentació de l’abast, els requeriments i la solució tècnica. La documentació en aquest escenari es converteix en una eina de contractació interna. Més enfocada a cobrir responsabilitats, que a ser una eina útil per a l’equip del projecte.
El seguiment d’un flux implica una sèrie d’accions o moments en què algunes o totes les parts es veuen implicades i necessiten col·laborar. És imprescindible que això sigui així, sobretot en escenaris de construcció iterativa.
Els projectes s’han de subdividir en parts assequibles per a l’equip, i amb prou valor per a l’àrea destinatària, per a poder ser utilitzat mentre es construeix la resta del producte. En aquest escenari és necessari que tots els implicats en el projecte participin i col·laborin en:
Per a mi, aquesta secció és la justificació de tot aquest esforç de mesos de durada; i respon a un treball cuidat i perfeccionat al llarg dels anys. La intenció aquí és fer una proposta el més detallat possible de flux i eines per facilitar la gestió i l’execució dels projectes. Això podem fer-ho a partir dels tres aspectes següents:
Els fluxos que comentarem a les seccions següents donen suport a les accions de gestió, seguiment i enginyeria que són necessàries per a poder assolir els objectius del projecte. Totes aquestes accions han d’estar suportades i justificades per mitjà de documentació, que dóna fe del disseny, les decisions, els resultats, i en general tot allò que és necessari per al govern del projecte, la consecució d’un resultat útil per a l’organització, tot garantint la sostenibilitat i evolució posterior del producte del projecte.
Els documents que trobarem explicats aquí són els següents:
Documents de gestió de projecte
Kickoff - Acta de constitució / Kickoff del projecte: Contracte d’inici del projecte
Aquest document és el “contracte” en el que es determinen totes les característiques i compromisos del projecte (abast, objectius, pressupost, compromisos, planificació, etc)
Mètriques d’Assegurament de la Qualitat
Seguiment
Tancament de projecte
Documents d’execució de projecte
Planificació de projecte: Document de proposta de solució, planificació, riscos i qualitat
Disseny / Definició
Testing / Proves * ETP - Especificació Tècnica de Proves: En aquest document es detallen les necessitats tècniques organitzatives i de recursos per a fer possibles l’execució de totes les proves planificades, per avaluar la idoneïtat del resultat del projecte * PPR - Pla de proves documentat: En aquest document es detallen de forma concreta i exhaustiva totes les proves que es duran a terme. Quan i qui les realitzarà
Manuals * MEX - Manual d’Explotació: Aquest document es centra en la informació dels procediments de manteniment i seguretat del producte * MDE - Manual de Desplegament: Aquest document es centra en les accions de desplegament del producte * MIA - Manual d’Instal·lació i Administració: Aquest document es centra en els procediments d’instal·lació del producte * MOP - Manual d’Operatòria: Aquest document es una versió unificada dels manuals MEX, MDE i MIA * MUS - Manual d’Usuari: Aquest document es centra en la formació dels usuaris del producte
Pla de Desplegament * PdD - Pla de desplegament: El pla de desplegament detalla totes les accions necessàries per al desplegament del producte, i coordina a tots els equips que hi intervenen
La documentació de projecte té un únic objectiu: Ha de ser útil a l’equip del projecte. No hi ha cap objectiu més important que aquest. Si la documentació no és treballada per l’equip tenint constantment al cap aquest objectiu, no servirà per a res ni per a ningú. Per aconseguir una documentació útil per a tothom cal principalment que tothom hi participi en la construcció documental. Aquesta tasca no ha de ser responsabilitat únicament d’una persona concreta de l’equip. La forma de participar en la construcció dels diferents documents és escrivint i dibuixant.
Els usuaris descriuen escenaris funcionals o històries d’usuari. Els desenvolupadors participen descrivint l’arquitectura i dissenyant models de domini. L’equip al complet hi participa definint la planificació i identificant riscos.
Podem explicar el cicle de vida de gestió d’un projecte a partir del diagrama següent:
Es tracta d’un flux seqüencial a partir del qual s’articula tota la gestió i informació de la situació del projecte. Les fites “Pre-projecte” i “Post-projecte” no es consideren com a part del projecte, però formen part del flux de gestió perquè contenen elements que poden afectar tant al projecte com a l’equip.
Pre-Projecte
En aquest moment, en què el projecte encara no existeix com a tal, és possible que calgui fer algunes accions, que involucrin al cap del projecte, i a alguns membres de l’equip. Entre altres accions tenim:
Inici del projecte
La fase d’inici ja l’hem explicat a la secció anterior, on hem explorat les principals fites del projecte. Recordem que en aquest moment, el cap de projecte situa el focus en aconseguir un acord general sobre l’abast, els objectius, la planificació (inicial), els riscos i el model organitzatiu del projecte. El principal objectiu de l’inici del projecte és la fabricació conjunta d’un kickoff de projecte que doni resposta a totes aquestes incògnites.
Seguiment de l’execució
Aquesta activitat es configura com un element d’unió entre els fluxos de gestió del projecte, i el d’execució.
Tancament
La fase de finalització del projecte ja l’hem explorada en el flux de fites del projecte. Recordem que l’objectiu d’aquesta fita és assolir els objectius necessaris que permetin declarar el tancament del projecte.
Post-projecte, manteniment i evolució
En aquesta activitat es duen a terme les tasques d’avaluació de la qualitat, corresponents a l’avaluació de beneficis i satisfacció; descrita en la secció de tancament de projecte, en les fites de projecte.
Aquest flux es caracteritza per proporcionar les eines, fites i mètode de treball necessari per a coordinar tots els esforços de l’equip del projecte en la construcció del producte. El podem representar gràficament de la forma següent:
Les activitats d’aquest flux són:
Fase de planificació del cicle Aquesta fase té com a objectiu planificar totes les tasques necessàries per materialitzar el producte del projecte (un únic cicle: waterfall), o bé una part de valor (iteratiu). El document que governa aquesta fase, i que és la guia per la resta de fases és el document de planificació (PLN). Però també hi ha altres documents que són interessants i necessaris en aquest punt:
Fase d’execució
Aquesta fase és el motiu principal de qualsevol projecte, i correspon al desenvolupament (ja sigui construcció, adaptació, implantació o adquisició) d’allò planificat a la fase anterior del flux. En aquesta fase han de desenvolupar-se completament tots els documents d’enginyeria necessaris:
Aquesta fase no és un simple encàrrec a constructors o proveïdors, a l’espera d’obtenir uns resultats. És un treball diari de revisió interna de l’avenç, revisió dels objectius, definició detallada dels requeriments, sessions de resolució de dubtes i de treball amb usuaris clau, i resolució de problemes i mitigació de riscos a mesura que es produeixen.
Fase de testing
La fase d’execució hauria d’incloure sempre una activitat destinada a assegurar que el producte creat en aquell cicle o període està llest. La forma de determinar si el producte està llest, és amb la definició de “fet” (DoD o Definition of Done). Aquesta definició forma part de la planificació (PLN), o bé dels documents d’enginyeria (per exemple en el disseny funcional)
L’equip determina els ítems que permeten establir que el producte del projecte creat en el cicle en curs està llest. Hi ha DoDs que són d’àmbit general, com per exemple:
Altres DoDs poden fer esment a necessitats d’una funcionalitat o mòdul concret, d’una història d’usuari o d’una integració amb un tercer producte o sistema.
Els documents que articulen aquesta fase són:
Presentació de resultats i acceptació
Un cop enllestida la part compromesa en el cicle en curs, i obtingut el DoD d’aquest, ja estem llestos per a fer una presentació de resultats als usuaris destinataris. Essencialment a usuaris clau, però també als equips d’usuaris destinataris del producte
De forma prèvia, s’ha fet lliurament de l’increment del producte als equips de desplegament, amb tota la documentació necessària o bé els artefactes que permetin el desplegament del producte (pla de desplegament: PdD). Aquest equip ha de donar acceptació al lliurament abans de la presentació als usuaris en forma d’un DoD
En la presentació als usuaris es treballa directament amb el producte completament integrat amb la resta de producte construït en fases anteriors. Es mostra a l’usuari el funcionament de la part, i aquest dóna acceptació passant un paquet de proves d’acceptació. Prèviament és recomanable haver fet aquesta sessió amb els principals usuaris clau, de forma que aquests ja hagin donat la seva acceptació, i la sessió demostrativa sigui una il·lustració pràctica sense debats
Fase de desplegament, manuals, formació En aquest moment, amb la informació del pla de desplegament (PdD), els equips d’operacions despleguen en els entorns productius l’increment de producte acceptat a la fase anterior.
A més en aquest punt (o abans) s’enceten les accions de formació i manuals que s’hagin determinat per tal que els usuaris puguin explotar el producte amb la nova incorporació. Per últim s’habiliten els canals de manteniment i atenció a usuaris de la forma que s’ha establert (contractació, accions de formació dels equips d’atenció, etc.).
Fase de tancament de l’execució
Aquesta és l’última fase del flux d’execució; i és prèvia i independent de la fase de Final de projecte del flux de gestió. En aquesta fase l’equip de projecte treballa per tancar tota la documentació d’enginyeria generada (DFU, DTE, ETP, PPR, PdD), i manuals, per tal de donar acceptació pel que fa a l’aspecte tècnic del projecte.
En escenaris de treball iteratius i incrementals, és important dedicar un temps en aquesta fase per assegurar la integritat i la coherència de tota la documentació generada al llarg dels cicles.
Els documents del projecte han de servir per mostrar únicament la informació que és necessària a cada moment. Amb una orientació d’enginyeria (problema, solució) i no narrativa. El que ha de primar és la utilitat cap als destinataris del document, i no explicar una “història”. Una plantilla pautada és un document que presenta el contingut i la forma en què s’ha de complimentar, i es donen les pautes sobre com s’ha d’exposar aquesta informació.
A les pàgines següents mostrarem una fitxa tècnica per a cada un dels documents que es proposen en el flux de govern del projecte, vists en seccions anteriors. A cada fitxa, a banda del nom del document mostrarem la informació següent:
Els diferents documents que descriurem tot seguit, apareixen en diferents moments del flux de govern del projecte, identificant en el moment en què es crea o apareix per primera vegada; en quins moments s’actualitza amb informació nova o es revisa el contingut; i en quin moment el document es tanca. Les llegendes per indicar això al diagrama anterior són:
Pots consultar l’índex de continguts de cada document a la secció Plantilles i continguts dels principals documents de projecte
En aquesta secció s’exposa la família de documents que s’utilitzen per articular la gestió del projecte:
Els documents d’inici del projecte s’articulen a partir del kickoff, que correspon a l’acta que documenta els acords, organització, planificació i tots els aspectes clau que governaran el projecte que tot just comença. Com a complements al document de kickoff trobem:
El primer correspon a la documentació dels acords de gestió i execució del projecte per part dels diferents grups que hi participen. Qualsevol acord no estàndard entre la direcció del projecte i algun d’aquests grups es documenta aquí.
El segon correspon a la definició de la coordinació per al projecte. Organigrama, matriu de rols i responsabilitats, definició dels comitès de seguiment, i qualsevol altra informació necessària per a la coordinació.
Com a part del seguiment del projecte, una peça fonamental consisteix en messurar l’avenç d’aquest en diferents àmbits. Les MAQ ens ajuden a informar sobre la situació del projecte i a detectar possibles desviacions o buits en la gestió.
El seguiment és una part fonamental de la gestió. Independentment que l’orientació del seguiment sigui àgil o predictiva, hi ha elements documentals que convé tenir sempre presents, encapçalats pels documents següents:
L’acta (ACT) és un element sovint poc valorat, sobretot degut a la imprecisió en la documentació dels fets i les decisions. L’acta és probablement el document més important en la definició dels acords, i en la defensa d’aquests al llarg del projecte.
L’arxiu diari (ARD) és un element molt útil de cara a l’aprenentatge continu de tots els implicats en el projecte. A l’ARD l’equip descriu els principals esdeveniments ocorreguts durant el projecte. Siguin errors o encerts. L’ARD té especial rellevància en les retrospectives de l’equip, i a l’hora d’explicar el perquè d’alguns resultats o fets ocorreguts. Per últim, l’Informe de Seguiment (IFS) es converteix en la peça informativa per a tots aquells grups que no viuen el dia a dia del projecte, però als que necessitem tenir informats.
Sovint oblidem que el projecte no acaba quan acaben els desenvolupaments i les tasques de posada en marxa dels productes. El document de tancament de projecte (TAP) ens ajuda a explicar a totes les audiències les fites assolides, i el perquè de tenir el producte del projecte en la situació final
En aquesta secció s’exposa la família de documents que s’utilitzen per articular la realització del projecte, i els treballs ordinaris d’execució:
La peça central en la definició de la planificació del projecte i en el seguiment de l’execució d’aquest, és el document de Planificació (PLN). Aquí es trasllada l’abast definit a la documentació d’Inici del projecte, en forma de tasques operatives que es seqüencien i es planifiquen en calendari. La planificació pot tenir un enfocament predictiu, de forma que és calendaritzen des del minut 0 del projecte absolutament totes les tasques, o pot tenir un enfocament àgil, de forma que la planificació només cobrirà la realització d’allò establert per al cicle actual. Sigui com sigui, una planificació és sempre una peça imprescindible per al govern del projecte.
Paral·lelament a la planificació tenim dos elements dels quals és imprescindible portar un bon control:
Un calendari d’execució es construeix en creuar informació sobre l’abast definit per al projecte, les dates crítiques i disponibilitat de persones i recursos i els requeriments que la solució ha de cobrir. El catàleg de requeriments queda cobert gràcies al Catàleg de Requeriments (REQ) on, per a cada requeriment o conjunt de requeriments, hauríem de trobar una fita en calendari que el resol.
Un altre element que marca la diferència en un projecte tranquil, o un projecte ple d’obstacles, correspon a la gestió dels problemes i dels riscos. Per tal de gestionar adequadament els problemes i els riscos que van apareixent tenim a la nostra disposició l’eina RIN, que ens ajudarà en la gestió diària dels problemes.
Els documents de disseny ens serveixen per explicar en detall tant la definició del problema a resoldre, com el disseny de la solució concreta. En aquesta secció trobem:
L’Anàlisi de Viabilitat (AVI) és una bona eina quan l’objectiu del projecte es basa a localitzar la millor de les solucions possibles, en un ventall de possibilitats. El Disseny Funcional (DFU) i el Disseny Tècnic (DTE) són eines de definició completa i exhaustiva de la solució en un projecte de construcció, d’implantació o de millores.
En un projecte de caràcter predictiu s’intentarà documentar tota la solució abans de les primeres accions d’execució. Mentre que en un projecte àgil aquesta documentació es va component a mesura que el projecte avança. En aquest cas és més adient un format documental diferent. El Product Backlog (PB) documenta necessitats funcionals atòmiques que poden ser assolides en no més d’un cicle de construcció (sprint)
Els documents de proves són la base amb la qual l’equip del projecte determina els diferents nivells de prova del resultat, així com els llindars a partir dels quals el producte del projecte és o no és acceptable des de les perspectives tecnològiques, funcionals i d’ussabilitat
Els documents que governen aquest àmbit són els següents:
El primer (ETP) especifica tot allò des dels punts de vista organitzatiu, humans, de recursos i tecnològics necessaris per dur a terme els diferents paquets de proves. El segon (PPR) defineix els diferents àmbits de prova, i el detall perquè les persones que realitzin les proves tinguin autonomia per realitzar-les
La documentació de manuals són una peça imprescindible per a fer un bon trasllat del producte cap als diferents responsables d’usuaris, explotació i manteniment. En aquesta secció trobareu les propostes de manuals següents:
El Pla de Desplegament (PdD) és un document imprescindible perquè, un cop acabats els desenvolupaments, i un cop acceptades totes les proves, es donin les pautes per un desplegament ordenat a l’entorn de producció de l’organització.
En aquesta secció fem una proposta de plantilles pautades per a cada un dels documents de gestió (Acta, Informe de seguiment, Arxiu diari, etc.), i d’execució (Disseny Funcional, Product Backlog, Pla de desplegament, etc.)
Cada organització té les seves particularitats. També podem trobar moltes especificacions particulars segons el tipus de projecte. I per descomptat, per a un projecte en concret, sigui quin sigui, són d’aplicació particularitats especials que depenen dels membres de l’equip, dels proveïdors, de la criticitat del projecte, etc.
Però per sobre de tot això hi ha la necessitat ineludible de documentar científicament allò que construïm, implantem o estudiem. Allò que ens diferència d’una organització improvisativa, és la capacitat d’incloure mètode en el nostre dia a dia.
Un mecanisme efectiu d’implantar mètode prové de l’ús de plantilles de documents. Les plantilles són eines que pretenen ajudar a múltiples persones que treballen plegades a focalitzar-se en un objectiu (un document) coneixent tots els requeriments documentals, de format i de contingut.
En aquesta secció us presentem una proposta de pauta per a cada un dels documents necessaris en el projecte. Amb explicacions sobre l’objectiu de cada secció/subsecció, o d’allò que s’espera que contingui
Usualment un arxiu de text
1. [RECORD] Acta de reunió
Dades de la reunió
Data i hora: dd de mm de yyyy
Lloc
Projecte
Durada de la reunió
Ordre del dia
Llista de distribució
2. [ELEMENTS] Elements de discussió Descripció dels diferents fils de conversa que han tingut lloc durant la reunió
3. [DOC] Documentació lliurada Relació de documents i productes que les parts lliuren en la reunió
4. [PLAN] Pla d’accions Relació d’accions, compromisos i accions pactades en la reunió
5. [COMMENTS] Observacions, comentaris i temes pendents Tot allò que no s’hagi tractat en la reunió, o comentaris de valor
Usualment un arxiu de full de càlcul en les que el cap de projecte (o l’equip) apunten les qüestions dignes de recordar que puguin ocórrer durant el projecte. O bé un sistema de logwork integrat amb els sistemes de gestió de projectes de l’organització. O un quadre kanban adaptat a aquesta funció
L’arxiu diari és una eina destinada al Cap de Projectes, en què aquest apunta els fets rellevants, decisions, acords, fets excepcionals o problemes que apareixen durant la realització del projecte. Serveix per a fer memòria dels fets en un marc temporal, i prendre decisions d’acord amb les experiències passades
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Definició del projecte
Definició del problema / Situació actual
Abast del projecte
Descripció dels beneficis i oportunitats de la proposta
Expectatives i/o lliurables
Planificació orientativa
Equip proposat
2. [REQ] Anàlisi de requeriments En aquesta secció es descriuen els requeriments tal com els sol·licita l’usuari.
3. [SURVEY] Sondeig de mercat i posicionament L’objectiu d’aquest apartat és obtenir una primera visió de com se situarà el producte resultant del projecte en el mercat. Per això farem servir diferents eines.
4. [NEEDS] Determinació de les necessitats per a l’execució del projecte Reflexiona sobre els principals elements que són necessaris per a poder dur a terme el projecte. Determina si aquests elements poden o convenen ser coberts internament i quins no.
5. [PLN] Pla de projecte L’essencial en aquesta secció és reflexionar sobre les fites més importants, cada una d’aquestes poden representar un punt de decisió sobre la continuïtat del projecte, i ha d’incloure les diferents fases contemplades en la metodologia
6. [BUDGET] Anàlisi econòmica En aquesta secció es recolliran els conceptes següents:
7. [CHANGE] Elements de gestió del canvi L’objectiu d’aquesta secció és recollir tots aquells aspectes que s’han de tenir en compte per enfocar l’impacte dels possibles canvis que el projecte pot tenir sobre l’organització a la qual es dirigeix.
8. [RISKS] Identificació de riscos En aquesta secció es relacionen els riscos del projecte i les accions a emprendre per minimitzar-les.
9. [ACCEPT] Aprovació de l’anàlisi de viabilitat Un cop finalitzades totes les etapes de l’Anàlisi de Viabilitat, es porta a terme una avaluació global del projecte amb què es determina la seva continuïtat. En aquesta secció es reflecteix l’acord per a cada un dels responsables de l’execució i/o validació de l’anàlisi
Usualment un document de text amb els acords per a cada grup d’interès
1. [ARQ] Consens Arquitectura
2. [UX] Consens equip UX
3. [OP] Consens Operacions
4. [QA] Consens equip de gestió / Qualitat
5. [FACILITATORS] Consens equip facilitadors
6. [OTHERS] Consens amb altres àrees i implicats
7. [ACCEPT] Aprovació del document
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Descripció del projecte
Descripció del propòsit del projecte. Definició inicial del projecte. Relació dels aspectes més rellevants del projecte
2. [CHART] Organigrama del projecte
Diagrames dels equips de gestió, àrees usuàries implicades, grups de col·laboradors. Diagrama dels equips del(s) proveïdor(s) amb les interrelacions amb l’equip de gestió
3. [RESP] Matriu de rols i responsabilitats
És molt important, per una correcta execució del projecte, que els diferents col·laboradors coneguin i acceptin la seva responsabilitat en el projecte. La matriu en aquest document pot realitzar-se de forma general, sense identificar en detall totes les activitats del projecte, ja que aquest detall ha de conformar la matriu de rols i responsabilitats en la planificació (PLN)
4. [COORD] Coordinació, comitès de projecte i planificació de reunions
Detalla la forma en què es durà a terme la coordinació del projecte. Identifica quins comitès de seguiment s’activaran, quin en formarà part i quina serà la seva periodicitat. Indica la forma en què es realitzaran les reunions
5. [TEAM] Equip i operativa per la Gestió del Canvi
Defineix en detall la forma en què es recepcionaran, es gestionaran i s’avaluaran totes les peticions de Canvi del projecte
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Descripció del projecte
Opcional. Informació introductòria que ajudi al lector a situar-se en el projecte. Recomanable màxim una pàgina.
2. [SCOPE] Descripció del resultat del projecte
Descripció resumida sobre el Sistema d’Informació objecte d’anàlisi. Descriure la funció del producte del projecte i l’objectiu principal. Situar el producte del projecte en el context general de l’organització o del macrosistema. Recomanable màxim una pàgina.
3. [RULES] Llista d’estàndards, normes i participants
Indiqueu aquí tot allò que sigui rellevant respecte a normes i organització, d’obligat compliment en el projecte. Llenguatges i tecnologies que s’han d’emprar en la solució
4. [REQ] Catàleg de requeriments
Opcional. Els requeriments poden relacionar-se en aquest document, o bé enllaçar-se amb el document de requeriments del projecte: REQ - Catàleg de requeriments del projecte
5. [MODEL] Model de negoci
El model de negoci explica, mitjançant casos d’ús centrats en l’usuari, les principals activitats (desenvolupades per l’usuari o per al mateix Sistema d’Informació), que defineixen l’objectiu primari del Sistema d’Informació (el negoci).
*6. [USER_STORIES] Històries d’usuari**
En aquesta secció definirem, a mesura que hi apareguin, les històries d’usuari que componen el producte del projecte. Al principi correspondrà a una llista no definida de necessitats. I a cada iteració aquesta llista s’anirà definint i detallant de forma suficient per a poder construir-les
Les històries d’usuari no poden excedir ni els objectius ni l’abast identificats en seccions anteriors. El product backlog pot estar en aquest document, o bé en un arxiu a banda
7. [UX] Definició de la interfície gràfica
Definició exhaustiva dels diferents elements gràfics i d’interacció amb l’usuari (pantalles, diàlegs, informes, etc.). El disseny d’interfícies gràfiques aquí defineix la funcionalitat i les regles d’interacció amb l’usuari. No defineixen el disseny gràfic final, que es veurà en el disseny orgànic del Sistema d’Informació.
8. [ACCEPT] Aprovació del disseny funcional
El Sistema d’Informació ha de ser aprovat per un representant de cada grup de participants relacionat a la secció “Llista d’estàndards, normes i participants”
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Descripció del projecte
Opcional. Informació introductòria que ajudi al lector a situar-se en aquesta fase del projecte.
Cal fer referència al Disseny Funcional (DFU). Recomanable màxim una pàgina.
2. [INFRA] Definició de la infraestructura
Aquesta secció descriu des d’una òptica tecnològica, l’entorn necessari tant per la construcció, com per l’explotació del Sistema d’Informació objecte de disseny.
3. [ENTITIES] Disseny de les entitats
Aquesta secció pren com a punt de partida la definició de classes del model de negoci de l’anàlisi funcional, incloent-hi sobre aquest tot el relatiu a l’arquitectura de suport establerta per al desenvolupament.
4. [BBDD] Disseny físic de dades
Aquesta secció descriu tot el relatiu a la persistència del Sistema d’Informació.
5. [LOAD] Disseny de la migració i la càrrega inicial de dades
De forma general, aquesta secció inclou:
En funció de la importància i de la criticitat de la migració i de la càrrega.
6. [PLN] Planificació de l’execució
Aquest apartat pren com a base la definició d’històries d’usuari establertes per l’equip del projecte, per a reflectir una planificació per al cicle actual. Aquesta planificació serveix com a registre d’allò inicialment planificat, i no pretén substituir les eines de coordinació de l’execució que l’equip estableixi.
7. [LEARNING] Pla de documentació d’usuari i formació
Aquesta secció fa referència a la documentació necessària per a la implantació i explotació del Sistema d’Informació. Els manuals s’elaboren en fases posteriors, tot i que en aquesta secció es proposen els documents necessaris, el format d’aquests, la seva estructura, etc.
8. [ACCEPT] Aprovació del Disseny Tècnic del Sistema d’Informació
El Sistema d’Informació ha de ser aprovat per un representant de cada grup de participants relacionat a la secció “Llista d’estàndards, normes i participants” del Disseny Funcional (DFU)
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Introducció
Opcional. Informació introductòria que ajudi al lector a situar-se en aquesta fase del projecte.
Cal fer referència al Disseny Funcional (DFU). Recomanable màxim una pàgina.
2. [TEST] Especificació tècnica de les proves
En aquesta secció es defineix:
Usualment un arxiu de presentació
1. [TRACE] Seguiment del projecte
2. [TASKS] Situació general de les tasques previstes
Un registre per a cada objectiu/èpica/fase del projecte
3. [QUALITY] Situació pel que fa a l’acompliment de la Qualitat
Un registre per a cada objectiu/èpica/fase del projecte
4. [ENDED] Descripció de les tasques finalitzades a data informe
Resum de les accions principals realitzades a data informe
5. [RISKS] Situació dels riscos
Descripció de l’estat general de cada risc
6. [PLAN] Pla d’accions
Descriu aquí les principals decisions per a constància de tots els assistents, i les principals tasques o encàrrecs que s’han decidit.
7. [COMMENTS] Comentaris i observacions
Comentaris sobre aspectes d’interès per l’evolució del projecte, o sobre tasques realitzades
Usualment un arxiu de presentació acompanyat d’una guia d’ús
[CONTEXT] Propòsit del projecte
[OBJ] Objectius del projecte
[SCOPE] Abast del projecte
[SUCCESS] Claus per l’èxit del projecte
[PLN] Planificació inicial i fites * Cronograma * Fites
[ORG] Organització, equips, responsabilitats
[RISKS] Riscos del projecte
[TANGIBLE] Lliurables del projecte
Usualment un full de càlcul amb registres d’avaluació on l’equip de projecte qualifica el resultat de cada ítem
Un full de càlcul amb les columnes següents:
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Presentació del sistema d’informació
Resum general del funcionament del Sistema d’Informació.
2. [REQ] Requeriments de maquinari i programari per al desplegament
3. [MANUAL] Manual de desplegament
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Presentació del sistema d’informació
Resum general del funcionament del Sistema d’Informació.
2. [REQ] Requeriments de maquinari i programari
3. [MAINTENANCE] Manteniment del sistema d’informació
4. [DATA] Descripció del model de dades
5. [SYSTEM] Procediments de manteniment i seguretat
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Presentació del sistema d’informació Resum general del funcionament del Sistema d’Inform ació.
2. [REQ] Requeriments de maquinari i programari
3. [MANUAL] Manual d’instal·lació
4. [CONFIG] Configuració del Sistema d’informació
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Presentació del sistema d’informació
Resum general del funcionament del Sistema d’Informació.
2. [REQ] Requeriments de maquinari i programari per la instal·lació i el desplegament
3. [SETTING] Manual d’instal·lació
4. [ADM] Manual d’administració
5. [DATA] Descripció del model de dades
6. [SYSTEM] Procediments de manteniment i seguretat
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Introducció
Resum general del funcionament del Sistema d’Informació.
2. [DESC] Descripció general del sistema
Descripció de l’entorn de treball, dels perfils d’usuari, del funcionament del sistema. Descripció dels sistemes relacionats. I si hi ha ajudes de context, en línia o altra descriure-la
3. [MANUAL] Manual d’usuari
Tutorial centrat en funcionalitats i preferentment en imatges i en cada secció operativa del sistema d’informació. Mencionar els perfils d’usuari que hi tenen accés a cada funcionalitat
Usualment un full de càlcul
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Introducció
Resum general del funcionament del Sistema d’Informació.
2. [DELIVER] Relació dels lliurables del producte
Llista exhaustiva de documents, productes i altres distribuïbles de què consta el producte del projecte
3. [LOAD] Resultats de la migració i càrrega inicial de dades
Resultat de la càrrega inicial de dades i posada en marxa del producte. Tal com es defineix al Disseny Tècnic (DTE). Aquesta secció es configura com una acceptació de la càrrega inicial i posada en marxa per part dels equips d’operació
4. [PPR] Validació de la realització de les proves
Informe d’execució de les proves definides als documents d’Especificació Tècnica de les Proves (ETP), i Pla de Proves (PPR)
5. [LEARNING] Pla de formació i documentació per a l’equip d’operacions i manteniment
Definició dels documents de tutorials definits amb l’equip d’operacions. Així com les accions de formació que siguin necessàries
6. [ACCEPT] Aprovació
Acompliment de la seguretat (acompliment de la normativa de seguretat de l’organització)
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Definició / Proposta de solució
Descripció del propòsit del projecte. Definició inicial del projecte. Relació dels aspectes més rellevants del projecte
2. [REQ] Requeriments del projecte
Relació inicial de requeriments, agrupada i prioritzada. Aquesta relació s’inclourà i es completarà al document (REQ) Catàleg de Requeriments
3. [PLN] Planificació del projecte
L’essencial en aquesta secció és reflexionar sobre les fites més importants, cada una d’aquestes poden representar un punt de decisió sobre la continuïtat del projecte, i ha d’incloure les diferents fases contemplades en la metodologia
4. [QUALITY] Pla de Qualitat
Objectius, abast i enfocament de la qualitat dins del projecte
5. [REPORT] Pla de comunicació
Identificar que cal comunicar, a qui i quan. Nivells de comunicació, continguts, periodicitat de les diferents comunicacions, i eines. Definició dels comitès de seguiment o informació
6. [RISKS] Pla de riscos del projecte
Identificar de forma detallada els riscos que afecten o poden afectar el projecte. Determineu, per a cada risc, l’impacte que aquest té sobre el projecte en el moment actual i la probabilitat que el risc tingui lloc
7. [BUDGET] Pressupost del projecte
Pressupost del projecte. Marges pressupostaris. Polítiques de contractació. Períodes de garantia i mecanismes de cancel·lació
Usualment un arxiu de text, o eina de gestió i execució de test
1. [INTRO] Introducció
Opcional. Informació introductòria que ajudi al lector a situar-se en aquesta fase del projecte. Cal fer referència al Disseny Funcional (DFU). Recomanable màxim una pàgina.
2. [TEST_PLAN] Especificació del pla de proves
En aquesta secció es defineix:
Usualment un full de càlcul
Usualment un full de càlcul
Índex de famílies de riscos
Regles de càlcul
Dades descriptives d’un risc. Document RIN
Usualment un document de text acompanyat d’una guia d’ús
1. [INTRO] Consideracions relatives al tancament del projecte
Indicar que la fi del projecte, implica que tots els recursos que estaven assignats, s’alliberen per poder ser assignats a altres projectes.
2. [STATUS] Descripció de l’estat del projecte al tancament
Descripció de l’estat del projecte, indicant clarament en quina situació es troba, (acabat, abandonat, cancel·lat…)
3. [PENDING] Accions pendents per al tancament del projecte
S’indicarà en aquesta secció qualsevol element documental que és necessari modificar per al tancament del projecte, sobre els aspectes següents:
4. [SATISFACTION] Valoració del projecte i satisfacció
En aquesta secció cal relacionar aquells elements que serveixen per a obtenir una mesura sobre l’èxit general del projecte, i el grau d’acompliment dels objectius plantejats a l’inici d’aquest. Així com la relació de les principals incidències que han suposat un canvi en l’abast, i el mesurament del grau de satisfacció dels usuaris i altres actors del projecte.
5. [WARRANTY] Consideracions per la garantia del projecte
Consideracions a fer constar de cara a la garantia del projecte. Desenvolupat per saber com gestionar aquesta garantia i el compromís per ambdues parts.
6. [EVO] Identificació de noves necessitats i evolucions
Relació de possibles vies d’evolució del producte objecte del projecte. O bé noves necessitats detectades durant el transcurs del mateix
