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.

Imagen por John Kraus

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.

5 comentarios en “Sobre externalizar tu desarrollo si eres una Startup”

  1. Buenos argumentos.

    Una opción a lo del precio fijo lo vi en una empresa que te vende una bolsa de horas. Me gusto la idea por que se adecua bastante a llevar un proyecto de manera a lo scrum.
    El cliente prioriza y vamos ejecutando. Seria una opcion cuando el cliente no para de pedir y no sale nunca a mercado.

    Por otro lado lo de Carlos Sanchez esta muy bien sobre el papel pero el proyecto no tiro lineas de codigo pero si tuvo que instalar wordpress y adecuarlo más la tarea mas costosa de conseguir leads mediante SEO,redes sociales donde Txarly es un experimentado.
    Si no eres Txarly tendras que contratar a un Txarly para tu proyecto.

    1. Buenas Antonio,

      Aun con la bolsa de horas, que es similar a presupuestar por sprint pero sin tener en cuenta la disponibilidad entiendo, la clave es lo que comentas, el priorizar. Pero antes de priorizar, hay que tener el mapa completo.

      Me gusta mucho la técnica de User Story Mapping para definir ese mapa, entre todos. El problema es que hay que encontrar el escenario en el que plantear esta técnica.
      Por suerte, en el cliente tipo startup debería ser algo fácil el aplicarlo.

      Sobre la experiencia de Carlos, el punto interesante es que para validar ese negocio pudo quitarse la inversión de un desarrollo a medida, ya que con el tipo de proyecto cuadraba.

      Aun así, hay proyectos de otro tipo en los que “estaría bien” automatizar ciertos procesos que de entrada parece obvios tenerlos desarrollados pero conlleva un coste el hacerlo.
      Si la gestión no te bloquea, igual esos procesos se pueden hacer de forma manual por el momento y reducir coste en eso, invirtiéndolo en otras áreas como diseño o copy.

      Saludos!

  2. Bueno, el punto 1 la verdad es que tiene su miga. Yo compito en otra liga y mis clientes son los pobres que esperan un facebook por 2k€, asi que la mayoria de cosas que has explicado me suenan a ciencia ficción :P
    No tengo clientes que piensen tan siquiera en un “precio abierto”, aka llamado “ir cobrando por horas hasta que se termine”.

    La mayoria de clientes quieren un precio cerrado y eso hace que luego a la hora de trabajar los devs nos mostremos cerrados e inflexibles ante los cambios que surgiran. Porque al fin y al cabo me has pedido X, con Y, si tu ahora quieres Z tendras que pagarlo, o yo no movere un dedo.
    Eso crea fricción y automaticamente eres el malo de la pelicula en la mayoria de casos, pues la empresa espera que seas flexible y pierdas dinero a costa de añadir esos detalles que no pensamos cuando hicimos el contrato.

    Yo personalmente le digo a cualquier cliente que con precio cerrado nos ceñiremos a lo pactado en el contrato y que no cambiare ni una sola coma sin previa aprobacion de un presupuesto nuevo. Muchos se molestan y se buscan a otro que sea capaz de ser “flexible”, aka llamado el heroe que traga con todo, y algunos (pocos) se quedan porque ven seriedad al mostrarte inflexible.

    Dicen que solo hay una “verdad absoluta”, el core de tu negocio lo deberias crear tu (tu empresa claro está), y el resto de tareas externalizarlas a quien sea, freelance, agencia, lo que sea.
    Porque es el core lo que te diferencia de la competencia, donde puedes brillar, asi que esa tarea critica deberia ser la unica donde no “te fies de nadie”. Pero lo mismo el business angel que dijo esto estaba equivocado…

    1. Alex, gracias por tu comentario.

      Yo no juego en otra liga, estoy precisamente en esa, me llegan clientes que quieren un facebook por 2000 euros, pero la contestación es que yo no soy su proveedor.
      Yo prefiero no coger proyectos y seleccionar clientes. Ofrecer servicios es ya lo suficientemente duro como para equivocarse de cliente o tirar el precio. Aun así, te acabas equivocando o fallando.

      Tampoco presupuesto con precio abierto, lo que sí hago es priorizar. Es decir, contamos con este presupuesto y tras ver el producto vamos a ver qué entra en dicho presupuesto.
      Pero sí que soy flexible, y puedo cambiar cosas pero claro, no trabajo con todo el mundo.

      Luego hay mucha frase repetida sin tener en cuenta el negocio en concreto.

      Saludos!

      1. Cuando digo otra liga lo digo porque yo no ofrezco servicios, soy un simple programador que programa lo que le digas, sin mas asesoramiento (ni estudios de mercado) que explicarte un poco como funciona la appstore o el google play market, para subir la app, que requisitos te piden y cosas asi (claro que yo solo hablo de moviles).

        El precio abierto o cerrado creo que aqui todos hacemos lo mismo, evaluas el trabajo y miras en ese presupuesto que cosas de lo que pide el cliente se pueden hacer y cuales le pueden interesar mas y sobre eso trabajas. Porque aunque sea abierto todos quieren una estimación, no van a gastarse de repente 300k cuando no pensaban mas de 30k (mera generalización)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *