Inicio

Sobre externalizar tu desarrollo si eres una Startup

Hace unos días Joel Gascoigne, cofundador de la herramienta SaaS para social media Buffer, escribió en su blog** tres razones para no subcontratar el desarrollo de tu startup en freelances o agencias de desarrollo**.

Me parece un tema interesante, sobre todo para contar mi opinión trabajando con clientes que son startups en Simettric.

Las tres razones que exponía son las siguientes

1. “Los objetivos de un freelance y los de una startup están completamente desalineados.”

No puedo quitarle la razón si generalizamos, pero el problema es precisamente este, el generalizar.

En el artículo se hace referencia al concepto de “scope-creep” que se da cuando un proveedor se compromete a tener un desarrollo por una cantidad fija de dinero. A menudo el “contrato” del desarrollo son los requisitos funcionales presupuestados y cuando estos cambian, que es lo más normal cuando trabajas con startup, el desarrollador pueda ponerse a la defensiva y evite el cambio para no perder rentabilidad.

Esto es un error que se comete mucho por parte del proveedor o incluso viene impuesto por algunos clientes. Sin hacer una labor de producto previa se estima un presupuesto y un tiempo fijo para desarrollar funcionalidades en lugar de soluciones a problemas del producto.

Trabajando de este modo es muy fácil no satisfacer las expectativas del cliente y entregar un producto de software que incluso no solucione las cosas a nivel de negocio.

Pero… ¿esto se evita teniendo desarrolladores contratados? La respuesta es no. De hecho el problema no está en quién haga el desarrollo, sino en el pensar que el desarrollo es la solución a todos los problemas y que al delegarlo, puedes desentenderte de la labor de analizar lo que quieres solucionar.

Existe un paso previo al proceso de desarrollar un software y es saber por qué quieres desarrollar la solución del problema y cómo lo vas a resolver en base a los recursos que tienes. Puede que ciertos problemas no requieran tanto o incluso ninguna inversión en desarrollo y en su lugar hacer esfuerzos en otras partes como textos, diseño o soporte humano.

En Simettric no empezamos un desarrollo ni damos un precio cerrado hasta haber realizado un estudio del producto o servicio previamente. Sin esa labor es imposible cumplir con las expectativas del cliente y el proyecto no va a ir bien para ninguna de las partes involucradas.

No somos los únicos y creo que cada vez más agencias y profesionales están evolucionando hacia este punto en lugar de dar un precio fijo en base a unos requisitos vagos en detalle.

Pero no puedo decir que esto sea lo habitual. Desde hace tiempo cada vez se ven más empresas con un proyecto al que no sólo le falta funcionalidad o que pueda tener errores, sino que la funcionalidad planteada no sigue un sentido coherente con el problema que intenta resolver.

En estos casos se da que se ha intentado hacer demasiado en programación pero no se ha seguido evolucionando el diseño, comunicación y en general experiencia de usuario en coherencia, por lo que el producto siempre da la sensación de no estar acabado.

En otros casos, quizás los más habituales, el proveedor se ha salido del proyecto y necesitan alguien que lo continúe. Algunos de estos casos son dramáticos ya que el cliente ha invertido todo el dinero que tenía, incluso su casa y ha vendido su coche, para descubrir finalmente que el desarrollo no resuelva el problema o tenga demasiada deuda técnica.

Pero este caso también se da si contratas equipo interno y de hecho puede incluso ser más dramático dependiendo de cómo lo hagas.

Sin entrar en lo difícil que es retener a un desarrollador senior en una empresa en España y el sueldo que ese perfil esté dispuesto a cobrar, de no disponer de una persona que piense bien el producto y alguien que gestione el equipo de desarrollo cubriendo las necesidades técnicas de la empresa también, las cosas pueden salirse de madre muy fácilmente.

No pretendo dar a entender que externalizar es siempre la mejor opción, ni mucho menos, pero no creo que defender una fórmula u otra como si vendieses una bala de plata sea correcto.

De hecho hay casos en los que el desarrollo tiene cierta complejidad más allá de consultar a bases de datos o APIs REST, con algoritmos y know-how que el cliente pueda perder si no lo tiene en “casa”. En estos casos sí que veo importante el no sacar el desarrollo fuera.

Pero aún así** hay fórmulas intermedias.** Muchas veces puedes externalizar una parte o un primer producto muy acotado para probar si realmente funciona en el mercado, antes de contratar o hacer inversiones más potentes. Puedes pactar en que el proveedor imparta formación a tu futuro equipo de desarrollo, es algo que en Simettric hacemos e incluso acompañamos en algunos casos al equipo hasta que pueden desligarse del trabajo que hemos hecho.

2. “Te hace pensar de forma equivocada sobre lo que cuesta sacar un producto adelante.”

Esta idea la comparto totalmente, pero creo que también se aplica al ser cauto a la hora contratar un equipo de desarrollo desde el primer minuto.

El pensar en utilizar algo ya hecho, o incluso no utilizar software en absoluto para validar tu idea de negocio es algo que más que aconsejable, es lo que debería hacerse siempre que sea viable. Hay casos en España como el conocido de Carlos Sanchez, al que he hecho referencia alguna que otra vez por aquí.

De hecho creo que lo ideal es que nuestra labor, la de agencias y freelances, debería venir tras esa validación previa y siempre pensando en añadir soluciones con el mínimo desarrollo que aporte el máximo beneficio en mercado.

No nos interesa desarrollar funcionalidad por que sí, haciendo que el proyecto se alargue indefinidamente y que nunca llegue a salir al mercado, quemándonos y quemando al cliente. Salir al mercado cuanto antes de hecho es algo muy beneficioso para nosotros, se cierran etapas, se detectan necesidades reales que aportan beneficio al cliente y este cuenta con más recursos para invertir en desarrollo.

Llegará el momento en el que ya no nos necesite, pero eso también está genial. Nuestro negocio no puede basarse en depender de un único cliente al igual que dicho cliente no debe depender de nosotros. De darse este hecho, no puede ser una relación sana desde mi punto de vista.

3. “Cada fundador debe llevar cada uno de los sombreros (roles).”

Esta forma de pensar creo que depende más del tipo de servicio que ofrezcas y la filosofía de la empresa que del cómo ejecutes el desarrollo junto al resto de tareas en la empresa.

A las personas con perfil técnico nos gusta trabajar con personas de perfil técnico y aunque en algunos casos está muy justificado, hay muchos tipos de negocio en los que el punto de vista tecnológico no es lo más clave, a pesar de ser importante.

De nuevo, no creo que deba aconsejarse que todo el equipo fundador deba saber y encargarse de programar sin ver de qué tipo de negocio estamos hablando.

Lo que personalmente sí que veo importante es que el equipo fundador tenga experiencia previa creando proyectos de este tipo y sepa la importancia de pensar las cosas bien antes de afrontar una inversión de desarrollo apostando por la fórmula que sea.