calaix[À]gil.com

www.calaigagil.com

CAT | ESP | EN



Gestió del canvi en projectes tecnològics. Estandarditzar les eines i els fluxos de govern del projecte

ES / CAT

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

descarrega la versió pdf d’aquest article


1. Estandarditzar les eines i els fluxos de govern del projecte

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.

Els fluxos de govern són un marc de treball per a l’equip

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

  • Els fluxos han de ser realistes i assumibles
  • Han de ser prou flexibles per acomodar les visions, estils de gestió i marcs de treball que siguin d’ús habitual a l’organització, així com les necessitats particulars del projecte

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.

La normativa de gestió i execució no són la finalitat del projecte. Són l’eina de coordinació del projecte

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ó

  • Han de ser coneguts en detall pels caps de projecte, usuaris clau i proveïdors en el projecte
  • Són d’obligat ús per a totes les parts

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.

Flux de gestió del projecte

El flux de gestió del projecte és l’eina que serveix a l’equip del projecte per determinar:

  • Els requeriments necessaris per poder iniciar el projecte
  • Els requeriments necessaris per poder determinar la finalització del projecte
  • Les eines, documentació i accions necessàries per al seguiment del projecte
  • La informació de la situació del projecte, accessible pel mateix equip, pels estaments de seguiment, i per qualsevol interessat extern al projecte

Els riscos

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.

Els repositoris

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.

Els 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.

Flux per l’execució 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.

Els constructors i els proveïdors han de conèixer el flux i utilitzar-lo de forma proactiva

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:

  • La documentació. En forma de disseny, consultoria, anàlisi o el que sigui desitjable segons el tipus de projecte
  • El seguiment periòdic o d’acord amb fites. Per mostrar resultats, demanar acceptació, continuar amb les següents fases, mostrar els problemes i proposar solucions

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.

L’execució involucra de forma activa als usuaris clau

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.

Els moments

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:

  • Definir i prioritzar les peces funcionals, històries d’usuari, mòduls funcionals, o com sigui que organitzem una subdivisió útil que aporti valor a l’organització.
  • Validar l’abast de cada part
  • Fer seguiment de l’execució de cada part. Crear i validar el disseny que permet la seva construcció i, posteriorment, validar el resultat en una prova real
  • Presentar la peça construïda a l’àrea destinatària, i facilitar-ne l’ús per part dels usuaris, en l’entorn d’explotació de l’organització

2. Les accions per fomentar el canvi en l’organització

Estandarditzar les eines i els fluxos de govern del projecte

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 documents
  • Cicle de vida de gestió d’un projecte
  • Cicle de vida de l’execució d’un projecte

Els documents

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)

  • CIP - Consens Intern de Projecte: En aquest document s’especifiquen tots els acords particulars per aquest projecte amb els principals grups d’interesats
  • COP - Coordinació de Projecte: En aquest document es detalla l’organització humana per al projecte, així com els òrgans de seguiment i informació

Mètriques d’Assegurament de la Qualitat

  • MAQ - Mètriques i assegurament de la qualitat: Aquest document és una eina per a l’equip que permet assegurar la qualitat del procés de gestió, execució i els resultats del projecte

Seguiment

  • ACT - Document d’Acta: En aquest document es plasmen les decisions i acords en una reunió
  • ARD - Arxiu diari: Llista de lliçons apreses i esdeveniments ocorreguts durant el projecte, que siguin dignes de recordar
  • IFS - Informe de Seguiment: En aquest document es documenta la situació del projecte respecte a les fites assolides, els problemes i les afectacions sobre la planificació en una data determinada

Tancament de projecte

  • TAP - Tancament de Projecte: En aquest document es consensua amb tots els interessats la finalització del projecte, el seu estat final, les possibles vies evolutives, i una anàlisi sobre la satisfacció en funció del curs del projecte i dels resultats obtinguts

Documents d’execució de projecte

