Col·laboració

Escrit per Aaloy a 07 de March , 2010 a les 8:05 p.m.

En Galigan l'altra dia es demanava pel Twitter com és que la gent que fa feina de manera independent no s'uneix per poder fer front a "consultoras dinosaurio".

Com que el Twitter és massa curt i massa immediat per poder poder dir les coses, doncs li vaig prometre un apunt al blog per contar com veia jo les coses. Potser amb aquest apunt tampoc aconseguiré explicar tot el que vull dir i el que pens del tema, però al manco serà un poc més desenvolupat que no un grapat de frases al Twitter.

Primer un poc de història.

La idea d'un conjunt de professionals autònoms que s'uneix baix una mateix marca no és nova a les illes. Fa temps i a partir d'un grup de gent que es coneixia de Bulma hi va haver un intent de fer tal cosa. Pel que jo sé (no hi vaig participar a l'experiment) la cosa no va acabar d'anar del tot bé.

Desconec exactament les raons del fracàs de l'experiment, però potser una d'elles va ser la inexperiència en unions com aquesta. En altres sectors com els missers i gestors per exemple, aquests tipus de col·laboracions són molt més habituals.

Tot i que no funcionàs la idea és prou bona. Va ser el punt de partida que ens motivà a formar APSL, no ja com a una marca sinó com a una societat limitada. La idea fonamental era, i és, unir a professionals amb una visió del que és el desenvolupament d'aplicacions web comú, professionals que es complementin i amb un objectiu comú.

L'experiment APSL

