La majoria de les enginyeries amb qui he treballat, no planifiquen o planifiquen poc i malament. Per què? Em sembla que aquestes són algunes de les causes.

Les metodologies de planificació clàssiques tipus cascada, camí crític o cadena crítica no tenen en compte que les persones no es comporten com robots. A més, aquests sistemes són difícils d’aplicar en entorns multiprojecte que comparteixen recursos.

En una enginyeria, les tasques són executades per persones, no per màquines: la durada de les tasques no és sempre la mateixa, les persones procrastinen i els projectes estan plens de tasques especialment procrastinables com, per exemple, les decisions.

L’ordre en què s’executen les tasques depèn moltes vegades de la voluntat del treballador. Hi ha tasques que s’han de fer en un ordre determinat (cal construir la paret abans de pintar-la), però sovint podem triar l’ordre en què les fem.

Normalment, no sabem per a quan ha d’estar feta realment una tasca. Tot ha d’estar fet per ahir o per tan aviat com sigui possible. Moltes vegades, la data en què s’acaba una tasca depèn de la data en què, sí o sí, cal haver-la acabat, com també de la importància i fins i tot de l’estat anímic del client.

Sovint, les tasques urgents passen al davant de les tasques importants.

Hi ha tasques infinitament expansibles: hi podem dedicar un matí, un dia, una setmana o un mes. Totes les que impliquen disseny són d’aquest tipus.

Tradicionalment, la planificació es fa de dalt cap a baix. És a dir, el cap de projecte li diu al projectista què ha de fer, per a quan i en quin ordre. El cap de projecte acostuma a no tenir prou temps per planificar els projectes que, a més, estan canviant tota l’estona.

Si planificar no funciona, per què hem de fer-ho?

• La incorporació de sistemes de planificació efectius permeten increments de la productivitat dels equips de dos dígits. 
• La planificació ens permet disminuir els riscos dels imprevistos.
• La planificació ens permet tenir millor control del projecte. 
• En un entorn planificat es viu millor.
• Ei vivim sempre en estat d’emergència, a la pràctica deixem de tenir la capacitat de posar-nos en mode emergència i ja no tindrem capacitat de reacció quan sigui verdaderament necessari. 
• El client vol saber quan tindrà acabat el projecte. I, si no podem lliurar un projecte en la data prevista, sempre serà millor comunicar-ho abans d’aquella data.
• El temps i el cost, i per tant el marge del projecte, estan directament relacionats.  

El camí no és senzill, però és altament rendible.

Per on comencem a planificar?

Un projecte és un equip de persones fent un munt de tasques que un client ens paga. 

En una enginyeria, tenim un munt de projectes, i això ens porta a un entorn multiprojecte on els recursos es comparteixen entre projectes. Tenim un sistema format per persones que fan tasques que s’han d’acabar en una data determinada. Analitzarem primer la naturalesa de les tasques i després algunes característiques de les persones. 

Comencem per les tasques. Les podem classificar en 3 eixos: segons la durada de la tasca, segons la necessitat/utilitat de la tasca i segons la motivació. 

Eix 1. Segons la durada de la tasca

• Tipus 1: Deterministes. De durada definida i concreta. Són totes aquelles tasques que en general són senzilles i rutinàries, que ja hem fet moltes vegades i coneixem bé quant trigarem a fer-les. 

• Tipus 2: Estocàstiques o de durada desconeguda. Són totes aquelles que no tenim manera de saber quan estaran resoltes. Les podem subdividir entre les que no sabem quan s’acabaran perquè depenen d’un tercer o bé per la naturalesa de la tasca. Alguns exemples: una vacuna per la malària, trobar un error en un sistema informàtic, saber quan el tècnic de l’ajuntament ens donarà la llicència, etc.

• Tipus 3: infinitament expansibles. Aquestes tasques compleixen la Llei de Parkinson, formulada el 1955 per Cyril Northcote Parkinson, i que afirma que una tasca s’expandeix fins a omplir tot el temps disponible per a completar-la. Les tasques d’aquest tipus són totes aquelles que impliquen creativitat, que sempre es poden millorar i perfeccionar. Per exemple, dissenyar una peça, fer un plànol, escriure una memòria o un article o trobar el millor component de mercat al millor preu. Un cas particular d’aquest tipus és la presa de decisions.

