Cando subcontratar e cando dicir “isto non o facemos”

Hai 5 anos, un cliente pediunos unha app móbil nativa. Nunca fixeramos ningunha. Pero pensamos: “Tan difícil pode ser? Contratamos a alguén que saiba, aprendemos sobre a marcha e ampliamos a nosa oferta”.

Ao cabo de 6 meses perderamos cartos, o cliente estaba frustrado e a relación nunca se recuperou.

Aprendemos 2 leccións duras:

1. Non é o mesmo contratar a alguén que sabe e delegar nel que contratar a alguén para que che ensine mentres cobras coma se xa soubeses.
2. Dicir “non” a tempo sae máis barato que dicir “si” a destempo.

Desde entón temos unha regra clara para decidir que facemos internamente, que subcontratamos e que rexeitamos. Aforrounos proxectos fallidos e permitiunos crecer sen perder calidade.

O triángulo da decisión: facer, subcontratar ou rexeitar

Cada proxecto, ou cada parte dun proxecto, entra nunha destas 3 categorías:

• Facémolo nós: é o noso core. Dominámolo e achegamos valor real.
• Subcontratámolo: sabemos avalialo e coordinalo, pero non é a nosa especialidade; ou si o é, pero agora mesmo non temos capacidade.
• Rexeitámolo: está fóra da nosa experiencia ou hai un conflito de intereses.

A trampa máis común está na zona gris entre subcontratar e rexeitar: aceptar proxectos para os que non temos a estrutura axeitada e confiar en que xa o resolveremos polo camiño.

Cando facelo internamente

Só facemos dentro o que de verdade sabemos facer mellor ca a maioría. Para iso teñen que cumprirse 4 condicións:

É a nosa especialidade principal. No noso caso: WordPress e Elementor, WooCommerce, Laravel e automatizacións con Python.

Podemos manter a calidade sen sacrificar outros proxectos. Se un proxecto encaixa coas nosas habilidades pero non coa nosa capacidade, reforzamos o equipo de forma temporal ou rexeitámolo. Non sacrificamos calidade por volume.

A rendibilidade é razoable. Algúns proxectos que tecnicamente podemos facer non teñen marxe dabondo para seren viables. Un proxecto complexo cun orzamento axustado é peor negocio ca un sinxelo con boa marxe.

O cliente valora a nosa especialización. Se o cliente puidese contratar a calquera sen notar a diferenza, estariamos competindo só en prezo. Preferimos proxectos nos que a nosa experiencia concreta achega un valor tanxible.

Cando subcontratar

Subcontratamos en 3 situacións:

1. Picos de capacidade. Temos máis traballo do que podemos executar, pero a demanda é puntual. Recorremos a freelancers ou a axencias partner que xa coñecemos. Non improvisamos con descoñecidos.

2. Especialidades adxacentes. O proxecto principal é o noso core, pero inclúe pezas que non dominamos. Por exemplo, unha tenda WooCommerce (o noso) que necesita fotografía de produto profesional (non o noso). Subcontratamos esa parte e coordinámola nós.

3. Necesidades técnicas por fases. Algúns proxectos necesitan, nun momento concreto, máis do que podemos cubrir. Por exemplo, unha migración masiva de datos que require un perfil de sistemas (devops) durante unhas semanas. É algo temporal, non estrutural.

A regra de ouro da subcontratación: nós mantemos a relación co cliente e a responsabilidade do resultado. Non somos un intermediario que reenvía correos. Somos o partner principal e respondemos de todo o que entregamos.

Cando dicir “isto non o facemos”

Rexeitamos proxectos en 4 situacións:

1. Está fóra da nosa especialidade. Apps móbiles nativas, desenvolvemento de hardware ou proxectos de ciberseguridade moi específicos, como auditorías de intrusión formais. Poderiamos aprender, pero o cliente non debería pagar a nosa curva de aprendizaxe.

2. Hai conflito de intereses. Por exemplo, cando nos piden traballar para un competidor directo dun cliente actual, ou cando o máis sensato para o cliente sería unha ferramenta SaaS que fai innecesario un desenvolvemento a medida. Neses casos non podemos ser imparciais, así que o dicimos e, se cómpre, apartámonos.

3. Non podemos manter o que entregamos. Desenvolver é a metade do traballo. Se non podemos ofrecer un mantemento de calidade a longo prazo, o proxecto acabará fallando. Mellor non empezar.

4. O orzamento non chega para facelo ben. Hai proxectos que só son viables se se fan mal. Eses non os facemos.

Como subcontratar sen perder calidade nin a relación

Cando subcontratamos, seguimos regras estritas:

Só con partners que xa coñecemos. Recomendados, probados e de confianza. Non experimentamos cos cartos do cliente.