Planificació de projecte: Document de proposta de solució, planificació, riscos i qualitat

  • PLN - Planificació del projecte: Aquest document mostra de forma constantment actualitzada la situació de la planificació
  • RIN - Registre d’Incidències i de Riscos: Aquest document és un catàleg dels riscos i problemes que apareixen o poden aparèixer durant el projecte. S’especifiquen responsables per la mitigació, situació i dates
  • REQ - Catàleg de Requeriments: Totes les funcions, productes i subproductes que es pretenen assolir com a resultat del projecte s’especifiquen en aquest document. Correspon a la materialització de l’abast prèviament definit

Disseny / Definició

  • AVI - Anàlisi de viabilitat: Aquest document correspon a un estudi sobre alternatives i la seva viabilitat en l’organització, per proporcionar una solució o producte necessari
  • DFU - Disseny Funcional: Aquest document correspon a la definició d’allò que es vol obtenir com a resultat del projecte, amb focus en “el que”
  • DTE - Disseny Tècnic: Aquest document correspon a la definició d’allò que es vol obtenir com a resultat del projecte, amb focus en “el com”

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 utilitat dels documents per a l’equip

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.

Cicle de vida de gestió d’un projecte

Podem explicar el cicle de vida de gestió d’un projecte a partir del diagrama següent:

Organización-máquina

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:

  • Seleccionar i crear l’equip del projecte
  • Encetar un Sprint 0 (o first sprint) per tal de resoldre algunes incògnites sobre l’abast o la tecnologia
  • Negociar amb els usuaris clau l’abast
  • Seleccionar i contractar els proveïdors

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ó.

Organización-máquina

  • Accions de seguiment: Les accions de seguiment són totes aquelles sessions informatives pactades en el projecte, o sota demanda, en que els interessats del projecte han de rebre informació de primera mà sobre la situació del projecte. L’eina que articula les accions de seguiment és L’Informe de Seguiment (IFS)
  • Accions del cicle de vida de l’execució del projecte: En aquesta activitat entra en joc el flux d’execució de projectes, que el veurem també en aquesta secció

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.

Cicle de vida de l’execució d’un 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:

Organización-máquina

Les activitats d’aquest flux són:

  • Fase de planificació del cicle
  • Fase d’execució i Fase de testing
  • Presentació de resultats i acceptació
  • Fase de desplegament, manuals, formació
  • Fase de tancament de l’execució

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:

Organización-máquina

  • El registre de riscos i incidències (RIN)
  • Els documents d’enginyeria que siguin necessaris en el projecte, que s’hauran de començar a construir amb la informació disponible en aquest punt, i que en la fase d’execució s’han d’enllestir completament.
  • Els acords de Consens Intern de Projecte (CIP), que com hem vist son part de la documentació d’Inici del projecte. Hi cap la possibilitat que al començament de cada cicle, canviï algun acord descrit al CIP. En aquest cas cal revisar el document per assegurar que els acords segueixen vigents

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:

Organización-máquina

  • Definició completa dels Requeriments (REQ) que es pretenen assolir en aquest cicle
  • Disseny Funcional (DFU) i Disseny Tècnic (DTE) per al cas d’un projecte de desenvolupament
  • Anàlisi de Viabilitat (AVI) per al cas d’una consultoria, exploració de mercat o adquisició
  • Qualsevol altre document que l’equip de projecte determina necessari per a una execució documentada i justificada. En aquest punt té especial importància el Registre d’incidències i riscos (RIN); ja que és en aquesta fase quan els problemes es materialitzen. I cal que l’equip estigui atent a la seva aparició per reaccionar de la forma més ràpida i eficient possible

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)

Organización-máquina

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:

  • El producte acompleix amb les regles d’usabilitat i accessibilitat definides per l’equip d’UX
  • El producte ha estat testat unitàriament i funcionalment per part dels constructors
  • El producte s’integra amb la resta de producte creat en cicles anteriors de forma incremental i regressiva

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:

  • Especificació Tècnica de les proves (ETP): On s’especifiquen les necessitats organitzatives i de recursos per a dur a terme les proves, així com la tipologia de proves i l’abast d’aquestes. En l’ETP també cal incloure el calendari detallat d’execució, avaluació i validació de cada una de les seccions de proves definides
  • Pla de proves (PPR): On s’especifica el detall de les proves per a cada nivell de proves, amb tota la informació necessària per a poder dur-les a terme

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

