Què és i què no és team as a service (TAAS)?

Team as a Service (d'ara endavant TaaS) és alhora un producte i una proposta organitzativa. SEIDOR ja oferia aquest servei des de fa un parell d'anys però enmig del tsunami COVID19 adquireix la denominació de “obligatori” pel que fa al desenvolupament de software es refereix.

Dic que TaaS és un producte perquè a SEIDOR tenim quantificats els preus i les condicions de servei, a falta d'acordar l'abast i la durada del projecte per a cada cas concret. I dic que és una proposta organitzativa, perquè no es tracta de posar un grup de persones partint de zero a escoltar el client... no és bodyshopping. TaaS té una organització precisa que, si bé pot adaptar-se en detalls específics al projecte concret, ha de respectar una estructura bàsica ben definida.

Però llavors, en què es diferencia TaaS de qualsevol altra forma d'organitzar un equip de treball? L'element diferencial són els valors conductors. Aquests no són exclusius del TaaS, es troben en algunes metodologies ben conegudes de desenvolupament de programari i gestió de projectes. I en TaaS, hem fet el nostre petit manifest particular basant-nos en el coneixement adquirit en dècades d'experiència en projectes IT.

Quins són els valors conductors de TAAS?

• Responsabilitat compartida: l'equip participa de les decisions, de manera que qualsevol membre està empoderat per proposar millores en la metodologia, identificar riscos, assumir responsabilitats (o delegar-les)... Tots els membres de l'equip estan informats permanentment de l'objectiu del projecte, de l'estat actual i del que fan els altres.
• Companyonia: vital per a la bona col·laboració. I això és sobretot el que es necessita perquè el TaaS rendeixi, una col·laboració oberta entre tots els membres de l'equip i amb el client. Atès que la companyonia funciona millor en equips petits, de no més de 10 persones, mantenim els equips TaaS per sota d'aquesta xifra. No hi ha cap raó perquè no hi hagi més d'un equip TaaS treballant en el mateix projecte si l'abast ho requereix.
• Transparència: ha de ser la mateixa que un bon restaurant japonès que permet veure la feina a la cuina darrere d'un vidre. Atès que l'equip TaaS treballa en remot, i no presencialment a les oficines del client, la transparència es materialitza en la publicació de la feina realitzada en una eina en línia a la qual accedeixen tant els membres de l'equip com el nostre client.
• Actualització diària: és fonamental. La disciplina d'actualitzar diàriament el grau de progrés permet la detecció primerenca de les desviacions i facilita la seva mitigació. De fet, saber que es revisa el progrés cada dia predisposa psicològicament a aconseguir petits objectius en consecució dels objectius generals del projecte. Cada dia es revisen els riscos del projecte, es posen en comú els bloquejos o dependències entre tasques.
• Confiança, entre els membres de l'equip i amb el client. En el model TaaS el client pot actuar com un membre més de l'equip. Està informat de tot i té accés a tot en qualsevol moment. Tota la informació està al núvol.

Què no fa funcionar el TAAS?

Cal tenir també ben presents els elements que no fan funcionar el TaaS. Aquests són alguns dels punts fal·laços en els quals és fàcil caure i que malgrat el seu aparent valor, sovint són més un llast que una ajuda efectiva:

• Les eines: a vegades sembla que més que eines, fem servir joguines. Hem vist en massa ocasions dipositar tota la confiança en l'organització d'una feina en l'eina utilitzada, com si tot anés a funcionar bé per utilitzar un programari car. És una de les fal·làcies més sorprenentment esteses en el nostre món. Un bon TaaS pot funcionar fins i tot comptant només amb llapis i paper, si bé seria una mica absurd fer això. Podem utilitzar Redmine, Jira, Trello, Miro... l'univers és infinit i no importa l'eina, el que importa és com s'utilitza.
• El fanatisme metodològic: la línia que separa el rigor del fanatisme en les metodologies de gestió de projectes és sorprenentment difusa. Per coincidència de les directrius generals, les metodologies iteratives encaixen millor amb el TaaS que les metodologies en cascada. Això no vol dir que les metodologies en cascada no es puguin aplicar, sinó que la seva aplicació pot requerir un major esforç. Dit això, les metodologies són com les lleis: no poden preveure tots els casos de l'univers i, de la mateixa manera que existeix alguna cosa anomenada l'esperit de la llei que s'aplica quan la lletra condueix a confusió, també tenim l'esperit de la metodologia, que ens permet assumir graus de llibertat quan arribem a imprevistos.
• La centralització: una de les grans pors del project manager tradicional és la descentralització. La necessitat de "tenir-ho tot controlat" pot arribar a ser realment compulsiva i s'ha d'evitar a tota costa. Cada membre d'un equip TaaS té la seva responsabilitat i l'assumeix, incloent-hi el client.

Resumint, el TAAS s'inspira directament en el manifest Agile (compte, en el manifest, no en les seves metodologies) i per damunt de tot persegueix la cooperació, el progrés sostenible i la millora contínua.