Contratos claros. O subcontratista asina un acordo de confidencialidade e un contrato que define alcance, calidade esperada, prazos e responsabilidades. Non deixamos nada á interpretación. Son as mesmas cláusulas técnicas que debería incluír calquera contrato de desenvolvemento.

Supervisión activa. Revisamos o traballo do subcontratista antes de que chegue ao cliente. A responsabilidade final é nosa.

Transparencia co cliente. Se unha parte relevante do proxecto a fai un partner, o cliente sábeo desde a proposta. Non fai falta detallar cada tarefa menor, pero nunca o ocultamos.

Marxe axeitada. Subcontratar ten custos de coordinación e risco. A nosa marxe sobre o custo do subcontratista cobre iso. Non pretendemos gañar o mesmo que se o fixésemos nós, pero tampouco traballar de balde xestionando a terceiros.

A trampa do “podemos aprender”

A tentación de aceptar proxectos para aprender unha tecnoloxía nova é forte, sobre todo cando parecen interesantes ou rendibles. Aprendemos a resistila.

Aprender sobre a marcha cos cartos dun cliente é eticamente cuestionable. O cliente non paga para ser o teu laboratorio. Se queres ampliar capacidades, inviste en formación interna, en prototipos propios ou en proxectos piloto con desconto nos que o cliente sabe que se trata de algo experimental.

O que si facemos é ampliar o noso core aos poucos. Hai anos non faciamos automatizacións con Python. Empezamos con proxectos internos, despois con clientes que sabían que estabamos a desenvolver esa área, e hoxe é unha especialidade consolidada. Foi un proceso controlado, non improvisación con proxectos reais.

Como comunicar “non o facemos” de forma profesional

Rexeitar un proxecto non é rexeitar o cliente. De feito, un “non” ben comunicado pode reforzar a relación. Unha resposta tipo:

“Este proxecto concreto non encaixa coa nosa especialidade porque [razón concreta]. Para isto recomendaríache falar con [contacto alternativo, se o temos]. Sigamos en contacto para futuros proxectos que si encaixen co que facemos ben”.

Esa mensaxe explica o porqué, ofrece unha alternativa e deixa a porta aberta. O cliente agradece a honestidade e a orientación, e é habitual que volva con outro proxecto precisamente porque non aceptaches este. Contámolo con máis detalle en como dicir “non” a un proxecto (e que o cliente cho agradeza).

O caso especial: white-label

O traballo white-label é un híbrido interesante. Outras axencias contrátannos para executar proxectos que presentan como propios. Tecnicamente é subcontratación, pero cunha dinámica distinta:

• A relación co cliente final é da outra axencia.
• Eles definen o alcance.
• Nós centrámonos na execución técnica.
• A marxe é menor, pero o volume pode compensala.

O white-label funciona cando a outra axencia sabe o que quere e necesita execución. Falla cando espera que fagamos o traballo de consultoría que lle corresponde a ela.

Por iso filtramos moito e só aceptamos proxectos ben definidos. Antes de empezar, pedimos un brief pechado e acordamos quen responde a que cando o cliente final pide cambios.

Preguntas frecuentes

Non é mellor dicir que o facemos todo e logo subcontratar?

É unha estratexia común e perigosa. O cliente contrátate pola especialización que prometes. Se despois descobre que esa parte a fai outro, a confianza rompe. Preferimos ser claros desde o principio.

Como atopas bos subcontratistas?

Por referencias e relacións previas. Case todos os nosos partners veñen de coincidir nalgún proxecto ou de recomendacións de xente de confianza. Antes de delegar algo crítico, empezamos cun encargo pequeno e vemos como traballan: prazos, comunicación, calidade do código e como reaccionan cando algo sae mal.

Que pasa se un subcontratista falla?

Respondemos ante o cliente. Resolvémolo con outro partner, facémolo nós ou renegociamos. Ese risco forma parte do que cobramos.

Debería medrar o equipo interno en lugar de subcontratar?

Depende de se a demanda é estrutural ou puntual. Se necesitas de forma constante máis capacidade en algo concreto, contrata. Se é un pico puntual ou unha especialidade que usas de cando en vez, subcontrata. Vimos axencias meterse en serios problemas por contratar persoal para unha demanda temporal. Afondamos neste criterio en cando externalizar e cando contratar.

Conclusión

Saber que fas, que subcontratas e que rexeitas é definir quen es. Intentar selo todo para todos é a receita da mediocridade.

Nós somos bos en desenvolvemento web, comercio electrónico e automatizacións. Para o demais, temos partners ou dicimos que non.

Esa claridade permítenos facer ben o que facemos e manter clientes que saben que agardar.

En Baqueiro traballamos como partner tecnolóxico white-label para axencias que queren ampliar a súa oferta sen improvisar. Se estás a redefinir os límites da túa axencia ou necesitas un partner para o que non é o teu core, falemos.