Organización-máquina

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.

Organización-máquina

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.

Organización-máquina

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.

3. Documents i plantilles del projecte

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:

  • Descripció: Perquè aplica el document, o a què pretén donar resposta
  • Àmbit: Flux (gestió o execució) sobre el que preferentment té sentit el document
  • Objectius: Quina és la motivació del document. Perquè està pensat i quina és la seva justificació en la gestió del projecte
  • Reponsabilitat principal: Qui és el principal responsable del document. La persona o persones responsables seran les que han de vetllar per la disponibilitat de la plantilla, fer-la arribar a les persones que treballaran sobre el document, vetllar per la integritat del contingut, distribuir-la allà on el document sigui necessari, i repositar-la per la seva salvaguarda.
  • Temporalitat: En quins moments del flux de govern es crea el document, s’actualitza amb nova informació, o es tanca.

Organización-máquina

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:

  • C - Crea: El document es crea
  • A - Actualitza: El document s’actualitza
  • T - Tanca: El document es tanca

Pots consultar l’índex de continguts de cada document a la secció Plantilles i continguts dels principals documents de projecte

Documents per la gestió del projecte

En aquesta secció s’exposa la família de documents que s’utilitzen per articular la gestió del projecte:

Documents d’inici 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:

  • CIP: Consens Intern de Projecte
  • COP: Coordinació del projecte

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ó.

Kickoff - Acta de constitució / Kickoff del projecte

  • Descripció: Contracte d’inici del projecte
  • Objectius: Document que explica els aspectes crítics del projecte, i que es conforma com a contracte entre totes les parts
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap de projecte, proveïdor i usuaris clau

CIP - Consens Intern de Projecte

  • Descripció: Document que aglutina totes les decisions de col·laboració amb els grups que participen en el projecte, per acomplir les seves premisses de qualitat
  • Objectius: Aquest document explica els acords de col·laboració amb els diferents departaments, àrees i grups implicats en el projecte, per tal que el projecte compta amb la col·laboració necessària per poder dur-les a terme, i assegurar-se que s’acompleixen totes les premisses de qualitat dels diversos grups
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap de projecte i els implicats interns

COP - Coordinació de Projecte

  • Descripció: Document en què es detallen totes les decisions sobre l’organització humana i de recursos del projecte
  • Objectius: Aquest document és opcional. Pot formar part del document de planificació (PLN), i té com a objectiu assegurar que l’equip de projecte i tots els interessats comprenen els mecanismes d’organització, informació i responsabilitats de cada grup del projecte
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap de projecte i els implicats interns

Mètriques d’assegurament de la qualitat

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ó.

MAQ - Mètriques i assegurament de la qualitat

  • Descripció: Document de mesurament de l’assoliment
  • Objectius: Donar una eina al Cap de Projectes per avaluar el grau d’assoliment dels itineraris d’assegurament de la qualitat previstos en la metodologia
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap de projecte

Documents de Seguiment

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:

  • ACT: Acta
  • ARD: Arxiu diari
  • IFS: Informe de seguiment

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.

ACT - Acta

  • Descripció: Document de temes tractats en una reunió, amb relació d’assistents, acords i compromisos
  • Objectius: Aquest document dóna fe dels temes tractats en una reunió, els acords, tasques que es desprenen dels acords i els responsables de dur a terme o fer seguiment d’aquestes tasques
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Qui lidera la reunió

ARD - Arxiu diari

  • Descripció: Llista de lliçons apreses i esdeveniments ocorreguts durant l’execució del projecte
  • Objectius: Mantenir una memòria dels esdeveniments importants ocorreguts. Perquè es va prendre una decisió? Perquè certa acció es va fer bé o malament?, etc.
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap del projecte

