En molts equips digitals el problema no és la manca de talent, sinó l’absència d’una estructura que permeti aprofitar-lo. Per mantenir un ritme productiu sostenible no n’hi ha prou amb bones intencions: cal organització, una definició precisa del que s’ha de fer i una planificació rigorosa que sàpiga adaptar-se quan cal.
Un element clau és la definició detallada de cada tasca: abast, prioritat, responsables i dependències. Quan una tasca és incompleta o està mal formulada, frena tot l’sprint, genera feina innecessària i retarda el projecte.
A somoscuatro fa anys que apliquem un sistema que redueix les ambigüitats i canvia la manera de treballar. És el mètode que utilitzem perquè cada tasca arribi a l’equip amb la claredat suficient per avançar.
L’objectiu real
El problema més habitual a l’hora de formular tasques és descriure-les sense context ni precisió. No queda clar què es vol aconseguir. L’objectiu real ha de partir d’una necessitat concreta del negoci, però moltes vegades es redacta amb un enfocament purament tècnic: s’explica què s’ha de fer, però no quin problema es resol ni quin valor aporta al negoci. Sense aquesta claredat, la solució queda condicionada des del principi i es perd l’oportunitat de valorar alternatives o, directament, de qüestionar si la tasca és necessària.
Per exemple, un bon objectiu seria:
Objectiu
Permetre a l’equip d’administració identificar i filtrar les despeses pagades per agilitzar la revisió setmanal.Que es muy diferente de:
Que es muy diferente de:
Objectiu
Afegir un filtre de despeses pagades/no pagades.
En el primer cas queda clar quin problema es vol resoldre i quin benefici s’obté. En el segon només hi ha una acció tècnica. No s’entén per a què serveix, quina necessitat cobreix ni quin impacte té.
Proposar solucions i escollir-ne una
Si l’objectiu està ben definit, l’equip tècnic podrà proposar una o diverses solucions ajustades a les necessitats reals del negoci, sense condicionants. De totes les opcions, se n’escollirà una segons criteris d’idoneïtat tècnica, rendibilitat, escalabilitat, rendiment i seguretat. Així obtindrem la millor solució possible, recolzada en el coneixement de tot l’equip.
Prenent l’objectiu anterior (Permetre a l’equip d’administració identificar i filtrar les despeses pagades per agilitzar la revisió setmanal), podríem tenir:
Solucions possibles
[A] Afegir un estat intern «pagat/no pagat» gestionat manualment per l’equip. L’equip marca cada despesa com a pagada des del panell d’administració. El sistema només emmagatzema l’estat i permet filtrar-lo.
[B] Integrar el sistema amb la passarel·la de pagament per actualitzar l’estat automàticament. El sistema consulta la passarel·la i marca les despeses com a pagades segons les transaccions registrades, reduint la feina manual.
Solució escollida
[A] Escollim l’opció A perquè cobreix la necessitat amb el menor esforç tècnic i sense introduir dependències externes. És una solució senzilla, fiable i suficient per millorar el procés des del primer dia. A més, deixa la porta oberta a automatitzacions futures si el volum de despeses creix o si l’equip necessita reduir encara més la feina manual.
Context, context, context
L’objectiu defineix què necessitem resoldre i per què; les solucions descriuen com. Però fins i tot amb aquests dos elements, la tasca no està completa.
Les tasques solen néixer de converses prèvies, depenen d’altres, es comenten en reunions o sorgeixen d’intercanvis a Slack o per correu. Gairebé sempre hi ha un context addicional que no s’ha de perdre.
Per això recomanem afegir, quan tingui sentit, tres seccions opcionals: Detalls, Recursos i PRs.
La secció Detalls recull qualsevol informació addicional que pugui influir en el resultat. No són decisions tècniques, sinó matisos que aclareixen regles de negoci, rols o condicions específiques. Per exemple:
Detalls
Només els usuaris amb rol d’administrador podran marcar una despesa com a pagada/no pagada.
L’estat s’ha de mostrar sempre a la vista de llistat, no només al detall.
La secció Recursos és una llista d’enllaços útils: documentació interna, arxius de disseny, referències externes o captures rellevants. Per exemple:
Recursos
Document de regles de validació de despeses (Google Drive)
Disseny de la vista de llistat actualitzat (Figma)
La secció PRs recull els enllaços a les Pull Requests obertes per resoldre la tasca. Facilita la revisió de codi i manté la traçabilitat sense dependre de la memòria. Per exemple:
PRs
PR #123
PR #124
Criteris d’acceptació
Encara falta un element: els criteris d’acceptació. Són l’eina que permet a l’equip saber exactament què ha de funcionar en acabar la implementació i, al mateix temps, donen al Product Owner una manera objectiva de validar el resultat abans de publicar el canvi i tancar la tasca.
Un bon criteri d’acceptació és binari i no deixa espai a interpretacions: o es compleix, o no es compleix. Seguint l’exemple:
Criteris d’acceptació
Els usuaris amb rol d’administrador poden marcar i desmarcar una despesa com a «pagada» des de la vista principal sense accedir al detall.
L’estat «pagat/no pagat» es desa correctament i es manté visible tant a la vista principal com al detall de la despesa.
En aplicar el filtre «pagat», la vista principal mostra únicament les despeses amb aquest estat, sense inconsistències ni resultats duplicats.
Conclusió
Quan cada tasca està ben definida, el projecte deixa de dependre d’interpretacions i comença a avançar amb l’estabilitat que necessita un producte digital seriós.
A somoscuatro organitzem tota la nostra feina a Asana i apliquem aquest sistema en cada projecte perquè sabem que la claredat és el que permet lliurar amb coherència, preveure riscos i prendre decisions amb seguretat.