Com triar un soci de consultoria IT: què preguntar, què evitar i com és realment una bona col·laboració
Quins criteris importen, quines preguntes cal fer, quins senyals d'alerta cal vigilar i com estructurar un compromís de consultoria IT.
Triar el soci tecnològic equivocat és un dels errors més cars que pot cometre una empresa. No perquè la tarifa per hora sigui alta, sinó perquè el cost d'un projecte fallit —en temps perdut, inversió malbaratada i deute tècnic que triga anys a desfer-se— supera amb escreix el cost de fer-ho bé a la primera. Descobreix més sobre 5 maneres senzilles de fer que el teu negoci sigui més visible.
Aquesta guia està escrita des de l'altra banda d'aquesta conversa. Hem estat el soci que ha heretat sistemes trencats construïts per l'empresa equivocada, i hem estat el soci que ho ha fet bé a la primera. Els patrons són constants. Això és el que realment importa a l'hora de triar un soci tecnològic. Coneix més sobre la fase d'aprenentatge del màrqueting.
La pregunta correcta no és «Qui és el més barat?»
La majoria d'empreses aborden la selecció d'un soci tecnològic com si compressin un producte bàsic. Per a més informació, consulta com trobar un soci qualificat. Demanen tres pressupostos, comparen les xifres i trien el del mig. És una manera fiable d'obtenir resultats mediocres.
La pregunta correcta és: en qui confio per resoldre aquest problema concret, i té les proves que ho avalen?
Les proves són projectes reals d'abast i complexitat semblants. Són referències de clients que realment s'asseuran a una trucada per explicar-te com va ser treballar amb l'empresa. Són portfolis que mostren la presa de decisions tècniques, no només captures de pantalla boniques.
L'empresa més barata ho és per alguna raó. Sovint, la raó és que et dirà que sí a tot, construirà exactament el que especifiquis i t'ho lliurarà quan no funcioni com esperaves, perquè no sabies què havies d'especificar.
Què significa realment la profunditat tècnica
Els projectes tecnològics fallen sobretot a les fronteres: allà on un sistema es troba amb un altre, on la seguretat es troba amb la usabilitat, on el rendiment es troba amb el cost. Són els llocs on un especialista d'abast estret et tornarà el problema.
Un soci tecnològic amb qui val la pena treballar cobreix tot el stack: disseny d'aplicacions, infraestructura, seguretat, rendiment, dades i integració. No perquè tots els projectes ho necessitin tot, sinó perquè un soci que entén tot això prendrà millors decisions en cadascuna de les capes.
Pregunta a qualsevol empresa que estiguis avaluant: qui s'encarrega de la seguretat? Si la resposta és «per a això incorporem un especialista», tens davant una empresa que tracta la seguretat com un afegit. Pregunta: qui s'encarrega de la infraestructura? Si la resposta és «nosaltres construïm l'aplicació i la lliurem al vostre equip perquè la desplegui», tens davant una empresa que et deixarà un problema de desplegament.
Els millors socis no tenen aquests traspassos perquè no els necessiten.
Com llegir un portfolio
Un portfolio t'explica què ha construït una empresa. El que realment necessites saber és com construeix i què passa quan alguna cosa surt malament.
Fixa't en:
- La varietat de tipus de problemes. No només aplicacions web, o només eines d'IA, o només comerç electrònic. Una empresa que ha resolt problemes de naturalesa diversa ha acumulat un reconeixement de patrons que als especialistes d'abast estret els falta.
- Els resultats quantificats. «Vam construir un lloc web per a una empresa sanitària» no t'explica res. «Vam reduir el temps de càrrega de pàgina un 60%, cosa que va augmentar les reserves de cites de pacients un 23%» t'indica que mesuren allò que importa.
- Els projectes que van canviar d'abast. Tot projecte real troba una complexitat inesperada. La manera com una empresa gestiona els canvis d'abast —amb transparència o amb evasives— t'explica com és treballar-hi sota pressió.
El que un portfolio gairebé mai no t'explica és com va ser realment la relació amb el client. Per això les referències importen més que els portfolis.
La trucada de referència és el pas més important
La majoria d'empreses demanen referències i després no hi truquen, o hi truquen i fan preguntes que produeixen respostes inútils («Van ser professionals?» «Sí.» «Els recomanaríeu?» «Sí.»).
Les preguntes que donen respostes útils:
«Què va anar malament i com ho van gestionar?» Tots els projectes tenen problemes. Una referència que diu que no va anar res malament menteix o descriu un projecte trivialment senzill. El que vols sentir és: «Hi va haver un problema amb X, ens ho van dir immediatament, i això és el que van fer per solucionar-ho».
«Es van oposar a les vostres decisions? Poseu-me un exemple.» Una empresa que està d'acord amb tot és una empresa que construirà la cosa equivocada si l'encamines cap a la direcció equivocada. Vols un soci que et digui quan t'equivoques.
«Qui va treballar realment en el vostre projecte? Eren les mateixes persones que van fer la presentació?» El clàssic ham i ou: els socis sèniors venen el projecte i els col·laboradors júniors el lliuren. Esbrina si l'equip que has conegut és l'equip que tindràs.
«Què faríeu de manera diferent si els tornéssiu a contractar?» La resposta a aquesta pregunta és el més valuós que sentiràs.
La descoberta: la fase que ho prediu tot
El factor que millor prediu l'èxit d'un projecte és la qualitat de la fase de descoberta: el treball que es fa abans d'escriure una sola línia de codi per entendre què necessites realment, per què ho necessites i com construir-ho correctament.
Una empresa que vol començar a construir de seguida és una empresa que construirà la cosa equivocada amb rapidesa. Una empresa que dedica temps a entendre el teu negoci, els teus usuaris, els teus sistemes existents i les teves limitacions abans de proposar una solució és una empresa que construirà la cosa correcta.
Com és una bona descoberta:
- Entrevistes amb les persones que realment faran servir el sistema, no només amb qui l'encarrega
- Disseny de l'arquitectura abans del disseny de la implementació
- Documentació escrita del que es construirà, del que no es construirà i del que passa quan apareixen casos límit
- Definició explícita de «fet»: no «construirem un tauler de control», sinó «construirem un tauler de control que mostri les mètriques X, Y i Z, es carregui en menys de 2 segons i no requereixi cap entrada manual de dades»
Si una empresa se salta la descoberta o la tracta com un tràmit, el projecte s'excedirà en temps, en pressupost o en tots dos.
La seguretat no és una funcionalitat: és el fonament
El 2026, les bretxes de dades i les sancions reglamentàries no són riscos hipotètics. Segons l'article 83 del RGPD, les infraccions més greus poden comportar multes de fins a 20 milions d'euros o el 4% del volum de negoci anual mundial total, la quantitat que sigui més alta. Un sistema insegur és una responsabilitat que acompanya el teu negoci durant anys.
Pregunta a qualsevol empresa que estiguis avaluant: «Com encaixa la seguretat en el vostre procés?» La resposta et diu a l'instant si la tracten com un fonament o com una funcionalitat.
Com és una bona resposta:
- Les bones pràctiques de l'OWASP se segueixen com a estàndard, no com a opció
- El compliment del RGPD i de la CCPA es considera des de la fase d'arquitectura, no s'afegeix al final
- Autenticació, autorització i xifratge de dades integrats des del primer dia
- Auditories periòdiques de dependències i processos d'actualització
- Documentació clara sobre el tractament de dades: quines dades s'emmagatzemen, on i qui hi té accés
Com és una mala resposta: «Farem una revisió de seguretat abans del llançament». La seguretat revisada al final és seguretat que fallarà. Les decisions que determinen si un sistema és segur es prenen la primera setmana d'arquitectura, no l'última setmana de proves.
Models de col·laboració: triar l'estructura adequada
La manera d'estructurar la col·laboració importa gairebé tant com la teva elecció de soci. Els tres models principals tenen casos d'ús clars.
Per projecte. Abast fix, calendari fix, preu fix. Funciona millor per a problemes ben definits amb requisits estables: un lloc web nou, una integració concreta, una automatització definida. Requereix una descoberta excel·lent des del principi. Riscos: l'ampliació de l'abast si els requisits no queden tancats, i una flexibilitat reduïda si el problema evoluciona.
Igualà. Assignació mensual d'hores o de capacitat. Funciona millor per al desenvolupament continuat, la iteració de producte i la millora contínua, on les prioritats canvien sovint. Requereix confiança i una comunicació constant. Riscos: pot perdre el focus si no hi ha objectius trimestrals clars.
Extensió d'equip. Els enginyers del soci treballen com a membres integrats del teu equip. Funciona millor per a organitzacions amb una direcció de producte interna sòlida que necessiten capacitat tècnica addicional. Requereix que el teu equip els gestioni amb eficàcia. Riscos: exigeix una càrrega de gestió interna.
La majoria de relacions comencen amb un projecte i evolucionen cap a una igualà a mesura que s'estableix la confiança. L'estructura pitjor és un projecte gran i obert, sense lliurables definits i sense clàusules de sortida.
La conversa sobre preus
La consultoria tecnològica té una gran variació de preus perquè cobreix un ventall enorme de nivells de capacitat. Un desenvolupador autònom que construeix un tema de Shopify i un equip sènior que dissenya l'arquitectura d'una plataforma de dades sanitàries són tots dos «consultoria IT», però no són comparables.
Com se solen estructurar els preus (les tarifes varien segons el proveïdor, la regió i l'abast, per això convé comprovar pressupostos actuals):
- Consultor independent, nivell sènior: normalment una tarifa per jornada
- Agència, enginyers sèniors: normalment una tarifa per jornada
- Desenvolupament concret (un flux de treball, una integració): sovint un preu de projecte tancat
- Plataforma de complexitat mitjana (autenticació, base de dades, integracions, interfície): un pressupost de projecte més gran
- Plataforma a escala empresarial: els pressupostos més grans
- Igualà mensual, desenvolupament continuat: una quota mensual recurrent
Les preguntes que importen més que la tarifa:
- Com gestioneu els canvis d'abast? (Per hores? Ordres de canvi fixes?)
- Què està inclòs i què es factura a part? (Suport, correcció d'errors, documentació?)
- Qui assumeix els sobrecostos si l'estimació era errònia?
Un soci que et dona un preu fix i després et cobra cada petit canvi és més car que un altre la tarifa per jornada del qual sembla més alta. Aconsegueix les condicions comercials per escrit abans de començar.
Senyals d'alerta per marxar-ne
Aquests són els patrons que prediuen de manera fiable un mal resultat:
Estan d'acord amb tot. Un soci que no té cap opinió sobre el teu enfocament no té prou experiència per portar-te la contrària. Obtindràs el que has demanat, no el que necessitaves.
Propostes vagues. «Construirem una plataforma que integri els vostres sistemes» no és una proposta. Una proposta especifica què es construirà, què no es construirà, com es provarà i com és el «fet».
Un equip júnior amagat darrere de presentadors sèniors. Pregunta-ho de manera explícita: «Qui treballarà en aquest projecte dia a dia?» Si el soci sènior no sap dir noms concrets, les persones que has conegut no seran les que tindràs.
Cap menció a la seguretat o al compliment normatiu. Si el RGPD, el tractament de dades o la seguretat no sorgeixen en la primera conversa, no estan integrats en el procés de l'empresa.
Contractes d'aferrament sense sortida. Una empresa segura del seu treball no necessita lligar-te durant 18 mesos. Exigeix clàusules de sortida clares i disposicions de portabilitat de dades des del principi.
No saben explicar les decisions tècniques amb claredat. Si una empresa no pot explicar per què ha triat una arquitectura determinada amb un llenguatge que puguis entendre, o bé no sap per què l'ha triada o bé no et respecta prou per explicar-t'ho. Cap de les dues coses és acceptable.
Com és realment una bona col·laboració
Després de 20 anys construint tecnologia, les característiques de les millors relacions de treball són constants:
Et donen les males notícies aviat. Quan alguna cosa va malament —i sempre hi ha alguna cosa que va malament—, un bon soci t'ho diu immediatament, t'explica què ha passat i et presenta un pla per solucionar-ho. Un mal soci amaga els problemes fins que es converteixen en crisis.
Tracten el teu pressupost com la seva limitació. Un bon soci optimitza per al resultat que necessites amb el pressupost que tens. Un mal soci construeix segons l'abast que prefereix i després et diu que el pressupost no n'hi havia prou.
La seva estimació s'acosta al resultat. No és idèntica —els projectes reals troben una complexitat inesperada—, però un soci que acaba sistemàticament al doble de la seva estimació té un problema d'estimació o un problema de comunicació, i tots dos et costaran diners.
Es preocupen pel que passa després del llançament. La veritable prova d'un soci tecnològic és què passa sis mesos després de la posada en marxa: quan hi ha un pic de trànsit, quan apareix el cas límit, quan canvia el requisit de negoci. Un bon soci continua present. Un proveïdor ja ha passat a una altra cosa.
Com fer-ho bé
Si estàs començant una cerca de soci tecnològic, el procés és senzill:
-
Defineix el problema amb precisió abans de parlar amb ningú. No «necessitem un lloc web millor», sinó «necessitem un lloc web que converteixi un 15% més de consultes entrants en trucades de descoberta, que tingui un temps de càrrega inferior a 2 segons en mòbil i que s'integri amb el nostre CRM».
-
Parla amb tres empreses com a mínim. No per obtenir tres pressupostos, sinó per entendre tres enfocaments diferents del teu problema. L'empresa que fa més preguntes abans de proposar sol ser la millor.
-
Truca a les referències. Truca-hi de debò. Fes-los les preguntes difícils que s'han enumerat més amunt.
-
Fes primer un sprint de descoberta. Abans de comprometre't amb un projecte complet, encarrega una fase de descoberta. Una fase de descoberta de pagament t'explica exactament què obtindràs, obliga l'empresa a entendre bé el teu problema i et dona una base per a una proposta de preu tancat que sigui realment precisa.
-
Posa les condicions comercials per escrit. L'abast, el calendari, les fites de pagament, què passa si l'abast canvia, de qui és la propietat intel·lectual i com se surt de la relació si no funciona.
Des del 2004 hem construït tecnologia per a empreses del comerç minorista, la salut, el sector immobiliari, la immigració i els serveis professionals. Els projectes que van bé s'assemblen tots: definició clara del problema, descoberta exhaustiva, comunicació regular i un soci que et diu la veritat. Els que no van bé també s'assemblen tots. Tria en conseqüència. Consulta com estructurem els nostres compromisos de consultoria IT si vols entendre l'enfocament abans de comprometre't.
Lectura relacionada:
Preguntes freqüents
- Com trio una empresa de consultoria IT?
- Avalua cinc aspectes: la profunditat tècnica (poden cobrir tot el teu stack, no només una capa?), el historial de lliurament (projectes reals, no només credencials), l'estil de comunicació (expliquen les coses amb claredat i sense jerga?), les pràctiques de seguretat (el RGPD, l'OWASP i el tractament de dades estan integrats des del principi?) i la flexibilitat del compromís (poden treballar com a soci de projecte, amb una igualà o com a extensió del teu equip segons les teves necessitats?). Demana referències d'empreses de mida similar i de sectors similars. El soci adequat qüestionarà les males idees, no es limitarà a dir que sí.
- Quina diferència hi ha entre un consultor IT i una agència de desenvolupament de software?
- Un consultor IT t'assessora sobre estratègia, arquitectura i enfocament: t'ajuda a decidir què construir i com fer-ho. Una agència de desenvolupament de software executa la construcció. A la pràctica, els millors socis tecnològics fan les dues coses: t'ajuden a pensar l'enfocament adequat i ho construeixen. Si una empresa només escriu codi sense qüestionar l'estratègia, és un proveïdor. Si només assessora sense saber construir, és un consultor. Busca socis que facin bé les dues coses.
- Quant hauria de costar la consultoria IT?
- Les tarifes de la consultoria IT varien molt segons la regió, l'experiència, l'especialització i la complexitat del projecte, de manera que convé comparar pressupostos actuals de diversos proveïdors. Els consultors independents i les agències solen cobrar per jornada, els desenvolupaments concrets se solen pressupostar com a projectes tancats i el suport continuat sol ser una igualà mensual. La pregunta clau no és el cost per dia, sinó el cost per resultat: una empresa més barata que triga el doble o que lliura un treball que cal refer acaba sent més cara en conjunt.
- Quines preguntes he de fer a una empresa de consultoria IT abans de contractar-la?
- Pregunta: Qui treballarà realment en el meu projecte (no qui presenta, sinó qui programa)? Em podeu ensenyar un projecte semblant al meu? Com gestioneu la seguretat i la privacitat de les dades? Què passa si el projecte se surt de l'abast? Com us comuniqueu durant un projecte: amb quina freqüència i en quin format? Quin és el vostre procés de descoberta abans de començar? Què feu quan no esteu d'acord amb la direcció que pren un client? Les respostes et diran més que qualsevol proposta.
- Quins són els senyals d'alerta en triar una empresa de consultoria IT?
- Vigila això: propostes vagues sense abast ni calendari definits, reticència a facilitar referències de clients, incapacitat per explicar les decisions tècniques amb un llenguatge planer, cap menció a la seguretat o al compliment normatiu en la primera conversa, membres júnior amagats darrere de presentadors sèniors, contractes d'aferrament sense clàusules de sortida i empreses que hi estan d'acord en tot el que dius sense qüestionar els supòsits. Un bon soci desafia la teva manera de pensar. Un de dolent només es queda els teus diners.
- He de triar una empresa de consultoria IT local o de fora (offshore)?
- Les dues opcions poden funcionar, depenent del que construeixis i de com us comuniqueu. Les empreses locals o de proximitat (nearshore, al mateix fus horari o a un de proper) tenen una càrrega de coordinació menor i vies d'escalada més àgils. Les empreses offshore sovint poden reduir costos, però exigeixen una gestió de projecte sòlida, especificacions clares i acceptar certa fricció horària. Per a projectes complexos i canviants, on els requisits varien sovint, la proximitat importa més. Per a desenvolupaments ben definits amb especificacions estables, l'offshore pot funcionar bé. El pitjor resultat és triar l'offshore per estalviar i gastar-ho tot en costos de coordinació i retreballs.
Vols parlar-ne pel teu negoci?
Explica'ns què necessites. Et direm què és possible.
Iniciar un projecte