Hace unos días almorzaba con un amigo que estuvo recientemente en Silicon Valley. Me confesaba que una de las cosas que más le impresionó fue una conversación informal con Jason Fried, CEO de 37signals, y de él destacó su énfasis en la filosofía de “hacer más con menos”.
Uno de los detalles que sobresalía de ese mantra, es la convicción que cualquier proyecto web, cuyo tiempo de desarrollo y puesta en marcha sea superior a 45 días no merece la pena.
Inspirándome en la línea de pensamiento de Jason Fried y en lo que predica en su libro “Getting Real”, tengo que reconocer que la fuerza de los hechos hace que comparta –para pymes y no tan pymes- gran parte de su recetario: procesos eficientes, focalizarse y no dispersarse en múltiples frentes, ejecutar rápido, ser frugal y pensar su empresa para ganar dinero en lugar de pensar en hacer rondas de inversión para venderlos,…
Algunos no tenemos esa clarividencia y visión. Aprendemos más tarde… y a golpes. Por eso hoy quería escribir mi lista. Partiendo –eso sí- de los principios de Fried. Aunque seguramente de una forma bastante más terrenal e insípida, basada en mi particular experiencia en el desarrollo de proyectos web.
Desde luego cada uno podría escribir una lista diferente, pero esta es la mía. Esencialmente son:
1) Pon fechas. La fecha no es el problema. El problema es el proyecto. Todo nuevo proyecto web con una línea temporal superior de tres meses… ufff, a sufrir. Sé más diligente si el proyecto es de una empresa en funcionamiento
2) Identidad. No pierdas el ADN del proyecto por el camino. Sí, eso que se puede escribir en una frase.
3) Las especificaciones funcionales son pura fantasía. Lo siento, tenía que decirlo.
4) Evitar los debates estériles sobre escalabilidad
5) Evitar las reuniones, especialmente las interminables (e improductivas),
6) Evita la necesidad de contratar una legión de empleados para mantener “eso”
7) No inventes la rueda. Si algo ya funciona, úsalo o cópialo (o adáptalo que suena más fino)
8) Configuración imposible. Evita un sinfín de opciones y ajustes que el usuario no ha pedido, no quiere y no usará jamás
9) Evitar jerarquías y comités. Si no has estado metido en el proyecto, no opines, salvo que te lo pidan
10) Empieza por el interfaz y el SEO (¿es eso posible?)
11) El diseño es importante, pero que un mal diseño no estropee un buen proyecto. Un buen diseño no salva un proyecto mediocre.
12) El tamaño importa. Permanecer pequeño es algo bueno. Tanto el proyecto, como el equipo de proyecto.
13) Hazlo más simple y más barato que la competencia. No pretendas el cojo-proyecto, ni replicar la catedral de Burgos, fracasarás.
14) La beta en continuo, bien. Pero no una “beta autista”, hay que preguntar y conversar con el cliente
15) La escasez agudiza el ingenio y la creatividad. Bueno, eso dicen.
16) Hazlo sin vaciar la caja (cash)
17) Se realista. Evita dejarte llevar por la ilusión, de lo contrario la realidad todavía te parecerá más dura
18) Los cambios bruscos (especialmente de interfaz) no gustan a los clientes. Aunque si tan malo era el punto de partida, tranquilo, porque entonces seguro que los pocos que te aguantaban te lo agradecerán
19) ¿Realmente mejoras la vida de alguien con “eso”?
20) Es importante “conversar”, pero también “convertir”
Y tú ¿qué añadirías?
PD. Si deseas un resumen completo del pensamiento de “Getting Real” adaptado a la empresa, te recomiendo el realizado por Paco López.