Las puras "cabezas pensantes" son peso muerto
Es curioso el montón de proyectos formados por puras "cabezas pensantes" (una o varias), gente que piensa que lo importante de un proyecto es la estrategia, la visión, los contactos, etc. todas ellos elementos que a efectos prácticos apenas contribuyen a la creación de un proyecto.
Una "cabeza pensante" es el tÃpico tipo que antes de tener ni una triste beta, ya cuenta todo en el blog y su emoción en directo en twitter. Oigan, una cosa es marketing de guerrilla para generar expectaction y otra cosa es una fantasmada.
Es fascinante como las cabezas pensantes piensan que sus tareas tan poco ejecutoras valen lo mismo que el trabajo de un programador que es su socio tecnológico, o aún peor, que su idea es tan genial y el trabajo del programador tan irrelevante que ni siquiera hace falta que el programador tenga porcentaje de la empresa, un salario basta, o mejor aún, esa genial idea podrÃa ser implementada por un freelance externo y baratico si puede ser.
Una cabeza pensante justifica su trabajo dando vueltas y más vueltas a las cosas y generando PPTs. Esto es inútil, no produce nada y es contraproducente, en Internet las ideas se desarrollan en vivo y online, no sobre una ppt ni en la cabeza de ningún estratega. Cierto, incluso en un proyecto pequeño hace falta algo de estrategia, contactos, etc. pero eso se hace en un 10% del tiempo de la persona del perfil no tecnológico y por una razón sencilla, esas son cosas no ayudan a arrancar el proyecto.
Quizás en super proyectos hagan falta pefiles pensantes, pero cuando estás arrancando un proyecto todo se basa en ejecutar y una cabeza pensante es un peso muerto. No es que crea que los cabezas pensantes lo hagan con mala intención o sean timadores, en la mayorÃa de los casos se creen honestamente lo que dicen, simplemente no tienen ni idea de como funcionan las cosas en el mundo de la start-ups.
Por qué esto funciona asÃ
Una start-up o proyecto de software no es una fábrica de chorizos ni una constructora, programar es un trabajo puramente intelectual y quizás la tareas más intensiva intelectualmente que conozco.
Programar requiere mucha concentración. No se trata de echar horas, a veces puede ser muy productivo una mañana y totalmente improductivo unos dÃas o una semana. Cada programador tiene unos ritmos personales de productividad vs improductividad, esto es simplemente asÃ, no se puede cambiar. No se trata de echar horas ni poner horarios ni ser estrictos en las fechas de entrega sino de crear un ambiente que favorezca la productividad de tareas intelectuales, básicamente lo que hace Google en sus oficinas.
Un programador trabajando solo o con un pequeño equipo en una start-up le toca quedarse a las tantas de las mañanas muchos dÃas porque cuando estás a mitad de solucionar un problema no funciona lo de "son las 19:00, hora de irme, mañana más", estás a mitad de concentración, motivado para acabarlo, dejarlo para mañana puede significar mañana o que no se arraglará en un par de semanas, cuando no en un mes. Ese trabajo correctamente no lo va a hacer nadie solo por un salario, ni un precio fijo.
Nunca he programado, pero siempre he prestado mucha atención a como funcionan estas tareas y es fascinante. Tratar a un programador como un currito que hace sus horas y se va es ignorar como funcionan las tareas intelectuales, la motivación humana, etc. Quizás se pueda hacer en proyectos ya consolidados, pero en start-ups y en proyectos que arrancan, absolutamente no.
La relación entre el socio técnico y el no técnico
Un proyecto hasta que se lanza la primera versión requiere de un 90% de horas de programación y un 10% del resto (UI, estrategia, ideas, etc.). Eso quiere decir que el socio programador se va a comer la inmensa parte del trabajo cuando una vez lanzado ni siquiera se sabe si el proyecto va a funcionar, además el programador tampoco sabe a priori la implicación del no-técnico que inicialmente solo pone buenas palabras y pocas horas, no hay mucho trabajo no-técnico que hacer, por tanto son todo incógnitas y mucho trabajo para el técnico.
Si la mayor inversión y riesgo es asumido por parte del programador, éste debe tener su recompensa. Hay muchas casuÃsticas dependiendo del tipo de proyecto, pero por ejemplo, en un proyecto de 2 el programador debe tener el 50%. En cualquier caso siempre debe existir una manera de retribuir al programador más allá de su salario para motivarle a ir más allá y que si la cosa vaya bien también reciba algo más que unas pocas migas discreccionales.
Pero las "cabezas pensantes" no entienden esto, si para empezar muchos ya piensan que alguien les va a hacer el proyecto por un salario o precio cerrado, cuando se plantean el socio tecnológico piensan que casi le hacen un favor dándole un porcentaje. Olvidan que alguien capaz y con talento de hacer un proyecto bueno nunca lo hará por un salario, si supiese hacerlo lo harÃa para si mismo no para un tercero. Se podrÃa contra-argumentar que los programadores no son buenos en visión de producto y muchas otras cosas y es cierto, pero nadie garantiza al programador que el "cabeza pensante" de su equipo sea bueno en esas tareas. Yo honestamente entiendo perfectamente que un programador ante esta decisión prefiera trabajar solo que con un socio no técnico.
Cuando un técnico confÃa en un no-técnico: mancharse las manos
Descartada la opción de hacerlo en plan freelance o a cambio de un salario, por irrealistas (o timos) solo queda la opción de un socio tecnológico con un porcentaje respetable, pero eso no basta, el programador es quien tiene que poner el 90% de las horas de trabajo iniciales. Hasta que haya trabajo no técnico suficiente para que el no-tecnico pueda ponerse al 100% pasa tiempo ¿Qué hacer?
Es sencillo, el programador debe ver al no-técnico ejecutando y solucionando problemas concretos, en definitiva, manchándose las manos y teniendo una predisposición infinita a hacer curros desagradables. Dada la enorme desproporción inicial de tareas lo único que compensa al técnico es que otra persona le solucione las cosas que no le gustan o no sabe hacer. En ese contexto lo peor que un no técnico puede hacer es ponerse en plan "cabeza pensante", interrumpiendo al programador, sugiriendo todo el rato modificaciones que resultan en más trabajo y dedicarse a generar una PPT tras otra. Tras haber definido los prototipos y funcionalidades básicas, de mejor o peor manera, cualquier cosa que interfiera en la ejecución es una molestia, un "cabeza pensante" que interrumpe es un peso muerto.
Aunque hay casos que el "cabeza pensante" apartentemente aparentemente se camela al programador, en realidad no funcionará porque se darán dos casos
a) El programador es malo y piensa que es él quien se ha camelado al "cabeza pensante" que supuestamente tiene unos contactos de la leche y lo solucionará todo en dos patadas, asà que Uno por otro, nadie trabajará.
b) Un programador inteligente. Si es socio tecnológico se dará cuenta que el está echando el 90% de horas y el otro no pringa nada. Si es asalariado o freelance en cuanto se le pase la emoción inicial echará las horas convenidas, le hagan al proyecto falta más horas o no.
Que el no-técnico se manche las manos es lo único que puede hacer al programador confiar y arriesgarse. Mancharse las manos es por ejemplo hacer tareas técnicas, pesadas, pero fáciles de hacer. Es por ejemplo, que te pasen una base de datos mundial donde la lista de ciudades más importantes del mundo no está correctamente priorizada (ej. Madrid, Texas, sale antes que Madrid, Spain) y hay que primero encontrar un listado con las 1.000 ciudades más importantes del mundo (o generarlo a manija) y luego modificar la base de datos manualmente. Mancharse las manos es dar la bienvenida personalizada a cada uno de los primeros usuarios con algo más que un "hola". Mancharse las manos es subir un montón de contenidos realmente útiles al sitio web para hacerlo mÃnimamente funcional. Mancharse las manos es encontrar a los bloggers más relevantes del sector del geoposicionamiento y escribirles e-mails totalmente personalizados explicándoles tu proyecto de fotos geoposicionadas.
En conclusión, la tarea de ser socio de un técnico significa ocuparte de todo lo demás, comerte cualquier marrón y hacer la vida lo más sencilla posible al programador. Eso es lo que
Un buen equipo
Idealmente en un equipo los perfiles deben complementarse, hay muchos flancos que cubrir y queremos gente que haga de todo. Al menos hacen falta dos personas, un perfil técnico y el otro perfil que hace todas las cosas que al técnico no sabe o no le gusta hacer.
TÃpicamente a quien le gusta programar no le gustan ciertas tareas, las que el socio no técnico tiene que "solucionarle": desde gestión de comunidad (blog, foro, mails…) al soporte, estrategia, producto, marketing de guerrilla, hasta comprar los dominios o simplemente cualquier gestión administrativa, repetitiva o burocrática.
No pasa nada que los perfiles se superpongan un poco, hay veces que los dos fundadores son técnicos, pero a uno le gusta programar y al otro no y le gusta el resto del trabajo no técnico. Hay veces incluso que los dos son técnicos, pero lo hacen tan bien que el resto de tareas se van haciendo entre los dos. No hay reglas respecto a equipos. Lo que está claro que ni todo es programar ni todo es pensar ni todo es hacer marketing, hay que cubrir todos los flancos.
Excepciones
Lo unico que se puede subcontratar de un proyecto viable y no del todo es el front CSS, html, etc. el logo, etc. Son cosas para las que inicialmente no hay trabajo todos los dÃas, por tanto añadir a alguien asi al proyecto solo podrÃa dársele un porcentaje muy pequeños. Por supuesto subcontratar se puede hacer en proyectos tipo webs presenciales, Alzado.org, etc. pero eso no son proyectos grandes con proyeccciones, son proyectos personales, experimentos, hobbies, etc.
¿Y hay gente con éxito subcontratando? Claro, tÃpicamente mega-proyectos con inversores detrás y donde lo crÃtico no es la web sino tener los contactos para conseguir acuerdos, muchos comerciales para conseguir clientes via off-line, proveedores con precios bajos en e-commerce, etc. En conclusión proyectos donde la web es una herramienta más de una estraegia off-line, pero no el corazón del proyecto.
Dos puntualizaciones antes de seguir. Primera, un socio tecnológico es alguien que sabe programar y que tiene porcentaje relevante del proyecto. Segunda, hablamos en este articulo de proyectos web viables con ambiciones de vivir de ellos, no webs personales, ni experimentos, ni webs meramente presenciales, ni proyectos con inversiones detrás.