APSL té un nucli estable de gent des de el principi, que hi col·labora d'una manera o altre, uns són socis, d'altres just col·laboradors voluntaris (un bon exemple d'això són els #creant_bits). Però tothom amb una visió semblant de la informàtica i amb una cosa fonamental: confiança mútua.

Des de la seva formació APSL ha tingut com a objectiu la col·laboració entre professionals, però per a que tal cosa es produesqui aquesta col·laboració s'ha de donar de manera natural, ordenada i amb el consens de tothom. La confiança és a més el nexe que fa possible el projecte. Tothom que hi forma part ha de poder tenir la confiança plena de que cada un farà el que s'ha de fer en cada moment, que els egos no han de prevalèixer damunt l'objectiu més gran que és dur endavant un projecte empresarial a llarg termini.

La visió no és sols orientada a la informàtica, sinó també al model empresarial, a l'ètica empresarial, el que darrerament s'ha anomenat la responsabilitat social de l'empresa. Per a nosaltres això representa fer negocis d'una manera molt determinada, convertint-nos no sols en proveïdors dels nostres clients, sinó en col·laboradors, en una relació quasi simbiòtica on tothom hi ha de sortir guanyant. En poques paraules, no es tracta de donar el pelotazo sinó de mantenir una relació de confiança i col·laboració que s'estengui al llarg del temps.

Supòs que tot això us sonarà a la gent que heu parlat amb mi i com molts us adonareu no és una cosa massa habitual en el nostre sector (sobretot fora del programari lliure), per això dic que APSL és un experiment, perquè trob s'ho paga intentar que un projecte així tiri endavant.

Per què empresa?

L'empresa és el nexe d'unió. Representa una manera formal de fer les coses i estableix unes regles de joc comercials i mercantils. Implica que hi ha un admintrador/gerent que dóna la cara, que pot coordinar els distints projectes i saber què fa tothom.

I per mi això és el que marca la diferència entre projectes semblants que s'estructurin al voltant d'una marca i dels que s'estructuren al voltant d'una empresa: la figura de l'administrador, de la persona que ha de vetlar per a que l'empresa funcioni com a tal, encara que internament els seus membres siguin tots professionals.

L'empresa com a tal dona recolzament als professionals que la formen. Fa que el tot sigui major que la suma de les parts, i a la seva vegada imposa tota una sèrie d'obligacions: facturació comuna, comptabilitat clara, despeses comunes, ...

Des del moment que es té un lloc comú de reunió, que s'ha de pagar, una facturació i uns comptes que s'han de presentar, la col·laboració passa de ser una cosa esporàdica entre professionals i convertir-se en un tirar del carro comú. S'han de tenir millors serveis compartits, aquella lasser que fa falta, el servidor que s'ha d'ampliar i gestionar, els clients que s'han de visitar, ...

APSL està pensada per créixer de manera orgànica i pausada en vers l'objectiu d'agrupar professionals, de sumar talent i proporcionar serveis comuns que d'altra manera no es podrien tenir, d'arribar a projectes que amb un altre tipus d'estructura serien directament inabastables.

Però tot això ja us dic que té tota una sèrie d'implicacions que s'han de conèixer i que potser en altres intents d'aquest tipus no s'han donat tant. Deixau-me canviar un poc de registre i no referir-me tant a APSL sinó a com ho veig en general.

Què implica un projecte de col·laboració?

  • Objectius comuns. Ja no es cosa d'anar cada un pel seu compte i que l'empresa sols es tengui en compte a l'hora de presentar-se a un projecte, sinó que s'ha de tenir l'objectiu de fer que l'empresa com a tal cresqui. Els projectes ja no són propis sinó que són de l'empresa, de la mateixa manera que ho són les despeses.

  • Confiança professional Tothom ha de poder confiar amb tothom i els clients han de poder confiar en els professionals de l'empresa. La visió de l'empresa i del model de negoci ha de ser la mateixa per tot els professionals agrupats entorn a l'empresa.

  • Complementarietat En un negoci global com és la informàtica els professionals que s'agrupin en un projecte de col·laboració han de ser complementaris i no tan sols en l'aspecte tècnic (que també) sinó en l'aspecte fin i tot de caràcter. No tot és programar, també s'ha d'anar a captar clients, fer pressupots, parlar amb gestors, dissenyar l'aplicació, documentar, fer fotografies, ...

  • Serveis compartits Un altre dels nexes del projecte ho han de representar els serveis compartis: el local, els servidors, la infraestructura posada a disposició del integrants del projecte. El local, per exemple, fa que hi pugui haver un punt de feina on la gent que es sent més còmoda fent feina fora de casa hi pugui anar. S'ha de pensar a llarg plaç i reservar capital per a invertir en el projecte: millor mobiliari, local amb més possibilitats, millors servidors, possibilitat de organitzar cursets, d'anar a conferències.

  • Despeses S'ha de ser conscient que un projecte de col·laboració a llarg plaç té despeses. La feina d'organització i gestió interna pot arribar a ser força important quan es tracta de gestionar un projecte on un gran nombre de professionals han de de col·laborarar, s'ha de mantenir per una estructura gran un nivell d'abstracció semblant al que es tenia com a professional, però aprofitant les sinèrgies que implica col·laborar amb altra gent. Això vol dir que els beneficis de la nostra feina com a professionals ja no són sols nostres, sinó que són de l'empresa i dels altres col·laboradors. Joel Spolsky tracta molt bé el tema a The Development Abstraction Layer. Fitxau-vos que les despeses no es refereixen al material, a la llum o al local, sinó a tot el necessari per mantenir el nivell d'abstracció que permeti aprofitar les sinergies que impliquen posar feina en comú.

  • Creixement orgànic Personalment pens que s'ha de ser caut a l'hora de créixer. S'han de cercar les col·laboracions permanents quan la gent ja es coneix i ha fet feina junta en alguns projectes. A l'hora d'admetre nous membres aquesta admisió no ha de ser fruit de la necessitat sinó de l'acord de tots els membres. Ja no estam sols, som un equip, una empresa i per tant la decisió de amb qui es col·labora i amb qui no ha de ser quelcom comú.

  • Suport mutu Quan un fa feina sols qualsevol problema o incidència personal té un impacte brutal damunt la seva activitat. Per una empresària el naixement d'un fill pot representar tant una alegria com a un risc. Col·laborar implica estar a les dures i a les madures, minimitzar els impactes que puguin tenir els membres. Ara es funciona com a empresa i com a tal els projectes i els clients són comuns. Implica estar dispost a conèixer els clients i els projectes de l'altra gent, ser-ne el backup en cas que fos necessari, i si més no sempre tenir-ho previst.

Així és com jo ho veig, i és el que estam intentant dur a terme amb APSL. Personalment crec que qualsevol projecte de col·laboració que es presenti just en termes mercantilistes i d'oportunitat té poc futur. S'han de tenir en compte més coses. Tot i que es vulgui mantenir la llibertat de moviments que implica ser un professional autònom s'han d'establir unes regles de joc i s'han d'assumir tant beneficis com obligacions.

Enllaços citats
Traducciones/Translations by apertium

12 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes APSL


Comentaris

1 Comentari de Paco Ros a les 09:03 del Sunday 7 Mar de 2010

Un post ben interessant. Crec que d'ente totes les persones que han fundat una empresa, aquesta és la primera vegada que hi veig una visió tan romàntica.

A mí m'agrada el romanticisme, però la vida m'ha ensenyat que les coses no són tan romàntiques.

Apostes fortament per una suma d'individuus que generin la força d'un col·lectiu i el primer punt que proposes per tal que funcioni és "tenir objectius comuns". Obvi: el primer que he pensat abans d'arribar-hi és "l'equip ha de tenir clars els objectius" però Realment és possible tenir objectius comuns? O en realitat el que es pot aconseguir és un consens?

El que ens duu a pensar en el punt 2: Confiança. Conec personalment a les persones d'APSL i sé que són bona gent amb principis ètics coneguts. És a dir, que no dubto d'ells ni de tú, però em torna a semblar massa romàntic. "Hasta que la muerte nos separe"sovint no funciona i ha de funcionar en una relació professional?

Els altres punts ja són més generalistes de qualsevol organització.

És un projecte ambiciós i guapo, però la seva feblesa és la feblesa del seu membre més feble. Si falla un s'en pot anar tot a porgar fum i això és perillós.

Imagina una desgràcia: un dels membres del col·lectiu pateix un accident i està fora de joc una bona temporada. O millor: li toca la loteria i s'escapa a una illa perduda. Com reaccionaria la resta dels membres? Podrien soportar la pèrdua del membre? Ara resulta que s'hauran d'aplicar les tècniques de alta disponibilitat que aprenguérem per les màquines i fer backup de les habilitats de cada persona.

Ja saps que la literatura empresarial em dóna la raó: quans menys socis millor. Ara bé. Tens raó: és massa guapo per no provar-ho. Sort!

2 Comentari de Paco Ros a les 10:03 del Sunday 7 Mar de 2010

Ara metre rellegia això he pensat que podríeu fer un exercici que es pot fer ben bé fent un cafetet.

Cada membre de l'empresa ha de dur apuntades situacions desfavorables que es podríen donar a l'empresa i com s'haurien de solucionar.

En una reunió, cada membre aporta les hipotètiques situacions i la resta han d'aportar la seva visió: com creu que reaccionaria ell i què creu que hauria de fer l'organització per superar el problema.

Posteriorment, es contrasta amb la visió que el que ha plantejat el problema havia previst.

Per exemple, imagina que sou la U.E. i que Grècia ha fet un poc l'animal últimament i està sense un duro. Les seves trepelleries han fet que la resta de països hagin hagut de treballar i fer coses que en principi no eren la seva responsabilitat.

Grècia se n'ha adonat del seu error i s'ha posat a dieta. Ha passat del pernil al Chopped i ara vui a una residència d'estudiants. Ve en bicicleta a fer feina i ha venut el cotxe.

Què hauria de fer la resta de membres? S'ha de recolzar tot i que impliqui una despesa d'energia brutal o fins i tot estigui en joc el prestigi de tota l'organització? I si la seva actitud no fos la de canviar?

Si fessiu aquest exercici i tot fos meravellós hi ha alguna cosa que no funciona.

Bé, és una proposta i jo no hi pinto res o sigui que, per suposat, sentiu-vos lliures d'ignorar-la.

3 Comentari de paurullan a les 10:03 del Sunday 7 Mar de 2010

Crec que si he entès bé el comentari de Paco és que el «factor bus» amb un model així passa a ser de TOTS els membres.

http://en.wikipedia.org/wiki/Bus_factor

4 Comentari de galigan a les 07:03 del Monday 8 Mar de 2010

Iep, antoni, m'has referenciat, gracies :)

Estic molt dacord, amb el que exposes, de fet la meva organització, és molt semblant al model que expliques, però amb la diferència, que nosaltres, no som empresa, però si que tenim local en comú i una marca: tempomedialab.com. D'aquesta manera, quan vem començar, vem creure que cada membre de la comunitat, es pot sentir lliure de participar o no, i és més això pots ser mutable.... Ara tinc més ganes de treballar, aquest projecte el faig, no en tinc tantes, només treballo als matins.

Però jo, no em referia tan a aixo, sinó a la col.laboaració entre entitats d'aquest tipus. Quan parlava de consultores dinosauri, no parlava d'organitzacions de 10 persones. Sinó d'organitzacions de 50-60, 100 o més persones. Consultores, tipus ibm, eds, andersen. Que són capaces d'oferir solucions mastodontiques, que normalment funcionen regular i que amb opensource podrien funcionar molt millor.

Algunes vegades m'he trobat defensant solucions obertes, davant "l'enterprise", he trobat arguments, he cercat idees, però segurament, una millor forma d'aportar confiança, és mostrant que formes part d'una estructura molt més gran, d'una estructura capaç de donar servei a una gran compte.... i fer-ho bé! Però clar, com és pot fer tot això aconseguint que casin els arguments i inquietuds de tots els components?

Segurament passa per generar recursos compartits, que et mostrin cap a fora, que et permetin introduir nous membres de forma facil, que et permetin generar #creant_bits comuns i que sobretot permetin saber que fem, com ho fem, i com ho podem compartir entre les diferents parts. I segurament també, de construir discursos comuns, estratègies comunes i poder presentar i oferir solucions compartides...

@Pau, m'acabo d'adonar que sempre tendeixo a tenir un busfactor d'1 ;) No se segur si es bo o dolent, de tota manera, m'agradaria saber que aquest 1 pot ser substituit de forma facil :^

5 Comentari de aaloy a les 08:03 del Monday 8 Mar de 2010

@pacoros el romanticisme segurament és part fundacional de moltes empreses, potser no totes ho diuen, però sense una visió l'empresa no té sentit, i aquesta visió no pot ser "guanyarem molts diners" i ja està. Quan montes una empresa ho fas per guanyar doblers i guanyar-te la vida, però també perquè creus que pots fer les coses d'una altra manera. El romanticisme crec que és inherent als qui ens dedicam al codi obert, però sense romanticisme i idealisme tot el que s'ha aconseguit avui no hi seria.

L'exercici que proposes pot ser interessant, però s'ha de fer a qualsevol tipus d'empresa, és el control de riscs, els plans de contingència. Davant l'adversitat la meva opinió és que els socis d'una empresa (o integrants d'una mateixa organització) s'han de recolzar, sols així pren vertader sentit l'estructura organitzativa. Això no vol dir no esbrinar perquè s'ha arribat a la situació de crisi o prendre mesures correctives, però el principal per mi és que la col·laboració ha d'anar més enllà d'una simple transacció comercial.

@pau Precisament en un model organitzatiu no basat sols en un interès puntual, el factor bus tendeix a ser menor que un, precisament perquè hi ha plans de contingència i col·laboració entre empreses. Posar-se malalt no implica perdre els projectes.

@galigan Crec que anam en la mateixa línia, però com intentava explicar, per donar aquesta imatge de cohesió i poder seguir mantenint la llibertat que implica el no tenir horaris, s'han d'establir unes regles de joc comuns. S'han de saber en tot moment en qui es pot comptar i amb qui no, quins recursos estan disponibles i saber que davant un projecte gran la gent assumirà les obligacions que li pertoquen. En poques paraules, hi ha d'haver unes regles de joc que tothom ha de conèixer i respectar.

6 Comentari de Xavier a les 09:03 del Monday 8 Mar de 2010

Llegint el teu apunt, pareix com si les empreses que es dediquen a realitzar projectes web no tenguessin professionals o no complissin alguns dels punts que enumeres, una empresa de coneixement ha d'aplicar tots aquests principis independentment de quina sigui la filosofia que hi ha darrera. No veig moltes diferències entre el que tu exposes i el que ha estat la meva empresa o moltes altres que conec dins aquest mon.
Sembla una resposta de polític, perquè contes com fas feina tu i no respons a perquè les petites consultores no som capaços de col·laborar per fer projectes més grans.
Contestant a aquesta qüestió, diré que el problema es que hi ha massa galls al galliner i que col·laborar es preciós sobre el paper però molt complicat a l'hora de la veritat. A més hi ha problemes afegits, un dels millor clients es l'administració pública (o com a mínim un dels que fa més projectes) i tot i que fossin mil profesionals de prestigi plegats no guanyarien un concurs per un gran projecte mai; les grans empreses volen garanties de continuïtat i mil profesionals independents que es posen d'acord, a part d'una utopia (galls-galliner) no semblen una estructura solida a ulls d'un empresari consolidat i menys encara per un director de un departament de una multinacional.
Dit això, crec que hi ha formules de col·laboració que funcionen, però que implique que s'han de prendre riscs. El kernel de Linux, JBoss, Pentaho, OpenERP, ... son exemples de projectes que funcionen i que son col·laboratius. Però no pots esperar que una empresa contracti a un grup heterogeni de professionals sense una trajectòria comuna contrastada i sense garanties de continuïtat, el projecte ha d'estar allà per quan el necessitin i aquí està la vertadera dificultat.
Les persones son el gran repte a les organitzacions modernes, independentment de quin sigui el sistema i ideologia que les sustenta, trobar un equilibri en l'equip i un avantatge competitiu que oferir als nostres clients es l'única forma d'aconseguir fer front a les grans consultores i no es gens fàcil.
Toni, que ofereix APSL als clients que sigui diferencial? Bons profesionals n'hi ha per tot i bones persones (que ho sou) no sol ser res gaire important pels clients. Aquí tens una bona oportunitat de vendré la teva empresa, que se que te bons arguments de venda ;-)