IFS - Informe de Seguiment

  • Descripció: Document de situació del projecte per a les reunions de seguiment pactades
  • Objectius: Explicar la situació del projecte a una data concreta
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap de projecte i proveïdor (segons l’àmbit de la reunió)

Documents de Tancament del project

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

TAP - Tancament de Projecte

  • Descripció: Document de tancament del projecte
  • Objectius: Document amb la informació i proves documentals necessàries per poder tancar el projecte
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Equip del projecte, ja que tothom té informació de valor per aportar al tancament

Documents d’execució del projecte

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ó:

Documents de proposta inicial de solució, planificació, riscos i qualitat

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:

  • REQ: Catàleg de requeriments
  • RIN: Registre d’incidències i de riscos

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.

PLN - Planificació de projecte

  • Descripció: Document de proposta de solució, planificació, riscos i qualitat
  • Objectius: Proporcionar tota la informació de valor que permeti realitzar el projecte, en els eixos de: Abast, Temps, Cost, política de qualitat, Definition of Done, Identificació dels riscos
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: Cap del projecte

REQ - Catàleg de Requeriments

  • Descripció: Llista de requeriments del projecte
  • Objectius: L’objectiu és tenir una llista detallada dels requeriments del projecte. La llista es va detallant mentre el projecte avança
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Cap de projecte i proveïdor

RIN - Registre d’Incidències i de Riscos

  • Descripció: Llista de riscos i d’incidències del projecte
  • Objectius: L’objectiu és tenir una llista detallada dels riscos i les incidències, saber en quina situació es troben, com es poden mitigar i qui és responsable de la mitigació
  • Àmbit: Cicle de gestió
  • Responsabilitat principal: L’equip del projecte. La gestió dels riscos és missió de tot l’equip, tot i que la responsabilitat recau sobre el cap de projectes

Documents de Disseny i Definició

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:

  • AVI: Anàlisi de viabilitat
  • DFU: Disseny Funcional
  • DTE: Disseny Tècnic
  • PB: Product Backlog

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)

AVI - Anàlisi de viabilitat

  • Descripció: Document de definició de les necessitats i requeriments del producte, anàlisi de mercat i econòmic, i proposta de pla d’implantació/construcció
  • Objectius: Per una banda, realitzar una definició exhaustiva de les necessitats, d’acord amb la definició dels objectius i l’abast, i la definició en detall dels requeriments. I per altra banda, d’acord amb aquesta informació, anàlisi de mercat o proposta de construcció
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Cap de projecte i els implicats interns

DFU - Disseny Funcional

  • Descripció: Document de definició funcional del producte del projecte
  • Objectius: Obtenir el detall de forma incremental del que es planteja aconseguir en el producte del projecte.
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Equip del projecte / constructors

DTE - Disseny Tècnic

  • Descripció: Document de definició tècnica del producte del projecte
  • Objectius: Obtenir el detall de forma incremental de totes les qüestions tècniques que expliquen com aconseguir el producte del projecte.
  • Ambit: Cicle d’execució
  • Responsabilitat principal: Equip del projecte / constructors i arquitectes

PB - Product Backlog

  • Descripció: Llista de definició d’aspectes funcionals a assolir com a producte del projecte
  • Objectius: El Product Backlog és l’element documental que articula el desenvolupament basat en cicles iteratius i incrementals.
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Cap de projecte, usuaris clau i equip de projecte

Document de proves i acceptacions

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:

  • ETP: Especificació Tècnica de les Proves
  • PPR: Pla de Proves Documentat

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

ETP - Especificació Tècnica de Proves

  • Descripció: Document de definició tècnica per a poder dur a terme les proves
  • Objectius: Obtenir el detall tècnic i les necessitats per tal que es puguin dur a terme les proves a tots els nivells
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Equip del projecte / constructors i arquitectes

PPR - Pla de proves documenta

  • Descripció: Document de definició i execució de les proves
  • Objectius: Obtenir el detall sobre les proves que es realitzaran, així com tenir registre de la realització i el seu resultat, per poder fer una validació
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Equip del projecte / constructors i usuaris clau