Eix 2. Segons la necessitat de la tasca

• Tasques necessàries per assolir els objectius del projecte.
  
• Tasques opcionals. Si es poden fer, fantàstic, però poden no fer-se sense comprometre el projecte.
  
• Tasques innecessàries. Són tasques que no cal fer, que si al final no es fan no passa res, però que per alguna raó són al llistat de tasques. 

Eix 3. Segons la motivació de la tasca

Hi ha tasques amb tendència a ser procrastinades o endarrerides. Són tasques que s’encallen, que no es posen en marxa. Són tasques que no agraden, que no se’ls veu el propòsit, que no tenim clar com fer. Moltes vegades, aquest fet depèn més de les persones que de la tasca mateixa.

Fins aquí ens hem fixat en la complexitat de les tasques, però que una tasca es faci depèn de les persones i de l’equip. Per tant, l’execució de les tasques depèn, en primer lloc, del fet  que la persona que ha de fer-les decideixi fer-les; de l’emoció de la persona envers la tasca. 

Quins són els factors que fan que una persona faci o no una tasca? En un entorn laboral de gestió de projectes, una persona mai decideix no fer una tasca, el què fa és triar fer-ne una altra abans. Per això, hi ha tasques que es poden endarrerir indefinidament perquè mai es trien per fer en primer lloc.

Factors que fan que una tasca es triï en primer lloc

1. La urgència. Diferents experiments han demostrat que les tasques urgents passen per davant de qualsevol altra. Tendim a “fer de bombers”, a apagar incendis. Moltes vegades ens trobem que l’equip dedica moltes hores al mode reactiu: es limita a contestar els correus i missatges que entren. 

2. Les tasques senzilles i curtes que permeten un resultat ràpid. Això és així especialment en entorns de càrrega de treball molt elevada. Es prioritzen les tasques senzilles per disminuir el volum de tasques pendents de manera ràpida. De vegades, després ja no queda energia per a la tasca important i complexa.

3. Les tasques que desperten curiositat, interès tècnic o que es gaudeixen.

4. Les tasques que sabem que farem bé. En dominem la tecnologia, coneixem el procediment, estan ben definides i sabem que podrem acabar-les. 

5. Les tasques que tenen un propòsit, una utilitat intrínseca per a mi o per la societat. 

Tasques que es tendeixen a procrastinar

1. Produeixen emocions desagradables:

• Les converses difícils
• Prendre decisions
• Les tasques per a un interlocutor conflictiu
• Iniciar una tasca per la qual pensem que no estem preparats
• Les tasques que no ens agraden

2. No són fàcils de començar: 

• No està ben explicat què es demana
• Cal buscar documentació que no sabem si trobarem
• Cal concretar com ho farem amb altres persones de l’equip

3. Es consideren inútils o innecessàries, o que se sap que ningú revisarà. 

La priorització no depèn només de les característiques de la tasca, sinó també de:

• Qui ho demana
• La proximitat del sol·licitant
• La capacitat d’escalar 
• La insistència de qui ho demana
• La visibilitat davant la direcció
• L’existència d’un procediment obligatori

La planificació dels projectes en una enginyeria és un problema amb una complexitat elevada que no podem pretendre resoldre amb un Gantt o un Excel. 

Queda clar que no podem tractar la planificació de projectes de manera determinista, de la mateixa manera que planifiquem un procés de fabricació amb un conjunt de màquines automàtiques. 

Les metodologies clàssiques de planificació no ofereixen solucions per gestionar la complexitat real del sistema. Funcionen quan les tasques són del primer tipus, però als projectes, la majoria de les tasques són del 2n i 3r tipus i, a més, els treballadors acostumen a fer les tasques en l’ordre que ells trien. Ens cal, per tant, una metodologia de treball diferent, una metodologia que doni molt més pes a la gestió de l’equip i que empoderi i impliqui a cada un dels seus integrants. 