7 Comentari de aaloy a les 10:03 del Monday 8 Mar de 2010

@xavier No m'agrada dir com s'han de fer les coses. Normalment dic com les veig jo i després que cada un sigui lliure d'equivocar-se com vulgui, que jo m'equivocaré a la meva manera :), d'aquí que posi l'exemple d'APSL, per no és contar una cosa teòrica, sinó quelcom que s'està intentant fer en aquests moments.

A part d'això la intenció del post és tocar amb els peus a terra. No sé perquè associacions de professionals poden fallar o no, el que veig són una sèrie de punts que s'han de tenir en compte i que procur tenir en compte jo mateix.

Bons professionals n'hi ha per tot, el problema és arribar a una organització que permeti tenir professionals/empreses organitzats i presentar una sola veu davant l'administració pública. El concepte d'UTE l'administració ho té molt assumit, així que tampoc no veig que sigui estrany que es pugui aplicar a un projecte informàtic. Hi estam poc acostumats, és veritat, però també és per la pròpia immaduresa de la professió, els constructors per exemple ens duen segles d'avantatge en el referent a col·laboració entre empreses. Com a empreses d'informàtica encara crec que hem de trobar el punt, però s'ha de començar d'alguna manera i anar polint les solucions fins a trobar allò que funcioni per a un conjunt d'empreses concretes.

No vull aprofitar el l'apunt per "vendre" APSL, l'estic posant d'exemple perquè és el que conec. El tema dels galls al galliner és bàsicament el problema dels egos a que faig referència a l'apunt. És quelcom que s'ha de tenir en compte i considerar-ho com a factor de risc, però com tot risc s'ha de poder gestionar.

No tenc solucions concretes, ja m'agradaria, el que pos damunt la taula són punts i riscs que s'han de gestionar. Sense conèixer els riscs es fàcil caure en l'eufòria, plantejar-se els problemes i les dificultats és el primer pas per a poder gestionar-los.

8 Comentari de Galigan a les 02:03 del Monday 8 Mar de 2010

Tot el que dieu té sentit, per això és indispensable que qualsevol projecte tingui una o unes cares visibles, que al final és al qui linxaran, si el projecte no arriba a temps o el projecte no és surt com s'esperava, i aquesta cara visible, és també la que en el cas concret (aquest projecte), és la responsable d'ell.

Així les coses són simples i els problemes i solucions amb que et trobes doncs són els normals:

- Algú es penja i no et fa la feina (jo com a responsable del meu projecte), sempre he de tenir algun as a la màniga que em salvi... (en la majoria dels casos sóc jo mateix), potser per això, quasi mai em complico en projectes on (ni que sigui a costa de la meva salut) me'n pugui sortir!

Però tot això és quan ja has aconseguit el projecte. Tot això és quan ja estàs fent feina, tot això és quan ja comparteixes recursos i el que jo trobo dificil, és aconseguir aquests projectes, per això és el que jo demanava, proposava, suggeria... crear algún tipus de garantia, algun tipus d'estructura, de xarxa professional que ens ajudes a competir en tot això. Bé de fet no ho tinc clar del tot, segurament hauria de ser quelcom creuat, on cadascú té la seva identitat, i al mateix temps pertany a una xarxa.... Es ven com a ell, però pertanyent a la xarxa, per a ell és bo, pel client també:

