Hazlo realidad

Hace unos días años un amigo me recomendó leer un libro (Getting Real) con el que realmente comparto la inmensa mayoría de consejos que apunta sobre cómo tener una empresa de desarrollo de software y no morir en el intento.

Perfectamente ordenados y de forma práctica, recorre temazos como:

• Diseño
• Funcionalidades de las aplicaciones
• Versiones
• Promoción
• Soporte
• Trabajo en equipo
• Motivación

Todos los puntos nos suenan mucho, ¿verdad?

Está escrito por una empresa muy reconocida en Internet llamada 37 Signals, absorbida por Basecamp hoy día, con varias aplicaciones para trabajo en equipo, gestión de proyectos, gestión de contactos, notas, etc.

Aunque el libro haya sido escrito hace ya más de diez años, continúa muy vigente hoy en día. Conforme iba leyéndolo, fui escribiendo un resumen en español que paso a compartiros.

Línea de salida

En un proyecto, la fecha límite y el presupuesto son intocables, si ves que no llegas, reduce el alcance. Elimina todo lo que no es realmente necesario: documentación, especificaciones técnicas, funcionalidades superfluas... Es bueno hacer equipo con el cliente, es una voz útil y debes involucrarlo en el proceso.

Es fundamental que el software sea intuitivo. No es necesaria formación para aprender a usar Google o Amazon, tu software debe ser igual de simple y usable. No te obsesiones con estudiar mucho a la competencia porque puede limitar tu pensamiento.

No engordes

No te excites cuando las cosas parezcan ir bien y pienses en contratar a talentos a destajo. Un equipo reducido y trabajando en objetivos cercanos es mucho más ágil que una gran organización. El mercado de las tecnologías exige ser ágil, no pierdas esa cualidad. Además, siendo pequeño puedes ser más cercano al cliente.

Prioridades

Lo primero es definir la visión de la aplicación, por ejemplo para BaseCamp es "Project Management is communication".  Esta filosofía condicionará muchas decisiones sobre la aplicación. Se parte de lo abstracto y se acaba en los detalles.

Usa equipos de 3 personas: 1 desarrollador + 1 diseñador + alguien entre los dos mundos. Las limitaciones te guían y te ayudan a focalizarte. No te preocupes de posibles problemas en el futuro (escalabilidad), pasa de ellos, concéntrate en los de ahora.

Seleccionando funcionalidades

Es muy importante filtrar las funcionalidades que quieres añadir a la aplicación. Piensa lo que necesita, luego divídelo entre dos una vez y luego otra. Una nueva funcionalidad es como adoptar un hijo, el proceso es el siguiente:

1. Di al cliente que no vas a incluir esa funcionalidad que te pide.
2. Pídele a esa funcionalidad que 'demuestre que lo vale'.
3. Si sale que no 'lo vale', fin. Si sale que 'sí lo vale', continua.
4. Boceta la pantalla.
5. Diseña la pantalla.
6. Prográmala.
7. Prueba, prueba, prueba, prueba, prueba y vuelve a probar.
8. Comprueba si los mensajes de ayuda deben cambiarse.
9. Actualiza el 'tour del producto' si es necesario.
10. Actualiza los contenidos / promesas de marketing si es necesario.
11. Actualiza los términos del servicio si es necesario.
12. Comprueba si algunas promesas han sido rotas.
13. Comprueba si la estructura del precio está afectada.
14. Lánzalo.
15. Aguanta la respiración.

Las propuestas de los clientes hay que olvidarlas, las verdaderamente importantes 'flotan en el ambiente'. Hay que preguntarse qué sobra en la aplicación, no qué hace falta.

Proceso

1. Brainstorming
2. Esquemas en papel
3. Pantallas en HTML
4. Desarrollo (programación)

Es importante hacer software que sea un marco general, sin muchas opciones. Cuanto más abierto, más fácil será que el usuario encuentre soluciones, no barreras. Pon a funcionar tu software cuanto antes para pulirlo bien. Desarrollar aplicaciones no es neurocirugía, las cosas no tienen que salir 100% bien a la primera, además el test bueno, es en real.

Organización

Las reuniones no son trabajo. La 'reunionitis' es síntoma de conceptos poco claros en la empresa. Si te reúnes mucho es que debes aclarar conceptos a tu equipo. Si no queda otro remedio haz reuniones de máximo 30 minutos, cuantas menos personas mejor y sin agenda del día.

Equipo

No es obligatorio contratar mucha gente, es preferible poca, buena y bien avenida que empezar a contratar gente porque pienses que los necesitas, probablemente te ralenticen, sea mucho más difícil de gestionar, problemas de comunicación, etc.

Diseño de la interfaz

La interfaz es tu producto y no lo que hay desarrollado debajo. Se diseña antes de programar nada y siempre desde el centro de la página (cuerpo principal que será un post, un menú, etc.) hacia fuera (colores, logo, encabezado y pie, márgenes, menús laterales....).

Hay que diseñar 3 estados: normal (aplicación en uso) blanco (aplicación nueva, que el cliente no vea una patalla vacía, fea).