Documents sobre manuals

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:

  • MDE: Manual de Desplegament
  • MEX: Manual d’Explotació
  • MIA: Manual d’Instal·lació i Administració
  • MOP: Manual d’Operatòria
  • MUS: Manual d’Usuari

MDE (Manual de Desplegament). MEX (Manual d’Explotació). MIA (Manual d’Instal·lació i Administració). MOP (Manual d’Operatòria)

  • Descripció: Document de manual lliurable
  • Objectius: Document de manual
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Cap de projecte, proveïdor i equips d’operacions

MUS - Manual d’Usuari

  • Descripció: Document de manual lliurable
  • Objectius: Document de manual
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Cap de projecte, proveïdor i usuaris clau

Documents de Desplegament

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ó.

PdD - Pla de desplegament

  • Descripció: Document de definició de les accions realitzades durant el cicle, el resultat de les proves i les accions de formació i posada en marxa necessàries
  • Objectius: Permetre mostrar els resultats d’allò construït en l’actual cicle del projecte, per tal d’obtenir una validació explícita del cicle. Això inclou evidències de la correctesa de les proves, informació per al desplegament i planificació de la formació i posada en marxa
  • Àmbit: Cicle d’execució
  • Responsabilitat principal: Proveïdor / constructors i equips d’operacions

4. Plantilles i continguts dels principals documents de projecte

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

ACT - Acta

Format

Usualment un arxiu de text

Contingut / Plantilla pautada

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

ARD - Arxiu diari

Format

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ó

Contingut / Plantilla pautada

  • Data de registre
  • Tema
  • Observacions o informació complementària

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

AVI - Anàlisi de viabilitat

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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.

  • Estudi quantitatiu
  • Enquesta qualitativa
  • Anàlisi de la competència
  • Diagrama de posicionament

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:

  • Costos desenvolupament del projecte. Per dur a terme aquesta anàlisi ens basarem en la planificació establerta en la secció anterior.
  • Costos de manteniment, suport i altres costos periòdics. Tots aquells costos de manteniment del Sistema d’Informació, la seva infraestructura i el servei a usuari.
  • Anàlisi de cost/benefici. Anàlisi del temps d’amortització del producte en comparació amb els beneficis esperats.

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

CIP - Consens Intern de Projecte

Format

Usualment un document de text amb els acords per a cada grup d’interès

Contingut / Plantilla pautada

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

  • Necessitats pròpies del grup respecte al projecte (però no “mètode o normes”, ja que les normes són del projecte i no del grup). Per exemple: catàleg d’arquitectura
  • Eines que el grup proposa per a operar amb les seves necessitats (per exemple: paquet d’eines del grup de qualitat)
  • Acords amb cada grup sobretot per col·laborar: reunions, informes…. Però també acords concrets segons el projecte (per ex: participació de persones)

COP - Coordinació de Projecte

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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

DFU - Disseny Funcional

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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”

DTE - Disseny Tècnic

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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:

  • Especificació de l’entorn de migració.
  • Definició de procediments de migració.
  • Disseny detallat de mòduls.
  • Especificació tècnica de les proves específiques per la migració i càrrega inicial
  • Planificació de la migració i càrrega inicial.

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)

ETP - Especificació Tècnica de Proves

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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:

  • Entorn tecnològic necessari per a l’execució de les proves
  • Planificació i calendarització de les proves
  • Relació d’excepcions que el sistema d’informació ha de controlar

IFS - Informe de Seguiment

Format

Usualment un arxiu de presentació

Contingut / Plantilla pautada

1. [TRACE] Seguiment del projecte

  • Data
  • Objectius
  • Seguiment del projecte
  • Descripció de l’estat del projecte en cada una de les seves tasques generals o objectius
  • Situació pel que fa a l’acompliment de la Qualitat
  • Descripció de les tasques finalitzades a data informe
  • Situació dels riscos
  • Pla d’acció
  • Comentaris i observacions
  • Llista de distribució

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

  • Motiu(s) de la/les desviació(ns) si hi ha (de forma global)
  • Accions correctores en cas de desviació (de forma global)

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

