Cómo encontrar y gestionar un partner técnico

Ayer me entrevisté con un joven emprendedor que anda reclutando al equipo de fundadores para su startup. No puedo publicar ningún detalle del proyecto, pero nuestra conversación atrajo mi atención sobre un problema que para muchos emprendedores puede llegar a ser bastante tortuoso: ¿cómo encontrar y gestionar a un partner tecnológico?

Una startup de base tecnológica necesita un director técnico, no un programador.
La plantilla de una startup es muy limitada, por ello un friki no es la persona adecuada para cubrir el primer puesto de responsabilidad tecnológica. La diferencia estriba en que un programador suele interesarse por la tecnología y sólo por la tecnología mientras que a un director técnico le preocupan, además, al menos otras tres cosas: a) el uso social que los clientes harán de la tecnología, b) la idoneidad de los lenguajes componentes y utilizados con independencia de ningún favoritismo personal, c) y la escalabilidad de la solución tanto en capacidad de cómputo como en facilidad para encontrar más programadores con los conocimientos necesarios. Y una cosa más, lo mismo que no es buena idea que tu cardiólogo te haga una endodoncia, aunque sea igual de médico que tu odontólogo, ningún programador es bueno en todas las áreas. Ciertamente la inteligencia vale para todo, pero puede ser que el programador un crack de las bases de datos y un zotes integral haciendo sitios web o un as de las aplicaciones de gestión y un cero a la izquierda escribiendo videojuegos.

No es buena idea evaluar a alguien sobre unas competencias de las que uno mismo carece.
La mayoría de las veces que alguien me ha dicho que “ese tío es la ostia de bueno” a la postre el sujeto en cuestión ha acabado siendo nefasto para el negocio. Ya he escrito anteriormente sobre el problema con los superhéroes. No es buena idea juzgar la competencia profesional de un programador a ojo de buen cubero sin saber realmente de tecnología porque se puede acabar sufriendo Síndrome de Estocolmo. Lo mejor es pedir referencias del candidato ¿Qué otros proyectos ha hecho? ¿Qué opinan sus ex-compañeros sobre la calidad de su trabajo?

No suele ser buena idea subcontratar absolutamente toda la tecnología.
Hay emprendedores que piensan que pueden subcontratar y gestionar ellos mismos toda la implementación. Esto, en general, es un error. Para empezar, si una parte del core business de la startup es la tecnología subcontratar absolutamente todo dejará a la empresa vacía de un know-how técnico propio esencial. Por otra parte, gestionar un proyecto de desarrollo de software es una ciencia en si misma. Si, además de carecer de experiencia previa, los equipos de trabajo se encuentran dispersos por el globo, entonces el fracaso está prácticamente garantizado. Los programadores de la India o de Europa del Este no son ni mejores ni peores que los nacionales, pero cada país tiene su propia forma de trabajar. Estas diferencias culturales pueden provocar un marasmo en el proyecto si no se sabe cómo influyen en la organización del proyecto. Adicionalmente a la gestión intercultural de personas se requiere dominar un sofisticado conjunto de herramientas de control de proyectos distribuidos.

El partner tecnológico no tiene necesariamente que ser un socio.
Desde mi punto de vista, lo ideal es intentar negociar un pago aplazado mediante reconocimiento de deuda o participación en beneficios antes que ceder participaciones de la sociedad. Y luego, en todo caso, otorgar stock options como medio para fidelizar a los programadores. Naturalmente, tal planteamiento no siempre es factible, bien porque los programadores disponibles carezcan de ahorros con los que esperar a un pago aplazado, bien porque les parezca injusto llevar todo el peso de la producción a cambio de una vaga promesa de futuro.

Si se contrata un becario se tendrá un trabajo de fin de carrera en vez de un coche de carreras.
Desarrollar un sitio web de alto tráfico es como fabricar un Fórmula 1. Se necesita un equipo multidisciplinar capaz de ensamblar miles de piezas probar el coche en las condiciones más extremas y optimizarlo hasta la última vuelta de tuerca. Hay estudiantes que son muy buenos, las mejores innovaciones, de hecho, las producen los estudiantes. Sin embargo, tratándose de implementar algo, la veteranía es una característica bastante deseable en el responsable técnico.

Ninguna tecnología es una solución mágica.
De un tiempo a esta parte está de moda la creencia de que Ruby On Rails o Python o GWT o lo que sea… obran milagros. Si se usan las herramientas adecuadas, con estos frameworks se obtiene más o menos la misma productividad que un entorno J2EE o .NET Lo que sí ofrecen es una curva de aprendizaje más suave, y es por ello, unido a su novedad que son los favoritos de muchos programadores. Hay ejemplos exitosos en todas las plataformas que demuestran que da igual si se desarrolla el sitio en Java, en PHP o en RoR indistintamente. Por último, reseñar, que la mayoría de las personas a quienes he oído afirmar que su software era muy escalable en realidad no tenían ni puñetera idea de lo que se requiere para que un sistema sea realmente escalable.

Usar Software Libre.
Siempre existe alguna excepción puntual que confirma una regla, pero, en general, no existe hoy en día ninguna razón a priori para utilizar en el desarrollo ninguna herramienta de software privativo. Más aún, en muchas áreas las alternativas libres superan ya con creces a las privativas en cantidad y calidad.