- El client, té la garantia de si el proveïdor es mora ... la xarxa respondrà! El cap de projecte, té la garantia de que si un dels col.laboradors no pot, en podrà trobar un altre que sigui de confiança ... no se si m'explico, no se si soc massa col.lectivista, o si tot plegat és una utopia, però la veritat és que nosaltres, de moment portem tres anys treballant així, i deu mido el que em fet ... (Tot i que el nostre mercat és mes orientat a productes de coumunicació, i no pas tant de tecnologia de la informació... )

I la xarxa li pot oferir moltes coses, trobades, punts de vista, tarifiacions, serveis compartits, professionals. Consultors, experts, forums, promoció, comunicació ... El punt d'unió de tots, doncs el treball amb opensource!

Bé, potser es molt idealista! En fi... m'agradaria que no ho fos!

9 Comentari de aaloy a les 03:03 del Monday 8 Mar de 2010

Crec que s'ha de ser utòpic per començar, realista quan s'hi hi és i caparrut per tirar-ho endavant.

10 Comentari de Paco Ros a les 04:03 del Monday 8 Mar de 2010

Toni, ja va bé que us organitzeu com trobeu millor, però com presentar-se al clients és diferent: estic d'acord amb les apreciacions que t'han fet de que hi ha d'haver una o dues cares visibles. Aquestes solen ser típicament el perfil comercial i el perfil analista i/o cap de projecte.

A tota organització li pot passar que un treballador s'en vagi i no ha de ser gaire diferent a que un soci/membre deixi de treballar amb els altres. L'important és donar garanties.

Resumint: que ningú ha dit que no es pugui donar bon servei amb l'estructura que proposes.

Quant al factor diferencial, la meva apreciació és que APSL ofereix un cicle de vida en espiral i desenvolupament iteratiu. No sé si el client ho sabrà apreciar, però està clar que és un factor.

L'altre és treballar amb programari lliure i apostar per tecnologies com Python. Tampoc sé si el client ho sabrà apreciar.

Jo esper que sí a les dues coses i que funcioni molt bé. :-)

11 Comentari de Xavier a les 09:03 del Tuesday 9 Mar de 2010

En general es un tema espinós lo de la col·laboració en tant en quant es bassa en la confiança entre les persones i en un conjunt de valors compartits, com molt be explica en Toni. Es a dir tot intangible, mal de valorar 'a priori' i subjecte a canvis. Resumint: molt de risc, mal d'avaluar.
També estic d'acord que a la construcció ens duen uns 5000 anys de ventatja ;)
@Paco Per desgracia o no, simplement perquè es així al client com facis la feina no li va ni li ve, es evident que emprar software lliure imprimeix unes caracteristiques al producte, com també ho fa la metodologia que s'emprei per desenvolupar el projecte. Però cara al client l'important es el temps de desenvolupament, el cost, la flexibilitat del programa resultant, l'usabilitat, ... be això si tens un client que n'entén una mica la nostra feina, sinó el que importa es únicament el preu, l'estética i que faci via (talment si fos un cotxe).

12 Comentari de aaloy a les 04:03 del Tuesday 9 Mar de 2010

Python, Django i el desenvolupament iteratiu el que permeten és tenir un client més content: entregues més aviat, controles més el risc i si torbes menys llavors també pots facturar menys, amb la qual cosa pot ser més competitiu que si fas el mateix projecte amb Java.

Com diu @Xavier al client li importarà poc el llenguatge de la solució (llevat que ho tengui que mantenir ell) i sí donarà més valor a cost i plaç d'entrega.

El model iteratiu també agrada, però tot i això la majoria demanen pressupost tancat. El que té, però, és que pots fer un pressupost tancat i després anar refinant el programa. El preu llavors és més aviat una cota superior i les característiques finals es poden anar negociant: s'afegeix una característica a canvi de llevar una que s'ha pressupostat de cost semblant. Al manco així el client potser no tindrà tot el que voldria però segurament sí tot el que necessita.

Avís: Els comentaris es tanquen automàticament als 30 dies