Kickoff - Acta de constitució / Kickoff del projecte

Format

Usualment un arxiu de presentació acompanyat d’una guia d’ús

Contingut / Plantilla pautada

[CONTEXT] Propòsit del projecte

[OBJ] Objectius del projecte

  • Objectius de negoci i dates clau
  • Beneficis quantitatius i qualitatius, definition of done

[SCOPE] Abast del projecte

  • Àmbit
  • solució plantejada. Diagrama

[SUCCESS] Claus per l’èxit del projecte

  • Claus per l’èxit
  • Estratègia tecnològica

[PLN] Planificació inicial i fites * Cronograma * Fites

[ORG] Organització, equips, responsabilitats

  • Equip de projecte
  • Matriu de responsabilitats
  • Òrgans de seguiment

[RISKS] Riscos del projecte

  • Riscos de negoci
  • Riscos tecnològics.

[TANGIBLE] Lliurables del projecte

  • Documents
  • Artefactes

MAQ - Mètriques i assegurament de la qualitat

Format

Usualment un full de càlcul amb registres d’avaluació on l’equip de projecte qualifica el resultat de cada ítem

Contingut / Plantilla pautada

Un full de càlcul amb les columnes següents:

  • Mètrica: Identificador de la mètrica aplicable en aquest registre, i que identifica un capítol d’ítems mesurables per donar resposta a un àmbit (qualitat documental, passes de l’inici del projecte, Gestió del Canvi, Acompliment del flux Agile, etc.)
  • Secció: Dintre d’una mètrica concreta identificada a la columna anterior, aquesta pot estar distribuïda en diferents seccions, per tal d’obtenir mesures a subàmbits concrets. Per exemple: En una mètrica per mesurar l’acompliment en l’inici del projecte, hi poden haver seccions per mesurar la preparatòria del kickoff, la realització del kickoff i la preparació dels entorns de gestió necessaris per a l’inici ordenat del projecte
  • Ítem: Correspon a un enunciat mesurable. Per exemple: “S’ha aixecat acta sobre la presentació del kickoff?”
  • Valor: Un valor de resposta a la pregunta mostrada en la columna Ítem. Acostuma a ser un valor de “Sí” o “No”. Tot i que poden haver-hi altres modalitats de resposta

MDE - Manual de Desplegament

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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

  • Equips d’explotació
  • Equips de servei
  • Equips d’emmagatzemament i dades

3. [MANUAL] Manual de desplegament

MEX - Manual d’Explotació

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

1. [INTRO] Presentació del sistema d’informació

Resum general del funcionament del Sistema d’Informació.

2. [REQ] Requeriments de maquinari i programari

  • Equips d’usuari
  • Equips de servei
  • Equips d’emmagatzemament i dades

3. [MAINTENANCE] Manteniment del sistema d’informació

  • Gestió d’usuaris
  • Gestions mestres
  • Gestió i configuració dels sistemes de preproducció

4. [DATA] Descripció del model de dades

  • Diagrama ER
  • Model normalitzat
  • Descripció de les entitats

5. [SYSTEM] Procediments de manteniment i seguretat

  • Procediments de manteniment del Sistema d’Informació
  • Procediments de còpia de seguretat
  • Verificació de les còpies de seguretat
  • Procediments de restauració i recuperació de les bases de dades
  • Log i auditoria
  • Codis d’error

MIA - Manual d’Instal·lació i Administració

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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ó

  • Preinstal·lació
  • Instal·lació del Sistema d’Informació
  • Instal·lació dels components
  • Instal·lació de les bases de dades
  • Altres instal·lacions

4. [CONFIG] Configuració del Sistema d’informació

  • Configuració dels components
  • Configuració d’usuaris
  • Dades per defecte

MOP - Manual d’Operatòria

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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

  • Equips d’usuari
  • Equips d’explotació
  • Equips de servei
  • Equips d’emmagatzemament i dades

3. [SETTING] Manual d’instal·lació

  • Preinstal·lació
  • Instal·lació del Sistema d’Informació
  • Instal·lació dels components
  • Instal·lació de les bases de dades
  • Altres instal·lacions