Especificar con mockups y controlar mediante metodologías ágiles.
Hay muchos programadores que viven en un microscópico mundo de bytes. Otras personas son visionarios con una mente anticipada a su tiempo, pero incapaces de concretar operativamente sus ideas abstractas. Lo mejor de un uso social de la tecnología surge cuando se conectan ambos mundos. Una de las mejores herramientas para comunicarse con los técnicos es aprender a dibujar. Algunas personas hablan o escriben muy bien pero no dibujan, y los dibujos son la forma más fácil de representar una visión. Mejor que el PowerPoint son los mockups, yo concretamente uso una de las herramientas “de pintar a boli” llamada Balsamiq pero hay muchas otras.
Las metodologías ágiles de gestión consisten, a grandes rasgos, el marcar hitos cortos de dos o tres semanas en los cuales se estabiliza una versión del producto funcionalmente limitada.

Las aplicaciones progresan como la construcción de una casa.
Esto significa que al principio, la obra progresa aparentemente muy despacio. Incluso cuando está completada en un 80% la morada parece que será un lugar horrible. Con paredes sin pintar ni grifos en los lavabos. Y luego, de repente es como si todos los alicatados hubiesen sido colocados de un día para otro como por arte de magia. Únicamente un programador experimentado puede predecir cómo quedará finalmente la casa echando sólo un vistazo a los andamios. Para empeorar las cosas, por muy sólidos que sean los cimientos lo que le da el feeling, o no, a la casa son los acabados. A veces los programadores pasar demasiado tiempo reforzando los cimientos contra terremotos y demasiado poco tiempo puliendo cómo te hacer sentir la decoración.

Los programadores son artistas del software.
Como tales artistas, unas veces les da por pintar una Gioconda, y otras por pintar un becerro. Algunas personas tienen una visión y se sienten muy frustradas cuando el programador no materializa exactamente dicha visión sino otra solución alternativa. Es imprescindible tener claras las especificaciones pero no hay que obsesionarse con que el programador haga las cosas de una determinada manera. Es posible que el programador, quien de seguro no es tonto, tenga buenas razones técnicas y de usabilidad para defender un punto de vista que no es fácilmente percibido de igual manera por personas sin conocimientos técnicos.

Lean, quick and dirty no es mejor, sólo es más lean, más quick y más dirty.
El software es inherentemente complejo. Se puede expresar dicha complejidad de una forma u otra, o incluso se puede ocultar, pero sigue estando ahí. Cuando más rápido y chapucero se lance un proyecto más deuda técnica acumulará. Con suerte esta deuda técnica en forma de cosas que habrá que rehacer será posible pagarla en la serie B o C de inversión, pero según sea la cantidad y “calidad” de “regalitos” dejados en el código con las prisas no es la primera vez que las chapuzas lo mandan todo al carajo debido a que los usuarios tiene muy poca paciencia con las aplicaciones que fallan.

Hay que lanzar productos terminados, no betas perpetuas.
En contra de lo que comúnmente se suele difundir, yo personalmente no soy partidario del “release soon, release often” ni de aquel épico “don’t worry, be crapy” de Guy Kawasaki. Lo óptimo es el “release on time, release stable”. Uno de los errores que aprecio cada vez con mayor frecuencia es sacar el producto al mercado demasiado pronto cuando aún no está listo para ello. El problema con salir demasiado pronto consiste en que es fácil captar la atención inicial de la gente pero es muy difícil mantenerla. Es necesario que a los usuarios les guste la aplicación la primera vez que la prueben, porque rara vez le dan una segunda oportunidad. Y es difícil que les guste si se les ofrece lo que llaman el “mínimo producto viable” (MVP).

El esfuerzo empleado en testear una aplicación debe ser al menos el mismo que el empleado en codificarla.
Escribir software es divertido. Testearlo es tedioso. Por ello, la mayoría de los desarrolladores programan demasiado y testean demasiado poco. A ser posible lo deseable es tener al menos un ratio 1:1 entre programadores y beta testers.

Mantener el software es igual de caro que fabricarlo.
La dinámica clásica de gestión financiera funciona con ciclos de inversión y amortización. Primero inviertes en generar un activo y luego lo vas amortizando a lo largo de los años. En el software, en cambio, el gasto fijo necesario se mantiene constante o crece a lo largo de tiempo pero nunca decrece.

Crear una cadena de custodia de datos.
Si subcontratas el desarrollo en Pakistán y les das acceso a tu base de datos de clientes para probar, ten por seguro que todos ellos estarán en todas las listas de SPAM del mundo mundial al día siguiente.

Fijar contractualmente la retribución, la propiedad intelectual y las cláusulas de confidencialidad.
En el caso de que por desavenencias entre los fundadores el programador abandone la startup se pueden producir una serie de sucesos tales como:

• Que el programador reclame el pago de los trabajos realizados. Para lo cual hay de que llevar un registro de horas dedicadas y entregables terminados junto con una tarifa horaria, cosas que permitan cuantificar objetivamente el esfuerzo realizado por el programador hasta el momento de su baja y liquidarle lo que en justicia le corresponda.
• Que el programador se apropie de los trabajos realizados. Para evitarlo hay que firmar con él un contrato que diga que cede la propiedad intelectual de los entregables incluyendo su código fuente de forma exclusiva y libre de royalties a la empresa. Además, hay que ir haciendo registros de código en la oficina legal que corresponda.
• Que el programador se asocie con otro para montar algo en competencia. Si hay algo que caracteriza a los programadores es la creencia de que sea lo que sea que haga otra persona, ellos pueden hacerlo mejor. Es conveniente redactar actas de las reuniones y especificar cual es la información relevante para el negocio a la cual el programador tiene acceso y no puede compartir en ningún caso con terceros ni siquiera después de haberse ido de la empresa.

Posts relacionados:
Porqué la gente odia a los programadores.
How to Recruit a Great Programmer as a Partner (Jason Fell)
How To Create A Minimum Viable Product (Emre Sokullu)
¿Qué hacer cuando no tienes un co-fundador técnico? (Allison Sheren)