El necesario liderazgo inicial de los técnicos

Hace unas semanas leí el artículo de Rogelio Bernal (al que conocí personalmente en nuestra visita a Googleplex el mes pasado) "¿Estudias informática? ¡Ah, un emprendedor!" y me pareció que tenía mucha razón. Igualmente el artículo de Kirai va en la misma línea.

Creo que alguna gente piensa que el desarrollo, la parte técnica de un proyecto, es algo secundario y por tanto programar es un trabajo aparte que lo puede hacer cualquier currante o incluso se puede sub-contratar y ser realizado por una tercera parte externa.

En mi opinión esto no es así. No diré que los técnicos deben ser los líderes en absolutamente todo tipo de proyectos tecnológicos, pero especialmente en start-ups y en las primeras fases de arranque de un proyecto si considero importante el liderazgo de los técnicos, es más, si es un equipo creo que la última palabra la deben tener ellos.

Quizás suena raro que esto lo diga yo que no soy un técnico, pero la verdad es que en el tiempo que estoy trabajando codo a codo con Joaquín Cuenca, mi socio en Panoramio y que se ocupa de toda la parte "técnica" lo he visto bastante claro. Otros tendrán experiencias diferentes, pero esta es la mia y por eso la cuento.

Es normal que esta idea inicialmente choque, de hecho hablando con Pau Llop al comentarle yo todas estas ideas, trazó un paralelismo con el mundo físico y me planteó esta pregunta "¿Es más predominante el papel de los encargados de las imprentas que el de los periodistas en un diario en papel?"

Mi respuesta es negativa, evidentemente el papel del periodista en un periódico es más importante que el de los impresores, pero creo que no se puede comparar. Los servicios de impresión son, hoy en día, lo que se llama una commodity, algo estándarizado y para lo que hay miles de proveedores que te lo darán con un nivel de calidad muy similar. Para imprimir más copias o tener mejor nivel de calidad simplemente hay que pagar más.

Sin embargo el desarrollo web no es en absoluto una commodity, no está estandarizado y los niveles de calidad que los proveedores tecnológicos pueden aportar son muy diferentes. Por pagar más no tienes más, por tener un equipo más grande no siempre trabajas más rápido. Es normal, es algo nuevo.

A la hora de crear una web, no basta con decirle al programador "quiero esto" porque "esto" se puede hacer de mil maneras, hay mil detalles, mil implicaciones que o se conoce la tecnología muy bien o se puede meter soberanamente la pata. Si el programador no tiene poder para decidir la mejor manera, tomar la decisión última, establecer las prioridades, podemos tener problemas serios.

Esto sucede porque en nuestra ignorancia los no-técnicos muchas veces damos por hechas ciertas cosas que luego no son tan triviales o viceversa. Se pueden poner varios ejemplos sencillos que harán sonreir a más de uno que conozca bien el tema, pero creo que es interesante comentarlos para no quedarnos solo en lo abstracto:

- Conseguir que una newsletter por e-mail enviada simultaneamente a decenas de miles de personas funcione bien no es trivial. No es física cuántica, pero si lo quieres hacer tu mismo y quieres que funcione perfectamente bien, puede darte más complicaciones de lo que parece. De hecho por algo hay servicios comerciales de pago, como elistas del propio Rogelio, muchas empresas están dispuestos a pagar con tal de que les resuelvan el problema. Si no eres técnico puedes pensar que sitios como elistas o como Loquo no tienen mucha complicación a nivel técnico. Es un error típico.

- Servidores: si un servidor esta sobrecargado, el problema no se resuelve tan fácilmente como comprando un servidor más potente, añadiendo más servidores o disponiendo de más ancho de banda. Optimizar los servidores es casi un arte, de hecho hay tanta casuística diferente hoy en día que cada web de las grandes (de las que sirven muchos millones de páginas al día), tiene una solución interna diferente. Si hay suerte servicios como el S3 de Amazon conseguirán convertir el hosting en una commodity donde simplemente pagas más y tienes más, pero a día de hoy pocos sitios pueden aguantar el efecto slashdot sin caer o arrastrarse. Aprovechar al máximo el efecto slashdot o cualquier aparición en medios muy populares es primordial al arrancar un proyecto.

- Las estimaciones de tiempo son muy inexactas porque es muy complicado saber a priori cuando se tardará en desarrollar una funcionalidad y menos aún un proyecto al completo. Al final todos los proyectos se retrasan y mucho. El no-técnico puede empeñarse en poner una fecha, pero la cosa tardará lo que tenga que tardar según lo que se haya decidido hacer o no, por eso es importante que el técnico tenga la última palabra sobre lo que se hace o se renuncia, para reducir al máximo el margen de error. La dificultad de estimar los tiempos hace que las estrategias de desarrollo ágil estilo 37signals suenen muy bien a la gente de perfil técnico que saben bien la importancia y magnitud de estos defases. En muchos casos es mejor empezar con una versión extremadamente sencilla y evitar los grandes planes que aumentan la probabilidad de error en las estimaciones temporales.

Puntualizar que una cosa es hablar del liderazgo de los técnicos y otra decir que todos los técnicos sean buenos para emprender. Aparte de los conocimientos técnicos, hace falta predisposición e interés por otras áreas. Sin embargo creo que es más fácil que un técnico inteligente aprenda de finanzas, periodismo, usabilidad o de marketing, que un MBA, un psicólogo o un periodista aprendan programación u optimización de servidores.

Todo lo anterior no quiere decir que los perfiles no-técnicos sean prescindibles, para nada, el programador aprenderá finanzas o usabilidad, pero dificilmente podrá ser un experto en todas las áreas, necesitará consejos, asesoramiento. Sin embargo a fin de cuentas toda la ejecución dependerá de los técnicos y eso será lo que termine marcando la diferencia.