4. [ADM] Manual d’administració

  • Configuració dels components
  • Configuració d’usuaris
  • Dades per defecte

5. [DATA] Descripció del model de dades

  • Diagrama ER
  • Model normalitzat
  • Descripció de les entitats

6. [SYSTEM] Procediments de manteniment i seguretat

  • Procediments de manteniment del Sistema d’Informació
  • Procediments de còpia de seguretat
  • Verificació de les còpies de seguretat
  • Procediments de restauració i recuperació de les bases de dades
  • Log i auditoria
  • Codis d’error

MUS - Manual d’Usuari

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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

PB - Product Backlog

Format

Usualment un full de càlcul

Contingut / Plantilla pautada

  • ID: Codi de la història d’usuari
  • Nom: Nom de la història d’usuari
  • Descripció
  • Notes / Observacions
  • Prioritat (Alta, Mitjana Alta, Mitjana Baixa, Baixa). O bé un valor numèric
  • Criteris d’acceptació (DoD)
  • Cost (en story points)
  • Sprint assignat

PdD - Pla de desplegament

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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ó)

PLN - Planificació de projecte

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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ó

PPR - Pla de proves documentat

Format

Usualment un arxiu de text, o eina de gestió i execució de test

Contingut / Plantilla pautada

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:

  • Definició de l’abast de les proves
  • Requeriments organitzatius per a la realització de les proves
  • Definició de les proves
  • Registre de realització de les proves

REQ - Catàleg de Requeriments

Format

Usualment un full de càlcul

Contingut / Plantilla pautada

  • Agrupació
  • ID
  • Data d’entrada
  • Data última actualització
  • Forma part de la definició inicial?: Si/No
  • Prioritat: (1) Vital, (2), Important, (3) Recomanable, (4) Opcional.
  • Tipus: (1) Funcional, (2) Rendiment, (3) Seguretat, (4) Implantació, (5) Disponibilitat del sistema.
  • Cas d’ús relacionat / Història d’usuari relacionada (Aquesta columna podria estar mantinguda en el DFU)
  • Descripció del requeriment

RIN - Registre d’Incidències i de Riscos

Format

Usualment un full de càlcul

Contingut / Plantilla pautada

Índex de famílies de riscos

  • Riscos en l’engegada del projecte
  • Riscos sobre pressupost
  • Riscos sobre l’abast i els objectius
  • Riscos sobre l’equip del projecte
  • Riscos sobre aspectes tècnics, arquitectura, infraestructura
  • Riscos sobre terceres parts o comunicacions
  • Riscos sobre el destinatari del producte
  • Riscos sobre la gestió del canvi

Regles de càlcul

  • severitat = probabilitat * impacte

Dades descriptives d’un risc. Document RIN

  • ID
  • Família de risc
  • Origen (d’on prové?: persona, àrea, altres)
  • Data identificació
  • Estat (pendent, en curs, tancat, cancel·lat)
  • Data última actualització
  • Persona que informa
  • Descripció del risc
  • Probabilitat (alta, mitjana, baixa)
  • Impacte (aturador, alt, mitjà, baix)
  • Severitat (probabilitat * impacte)
  • Pla de mitigació
  • Responsable del pla de mitigació
  • Data de tancament

TAP - Tancament de Projecte

Format

Usualment un document de text acompanyat d’una guia d’ús

Contingut / Plantilla pautada

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:

  • Canvis sobre la documentació tècnica que han quedat pendents i que cal fer per tancar el projecte
  • Accions de formació que han quedat pendents o que cal completar. Documentació dels canvis sobre la formació
  • Pla de manteniment: O bé la proposta d’una acció de manteniment externalitzada, o bé un pla de transició a l’equip de manteniment del client.

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.

  • Acompliment d’objectius del projecte i del negoci
  • Incidències dignes de menció
  • Contrast de l’execució amb la planificació
  • Mesurament del grau de satisfacció dels implicats al projecte
  • Lliçons apreses

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