El manifest Agile i la metodologia SCRUM, nascuts fa més de 20 anys en entorns de desenvolupament de software, tot i que no són directament aplicables a la planificació d’una enginyeria, aporten una colla de principis que ens poden permetre fer un gran pas endavant. 

Com ha de ser el sistema per planificar la meva enginyeria?

Per resoldre el problema hem de:

1. Aconseguir que cada un dels tècnics executi les tasques en l’ordre òptim.
2. Calcular, a partir de l’ordre de les tasques, la durada de cada tasca i les hores disponibles de cada tècnic, així com la data en què estarà completada cada tasca. 

Quins passos cal fer per aconseguir-ho?

El més important és donar d’alta totes les tasques organitzades per fases en un programari de planificació. Aquesta és la barrera d’entrada més alta per aconseguir la planificació de tot l’equip. El temps necessari per a donar d’alta detalladament totes les tasques en un sistema és aparentment temps perdut no productiu, però és la clau del sistema. No es pot transigir en aquest punt.

És necessari que tot allò que fa l’equip estigui donat d’alta com a tasca.

Les raons més habituals que els equips exposen per justificar no fer aquesta tasca són:

• “Tenim moltes tasques molt curtes i és molta feina”
• “Els nostres projectes tenen poques tasques, però molt llargues que canvien contínuament”
• “No tenim temps de donar d’alta les tasques”
• “Les nostres tasques són sempre diferents”
• “El programa és massa enrevessat per donar d’alta totes les tasques”

Per planificar una enginyeria cal fer aquesta feina i, encara que és cert que donar d’alta les tasques en un sistema no és agradable i requereix hores, permet aconseguir guanys de productivitat que moltes vegades superen el 20%.

Funcionalitats clau del programari

Per aconseguir aquests increments de productivitat, cal que el programari que triem disposi de les següents funcionalitats:

• Permetre la comunicació dels diferents actors al voltant de la tasca. D’aquesta manera, ens estalviarem escriure correus parlant d’una tasca en concret. Quan has d’explicar en un e-mail què cal fer en una tasca, primer has d’identificar la tasca de manera inequívoca. Si disposem d’una eina on podem posar comentaris a la mateixa tasca, el procediment és molt més eficaç i estalvia errors.
  
• Penjar tota la informació de la tasca a la mateixa tasca: documents, metodologies, etc. Una tasca és un molt bon repositori de coneixement. Si podem posar els documents necessaris per fer una tasca enllaçats a la tasca, ens estalviem tot el temps en buscar documents.
  
• Agrupar les tasques en fases i subfases en tants nivells com sigui necessari.
  
• Visualitzar els projectes en un Gantt.
  
• Disposar d’una visualització Kanban que es pugui filtrar per projectes, fases, equips i persones.
  
• Modificar l’ordre de les tasques o disposar de funcionalitats per ordenar les tasques segons diferents criteris.
  

Altres funcionalitats interessants són:

• Crear plantilles de projectes des de zero o a partir de projectes fets. Així quan ens contracten un nou projecte similar al que ja hem fet no ens caldrà donar d’alta totes les tasques de zero.
  
• Comunicar al client de manera semiautomatitzada o automatitzada l’estat del projecte.
  
• Conèixer els costos d’execució de cada tasca i de cada fase per a millorar el procés d’oferta de nous projectes. Si disposem d’una bona base de dades de costos, sabrem el que ens costarà de veritat fer un projecte similar.
  
• Mesurar el treball en curs de cada un dels projectes i aplicar-lo convenientment a la comptabilitat.
  
• Mesurar la productivitat de l’equip i de cada un dels seus integrants.
  
• Conèixer les desviacions en temps i pressupost del projecte en temps real. 

Planifica per fases i subfases

Quan ens posem a donar d’alta les tasques del projecte en el sistema, el primer dubte és: Quan zoom faig? Moltes tasques molt petites o poques tasques molt grans? 

La meva norma és que una tasca ha de durar com a màxim una setmana, el responsable de la tasca és qui l’executa i cada tasca defineix una cosa que cal fer, no un grup de coses diferents.

