El camino a FogBugz
Joel Spolsky, de quien siempre he hablado muy bien aquí, es el “jefe” de la empresa Fog Creek Software.
Coincidiendo con el lanzamiento de una nueva versión de su programa FogBugz, una herramienta de planificación de proyectos, ha escrito una serie de artículos sobre el “cómo se hizo” de dicho software, The Road to FogBugz: Parte 1, parte 2, parte 3, parte 4 y parte 5
Son todos ellos muy interesantes. Estas son algunas de las cosas que me han llamado la atención de lo que cuenta:
- Escucha a tus clientes, no a tu competencia. Esto te ayudará a desarrollar nuevas funcionalidades realmente útiles, y no simples copias de tu competencia.
- Utiliza tu propio software, algo que los ingleses llaman “eat your own dogfood”. Nos explica un par de buenas funcionalidades que surgieron directamente gracias a que ellos mismos las necesitaron. Claro que hacer esto es más fácil cuando vendes un gestor de proyectos, que cuando uno desarrolla, por ejemplo, un software para gestión de estabilidad de aviones, algo difícil de aplicar en nuestro día a día.
- ¿Cuanto tiempo real se utiliza en el desarrollo (escribir nuevas funcionalidades) de un producto? Joel comenta que su experiencia es que sólo el 2%. El 55% se utiliza en debugging, beta testing, etc. El resto se utiliza en labores de marketing, servicio al cliente, etc.
- Esta es buena: ¿Cómo decide un cliente si compra tu software?
- Evalúan la calidad de tu sitio web.
- Buscan en los grupos de discusión para ver si la gente está utilizando realmente el producto y si cuando tienen problemas se les responde rápidamente.
- Miran si hay una infraestructura de soporte de terceros, como libros.
- Evalúan tu reputación.
- Miran en la web para ver si se habla bien de ti.
- Miran durante cuanto tiempo llevas en el negocio y si están obteniendo éxito y por lo tanto es más probable que continúes dando soporte y manteniendo el producto.
- Ah, y si les quedan unos minutos libres, puede que miren el producto en si para ver si funciona.
En fin, como siempre, artículos que dan que pensar.
No estoy totalmente de acuerdo en lo que se refiere a realizar un producto e incorporar funcionalidades que directamente necesitas. Esto puede volverse contra tu producto en el caso que no se controla bien, es decir si se piensa que como "nosotros" lo necesitamos todo el mundo lo necesita. A Joel le funcionó porque el es muy consciente de lo que cuesta desarrollar y no pierde de vista al cliente (cosa extraña en esto del desarrollo del software) pero no creo que valga como generalización.
blc.glz
Yo recuerdo el caso de Forté, la primera versión del entorno de desarrollo en Java de Sun, lo que hoy se ha convertido en Netbeans. Fue curioso enterarme por un contacto que tuve con técnicos de Sun en EEUU que ellos mismos utilizaban emacs para desarrollar. No era extraño que hubiese cosas que directamente no funcionaban como debían.
Un saludo.
Buena idea para escribir una entrada en mi blog ;-)
Saludos,
Comentarios cerrados para este artículo