Como no hay datos, habrá que incluir tutoriales y comentarios de ayuda, capturas de pantalla de ejemplo con datos, explicar cómo será la pantalla, contestar a estas preguntas: ¿qué es esta página?, ¿qué hago ahora?, ¿cómo será esta página cuando esté completa? ¿cómo serán los errores? (cuando la aplicación falla).

Es lo que llamamos 'diseño defensivo'. No todas las páginas deben mantener cabecera, pie, etc. Pesa más el contexto/funcionalidad de cada pantalla que la coherencia extrema de todo. El texto es diseño. Las pantallas de administración/personalización no deben estar separadas, sino que se deben poder editar los valores en la pantalla principal.

Código

Se debería pagar a los programadores para que quiten código de un programa, no para que lo escriban. Se debe permitir que fluya la información hacia fuera: XML, JSON, API... para otros desarrolladores.

Palabras

No escribas documentos muertos como borradores (mejor trabajar con cosas reales), especificaciones técnicas (son un brindis al sol, nadie las lee, están desactualizadas...). No hagas ningún documento que viva fuera/aparte de las aplicaciones.

Habla en lenguaje coloquial, sin ser pedante/técnico. Pon texto real, no Lorem Ipsum. Piensa en tu producto como en una persona con personalidad, el texto debe tener esa personalidad. El texto es la voz de tu producto y está 24 horas hablando a tus clientes.

Precios y registro en la web

El alta y la baja deben ser procesos sencillos, rápidos y gratuitos. La importación y exportación de datos debe ser fácil y poder hacerse en cualquier momento. Si hay que dar malas noticias (subida de precios) se comunicará con antelación y se darán periodos de adaptación para suavizar el impacto entre los clientes.

Promoción y publicidad

Se seguirá la filosofía de Hollywood:

1. Trailer (intriga): Se contactará con expertos apelando a su vanidad para que hablen de ti: Boing Boing, Digg, TechCrunch...
2. Pre-estreno Semanas antes del lanzamiento publica las características que tendrá, da acceso a los expertos que vieron el trailer, pon pantallazos, anima a la gente a que esté informad, que se dé de alta, es decir, crea expectación.
3. Lanzamiento: Lanza el marketing a saco, consigue que blogs enlacen con tu página, publica los progresos: número de usuarios que lo usan, noticias, actualizaciones... manténlo vivo.

En cualquier caso ten en cuenta que la mejor promoción es un excelente producto. Ingredientes aconsejables en tu web:

• Vista general que explique los beneficios del producto.
• Tour guiado a los visitantes por sus características.
• Pantallazos y videos con la filosofía tras el producto.
• Ejemplos reales de lo que se puede hacer.
• Testimonios, prensa y noticias reales sobre el mismo.
• Foro.
• Precios.
• Blog, útil y ameno, dirigido al perfil de usuarios del producto.

Los blogs funcionan mejor que la publicidad y son más baratos. Comenta donde te comenten y pregúntales si quieren ser 'VIP', sé elegante con los que te critican.

También es promoción publicar videotutoriales, trucos o consejos. Puede ser interesante usar tecnologías e integraciones llamativas.

Aprovecha el poder del upgrade: si alguien no puede hacer algo porque está en una versión básica, dile que pagando algo más podría hacerlo, y que tendría además otras ventajas que pasarás a mencionar.

El nombre de la aplicación debe ser explicativo y recordable, no pongas 'Project Manager Collaboration', si no 'BaseCamp', por ejemplo.

Que el dominio .com esté cogido no es crítico, puedes añadirle algo tipo 'ourbasecamp.com'

Soporte

Derriba el muro entre soporte (camareros) y programación (cocina). Deben cambiarse los roles de vez en cuando para sentir el feedback de los clientes en cocina.

Formación: usa la ayuda y las FAQ para completar el manual y la formación. Nadie aprende a usar Google o Amazon, ¿por qué deben aprender a usar tu aplicación? Si recibes soportes repetitivos por el mismo tema, pon información o enlace a FAQ en el punto donde se produce esa duda.

Los soportes deben responderse en el momento (90% en 90 minutos), personalmente, sin textos enlatados.

Fomenta que los foreros se ayude unos a otros, quítate de en medio. Si hay problemas técnicos, avisa a todos, aunque casi nadie se hubiera enterado.

Post-Lanzamiento

30 días después del lanzamiento saca una actualización. Realiza publicaciones sobre las nuevas mejoras.

No hay betas, si tu app no está para consumo público, mejor no la publiques.

Los bugs suceden, no pasa nada. Se priorizan por impacto (gravedad y alcance de usuarios) y punto. Si te chivan uno y no es prioritario explica por qué no es urgente, que hay otros que afectan a más gente. Sobre todo sé honesto.

Hay un punto en el que debemos dejar que el producto simplemente exista, sin añadirle funcionalidades hasta el infinito.

Conclusión

Concéntrate en poner todo esto en práctica, ejecutarlo. Las ideas sin ejecución no sirven de nada. Mantén el equipo motivado. Puedes aplicar la filosofía 'Getting Real' a otras áreas de la vida, no solo al software

También podéis leer el libro completo en inglés (son pocas páginas) de forma totalmente gratuita.