Les tasques les agruparem en fases o etapes. Cada fase ha de durar una o vàries setmanes. Si les fases són més llargues, aconsello reduir-les en subfases. És important que una fase no duri 6 mesos perquè, normalment, si una cosa ha d’estar acabada per d’aquí a sis mesos, no cal que comencem avui, “ja ho farem”, però si només tenim dues setmanes per fer la feina, ens hi posarem avui.

Cada fase ha de tenir una data d’inici i una data de fi i les hem de poder visualitzar molt bé en un diagrama de Gantt. Les fases són la part del projecte que s’ha de planificar de dalt cap a baix. És a dir, són establertes pel cap de projecte. Aquí utilitzarem el mètode de Goldratt: no posarem marges de seguretat a cada una de les fases, però deixarem un buffer al final del projecte. 

Cada fase o etapa té un conjunt de tasques que s’han de completar, i ha de ser el mateix equip qui s’autoorganitzi per repartir-se i ordenar les tasques de la manera més eficient. 

El programari ens pot proposar un ordre de les tasques a partir de criteris preestablerts. De tota manera, al final sempre serà el tècnic qui decidirà en quin ordre fa les tasques.

Reunions regulars amb l’equip 

Per al correcte funcionament de l’equip és necessari sistematitzar reunions per a la planificació i el seguiment del projecte. Es recomanen les següents:

Reunions d’inici de fase

Es revisen els objectius de la fase, els entregables, les dates límit i el llistat de tasques. Fem un primer repartiment de tasques entre els tècnics. Es planifiquen les tasques de la primera setmana, i en alguns casos ja es poden planificar les tasques per la resta de setmanes. La visualització Kanban permet repartir de manera senzilla la càrrega de feina entre els tècnics i avaluar la feina que té assignada cada setmana cada tècnic. En aquest punt és molt important el compromís de cada tècnic en la planificació.

Reunions de planificació setmanal

Es revisa l’estat de la planificació i es reajusta: quines tasques van quedar pendents de la setmana anterior, quines cal moure cap endavant, quines han deixat de tenir sentit o quines tasques noves han aparegut. Cada tècnic es compromet a fer les tasques que té assignades aquella setmana. Si s’aconsegueix que l’equip marxi divendres amb la feina planificada enllestida es produeix un canvi molt positiu a l’organització. Si les fases són molt curtes, aquestes reunions poden no ser necessàries. 

Reunions de seguiment diàries

Són complicades de posar en marxa però són molt efectives, productives i necessàries. Són reunions d’equip que duren entre 15 i 30 minuts, moltes empreses les fan de peu dret i sempre a la mateixa hora. Aquestes reunions permeten que cada dia hi hagi un moment amb tot l’equip junt, cosa que facilita el tractament de canvis de planificació i la gestió de les incidències. L’ordre del dia és el següent: 

• Incendis, problemes detectats i comunicacions importants per a tot l’equip. Els problemes no es resolen en aquesta reunió, s’enuncien i es fixen reunions específiques per tractar-los.
• Ronda on cada integrant de l’equip explica en què va estar treballant ahir i en què té previst treballar avui.

Reunions de tancament de fase

Es revisa el compliment d’objectius de la fase, què ha funcionat, què no ha funcionat i què cal millorar per a la pròxima fase.

Un cop posem el sistema en funcionament, tindrem les tasques de tots els projectes en una sola base de dades, ordenades i amb dates d’execució. A partir d’aquí, el programari ens ha de poder fer una estimació de la data en què hauria d’estar acabada una tasca concreta, un projecte concret, quina és la càrrega de treball de cada tècnic i fins a quin dia un tècnic concret té feina.

En resum

Cal una metodologia adaptada a les especificitats del teu equip i als teus tipus de projectes. Cal que aquesta metodologia estigui basada en les persones i en el compromís envers la planificació, i cal aprofitar la tecnologia per gestionar totes i cadascuna de les tasques de la teva empresa.

Per planificar, cal donar d’alta en un sistema totes les tasques de tots els projectes.