37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Getting Real Español



Introducción capítulo 1

¿Qué es Haciéndolo Real?

¿Quieres crear aplicaciones web exitosas? Entonces es hora de Hacerlo Real. Haciéndolo Real es una forma más pequeña, más rápida y mejor de crear software.

Los Beneficios de Haciéndolo Real

Haciéndolo Real da mejores resultados porque te obliga a tratar con los verdaderos problemas que estas tratando de resolver en lugar de tus ideas acerca de ellos. Te obliga a tratar con la realidad.

Haciéndolo Real olvida las especificaciones funcionales y otra documentación transitoria en favor de la construcción de pantallas reales. Una especificación funcional es hacer creer, una ilusión de conformidad, mientras que una verdadera página web es la realidad. Eso es lo que tus clientes van a ver y usar. Eso es lo que importa. Haciéndolo Real te lleva allí más rápido. Y eso quiere decir que estás tomando decisiones con respecto al software basadas en el objeto real en vez de nociones abstractas.

Por último, Haciéndolo Real es una aproximación idealmente adaptada al software basado en la web. El modelo de la vieja escuela de distribuir el software en una caja y luego esperar un año o dos para sacar una actualización está desapareciendo. A diferencia del software que requiere instalación, las aplicaciones web pueden evolucionar constantemente basandose en el día a día. Haciéndolo Real influencia esta ventaja con todo su valor.

Cómo Escribir Software Robusto

La escritura robusta es concisa. Una oración no debe contener palabras innecesarias, un párrafo oraciones innecesarias, por la misma razón que un dibujo no debería tener líneas innecesarias y una máquina partes innecesarias. Esto no indica que el escritor deba hacer cortas todas las oraciones o evitar tratar las materias de manera superficial, sino cada palabra cuenta.

—De "The Elements of Style" por William Strunk Jr.


Basta de inflarlo

El viejo modo: un proceso largo, burocrático, estamos-haciendo-esto-para-cubrirnos-las-espaldas. El resultado típico: software inflado, que se puede olvidar, goteando mediocridad.

Haciéndolo Real se libra de ...

No necesitas toneladas de dinero o un equipo gigante o un ciclo de desarrollo prolongado para crear software magnífico. Esas cosas son los ingredientes de aplicaciones lentas, lóbregas e invariables. Haciéndolo Real toma el método opuesto.

En este libro te mostrarámos...

El enfoque está en las ideas generales. No te vamos a molestar con pedazos detallados de código o trucos de CSS. Vamos a ceñirnos a las grandes ideas y las filosofías que conducen el proceso de Haciéndolo Real.

¿Este libro es para tí?

Eres un emprendedor, diseñador, programador o un vendedor trabajando en una gran idea.

Te das cuenta de que las viejas reglas no aplican. ¿Distribuir tu software todos los años en CDROM? ¿Como en el 2002? ¿Números de versiones? Por la ventana. Necesitas construir, entregar y optimizar. Luego mejoras y repites.

O tal vez no estás todavía abordo del desarrollo ágil y las estructuras de negocio, pero estás ansioso de aprender más.

Si se parece a tí, entonces sí.

Nota: Aún cuando este libro hace énfasis en la creación de aplicaciones web, muchas de éstas ideas son aplicables en actividades que no están relacionadas con el software. Las sugerencias acerca de equipos pequeños, generación de prototipos rápidos, iteraciones y muchas otras más pueden servir como una guía si se está al inicio un negocio, escribiendo un libro, diseñando un sitio web, grabando un álbum o haciendo una variedad de otras actividades. Una vez que hayas iniciado Haciéndolo Realidad en un área de tu vida, verás como estos conceptos se pueden aplicar a una amplia gama de disciplinas.



Sobre 37signals

Qué hacemos

37signals es un pequeño equipo que crea software centrado en la simpleza. Nuestros productos te ayudan a colaborar y estar organizado. Más de 350.000 personas y pequeñas empresas usan nuestras aplicaciones web para lograr sus objetivos. Jeremy Wagstaff, del Wall Street Journal, escribió, "Los productos de 37signals son hermosamente simples, son herramientas intuitivas y elegantes que hacen que una pantalla de Outlook se vea como una cámara de torturas". Nuestras aplicaciones nunca te pondrán en el potro.

Nuestro modus operandi

Creemos que el software es demasiado complejo. Demasiadas características, demasiados botones, demasiado que aprender. Nuestros productos hacen menos que la competencia — intencionalmente. Nosotros creamos productos que trabajan mejor, se sienten mejor, te permiten hacer las cosas a tu manera y son más fáciles de usar.

Nuestros Productos

A la fecha de publicación de este libro, tenemos cinco productos comerciales y un framework de código abierto para aplicaciones web.

Basecamp cambia la manera de manajar proyectos. En vez de Gantts, gráficos vistosos, y pesadas hojas de cálculo de estadísticas, Basecamp ofrece una pizarra de mensajes, listas de tareas, una agenda simple, escritura colaborativa, y la posibilidad de compartir archivos. Por el momento, cientos de miles estan de acuerdo en que es una forma mejor. Farhad Manjoo de Salon.com dijo: "Basecamp representa el futuro del software de la Web."

Campfire ofrece un simple salón grupal de chat a la necesidad de hacer negocios. Las empresas actualizadas comprenden cuan valioso puede ser una sala de chat persistente en tiempo real. El chat convencional es bueno para chats de 1-a-1, pero es miserable para 3 o más personas a la vez. Campfire resuelve ese problema y con mucha facilidad.

Backpack es la alternativa a esos confunsos, complejos, organizadores personales del tipo "organiza tu vida en 25 simples pasos". Backpack simplemente toma páginas, notas, listas de tareas, y recordatorios desde teléfonos móviles/emails. Es una nueva idea en una categoría de producto que sufre una status-quo-itis. Thomas Weber de Wall Street Journal dijo: "Es el mejor producto en su clase" y David Pogue del New York Times lo denominó como "Una herramienta de organización muy cool".

Writeboard te permite escribir, compartir, revisar y comparar texto solo o con otros. Es la refrescante alternativa a los gordos procesadores de textos que son inútiles para el 95% de lo que escribes. John Gruber de Daring Fireball dijo, "Writeboard podria ser la más clara, simple aplicación web que jamás haya visto". El Guru-web Jeffrey Zeldman dijo, "Las mentes brillantes de 37signals lo han logrado nuevamente."

Ta-da List mantiene todas tus listas de tareas juntas, organizadas y online. Las mantiene para tí o puedes compartirlas con otros para una fácil colaboración. No hay otra forma mas fácil de lograr los objetivos. Más de 100,000 listas con cerca de 1,000,000 de ítems se han creado hasta ahora.

Ruby on Rails, para desarrolladores. Es un completo framework de código abierto para desarrollo web, escrito en lenguaje Ruby, que permite crear de manera rápida y fácil aplicaciones productivas. Rails toma en cuenta el tiempo de tu trabajo para que puedas enfocarte en tus ideas. Nathan Torkington del imperio de publicacion O'Reilly dijo "Ruby on Rails es increíble. Usarlo es como estar viendo una película de kung-fu, donde una docena de frameworks malvados se preparan para golpear al nuevo y pequeño recién llegado, para terminar al final derrotados en una gran variedad de imaginativas formas".

Puedes encontrar más sobre nuestros productos y nuestra empresa en nuestro sitio web, en www.37signals.com.



Advertencias, negaciones y otros ataques preventivos.

Para dejar algunas cosas en claro, estas son nuestras respuestas a los reclamos que comunmente escuchamos:

"Estos métodos no funcionan para mí."

Haciéndolo Realidad es un sistema que ha funcionado fabulosamente para nosotros. Dicho esto, las ideas de este libro puede que no sean aplicables a todos los proyectos. Si tú creas un sistema de armamento, una planta de control nuclear, un sistema bancario con millones de usuarios u otro sistema crítico de finanzas o de vida, vas a verte frustrado con nuestra actitud permisiva. No lo dudes y toma precauciones adicionales.

Y esto no significa que debe ser todo o nada. Aún cuando no puedas implementar a pleno Haciéndolo Realidad, existen algunas ideas que puedes introducir dentro de sus límites.

"Ustedes no inventaron esta idea."

Nosotros no decimos que inventamos estos métodos. Muchos de estos conceptos estuvieron de una u otra manera entre nosotros por mucho tiempo. No te vuelvas susceptible si leyendo alguno de nuestros consejos te recuerda algo que ya leíste en un weblog o en algún libro publicado 20 años atrás. Definitivamente es posible. Estos métodos no son de ninguna manera exclusivos de 37signals. Simplemente te relatamos cómo nosotros trabajamos y lo bien que esto ha funcionado para nosotros.

"Su visión es muy absolutista."

Si nuestra manera de decir las cosas suena a "lo sabemos todo", ten nos un poco de paciencia. Creemos que es mejor presentar estas ideas con trazos gruesos que de una manera débil e ineficiente. Si esto suena engreído o arrogante, que así sea. Preferimos ser provocativos que arrojar duda con "eso depende...". Por supuesto que habrá momentos donde estas reglas deberán ser acotadas o rotas y algunas de estas estrategias pueden no aplicarse a tú situación. Usa tu juicio e imaginación.

"Esto no funcionará dentro de mi empresa."

¿Crees que tu empresa es muy grande para Hacerlo Realidad? Inclusive Microsoft está Haciéndolo Realidad (y dudamos que sea más grande que ellos).

Aún si tu empresa funciona con cronogramas a largo plazo y grandes equipos, todavía existe la posibilidad de volverlo realidad. El primer paso es cortar todo en pequeñas unidades. No se logra resolver nada mientras haya mucha gente involucrada. Mientras menos presionado se encuentre, mas rápido — y mejor — resultarán las cosas.

Garantizado, podrá costarte un poco de marketing. Impulsa a tu empresa en el proceso de Hacerlo Realidad. Muestrales este libro. Muestrales resultados reales que pueden ser logrados en menos tiempo y con grupos de trabajo más pequeños.

Explica que Haciéndolo Realidad es una inversión de bajo costo y bajo nivel de riesgo como una manera de probar nuevos conceptos. Observa si puede separarse del común en un pequeño proyecto como prueba de concepto. Demuestra resultados.

O si deseas demostrar coraje, hazlo encubierto. Vuela por debajo del radar y demuestra resultados reales. Este fue el método empleado por el equipo de Start.com mientras estaban Haciéndolo Realidad en Microsoft. "He observado como trabaja el equipo de Start.com, ellos no piden permiso." dijo Robert Scoble, Evangelista Técnico de Microsoft. "Ellos tienen un jefe que les provee su espacio. Ellos toman las tareas en pequeñas unidades y responden en tiempo y forma."

Entregando Start.com de Microsoft

En las grandes empresas, los procesos y las reuniones marcan la norma. Muchos meses son invertidos en la planificación de características y la justificación de los detalles con el objetivo de que todos concuerden en lo que es "correcto" para el cliente.

Este puede sea el mejor método para sistemas enlatados, pero con la web nosotros tenemos una ventaja increíble. ¡Simplemente entrégalo!. Deja que el usuario te indique lo que está bien o no — aún mejor — tú puedes corregirlo y entregarlo el mismo día si así lo deseas!. No hay comentario más valioso que el de tu cliente — resiste la necesidad de iniciar largas charlas y justificaciones. Simplemente entrégalo y demuestra su punto.

Mucho más fácil es decir que hacer — esto implica:

No son necesarios meses de planificación.
No es necesario escribir especificaciones durante meses — los cimientos de sus especificaciones deben estar fijos y los detalles deben ser deducidos y refinados durante la fase de desarrollo. No intentes atar todos los cabos y fijar cada detalle antes de iniciar el desarrollo.

Entrega menos funcionalidad, pero de mayor calidad.
No necesitas un enfoque explosivo con cada versión y un montón de nuevas funciones. Entrega a los usuarios pequeñas porciones que puedan digerir.

Si existen pequeños errores, entrega tan pronto tengas establecidos los escenarios claves y luego, de manera gradual, las correcciones en la web. Mientras más rápido tengas respuestas de los usuarios mejor. Las ideas pueden sonar excelentes en papel, pero puede que no sean óptimas en la práctica. Será mucho mejor que puedas determinar las fallas principales de una idea lo más pronto posible.

Una vez que iteres rápidamente por este proceso y reacciones a las necesidades del cliente, establecerás un vínculo con éste. Recuerda que el objetivo es ganar un cliente construyendo lo que él necesita.

—Sanaz Ahari, Program Manager de Start.com, Microsoft


La línea de inicio capítulo 2

Construye menos

Haz menos que tu competencia

El pensamiento tradicional dice que para vencer a tus competidores necesitas estar por sobre ellos. Si sus productos poseen cuatro características, tú necesitarás cinco (o 15, o 20). Si ellos gastan X, tu deberás gastar XX. Si ellos tienen 20, tu necesitas 30.

Esta manera de pensar — al estilo de la guerra fría — es un camino sin salida. Es una manera costosa, defensiva y paranoica de crear productos. Empresas paranoicas y defensivas no pueden pensar a futuro, solo pueden pensar en pasado. Ellos no guían, solo siguen.

Si deseas construir una empresa que siga la tendencia, entonces es mejor que dejes este libro ahora.

¿Entonces qué debo hacer? La respuesta es menos. Haz menos que tus competidores para vencerlos. Resuelve los problemas sencillos y deja los complicados y tramposos para otros. En lugar de estar por arriba, intenta por debajo. En lugar de aventajar, intenta hacer menos.

En este libro abarcaremos el concepto de menos, pero para los que recién se inician, menos significa:



¿Cuál es tú problema?

Crea software para tí

Una buena manera de crear software es empezar por resolver tus propios problemas. Tú serás tu propio público y sabrás qué es importante y qué no. Esto te dará una gran ventaja al entregar tu producto.

La clave esta en entender que no estás solo. Si tú tienes este problema, es muy probable que otros cientos de miles tambien lo tengan. Ahí tienes tu mercado. ¿No fué fácil?

Basecamp nació de un problema: como una empresa de diseño, necesitabamos una simple menera de comunicarnos con nuestros clientes acerca de los proyectos. Empezamos haciéndolo mediante extranets que actualizabamos manualmente, pero cambiar a mano el código HTML cada vez que un proyecto debía ser actualizado no funcionaba. Estos sitios de proyecto siempre parecían quedarse viejos y eventualmente eran abandonados. Esto era frustrante porque nos desorganizaba y dejaba a oscuras a los clientes.

Así empezamos a buscar otras opciones. Pero cada herramienta que encontrábamos 1) no hacia lo que nosotros queríamos o 2) estaba sobrecargada de funciones que no necesitamos — como facturación, controles de acceso estrictos, gráficos, etc. En ese momento nos dimos cuenta que debía haber una mejor opción y decidimos construirla.

Cuando tú resuelves tu propio problema, creas una herramienta por la cual te apasionas. La pasión es la clave. Pasión significa que de verdad la usarás y te preocuparás por ella. Y esta es la mejor manera de que otros puedan sentirse apasionados también.

Rascándote tu propia comezón

El mundo del Open Source (Código Abierto) tomó como propio este método hace bastante tiempo ya — ellos lo llaman "rascarse tu propia comezón". Para los desarrolladores de código abierto, esto significa que ellos obtienen la herramienta que ellos necesitan, entregada de la manera que ellos lo quieren. Pero los beneficios más mucho más allá.

Como diseñador o desarrollador de un nuevo programa, te enfrentas con cientos de pequeñas decisiones todos los días: ¿azul o verde? ¿Una o dos tablas? ¿Estático o dinámico? ¿Abortar o recuperar? ¿Cómo es que tomamos estas decisiones? Si es algo que reconocemos es importante, tal vez preguntemos; para el resto, deducimos. Y todas esas deducciones construyen un tipo de duda sobre nuestro programa — una tela de araña llena de presunciones.

Como desarrollador odio esto. Saber que todas esas pequeñas bombas de tiempo están dentro los programas que escribo suben mi estrés. Desarrolladores de código abierto, que rascan su propia comezón, no sufren de esto. Ellos, actuando como sus propios usuarios, saben que el 90% las decisiones que tomaron son correctas. Creo esta es una de las razones por las que muchos llegan a sus casa luego de un agotante día de programación y trabajan sobre código abierto: es relajante.

—Dave Thomas, The Pragmatic Programmer

Nacido de la necesidad

Campaign Monitor realmente nació de la necesidad. Por años la calidad de las opciones en marketing de correo electrónico no han frustrado. Una herramienta puede hacer X e Y pero nunca Z, la otra tiene Y y Z, pero no puede hacer que X funcione correctamente. No podíamos ganar.

Decidimos acomodar nuestro calendario y contruir nuestra soñada herramienta de marketing de correo electrónico. Concientemente decidimos no ver que habian hecho otros y en su lugar construir algo nos facilite la vida a nosotros y a nuestros clientes.

Como era de esperarse, no eramos los únicos que no estábamos contentos con las opciones disponibles. Hicimos unas pequeñas modificaciones a nuestro software de tal manera que cualquier empresa de diseño pudiera usarla y empezamos a comentar la noticia. En menos de seis meses, miles de diseñadores usaban Campaign Monitor para enviar boletines de noticias por ellos y para sus clientes.

—David Greiner, fundador, Campaign Monitor

Necesitas preocuparte de él

Cuando escribes un libro, se necesita más que una historia interesante. Necesitas tener ganas de contar la historia. Necesitas estar involucrado de alguna manera. Si piensas convivir con algo por dos, tres años, o el resto de tu vida, necesitas preocuparte por él.

—Malcolm Gladwell, autor (extraído de Pequeños fragmentos de Malcolm Gladwell)


Financiate a ti mismo

El dinero ajeno es el plan B

La primer prioridad de muchos comienzos de proyecto es conseguir fondos de los inversores. Pero recuerda, si cambias y eliges inversores externos, tendrás que responder a ellos también. Las expectativas crecen. Los inversores quieren recuperar su inversión — y rápido. La parte triste es que el aporte financiero a menudo se sobrepone a la construcción de un producto de calidad.

En estos días no toma mucho tiempo lograr el equilibrio. El Hardware es barato y la abundancia de software open source y gratis ofrecen una gran infraestructura. Y la pasión no tiene marcado el precio.

Entonces, haz lo que puedas con los fondos disponibles. Piensa seriamente y determina qué es realmente esencial y qué puedes dejar de lado. ¿Qué puedes hacer con tres personas en vez de diez? ¿Qué puedes hacer con $20k en vez de $100k?

Las restricciones fuerzan la creatividad

Trabaja con recursos limitados y te verás forzado a contar con restricciones tempranas y más intensamente. Y eso es bueno. La restricciones conducen a innovaciones.

La restricciones también te fuerzan a poner tu idea en producción más temprano que tarde — otro tema importante. Luego de uno o dos meses debes tener una buena idea acerca de si tu proyecto es correcto o no. Si lo es, en poco tiempo podrás auto-sustentarte sin financiamiento externo. Si tu idea no funciona, es tiempo de regresar al tablero de diseño. Al menos ahora lo sabes. Al menos así te puedes retirar fácilmente. Los planes de retirada se vuelven cada vez más complicados una vez que los inversos han sido involucrados.

Si estás creando software sólo para hacer dinero fácil, eso saldrá a la luz. La verdad, una liquidación rápida es bastante improbable. Así que haz foco en construir una herramienta de calidad que tu y tus clientes puedan usar por un largo tiempo.

Dos caminos

[Jake Walker inició una compañía con dinero de inversores (Disclive) y una sin (The Show). Aquí él discute las diferencias entre ambos caminos.]

La raiz de todos los problemas no era obtener el dinero, sino todo lo que venía con él. La expectativas eran simplemente altas. La gente comienza a recibir el salario, y la motivación es "construirlo y venderlo", o buscar alguna otra manera de conseguir el dinero para los inversores. En el caso de la primera compañía, simplemente comenzamos actuando mucho más grande de lo que éramos — sin necesidad de hacerlo...

[Con The Show] no dimos cuenta de que podíamos entregar un mejor producto a menor costo, pero requiriendo más tiempo. Y apostamos con un poco de nuestro dinero que la gente estaría dispuesta a esperar calidad a pesar de la velocidad. pero la compañía ha permanecido (y lo más probable es que siga así) siendo una pequeña operación. Y desde aquel primer proyecto hemos sido financiados por nosotros mismos. Siguiendo algunos términos creativos de nuestros vendedores, nunca necesitamos poner mucho de nuestro dinero. Y las expectativas no son crecer y vender, sino crecer para poder continuar beneficiándonos financieramente.

—Un comentario sacado de Señal vs. Ruído


Ajusta tiempo y presupuesto, Flexibiliza tu alcance

Entrega en tiempo y dentro del presupuesto

He aquí una forma fácil de finalizar y entregar el proyecto en tiempo y dentro del presupuesto: corrigiendo ambos. Nunca gastes más tiempo o dinero en un problema, sólo ajusta su alcance.

Hay un mito que dice así: podemos entregar a tiempo, dentro del presupuesto, y dentro del alcance. Esto casi nunca sucede, y cuando sucede, la calidad se ve deteriorada.

Si no puedes lograr que todo entre dentro del plazo de tiempo y el presupuesto asignado, entonces no extiendas el tiempo y el presupuesto, debes reducir el alcance. Siempre hay tiempo para agregar cosas luego — luego es eterno, el ahora es efímero.

Entregar algo excelente que es un poco más pequeño que lo planeado originalmente, es mejor que algo mediocre y lleno de agujeros porque hubo que hacer algo mágico en tiempo, presupuesto y alcance. Deja la magia a Houdini. Tú tienes un negocio real que realizar y un producto real a entregar.

Aquí están los beneficios de corregir el tiempo y el presupuesto manteniendo un alcance flexible:

Nuestra recomendación: Reduce el alcance. Es mejor hacer medio producto que hacer un mal producto a medias (detallaremos mas adelante).

Uno, dos, tres ...

Cómo un proyecto llega a estar un año antes de lo programado? Un dia a la vez.

—Fred Brooks, ingeniero en software y científico computacional


Ten un enemigo

Elige una pelea

A veces la mejor manera de saber como debería ser tu aplicación es tener claro lo que no debería ser. Descubre al enemigo de tu aplicación y así encenderás una luz que te indicará hacia donde ir.

Cuando decidimos crear nuestro software de administración de proyectos, sabíamos que Microsoft Project era el gorila en la habitación. En vez de temerle, lo usamos como motivador. Decidimos que Basecamp sería algo completamente diferente, el anti-Project.

Nos dimos cuenta de que la administración de proyectos no tenía nada que ver con estadísticas, gráficos y reportes — era acerca de la comunicación. Tampoco es acerca de administradores de proyectos sentados mirando desde arriba y transmitiendo desde allí el plan de proyecto. Es acerca de todos tomando responsabilidades como grupo de hacer que todo salga adelante.

Nuestros enemigos fueron los Dictadores de la Administración de Proyecto y las herramientas que ellos utilizaban para azotar. Nosotros queríamos democratizar las administración de proyectos — hacer que cada uno fuera parte de ella (inclusive el cliente). Los proyectos obtienen mejores resultados cuando todos sienten ser parte del proceso.

Cuando fue el turno de Writeboard, sabíamos que allí afuera había competidores con una gran cantidad de características espectaculares. Por esa razón decidimos enfatizar el ángulo "sin alboroto". Creamos una aplicación que le permitió a la gente compartir y colaborar en ideas de una manera simple, sin molestarlos con características no esenciales. Si no era esencial lo dejábamos fuera. Y en sólo tres meses después del lanzamiento, mas de 100,000 Writeboards habían sido creadas.

Cuando comenzamos con BackPack nuestro enemigo eran las estructuras y las reglas rígidas. La gente debe poder organizar su información a su manera — no basándose en una serie de pantallas preestablecidas o un sinfín de campos requeridos en un formulario.

Un bonus que se obtiene al tener un enemigo es un mensaje de marketing muy claro. La gente está alimentada por el conflicto. Y también entienden un producto al compararlo con otros. Con un enemigo elegido, se está alimentado a la gente con una historia que ellos quieren escuchar. No sólo entenderán tu producto mejor y más rápido, sino que tomarán partido. Y esa es una segura forma de obtener atención y generar pasión.

Ahora, con todo esto dicho, es también importante no obsesionarse con la competitividad. Sobre-analiza otro producto y estarás limitando tu manera de pensar. Da un vistazo y luego sigue adelante con tu propia visión y tus propias ideas.

No sigas al líder

Los Marketers (y todos los seres humanos) están bien entrenados para seguir al líder. El instinto natural es descubrir en que está trabajando la competencia y luego tratar de exceder aquel descubrimiento — ser más barato que tu competencia quien compite en precio, o más rápido con quien compite en velocidad. El problema es que una vez que el consumidor ha creído la historia de otro, y cree en esa mentira, convencerlo de cambiar su manera de pensar es lo mismo que persuadir para que admita que estaba equivocado. Y la gente odia admitir sus equivocaciones.

En vez de eso, debes contar una historia diferente y persuadir a los escuchas de que tu historia es más importante que la historia en la que ellos creen actualmente. Si tu competencia es más rápida, tu debes ser más barato. Si ellos venden el concepto de salud, tu debes vender el concepto de conveniencia. No sólo la declaración al estilo "Nosotros somos más baratos!", sino contar una historia que sea completamente diferente a la que ya se ha dicho.

Seth Godin, autor (de Se un mejor Mentiroso)

¿Cuál es el problema clave?

Una de las maneras más rápidas de meterse en problemas es mirar qué es lo que está haciendo tu competencia. Esto ha sido especialmente verdad para nosotros en BlinkList. Desde el lanzamiento han salido otros 10 servicios de bookmarking. Algunas personas han comenzado a generar plantillas de cálculo con detalladas comparaciones entre las características.

De cualquier modo, esto podría conducirte a lugares complicados. En vez de eso, enfocamos nuestras fuerzas en la gran pintura y nos continuamos preguntando cuál es el problema principal que estamos tratando de resolver y cómo podemos hacerlo.

—Michael Reining, co-foundador, MindValley & Blinklist


No debe ser una Tarea

Tu pasión — o su ausencia — quedará en evidencia

Cuanto menos atareada sea la construcción de tu aplicación, mejor será. Intenta mantenerlo pequeño y manejable para que puedas disfrutar del proceso.

Si tu aplicación no te excita algo anda mal. Si sólo estás trabajando por un desembolso económico, esto se evidenciará. Del mismo modo, si sientes pasión por tu aplicación, esto se demostrará en el producto final. La gente sabe leer entre líneas.

La presencia de la pasión

En diseño, donde el significado es, en general, controversialmente subjetivo o dolorosamente inescrutable, pocas cosas son más aparentes y lúcidas que la presencia de pasión. Esto es verdad en el diseño de un producto que te encanta o uno que no te produce nada; en ambos casos es difícil detectar la inversión emocional invertida por las manos que lo construyeron.

El entusiasmo se manifiesta fácilmente, pero la indiferencia es igualmente visible. Si tu compromiso no se acerca a una genuina pasión por el trabajo, esto se transforma en vacío imposible de ocultar, no importa cuan elaborado o atractivo el diseño sea.

—Khoi Vinh, Subtraction.com

La panadería

A esta altura los negocios americanos son de desarrollar una idea, hacerla rentable, venderla mientras siga siéndolo y luego salir del juego o diversificarse. Es sólo cuestión de absorber todo lo posible. Mi idea fue: Disfruta haciendo el pan; véndelo, a la gente le gusta, vendele más. Conserva la panadería en funcionamiento porque estás realizando buen alimento, y a la gente le gusta.

—Ian MacKaye, miembro de Fugazi y co-funcdador de Dischord Records
(de Gente de Salon.com | Ian MacKaye)


Mantente ligero capítulo 3

Menos masa

Cuanto más ligero seas, más fácil será cambiar

Cuanta más masa tenga un objeto, más energía es necesaria para cambiar su dirección. Es tan cierto en el mundo de los negocios como en el mundo físico.

En lo que respecta a tecnología web, los cambios deben ser rápidos y baratos. Si no puedes cambiar sobre la marcha, perderás terreno frente a alguien que pueda. Por eso tienes que intentar tener menos peso.

La masa la incrementan...

La masa la reducen...

Con menos masa puedes cambiar de dirección rápidamente. Puedes reaccionar y evolucionar. Puedes centrarte en las buenas ideas y descartar las malas. Puedes escuchar y responder a tus clientes. Puedes integrar nuevas tecnologías ahora en lugar de más tarde. En vez de un portaaviones, pilotas una lancha motora. Disfruta de eso.

Por ejemplo, imaginemos una empresa ligera, con menos masa, que ha construído un producto con menos software y menos funcionalidades. Por otra parte tenemos una empresa con más masa que tiene un producto con muchas más funcionalidades y más software. Supongamos que una nueva tecnología como Ajax o un nuevo concepto como el etiquetado aparece. ¿Quien va a ser capaz de adaptar su producto más rápido? El equipo con más software y funcionalidades y un plan de acción a 12 meses vista, o el equipo con menos software, menos funcionalidades y un proceso orgánico del tipo "centrémonos en lo que nos tenemos que centrar ahora mismo"?

Obviamente la compañía con menos masa está en una posición mejor para ajustarse a las peticiones reales del mercado. La compañía con más masa probablemente estará discutiendo los cambios o encajándolos dentro de su proceso burocrático mucho después de que la compañía con menos masa haya hecho el cambio. La compañía con menos masa está dos pasos por delante mientras que la compañía con más masa todavía está aprendiendo a andar.

Los negocios ágiles, ligeros y con menos masa pueden cambiar su modelo de negocio completo, producto, conjunto de funcionalidades y mensajes de marketing. Pueden cometer errores y solucionarlos rápidamente. Pueden cambiar sus prioridades, línea de productos, y enfoque. Y, lo más importante, pueden cambiar de idea.



Reduce el coste asociado al cambio

Permanece flexible reduciendo lo que te obstaculiza el cambio

El cambio es tu mejor amigo. Cuanto más caro sea hacer un cambio, será menos probable que lo hagas. Y si tu competencia puede cambiar más rápido que tú, tienes una gran desventaja. Si el cambio se hace demasiado caro, estás perdido.

Aquí es donde permanecer ligero te ayuda de verdad. La capacidad de cambiar en un instante es algo que los equipos pequeños tienen por defecto y que los equipos grandes nunca pueden tener. Aquí es donde los tipos grandes envidian a los tipos pequeños. Lo que que puede costar cambiar semanas a un equipo grande de una organización enorme, puede suponer sólo un día en una organización pequeña y ágil. La ventaja no tiene precio. Los cambios baratos y rápidos son el arma secreta de los pequeños.

Y recuerda: todo el capital, todo el marketing, toda la gente del mundo no puede comprar la agilidad que tienes por ser pequeño.

Cuando se trata de tecnología web, el cambio debe ser fácil y barato. Si no puedes cambiar sobre la marcha, perderás terreno frente a alguien que pueda. Por eso tienes que centrarte en tener menos masa.

Eventualidad

La eventualidad es uno de los principios fundamentales de la agilidad, y es la más cercana a la auténtica magia. Las propiedades de una eventualidad no se diseñan o se construyen, sencillamente ocurren como un resultado dinámico del resto del sistema. "Eventualidad" viene del latín de mediados del Siglo XVII, en el sentido de "evento imprevisto". No puedes programarla ni planificarla, pero puedes cultivar un entorno donde la dejes suceder y beneficiarte de ella.

Un ejemplo clásico de eventualidad lo tenemos en el comportamiento de agrupación de los pájaros. Una simulación por ordenador podría reducirse a utilizar tres reglas sencillas (del tipo "no chocarse con otro"), y de repente consigues un comportamiento muy complejo a medida que la bandada flota y redirige su rumbo elegantemente en el cielo, cambiando de forma alrededor de obstáculos, y así sucesivamente. Nada de este complejo comportamiento (como cambiar a la misma forma alrededor de obstáculos) se especifica en las reglas; aparece de la dinámica del sistema.

Las reglas sencillas, como ocurre con la simulación de los pájaros, conducen a un comportamiento complejo. Las reglas complejas, como ocurre con la legislación de impuestos en la mayoría de los países, conducen a un comportamiento estúpido.

Muchas prácticas comunes de desarrollo de software tienen el mismo efecto secundario desafortunado de comportamiento eventual. La mayoría de los intentos de optimización — acotar algo muy explicitamente — reducen la amplitud y el alcance de interacciones y relaciones, que es el mismo origen de la eventualidad. En el ejemplo de la bandada de pájaros, como en un sistema bien diseñado, son las interacciones y relaciones las que crean un comportamiento interesante.

Cuanto más ciñamos las cosas, quedará menos espacio para que aparezca una solución eventual. Ya sea cerrar requisitos antes de que estén bien comprendidos, o inventar navigaciones complejas y escenarios de workflow antes de dejar que los usuarios finales jueguen con el sistema, el resultado es el mismo: un sistema estúpido, demasiado complicado, en lugar de un sistema limpio y elegante que acepte las eventualidades.

Mantenlo pequeño. Mantenlo simple. Deja que suceda.

—Andrew Hunt, The Pragmatic Programmers


Los Tres Mosqueteros

Usa un equipo de tres para la versión 1.0

Para la primera versión de tu aplicación, empieza sólo con tres personas. Es el número mágico que te dará suficiente mano de obra a la vez que te mantiene eficiente y ágil. Empieza con un desarrollador, un diseñador, y un encargado de limpieza (alguien que pueda vagar entre ambos mundos).

Desde luego, es un desafío contruir una aplicación con sólo tres personas. Pero si tienes el equipo adecuado, merece la pena. La gente con talento no necesita recursos ilimitados. Ellos sacan partido del desafío de trabajar con limitaciones y usar su creatividad para resolver problemas. Tu falta de mano de obra significa que te verás obligado a tratar con pros y contras del proceso antes — y eso es bueno. Te obligará a imaginar tus prioridades cuanto antes. Y podrás comunicarte sin tener que preocuparte constantemente por dejar gente fuera del ciclo.

Si no puedes contruir tu versión inicial con tres personas, entonces necesitas otras personas o necesitas aligerar tu versión inicial. Recuerda, está bien mantener tu primera versión pequeña y ajustada. Enseguida podrás ver si tu idea tiene alas, y si es así, tendrás una base limpia y simple sobre la que construir.

La Ley de Metcalfe y los equipos de proyecto

Mantén el equipo tan pequeño como sea posible. La Ley de Metcalfe, que dice "el valor de un sistema de comunicación crece a un ritmo equivalente a aproximadamente el cuadrado del número de usuarios del sistema", tiene un corolario en lo que respecta a equipos de proyecto: La eficiencia del equipo es aproximadamente la inversa al cuadrado del número de miembros del equipo. Estoy empezando a pensar que tres personas son óptimas para un lanzamiento de la versión 1.0 de un producto... Empieza reduciendo el número de personas que tienes previsto incorporar al equipo, y entonces redúcelo un poco más.

—Marc Hedlund, emprendedor de O'Reilly Media

Flujo de comunicaciones

La comunicación fluye más fácilmente en equipos pequeños que en equipos grandes. Si eres la única persona de un proyecto, la comunicación es sencilla. El único canal de comunicaciones es entre tí y el cliente. A medida que el número de personas de un proyecto aumenta, sin embargo, también aumenta el número de canales de comunicación. No se incrementa en adición; a medida que el número de personas aumenta, se multiplica en proporción al número de personas.

—Steve McConnell, Ingeniero de Software Jefe en Construx Software Builders Inc.
(de Less is More: Jumpstarting Productivity with Small Teams)


Acepta las restricciones

Deja que las limitaciones te conduzcan a soluciones creativas

Nunca hay nada suficiente para hacer cosas. No hay tiempo suficiente. No hay dinero suficiente. No hay gente suficiente.

Eso es bueno.

En vez de desesperarte con estas restricciones, aceptalas. Deja que te guíen. Las restricciones te conducen a innovar y te obligan a centrarte. En lugar de tratar de eliminarlas, úsalas para tu provecho.

Cuando 37signals estaba contruyendo Basecamp, tuvimos montones de limitaciones. Tuvimos:

Sentimos la preocupación del "no es suficiente". Así que mantuvimos nuestro marco pequeño. Sólo de ese modo pudimos echar tanta dedicación en ello. Cogimos tareas grandes y las desmenuzamos en pequeños pedacitos que abordamos de uno en uno. Nos movimos paso a paso y fuimos priorizando sobre la marcha.

Eso nos obligó a sacar a relucir soluciones creativas. Redujimos el coste asociado al cambio construyendo siempre menos software. Le dimos a la gente sólo las funcionalidades necesarias para resolver sus problemas a su propia manera — y entonces nos apartamos. La diferencia horaria y la distancia entre nosotros nos hizo más eficientes en nuestras comunicaciones. En lugar de reunirnos en persona, nos comunicamos casi exclusivamente por correo electrónico, lo que nos obligó a ir al grano rápidamente.

Las restricciones a menudo son ventajas disfrazadas. Olvida los capitales de riesgo, los ciclos de lanzamiento largos, y contrataciones urgentes. En vez de eso, trabaja con lo que tienes.

Evita plagas

Lo que se ha descrito como "elegancia cosmética", probablemente se describa mejor como "plaga de funcionalidades"; ya que como los hongos en una planta, gradualmente se desarrollan y desdibujan el auténtico perfil del producto, mientras drenan su savia. El antídoto para la plaga de funcionalidades es, por supuesto, el "plazo límite por restricción". Esto da como resultado funcionalidades descartadas en proporción al tiempo que llevaría implementarlas. A menudo ocurre que las funcionalidades más utiles son las que más tiempo llevan en implementar. Luego la combinación de la plaga y el plazo límite produce el software que conocemos y queremos, que consiste en grandes cantidades de funcionalidades inútiles.

—Jef Raskin, autor (de "Why Software Is the Way It Is")


Sé tú mismo

Diferénciate de las grandes compañías siendo personal y amistoso

Muchas empresas pequeñas cometen el error de actuar a lo grande. Como si percibieran su tamaño como una debilidad que tuviera que ser ocultada. Muy mal. Ser pequeño en realidad puede suponer una gran ventaja, especialmente en lo que respecta a la comunicación.

Las empresas pequeñas disfrutan de menos formalidades, menos burocracia, y más libertada Las compañías pequeñas están más cerca del cliente por definición. Eso significa que pueden comunicarse de forma más directa y personal con los clientes. Si eres pequeño, puedes utilizar lenguaje corriente en lugar de jerga. Tu sitio y tu producto pueden tener una voz humana en vez de sonar como un autómata corporativo. Ser pequeño significa que puedes hablar con tus clientes, no hacia ellos.

También hay ventajas en las comunicaciones internas de las compañías pequeñas. Puedes evitar formalidades. No hay necesidad de arduos procesos y varias conclusiones para todo. Todo el mundo implicado en el proceso puede hablar abierta y honestamente. Este flujo de ideas sin estorbos es una de las grandes ventajas de permanecer pequeño.

Sé orgulloso, desafiantemente sincero

Aunque puedas creer que al cliente se le puede engañar con exageraciones sobre la plantilla de tu empresa o la variedad de tus ofertas, los listos, los que de verdad quieres, siempre sabrán la verdad — ya sea por intuición o deducción. Vergonzosamente, yo he sido parte de mentiras inocentes como esta en el pasado, y ninguna de esas situaciones acabó en lo que más importa a un negocio: relaciones duraderas, importantes y mutuamente beneficiosas con gente que tenga una necesidad real de los servicios ofrecidos. La mejor forma hubiera sido ser orgullosa y desafiantemente sincero sobre el tamaño exacto y el amplitud de la compañía.

—Khoi Vinh, Subtraction.com

En cualquier momento

No importa en qué negocio estés, un buen servicio al cliente tiene que ser la mayor demanda que cualquier cliente pueda hacer. Lo exigimos para los servicios que utilizamos, así que ¿por qué deberíamos pensar que nuestros clientes iban a ser diferentes? Desde el primer instante hicimos fácil y transparente para nuestros clientes ponerse en contacto con nosotros para cualquier cantidad de preguntas que pudieran tener. En nuestra página web ofrecemos un número gratuito que redirige a nuestros teléfonos móviles y en nuestras tarjetas de visita cada uno de nosotros muestra nuestros teléfonos móviles. Recalcamos a nuestros cliente que pueden ponerse en contacto con nosotros en cualquier momento, sin importar el problema que tengan. Nuestros clientes aprecian este nivel de confianza y nadie ha abusado jamás de este servicio.

—Edward Knittel, Director de Ventas y Marketing, KennelSource


Prioridades capítulo 4

Cuál es la Gran Idea

Diferénciate de compañías más grandes siendo más personal y amistoso

Define explícitamente una visión para tu aplicación. ¿Para qué sirve? ¿De qué se trata la aplicación en realidad? Antes de diseñar o programar cualquier cosa necesitas conocer el propósito de tu producto — la visión. Piensa en grande. ¿Porqué existe? ¿Qué la hace diferente de otros productos similares?

Esta visión guiará tus decisiones y te mantendrá en una ruta consistente. En cualquier momento que hayan dudas, pregúntate: "¿Estamos siendo fieles a la visión?"

Además, tu visión debiera ser breve. Una frase debiera ser suficiente para transmitir la idea. He aquí la visión para cada uno de nuestros productos:

Con Basecamp, por ejemplo, la visión era "la administración de proyectos es comunicación". Creíamos fehacientemente que la comunicación efectiva en un proyecto lleva a la propiedad colectiva, devoción e ímpetu. Encausa el trabajo de todos hacia un objetivo común. Sabíamos que si Basecamp podía lograr esto, todo lo demás seguiría naturalmente.

Esta visión nos condujo a mantener Basecamp tan abierto y transparente como fuese posible. En lugar de limitar la comunicación dentro de una firma, le dimos también acceso a los clientes. Pensamos menos en autorizaciones y más sobre cómo incentivar la participación de todos los participantes. La visión explica porqué evitamos las planillas, gráficos, tablas, reportes y estadísticas y nos concentramos en prioridades de la comunicación como mensajes, comentarios, listas y compartir archivos. Haz la gran decisión sobre tu visión al comienzo y todas las pequeñas decisiones subsiguientes se harán más sencillas.

Filosofía de pizarra

Andy Hunt y yo una vez escribimos un interruptor de tarjetas de débito. Un requerimiento importante era que el usuario de una tarjeta de débito no debiera tener la misma transación aplicada dos veces a su cuenta. En otras palabras, sin importar qué tipo de error ocurriera, el error debía estar en el momento previo a procesar una transación antes que procesar una transacción duplicada.

Así, lo escribímos en nuestra pizarra compartida en letras grandes: Falla en favor de los usuarios.

Eso se sumó a media docena de máximas. En conjunto, éstas guiaban todas esas decisiones engañosas que uno toma al construir algo complejo. Juntas, estas leyes le dieron a nuestra aplicación una fuerte coherencia interna y gran consistencia externa

—Dave Thomas, The Pragmatic Programmers

Haz Mantra

Las organizaciones necesitas guías. Necesitan un esquema; los empleados necesitan saber cada día, cuando se despiertan, porqué están yendo al trabajo. Este esquema debiera ser breve y sencillo, y abarcarlo todo: ¿Porqué existes? ¿Qué te motiva? Yo a esto lo llamo un mantra — una descripción de tres o cuatro palabras del porqué de tu existencia.

Guy Kawasaki, autor (de Make Mantra)


Ignora los detalles al comienzo

Trabaja desde grande a pequeño

Nos fascinan los detalles.

El éxito y la satisfación estan en los detalles.

Sin embargo, éxito no es lo único que encontrarás en los detalles. También encontrarás demora, desacuerdo, reuniones y atrasos. Estas cosas pueden matar la moral y disminuír tus posibilidades de éxito.

¿Cuán a menudo te has encontrado atrapado en un solo diseño o elemento de código por un día entero? ¿Cuán a menudo te has percatado de que el progreso que hiciste hoy no ha sido progreso real? Esto sucede cuando te concentras en los detalles demasiado temprano en el proceso. Hay tiempo de sobra para ser perfeccionista. Hazlo despues.

No te preocupes del tamaño de tus titulares en la primera semana. No tienes que lograr el tono perfecto de verde en la segunda semana. No tienes que mover ese botón "enviar" tres pixeles a la derecha en la tercera. Sólo pon todo en la página por ahora. Luego úsalo. Asegúrate de que funciona. Más tarde podrás ajustarlo y perfeccionarlo.

Los detalles se irán desvelando mientras utilices lo que estás construyendo. Verás qué necesita más atención. Sentirás si falta algo. Sabrás qué baches hay que asfaltar porque tropezarás con ellos constantemente. Es entonces cuando necesitas prestar atención, no antes.

El Diablo está en los detalles

Ya superé la actitud de "vamos a por los detalles directamente" después de tomar clases de dibujo... Si empiezas por dibujar directamente los detalles puedes estar seguro de que el dibujo va a ser un asco. De hecho, no estás comprendiendo nada.

Deberías empezar calculando las proporciones para toda la escena. Entonces esbozas los objetos mayores en la escena, hasta el más pequeño. El esbozo tiene que ser muy holgado hasta este punto. Entonces puedes comenzar con el sombreado, que consiste en dar volument a la vida. Empieza sólo con tres tonos (claro, medio, oscuro). Esto te proporciona un esbozo tonal. Entonces para cada parte de tu dibujo evalua los tres tonos y aplícalos. Hazlo hasta que aparezcan volúmenes (esto requiere varias iteraciones)...

Trabaja de grande a pequeño. Siempre.

—Patrick Lafleur, Creation Objet Inc. (de Signal vs. Noise)


Es un problema cuando es un problema

No pierdas tiempo en problemas que todavía no tienes

¿Necesitas preocuparte sobre cómo escalar a 100000 usuarios si te llevará dos años llegar a ese punto?

¿De verdad necesitas contratar ocho programadores si sólo necesitas tres hoy?

¿De verdad necesitas 12 servidores tope-de-la-gama ahora si puedes aguantar con dos durante un año?

Simplemente, échalo a volar

La gente a menudo pierde mucho tiempo intentando resolver problemas que ni siquiera tienen todavía. No lo hagas. ¡Diablos, nosotros lanzamos Basecamp sin la capacidad de facturar a los clientes! Ya que el producto facturaba en ciclos mensuales, supimos que teníamos un margen de 30 días para resolverlo. Utilizamos ese tiempo para resolver problemas más urgentes y después del lanzamiento, abordamos la facturación. Funcionó perfectamente (y nos obligó a pensar una solución sencilla sin artificios innecesarios)

No sudes antes de tiempo. No construyas más de la cuenta. Aumenta software y hardware a medida que sea necesario. Si vas despacio durante una semana o dos no es el fin del mundo. Simplemente se honesto: explica a tus clientes que tienes algunos problemas de crecimiento. Puede que no se entusiasmen pero apreciarán la franqueza.

En resumidas cuentas: toma las decisiones justo a tiempo, cuanto tengas acceso a la información real que necesites. Mientras tanto, podrás derrochar atención en las cosas que requieren cuidados inmediatos.



“Contrata” a los clientes apropiados

Encuentra cuál es el mercado principal para tu aplicación y enfócate exclusivamente en él

El cliente no siempre tiene la razón. La realidad es que tu tienes que escoger quién es apropiado para tu aplicación y quien no. La buena noticia es que Internet ha hecho el encontrar a la gente apropiada más fácil que nunca.

Si tratas de complacer a todo el mundo, terminarás por no complacer a nadie

Cuando creamos Basecamp, nosotros enfocamos nuestro mercadeo en firmas de diseño. Al limitar nuestro mercado de esta forma, hicimos más probable el atraer a clientes apasionados que, a su vez, hicieran la labor de "evangelizar" el producto. Averigua para quién es realmente tu aplicación, y concéntrate en complacerlos.

La mejor decisión que hemos tomado

La decisión de enfocar Campaign Monitor estrictamente al mercado de diseñadores web fue la mejor que hemos tomado. Nos permitió identificar fácilmente qué prestaciones serían realmente útiles y, más importante, qué prestaciones deberíamos dejar por fuera. No solamente hemos atraído más clientes al dirigirnos a un grupo reducido de personas, sino que todos estos clientes tienen necesidades comunes que hace de nuestro trabajo algo más fácil. Hay muchas prestaciones en Campaign Monitor que carecen de sentido para alguien que no sea un diseñador web.

El enfocarse en un mercado especializado igual hace mucho más fácil que se difundan las noticias sobre tu software. Ahora que contamos con una audiencia bastante definida, podemos anunciarnos en los lugares que frecuentan en línea, publicar artículos que puedan considerar interesantes, y en términos generales crear una comunidad en torno de nuestro producto.

—David Greiner, fundador, Campaign Monitor


Escala después

Todavía no tienes un problema de escalado

"¿Se adaptará mi aplicación cuando millones de usuarios empiecen a usarla?"

¿Sabes qué? Espera a que eso realmente suceda. Si tienes un número enorme de gente sobrecargando tu sistema entonces ¡hurra! Es un problema exagerado que tener. La verdad es que la inmensa mayoría de las aplicaciones web nunca van a alcanzar esa fase. E incluso si empiezas a estar desbordado normalmente no es un tema de todo-o-nada. Tendrás tiempo para adaptarte y responder al problema. Además, tendrás más información del mundo real y mediciones cuando hagas el lanzamiento que podrás utilizar para averiguar en qué partes centrarte.

Por ejemplo, ejecutamos Basecap en un único servidor el primer año. Como empezamos con una configuración tan sencilla, sólo nos llevó una semana implementarla. No empezamos con un cluster de 15 cajas ni perdimos meses preocupandonos por el escalado.

¿Tuvimos algún problema? Unos pocos. Pero también nos dimos cuenta de que la mayoría de los problemas que temíamos, como una breve ralentización, realmente no eran gran cosa para los clientes. Mientras mantentas a la gente en el ciclo, y seas honesto con la situación, lo comprenderán. En retrospectiva, estamos bastante orgullosos de que no haber retrasado el lanzamiento varios meses para crear "la configuración perfecta".

Al principio, hicimos de crear un núcleo del producto sólido nuestra prioridad en vez de obsesionarnos con la escalabilidad y las granjas de servidores. Crea una aplicación excelente y preócupate de qué hacer cuando tenga un éxito salvaje. De lo contrario gastarás energía, tiempo, y dinero centrándote en algo que tal vez nunca suceda.

Lo creas o no, el mayor problema no es escalar, es llegar al punto donde tienes que escalar. Sin el primer problema no tendrás el segundo.

Tienes que repasar de todas formas

Lo cierto es que todo el mundo tiene problemas de escalabilidad, nadie puede estar pendiente de su servicio desde cero a millones de usuario sin repasar prácticamente cada punto de su diseño y arquitectura.

—Dare Obasanjo, Microsoft (de Scaling Up and Startups)


Haz software testarudo

Tu aplicación debe posicionarse

Algunos insisten en que el software debería ser agnóstico. Dicen que es arrogante que los desarrolladores limiten funcionalidades o ignoren peticiones de funcionalidades. Dicen que el software debería ser tan flexible como sea posible.

Nosotros creemos que eso es una estupidez. El mejor software tiene una visión. El mejor software se posiciona. Cuando alguien utiliza software, no están buscando funcionalidades, están buscando un enfoque. Están buscando una visión. Decide cual es tu visión y ve a por ella.

Y recuerda, si no les gusta tu visión hay un montón de otras visiones ahí fuera para la getne. No persigas gente a la que nunca contentarás.

Un ejemplo fantástico es el diseño wiki original. Ward Cunningham y amigos despojaron deliberadamente al wiki de muchas funcionalidades que se consideraban fundamentales para documentos colaborativos en el pasado. En vez de atribuir cada cambio del documento a una persona concreta, eliminaron gran parte de la representación visual de la propiedad. Hicieron que el contenido no tuviera ego ni fecha ni hora. Decidieron que no era importante quien escribió el contenido o cuando fue escrito. Y eso marcó toda la diferencia. Esta decisión fomentó un sentido compartido de comunidad y fue un ingrediente clave en el éxito de la Wikipedia.

Nuestras aplicaciones siguen un camino similar. No intentan ser todo para todos. Tienen una postura. Buscan clientes que sean realmente socios. Hablan a la gente que que comparte nuestra visión. O te subes al carro, o no te subes.



Selección de características capítulo 5

La mitad, no a medias

Haz la mitad de un producto, no hagas un producto a medias

Cuidado con la estrategia de “tener de todo” en el desarrollo de aplicaciones web. Incluye cuanta idea decente se te ocurra y al final terminarás con una versión “a medias” de tu producto. Lo que tú realmente quieres hacer es crear la mitad de un producto que sea el mejor en su clase.

Apégate a lo que es realmente esencial. Las buenas ideas pueden ser tabuladas. Toma lo que creas que tu producto debiera ser y redúcelo a la mitad. Ve restando características hasta que termines solamente con las más esenciales. Y hazlo de nuevo.

Con Basecamp, nosotros iniciamos con solo la sección de mensajes. Sabíamos que esta función era el corazón de la aplicación así que ignoramos “metas”, listas de pendientes, y otros asuntos mientras tanto. Esto nos permitió basar decisiones futuras en uso real en vez de conjeturas.

Comienza con una aplicación ligera e inteligente y deja que adquiera impulso. Luego podrás comenzar a agregar a la base sólida que has creado.



Simplemente no importa

Solamente lo esencial

Nuestra respuesta favorita a la pregunta “¿por qué ustedes no hicieron esto o aquello”? siempre es: “Porque simplemente no importa”. Esta frase encierra lo que hace grande a un producto. Encontrar qué importa y dejar el resto por fuera.

Cuando lanzamos Campfire escuchamos algunas de estas preguntas por parte de personas que usaban el producto por primera vez:

“¿Por qué marcar el tiempo solo cada 5 minutos? ¿Por qué no marcar el tiempo de cada línea de conversación?” Respuesta: Simplemente no importa. ¿Cuán a menudo necesitas llevar control de una conversación a cada segundo o aún a cada minuto? Ciertamente no un 95% del tiempo. Un marcado de 5 minutos es suficiente porque cualquier otra cosa más específica simplemente no importa.

“Porqué no permiten usar negrita o cursiva o colores en los textos de los chats?” Respuesta: Simplemente no importa. Si necesitas hacer énfasis en algo usa la confiable tecla de Bloq Mayús (Caps Lock) o pon unos cuantos asteriscos (*) alrededor de la palabra o frase. Estas soluciones no requieren de software adicional, soporte técnico, capacidad de procesamiento, o una curva de aprendizaje. Además, demasiado formato en un chat basado en texto simple, simplemente no importa.

“¿Por qué no muestran el número total de gente en una sala en un tiempo determinado?” Respuesta: Simplemente no importa. El nombre de todos está en lista por lo que puedes saber quién está ahí; ¿pero qué diferencia hace el que haya 12 o 16 personas? Si esto no cambia tus patrones, entonces simplemente no importa.

¿Sería bonito tener estas cosas? Por supuesto. ¿Pero son esenciales? ¿Realmente importan? No. Y por eso es que las hemos dejado por fuera. Los mejores diseñadores y los mejores programadores no son los que poseen las mejores habilidades, o los dedos más ágiles, o los que pueden hacer olas con Photoshop o el ambiente de su elección, sino que son los que pueden determinar qué es lo que simplemente no importa. Es ahí donde se hacen los verdaderos avances.

La mayoría del tiempo que gastas se va en cosas que simplemente no importan. Si puedes acortar el trabajo y pensar que eso simplemente no importa, obtendrás un nivel de productividad como nunca te lo has imaginado.



Start With No

Make features work hard to be implemented

The secret to building half a product instead of a half-ass product is saying no.

Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it. Just try to take a released feature away from customers and see how pissed off they get.

Don't be a yes-man

Make each feature work hard to be implemented. Make each feature prove itself and show that it's a survivor. It's like "Fight Club." You should only consider features if they're willing to stand on the porch for three days waiting to be let in.

That's why you start with no. Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.

And what do you say to people who complain when you won't adopt their feature idea? Remind them why they like the app in the first place. "You like it because we say no. You like it because it doesn't do 100 other things. You like it because it doesn't try to please everyone all the time."

"We Don't Want a Thousand Features"

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?". Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features."

—-Derek Sivers, president and programmer, CD Baby and HostBaby
(from Say NO by default)


Hidden Costs

Expose the price of new features

Even if a feature makes it past the "no" stage, you still need to expose its hidden costs.

For example, be on the lookout for feature loops (i.e. features that lead to more features). We've had requests to add a meetings tab to Basecamp. Seems simple enough until you examine it closely. Think of all the different items a meetings tab might require: location, time, room, people, email invites, calendar integration, support documentation, etc. That's not to mention that we'd have to change promotional screenshots, tour pages, faq/help pages, the terms of service, and more. Before you know it, a simple idea can snowball into a major headache.

For every new feature you need to...



Can You Handle It?

Build something you can manage

If you launch an affiliate program do you have the systems in place to handle the accounting and payouts? Maybe you should just let people earn credit against their membership fees instead of writing, signing, and mailing a check each month.

Can you afford to give away 1 gb of space for free just because Google does? Maybe you should start small at 100 mb, or only provide space on paying accounts.

Bottom line: Build products and offer services you can manage. It's easy to make promises. It's much harder to keep them. Make sure whatever it is that you're doing is something you can actually sustain — organizationally, strategically, and financially.



Human Solutions

Build software for general concepts and encourage people to create their own solutions

Don't force conventions on people. Instead make your software general so everyone can find their own solution. Give people just enough to solve their own problems their own way. And then get out of the way.

When we built Ta-da List we intentionally omitted a lot of stuff. There's no way to assign a to-do to someone, there's no way to mark a date due, there's no way to categorize items, etc.

We kept the tool clean and uncluttered by letting people get creative. People figured out how to solve issues on their own. If they wanted to add a date to a to-do item they could just add (due: April 7, 2006) to the front of the item. If they wanted to add a category, they could just add [Books] to the front of the item. Ideal? No. Infinitely flexible? Yes.

If we tried to build software to specifically handle these scenarios, we'd be making it less useful for all the cases when those concerns don't apply.

Do the best job you can with the root of the problem then step aside. People will find their own solutions and conventions within your general framework.



Forget Feature Requests

Let your customers remind you what's important

Customers want everything under the sun. They'll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.

We'll hear about "this little extra feature" or "this can't be hard" or "wouldn't it be easy to add this" or "it should take just a few seconds to put it in" or "if you added this I'd pay twice as much" and so on.

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

How did we come to this conclusion? When we first launched Basecamp we tracked every major feature request on a Basecamp to-do list. When a request was repeated by someone else we'd update the list with an extra hash mark (II or III or IIII, etc). We figured that one day we'd review this list and start working from the most requested features on down.

But the truth is we never looked at it again. We already knew what needed to be done next because our customers constantly reminded us by making the same requests over and over again. There was no need for a list or lots of analysis because it was all happening in real time. You can't forget what's important when you are reminded of it every day.

And one more thing: Just because x number of people request something, doesn't mean you have to include it. Sometimes it's better to just say no and maintain your vision for the product.



Hold the Mayo

Ask people what they don't want

Most software surveys and research questions are centered around what people want in a product. "What feature do you think is missing?" "If you could add just one thing, what would it be?" "What would make this product more useful for you?"

What about the other side of the coin? Why not ask people what they don't want? "If you could remove one feature, what would it be?" "What don't you use?" "What gets in your way the most?"

More isn't the answer. Sometimes the biggest favor you can do for customers is to leave something out.

Innovation Comes From Saying No

[Innovation] comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much. We're always thinking about new markets we could enter, but it's only by saying no that you can concentrate on the things that are really important.

—Steve Jobs, CEO, Apple (from The Seed of Apple's Innovation)


El Proceso capítulo 6

Race to Running Software

Get something real up and running quickly

Running software is the best way to build momentum, rally your team, and flush out ideas that don't work. It should be your number one priority from day one.

It's ok to do less, skip details, and take shortcuts in your process if it'll lead to running software faster. Once you're there, you'll be rewarded with a significantly more accurate perspective on how to proceed. Stories, wireframes, even html mockups, are just approximations. Running software is real.

With real, running software everyone gets closer to true understanding and agreement. You avoid heated arguments over sketches and paragraphs that wind up turning out not to matter anyway. You realize that parts you thought were trivial are actually quite crucial.

Real things lead to real reactions. And that's how you get to the truth.

The Real Thing Leads to Agreement

When a group of different people set out to try and find out what is harmonious...their opinions about it will tend to converge if they are mocking up full-scale, real stuff. Of course, if they're making sketches or throwing out ideas, they won't agree. But, if you start making the real thing, one tends to reach agreement.

—Christopher Alexander, Professor of Architecture
(from Contrasting Concepts of Harmony in Architecture)

Get It Working ASAP

I do not think I've ever been involved with a software project — large or small — that was successful in terms of schedule, cost, or functionality that started with a long period of planning and discussion and no concurrent development. It is simply too easy, and sometimes fun, to waste valuable time inventing features that turn out to be unnecessary or unimplementable.

This applies at all levels of development and "get something real up and running" is a fractal mantra. It doesn't just apply to the project as a whole, it is at least equally applicable to the smaller-scale development of components from which the application is built.

When there is a working implementation of a key component available, developers want to understand how it will or won't work with their piece of the application and will generally try to use it as soon as they can. Even if the implementation isn't perfect or complete at first, this early collaboration usually leads to well-defined interfaces and features that do exactly what they need to.

—Matt Hamer, developer and product manager, Kinja


Rinse and Repeat

Work in iterations

Don't expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there's no need to ship perfection. Design screens, use them, analyze them, and then start over again.

Instead of banking on getting everything right upfront, the iterative process lets you continue to make informed decisions as you go along. Plus, you'll get an active app up and running quicker since you're not striving for perfection right out the gate. The result is real feedback and real guidance on what requires your attention.

Iterations lead to liberation

You don't need to aim for perfection on the first try if you know it's just going to be done again later anyway. Knowing that you're going to revisit issues is a great motivator to just get ideas out there to see if they'll fly.

Maybe you're smarter than me

Maybe you're a LOT smarter than me.

It's entirely possible. In fact, it's likely. However, if you're like most people, then like me, you have trouble imagining what you can't see and feel and touch.

Human beings are extremely good at responding to things in the environment. We know how to panic when a tiger enters the room, and how to clean up after a devastating flood. Unfortunately, we're terrible at planning ahead, at understanding the ramifications of our actions and in prioritizing the stuff that really matters.

Perhaps you are one of the few individuals who can keep it all in your head. It doesn't really matter.

Web 2.0, the world where we start by assuming that everyone already uses the web, allows smart developers to put this human frailty to work for them. How? By allowing your users to tell you what they think while there's still time to do something about it.

And that last sentence explains why you should develop this way and how you might want to promote/launch.

Get your story straight. Make sure the pieces work. Then launch and revise. No one is as smart as all of us.

Seth Godin, author/entrepreneur


From Idea to Implementation

Go from brainstorm to sketches to HTML to coding

Here's the process we use to Get Real:

Brainstorm

Come up with ideas. What is this product going to do? For Basecamp, we looked at our own needs. We wanted to post project updates. We wanted clients to participate. We knew that projects had milestones. We wanted to centralize archives so people could easily review old stuff. We wanted to have a big-picture, bird's-eye view of what's going on with all our projects. Together, those assumptions, and a few others, served as our foundation.

This stage is not about nitty gritty details. This is about big questions. What does the app need to do? How will we know when it's useful? What exactly are we going to make? This is about high level ideas, not pixel-level discussions. At this stage, those kinds of details just aren't meaningful.

Paper sketches

Sketches are quick, dirty, and cheap and that's exactly how you want to start out. Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs. This step is all about experimentation. There are no wrong answers.

Create HTML screens

Make an html version of that feature (or section or flow, if it's more appropriate). Get something real posted so everyone can see what it looks like on screen.

For Basecamp, we first did the "post a message" screen, then the "edit a message" screen, and it went on from there.

Don't write any programming code yet. Just build a mock-up in html and css. Implementation comes later.

Code it

When the mock-up looks good and demonstrates enough of the necessary functionality, go ahead and plug in the programming code.

During this whole process remember to stay flexible and expect multiple iterations. You should feel free to throw away the deliverable of any particular step and start again if it turns out crappy. It's natural to go through this cycle multiple times.



Avoid Preferences

Decide the little details so your customers don't have to

You're faced with a tough decision: how many messages do we include on each page? Your first inclination may be to say, "Let's just make it a preference where people can choose 25, 50, or 100." That's the easy way out though. Just make a decision.

Preferences are a way to avoid making tough decisions

Instead of using your expertise to choose the best path, you're leaving it in the hands of customers. It may seem like you're doing them a favor but you're just making busy work for them (and it's likely they're busy enough). For customers, preference screens with an endless amount of options are a headache, not a blessing. Customers shouldn't have to think about every nitty gritty detail — don't put that burden on them when it should be your responsibility.

Preferences are also evil because they create more software. More options require more code. And there's all the extra testing and designing you need to do too. You'll also wind up with preference permutations and interface screens that you never even see. That means bugs that you don't know about: broken layouts, busted tables, strange pagination issues, etc.

Make the call

Make simple decisions on behalf of your customers. That's what we did in Basecamp. The number of messages per page is 25. On the overview page, the last 25 items are shown. Messages are sorted in reverse chronological order. The five most recent projects are shown in the dashboard. There aren't any options. That's just the way it is.

Yes, you might make a bad call. But so what. If you do, people will complain and tell you about it. As always, you can adjust. Getting Real is all about being able to change on the fly.

Preferences Have a Cost

It turns out that preferences have a cost. Of course, some preferences also have important benefits — and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don't understand this, and end up with a lot of cost and little value for their preferences dollar...I find that if you're hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall ui in the right direction.

—Havoc Pennington, tech lead, Red Hat (from Free software and good user interfaces)


"Done!"

Decisions are temporary so make the call and move on

Done. Start to think of it as a magical word. When you get to done it means something's been accomplished. A decision has been made and you can move on. Done means you're building momentum.

But wait, what if you screw up and make the wrong call? It's ok. This isn't brain surgery, it's a web app. As we keep saying, you'll likely have to revisit features and ideas multiple times during the process anyway. No matter how much you plan you're likely to get half wrong anyway. So don't do the "paralyis through analysis" thing. That only slows progress and saps morale.

Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn't work out.

Accept that decisions are temporary. Accept that mistakes will happen and realize it's no big deal as long as you can correct them quickly. Execute, build momentum, and move on.

Be An Executioner

It's so funny when I hear people being so protective of ideas. (People who want me to sign an nda to tell me the simplest idea.)

To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

Explanation:

  • Awful idea = -1
  • Weak idea = 1
  • So-so idea = 5
  • Good idea = 10
  • Great idea = 15
  • Brilliant idea = 20
  • No execution = $1
  • Weak execution = $1000
  • So-so execution = $10,000
  • Good execution = $100,000
  • Great execution = $1,000,000
  • Brilliant execution = $10,000,000

To make a business, you need to multiply the two.

The most brilliant idea, with no execution, is worth $20. The most brilliant idea takes great execution to be worth $20,000,000.

That's why I don't want to hear people's ideas. I'm not interested until I see their execution.

—Derek Sivers, president and programmer, CD Baby and HostBaby


Test in the Wild

Test your app via real world usage

There's no substitute for real people using your app in real ways. Get real data. Get real feedback. Then improve based on that info.

Formal usability testing is too stiff. Lab settings don't reflect reality. If you stand over someone's shoulder, you'll get some idea of what's working or not but people generally don't perform well in front of a camera. When someone else is watching, people are especially careful not to make mistakes — yet mistakes are exactly what you're looking for.

Instead, release beta features to a select few inside the real application itself. Have them use the beta features alongside the released features. This will expose these features to people's real data and real workflow. And that's where you'll get real results.

Further, don't have a release version and a beta version. They should always be the same thing. A separate beta version will only get a superficial walk through. The real version, with some beta features sprinkled in, will get the full workout.

The Beta Book

If developers are nervous releasing code, then publishers and authors are terrified of releasing books. Once a book gets committed to paper, it's seen as a big hairy deal to change it. (It really isn't, but perception and memories of problems with old technologies still linger in the industry.) So, publishers go to a lot of trouble (and expense) to try to make books "right" before they're released.

When I wrote the book Agile Web Development With Rails, there was a lot of pent up demand among developers: give us the book now — we want to learn about Rails. But I'd fallen into the mindset of a publisher. "It isn't ready yet," I'd say. But pressure from the community and some egging on from David Heinemeier Hansson changed my mind. We released the book in pdf form about 2 months before it was complete. The results were spectacular. Not only did we sell a lot of books, but we got feedback — a lot of feedback. I set up an automated system to capture readers' comments, and in the end got almost 850 reports or typos, technical errors, and suggestions for new content. Almost all made their way into the final book.

It was a win-win: I got to deliver a much improved paper book, and the community got early access to something they wanted. And if you're in a competitive race, getting something out earlier helps folks commit to you and not your competition.

—Dave Thomas, The Pragmatic Programmers

Do it quick

  • 1. Decide if it's worth doing, and if so:
  • 2. Do it quick — not perfect. just do it.
  • 3. Save it. upload it. publish it
  • 4. See what people think
    • Though I'm always reluctant to add new features to things, once I have that "yeah!" moment of deciding something is worth doing, it's usually up on the website a few hours later, flawed but launched, letting feedback guide future refinement of it.

      —Derek Sivers, president and programmer, CD Baby and HostBaby


Shrink Your Time

Break it down

Estimates that stretch into weeks or months are fantasies. The truth is you just don't know what's going to happen that far in advance.

So shrink your time. Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time.

The same theory applies to other problems too. Are you facing an issue that's too big to wrap your mind around? Break it down. Keep dividing problems into smaller and smaller pieces until you're able to digest them.

Smaller Tasks and Smaller Timelines

Software developers are a special breed of optimist: when presented with a programming task, they think, "That'll be easy! Won't take much time at all."

So, give a programmer three weeks to complete a large task, and she'll spend two and a half procrastinating, and then one programming. The off-schedule result will probably meet the wrong requirements, because the task turned out to be more complex than it seemed. Plus, who can remember what the team agreed upon three weeks ago?

Give a programmer an afternoon to code a small, specific module and she'll crank it out, ready to move onto the next one.

Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, and cost less to change your mind about or redo. Smaller timelines keep developers engaged and give them more opportunities to enjoy a sense of accomplishment and less reason to think, "Oh I've got plenty of time to do that. For now, let me finish rating songs in my iTunes library."

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide

True Factors

Next time someone tries to pin you down for an exact answer to an unknowable question — whether it's for a deadline date, a final project cost, or the volume of milk that would fit in the Grand Canyon — just start by taking the air out of the room: say "I don't know."

Far from damaging your credibility, this demonstrates the care you bring to your decision-making. You're not going to just say words to sound smart. It also levels the playing field by reframing the question as a collaborative conversation. By learning how exact your estimate needs to be (and why), you can work together to develop a shared understanding about the true factors behind the numbers.

—Merlin Mann, creator and editor of 43folders.com

Solve The One Problem Staring You in the Face

My absolute favorite thing to happen on the web in recent memory is the release and adoption of the "nofollow" attribute. Nobody talked about it beforehand. There were no conferences or committees where a bunch of yahoos could debate its semantic or grammatical nature. No rfc that could turn a simple idea into a 20-line xml snippet I'd have to read up on just to figure out how to use, and then not use because I wasn't sure if I was formatting for version .3 or 3.3b.

It's simple, it's effective, it provided an option for people who wanted an option — and that is far more important when dealing with a population of the web that doesn't care about specifications or deference.

Sometimes solving the next twenty problems is not as useful or as prudent as solving the one staring us right in the face. It wasn't just a small victory against spam (all victories against spam are small), but a victory for those of us who enjoy the simple and swift results that being a web developer is all about.

—Andre Torrez, programmer and VP of Engineering at Federated Media Publishing


La Organización capítulo 7

Unity

Don't split into silos

Too many companies separate design, development, copywriting, support, and marketing into different silos. While specialization has its advantages, it also creates a situation where staffers see just their own little world instead of the entire context of the web app.

As much as possible, integrate your team so there's a healthy back-and-forth dialogue throughout the process. Set up a system of checks and balances. Don't let things get lost in translation. Have copywriters work with designers. Make sure support queries are seen by developers.

Even better, hire people with multiple talents who can wear different hats during development. The end result will be a more harmonious product.



Alone Time

People need uninterrupted time to get things done

37signals is spread out over four cities and eight time zones. From Provo, Utah to Copenhagen, Denmark, the five of us are eight hours apart. One positive side effect of this eight hour difference is alone time.

There are only about 4-5 hours during the day that we're all up and working together. At other times, the us team is sleeping while David, who's in Denmark, is working. The rest of the time, we're working while David is sleeping. This gives us about half of the day together and the other half alone.

Guess which part of the day we get the most work done? The alone part. It's not that surprising really. Many people prefer to work either early in the morning or late at night — times when they're not being bothered.

When you have a long stretch when you aren't bothered, you can get in the zone. The zone is when you are most productive. It's when you don't have to mindshift between various tasks. It's when you aren't interrupted to answer a question or look up something or send an email or answer an im. The alone zone is where real progress is made.

Getting in the zone takes time. And that's why interruption is your enemy. It's like rem sleep — you don't just go to rem sleep, you go to sleep first and you make your way to rem. Any interruptions force you to start over. rem is where the real sleep magic happens. The alone time zone is where the real development magic happens.

Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.

A successful alone time period means letting go of communication addiction. During alone time, give up instant messenging, phone calls, and meetings. Avoid any email thread that's going to require an immediate response. Just shut up and get to work.

Get Into the Groove

We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration...trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — especially interruptions by coworkers — all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble.

—Joel Spolsky, software developer, Fog Creek Software
(from Where do These People Get Their (Unoriginal) Ideas?)


Meetings Are Toxic

Don't have meetings

Do you really need a meeting? Meetings usually arise when a concept isn't clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire. The goal is to avoid meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead.

There's nothing more toxic to productivity than a meeting. Here's a few reasons why:

For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:

Have fewer meetings

There are too many meetings. Push back on meetings that do not make sense or are unproductive. Only book a meeting when you have an important business issue to discuss and you want or need input, approval, or agreement. Even then, resist the urge to invite everyone and their brother — don't waste people's time unnecessarily.

—Lisa Haneberg, author (from Don't Let Meetings Rule!)

Break it Down

As projects grow, adding people has a diminishing return. One of the most interesting reasons is the increased number of communications channels. Two people can only talk to each other; there's only a single comm path. Three workers have three communications paths; 4 have 6. In fact, the growth of links is exponential...Pretty soon memos and meetings eat up the entire work day.

The solution is clear: break teams into smaller, autonomous and independent units to reduce these communications links.

Similarly, cut programs into smaller units. Since a large part of the problem stems from dependencies (global variables, data passed between functions, shared hardware, etc.), find a way to partition the program to eliminate — or minimize — the dependencies between units.

The Ganssle Group (from Keep It Small)


Seek and Celebrate Small Victories

Release something today

The most important thing in software development is motivation. Motivation is local — if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be. In fact, it's probably going to suck.

Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.

So, if you're in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories. Ask yourself "What can we do and release in 4 hours?" And then do it. It could be...

When you find those 4-hour quick wins, you'll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.



El Personal capítulo 8

Hire Less and Hire Later

Add slow to go fast

There's no need to get big early — or later. Even if you have access to 100 of the very best people, it's still a bad idea to try and hire them all at once. There's no way that you can immediately assimilate that many people into a coherent culture. You'll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?

Whenever Jack Welch, former ceo of ge, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long ge could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.

If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.

Brooks' law

Adding people to a late software project makes it later.

—Fred Brooks

Programming and Mozart's Requiem

A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time... The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.

—Joel Spolsky, software developer, Fog Creek Software (from Hitting the High Notes)


Kick the Tires

Work with prospective employees on a test-basis first

It's one thing to look at a portfolio, resume, code example, or previous work. It's another thing to actually work with someone. Whenever possible, take potential new team members out for a "test drive."

Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight. You'll learn pretty quickly whether or not the right vibe is there.

Scheduling can be tough for this sort of thing but even if it's for just 20 or 40 hours, it's better than nothing. If it's a good or bad fit, it will be obvious. And if not, both sides save themselves a lot of trouble and risk by testing out the situation first.

Start small

Try a small test assignment to start. Don't leap in with all of your work at once. Give your new [virtual assistant] a test project or two to work on and see how the chemistry develops. In the beginning, it's too easy to gloss over potential problems with rose-colored glasses. Make it clear this is a test run.

—Suzanne Falter-Barns, author/creativity expert
(from How To Find And Keep The Perfect VA)


Actions, Not Words

Judge potential tech hires on open source contributions

The typical method of hiring for technical positions — based on degrees, resumés, etc. — is silly in a lot of ways. Does it really matter where someone's degree is from or their gpa? Can you really trust a resumé or a reference?

Open source is a gift to those who need to hire technical people. With open source, you can track someone's work and contributions — good and bad — over a lengthy period of time.

That means you can judge people by their actions instead of just their words. You can make a decision based on the things that really matter:

When it comes to programmers, we only hire people we know through open source. We think doing anything else is irresponsible. We hired Jamis because we followed his releases and participation in the Ruby community. He excelled in all the areas mentioned above. It wasn't necessary to rely on secondary factors since we could judge him based on what really matters: the quality of his work.

And don't worry that extra-curricular activities will take focus and passion away from a staffer's day job. It's like the old cliché says: If you want something done, ask the busiest person you know. Jamis and David are two of the heaviest contributors to Rails and still manage to drive 37signals technically. People who love to program and get things done are exactly the kind of people you want on your team.

Open Source Passion

What you want the most from a new hire is passion for what he does, and there's no better way of showing it than a trace of commitment in open source projects.

—Jarkko Laine, software developer
(from Reduce the risk, hire from open source)


Get Well Rounded Individuals

Go for quick learning generalists over ingrained specialists

We'll never hire someone who's an information architect. It's just too overly specific. With a small team like ours, it doesn't make sense to hire people with such a narrowly defined skill-set.

Small teams need people who can wear different hats. You need designers who can write. You need programmers who understand design. Everyone should have an idea about how to architect information (whatever that may mean). Everyone needs to have an organized mind. Everyone needs to be able to communicate with customers.

And everyone needs to be willing and able to shift gears down the road. Keep in mind that small teams often need to change direction and do it quickly. You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.



You Can't Fake Enthusiasm

Go for happy and average over frustrated and great

Enthusiasm. It's one attribute you just can't fake. When it comes time to hire, don't think you need a guru or a tech-celebrity. Often, they're just primadonnas anyway. A happy yet average employee is better than a disgruntled expert.

Find someone who's enthusiastic. Someone you can trust to get things done when left alone. Someone who's suffered at a bigger, slower company and longs for a new environment. Someone who's excited to build what you're building. Someone who hates the same things you hate. Someone who's thrilled to climb aboard your train.

Extra points for asking questions

Observe whether a potential hire asks a lot of questions about your project. Passionate programmers want to understand a problem as well as possible and will quickly propose potential solutions and improvements, which leads to a lot of questions. Clarifying questions also reveal an understanding that your project could be implemented thousands of different ways and it's essential to nail down as explicitly as possible exactly how you imagine your web app working. As you dig into the details, you'll develop a sense of whether the person is a good cultural match.

—Eric Stephens, BuildV1.com


Wordsmiths

Hire good writers

If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.

That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.

An Organized Mind

Good writing skills are an indicator of an organized mind which is capable of arranging information and argument in a systematic fashion and also helping (not making) other people understand things. It spills over into code, personal communications, instant messaging (for those long-distance collaborations), and even such esoteric concepts as professionalism and reliability.

—Dustin J. Mitchell, developer (from Signal vs. Noise)

Clear Writing Leads To Clear Thinking

Clear writing leads to clear thinking. You don't know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what's easy for you, do what's easy for your reader.

—Michael A. Covington, Professor of Computer Science at The University of Georgia
(from How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily)


El Diseño de la Interfaz capítulo 9

La interfaz primero

Diseña la interfaz de usuario antes de comenzar a programar

Demasiadas aplicaciones comienzan con una mentalidad de programar primero. Y esa es una mala idea. La programación es el elemento que más recursos consume en el desarrollo de una aplicación, lo cual significa que es la parte que es mas cara y difícil de cambiar. En vez de empezar con la programación, empieza con el diseño.

El diseño es un elemento relativamente flexible. Un boceto en papel es barato y fácil de modificar. Los diseños en html se pueden cambiar (o desechar) con relativa simplicidad. No se puede decir lo mismo sobre la programación. Diseñar primero te mantiene flexible. Comenzar programando te cierra opciones y conlleva futuros costes adicionales.

Otra razón por la cual conviene comenzar con el diseño es que la interfaz es tu producto. Lo que ven las personas es lo que estás vendiendo. Si simplemente colocas la interfaz al final de la programación se podrán ver las grietas.

Empezamos con la interfaz para poder ver desde el principio el aspecto y funcionamiento de la aplicación. La interfaz se revisa continuamente durante el proceso completo de desarrollo. ¿Tiene sentido? ¿Es fácil de usar? ¿Soluciona el problema que tenemos entre manos? Estas son preguntas que sólo se pueden contestar de verdad cuando se están trabajando con las pantallas reales. Comenzar con el diseño te mantiene flexible y te proporciona las respuestas antes que después en el proceso de desarrollo.

The Orange Pen That Started Blinksale

As soon as I realized my frustration with off-the-shelf invoicing software, I decided to draw out how I would prefer my invoicing solution to work. I pulled out an orange pen, because it was the only thing handy that evening, and had about 75 percent of the ui drawn out within a few hours. I showed it to my wife, Rachel, who was ironing at the time, and asked, "What do you think?" And she replied with a smile, "You need to do this. For real."

Over the next two weeks I refined the designs, and completely mockedup static html pages for almost the entire first version of what would become Blinksale. We never did any wireframes beyond those orangepen sketches, and getting straight into the html design helped us stay excited about how "real" the project was becoming, even though at the time we really didn't know what we were getting into.

Once the html mockups were completed, we approached our developer, Scott, with the idea for Blinksale. Having most of the ui designed up front was extremely beneficial on several levels. First, it gave Scott a real vision and excitement for where we were going. It was much more than just an idea, it was real. Second, it helped us accurately gauge how much of Scott's effort and time it would require to turn the design into a functioning application. When you're financially bootstrapping a project, the earlier you can predict budget requirements, the better. The ui design became our benchmark for the initial project scope. Finally, the ui design served as a guide to remind us what the application was about as we progressed further into development. As we were tempted to add new features, we couldn't simply say, "Sure, let's add that!" We had to go back to the design and ask ourselves where that new feature would go, and if it didn't have a place, it wouldn't get added.

—Josh Williams, founder, Blinksale


Epicenter Design

Start from the core of the page and build outward

Epicenter design focuses on the true essence of the page — the epicenter — and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.

Whatever the page absolutely can't live without is the epicenter. For example, if you're designing a page that displays a blog post, the blog post itself is the epicenter. Not the categories in the sidebar, not the header at the top, not the comment form at the bottom, but the actual blog post unit. Without the blog post unit, the page isn't a blog post.

Only when that unit is complete would you begin to think about the second most critical element on the page. Then after the second most critical element, you'd move on to the third, and so on. That's epicenter design.

Epicenter design eschews the traditional "let's build the frame then drop the content in" model. In that process, the page shape is built, then the nav is included, then the marketing "stuff" is inserted, and then, finally, the core functionality, the actual purpose of the page, is poured in to whatever space remains. It's a backwards process that takes what should be the top priority and saves it for the end.

Epicenter design flips that process and allows you to focus on what really matters on day one. Essentials first, extras second. The result is a more friendly, focused, usable screen for customers. Plus, it allows you to start the dialogue between designer and developer right away instead of waiting for all aspects of the page to fall in line first.



Los Tres Estados de la Solución

Diseña para los estados normal, en blanco y de error

Para cada pantalla tienes que considerar tres posibles estados:

El estado normal es el más evidente. Esta es la pantalla que pasarás más tiempo desarrollando. Pero no te olvides de invertir también tiempo en los otros estados (lee los artículos siguientes para más información sobre el tema).



The Blank Slate

Set expectations with a thoughtful first-run experience

Ignoring the blank slate stage is one of the biggest mistakes you can make. The blank slate is your app's first impression and you never get a second...well, you know.

The problem is that when designing a ui, it's usually flush with data. Designers always fill templates with data. Every list, every post, every field, every nook and cranny has stuff in it. And that means the screen looks and works great.

However, the natural state of the app is one that's devoid of data. When someone signs up, they start with a blank slate. Much like a weblog, it's up to them to populate it — the overall look and feel doesn't take shape until people enter their data: posts, links, comments, hours, sidebar info, or whatever.

Unfortunately, the customer decides if an application is worthy at this blank slate stage — the stage when there's the least amount of information, design, and content on which to judge the overall usefulness of the application. When you fail to design an adequate blank slate, people don't know what they are missing because everything is missing.

Yet most designers and developers still take this stage for granted. They fail to spend a lot of time designing for the blank slate because when they develop/use the app, it's full of data that they've entered for testing purposes. They don't even encounter the blank slate. Sure, they may log-in as a new person a few times, but the majority of their time is spent swimming in an app that is full of data.

What should you include in a helpful blank slate?

First impressions are crucial. If you fail to design a thoughtful blank slate, you'll create a negative (and false) impression of your application or service.

You Never Get A Second Chance...

Another aspect of the Mac OS x ui that I think has been tremendously influenced by [Steve] Jobs is the setup and first-run experience. I think Jobs is keenly aware of the importance of first impressions...I think Jobs looks at the first-run experience and thinks, it may only be one-thousandth of a user's overall experience with the machine, but it's the most important onethousandth, because it's the first one-thousandth, and it sets their expectations and initial impression.

John Gruber, author and web developer (from Interview with John Gruber)


Get Defensive

Design for when things go wrong

Let's admit it: Things will go wrong online. No matter how carefully you design your app, no matter how much testing you do, customers will still encounter problems. So how do you handle these inevitable breakdowns? With defensive design.

Defensive design is like defensive driving. The same way drivers must always be on the lookout for slick roads, reckless drivers, and other dangerous scenarios, site builders must constantly search for trouble spots that cause visitors confusion and frustration. Good site defense can make or break the customer experience.

We could fill a separate book with all the things we have to say about defensive design. In fact, we already have. "Defensive Design for the Web" is the title and it's a great resource for anyone who wants to learn how to improve error screens and other crisis points.

Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they're unlikely to forget it.



Context Over Consistency

What makes sense here may not make sense there

Should actions be buttons or links? It depends on the action. Should a calendar view be in list-form or grid-form? It depends where it's being shown and how long the time period is. Does every global navigation link need to be on every page? Do you need a global search bar everywhere? Do you need the same exact footer on each page? The answer: "It depends."

That's why context is more important than consistency. It's ok to be inconsistent if your design makes more sense that way. Give people just what matters. Give them what they need when they need it and get rid of what they don't. It's better to be right than to be consistent.

Intelligent Inconsistency

Consistency is not necessary. For years, students of ui and ux have been taught that consistency in the interface is one of the cardinal rules of interface design. Perhaps that holds in software, but on the Web, it's just not true. What matters on the Web is whether, on each individual page, the user can quickly and easily advance the next step in the process.

At Creative Good, we call it "intelligent inconsistency": making sure that each page in the process gives users exactly what they need at that point in the process. Adding superfluous nav elements, just because they're consistent with the rest of the site, is just silly.

—Mark Hurst, founder of Creative Good and creator of Goovite.com
(from The Page Paradigm)


Copywriting is Interface Design

Every letter matters

Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you're writing your interface, always put yourself in the shoes of the person who's reading your interface. What do they need to know? How you can explain it succinctly and clearly?

Do you label a button Submit or Save or Update or New or Create? That's copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

You need to speak the same language as your audience too. Just because you're writing a web app doesn't mean you can get away with technical jargon. Think about your customers and think about what those buttons and words mean to them. Don't use acronyms or words that most people don't understand. Don't use internal lingo. Don't sound like an engineer talking to another engineer. Keep it short and sweet. Say what you need to and no more.

Good writing is good design. It's a rare exception where words don't accompany design. Icons with names, form fields with examples, buttons with labels, step by step instructions in a process, a clear explanation of your refund policy. These are all interface design.



One Interface

Incorporate admin functions into the public interface

Admin screens — the screens used to manage preferences, people, etc. — have a tendency to look like crap. That's because the majority of development time is spent on the public-facing interface instead.

To avoid crappy-admin-screen syndrome, don't build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface.

If you have to maintain two separate interfaces (i.e. one for regular folks and one for admins), both will suffer. In effect, you wind up paying the same tax twice. You're forced to repeat yourself and that means you increase the odds of getting sloppy. The fewer screens you have to worry about, the better they'll turn out.

No Separate Interface

The application is everything. Anything that can be changed, added, or adjusted can be done directly through the management area of the application. This allows us to see exactly what our customers see to help them through any problems or questions that they have. And our customers don't have to worry about logging into a separate interface to do different tasks. One minute they might be dealing with appointments for their clients and the next minute they might have to add a new employee. They can't be bothered with jumping between different applications and maintaining a consistent interface they're able to adapt to the application even quicker.

—Edward Knittel, Director of Sales and Marketing, KennelSource


El Código capítulo 10

Less Software

Keep your code as simple as possible

You'd think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you'll have created the dreaded Big Ball of Mud.

The way you fight this complexity is with less software. Less software means less features, less code, less waste.

The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that's alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it's worth five times the effort to solve it.

Less software means you put away the crystal ball. Instead of trying to predict future problems, you deal only with the problems of today. Why? Fears you have about tomorrow often never come to fruition. Don't bog yourself down trying to solve these phantom issues.

From the beginning, we've designed our products around the concept of less software. Whenever possible, we chop up hard problems into easy ones. We've found solutions to easy problems are not only easier to implement and support, they're easier to understand and easier to use. It's all part of how we differentiate ourselves from competitors; Instead of trying to build products that do more, we build products that do less.

Which features you choose to include or omit have a lot to do with less software too. Don't be afraid to say no to feature requests that are hard to do. Unless they're absolutely essential, save time/effort/confusion by leaving them out.

Slow down too. Don't take action on an idea for a week and see if it still seems like a great idea after the initial buzz wears off. The extra marinading time will often help your brain come up with an easier solution.

Encourage programmers to make counteroffers.
You want to hear: "The way you suggested will take 12 hours. But there's a way I can do it that will only take one hour. It won't do x but it will do y." Let the software push back. Tell programmers to fight for what they think is the best way.

Also, search for detours around writing more software. Can you change the copy on the screen so that it suggests an alternate route to customers that doesn't require a change in the software model? For example, can you suggest that people upload images of a specific size instead of doing the image manipulation on the server side?

For every feature that makes it into your app, ask yourself: Is there a way this can be added that won't require as much software? Write just the code you need and no more. Your app will be leaner and healthier as a result.

There is No CODE That is More Flexible Than NO Code!

The "secret" to good software design wasn't in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.

—Brad Appleton, software engineer
(from There is No CODE that is more flexible than NO Code!)

Complexity Does Not Scale Linearly With Size

The most important ruleof software engineering is also the least known: Complexity does not scale linearly with size...A 2000 line program requires more than twice as much development time as one half the size.

The Ganssle Group (from Keep It Small)


Optimize for Happiness

Choose tools that keep your team excited and motivated

A happy programmer is a productive programmer. That's why we optimize for happiness and you should too. Don't just pick tools and practices based on industry standards or performance metrics. Look at the intangibles: Is there passion, pride, and craftmanship here? Would you truly be happy working in this environment eight hours a day?

This is especially important for choosing a programming language. Despite public perception to the contrary, they are not created equal. While just about any language can create just about any application, the right one makes the effort not merely possible or bearable, but pleasant and invigorating. It's all about making the little details of daily work enjoyable.

Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.

We found programming bliss in the language Ruby and passed it on to other developers with our framework Rails. Both share a mission statement to optimize for humans and their happiness. We encourage you to give that combination a spin.

In summary, your team needs to work with tools they love. We've talked here in terms of programming languages, but the concept holds true for applications, platforms, and anything else. Choose the fuse that gets people excited. You'll generate excitement and motivation and a better product as a result.

The kinds of engineers you want

The number one reason I wanted to build our app using Ruby on Rails is that it is so elegant, productive, and beautifully designed. It tends to attract the kind of engineers who care about just those sort of things...those are exactly the kinds of engineers you want on your team because they create the kind of beautiful, elegant and productive software you need to win the market.

—Charles Jolley, Managing Director at Nisus Software (from Signal vs. Noise)


Code Speaks

Listen when your code pushes back

Listen to your code. It will offer suggestions. It will push back. It will tell you where the pitfalls reside. It will suggest new ways to do things. It will help you stick to a model of less software.

Is a new feature requiring weeks of time and thousands of lines of code? That's your code telling you there's probably a better way. Is there a simple way to code something in one hour instead of a complicated way that will take ten hours? Again, that's your code guiding you. Listen.

Your code can guide you to fixes that are cheap and light. Pay attention when an easy path emerges. Sure, the feature that's easy to make might not be exactly the same as the feature you originally had in mind but so what? If it works well enough and gives you more time to work on something else, it's a keeper.

Listen up

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.

—Martin Fowler, Chief Scientist, ThoughtWorks (from Is Design Dead?)

If Programmers Got Paid To Remove Code...

If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better.

Nicholas Negroponte, Professor of Media Technology at MIT
(from And, the rest of the (AIGA Conference) story)


Manage Debt

Pay off your code and design "bills"

We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt.

Hack together some bad code that's functional but still a bit hairy and you're building up debt. Throw together a design that's good enough but not really good and you've done it again.

It's ok to do this from time to time. In fact, it's often a needed technique that helps you do the whole Get-Real-asap thing. But you still need to recognize it as debt and pay it off at some point by cleaning up the hairy code or redesigning that so-so page.

The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don't, you'll just be paying inter est (fixing hacks) instead of paying down the principal (and moving forward).



Open Doors

Get data out into the world via RSS, APIs, etc.

Don't try to lock-in your customers. Let them get their information when they want it and how they want it. To do that, you've got to give up the idea of sealing in data. Instead, let it run wild. Give people access to their information via rss feeds. Offer apis that let third-party developers build on to your tool. When you do, you make life more convenient for customers and expand the possibilities of what your app can do.

People used to think of rss feeds as merely a good way to keep track of blogs or news sites. Feeds have more power than that though. They also provide a great way for customers to stay up to date on the changing content of an app without having to log in repeatedly. With Basecamp feeds, customers can pop the url into a newsreader and keep an eye on project messages, todo lists, and milestones without having to constantly check in at the site.

APIs let developers build add-on products for your app that can turn out to be invaluable. For example, Backpack supplies an api which Chipt Productions used to build a Mac os x Dashboard widget. The widget lets people add and edit reminders, list items, and more from the desktop. Customers have raved to us about this widget and some have even said it was the key factor in getting them to use Backpack.

Other good examples of companies letting data run free in order to get a boomerang effect:

A Widget Makes the Difference

When 37signals released Backpack a while back, my first impression was...eh.

So it was around the time that Chipt Productions released a Backpack widget for Tiger — which was too cool not to download and try — that I gave Backpack a second look. The result? Quite a difference.

Now whenever an idea hits, I pop up the widget, type, and submit — done. Email arrives with something I want to check out? Pop up the widget, type, and submit — done. The widget is an immediate brain dump readily available on each Mac I use. And because everything is web based, there isn't any version control or syncing — just the fluid input of content without having to be concerned about where it's going or how I'll access it later.

—Todd Dominey, founder, Dominey Design
(from Trying on Backpack)


Las Palabras capítulo 11

There's Nothing Functional about a Functional Spec

Don't write a functional specifications document

These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:

Functional specs are fantasies

They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.

Functional specs are about appeasement

They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They're never about making tough choices and exposing costs, things that need to happen to build a great app.

Functional specs only lead to an illusion of agreement

A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it." "Yes it was and we all agreed on it — you even signed off on it." You know the drill.

Functional specs force you to make the most important decisions when you have the least information

You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making decisions — when you have more information, not less.

Functional specs lead to feature overload

There's no pushback during spec phase. There's no cost to writing something down and adding another bullet point. You can please someone who's a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that's how you wind up with an overloaded site that's got 30 tabs across the top of the screen.

Functional specs don't let you evolve, change,and reassess

A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes.

So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.

Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.

Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.

Useless Specs

A "spec" is close to useless. I have never seen a spec that was both big enough to be useful and accurate.

And I have seen lots of total crap work that was based on specs. It's the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

—Linus Torvalds, creator of Linux (from: Linux: Linus On Specifications)

Fight the blockers

I found the people insisting on extensive requirements documents before starting any design were really 'blockers' just trying to slow the process down (and usually people with nothing to contribute on design or innovative thinking).

All our best work was done with a few concepts in our heads about improving a site, doing a quick prototype (static), changing the design a bit and then building a live prototype with real data. After kicking the tires on this prototype, we usually had a real project in motion and good result.

—Mark Gallagher, corporate intranet developer (from Signal vs. Noise)


Don't Do Dead Documents

Eliminate unnecessary paperwork

Avoiding functional specs is a good start but don't stop there; Prevent excess paperwork everywhere. Unless a document is actually going to morph into something real, don't produce it.

Build, don't write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.

Here's an example: If a wireframe document is destined to stop and never directly become the actual design, don't bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.

Documents that live separately from your application are worthless. They don't get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it's dead.

No One's Going to Read It

I can't even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user testing as we went. I've even worked with developers who've spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don't move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don't waste your time typing up that long visionary tome; no one's going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won't resemble anything you wrote about anyway.

—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide


Tell Me a Quick Story

Write stories, not details

If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don't get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.

It doesn't need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.

Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.



Use Real Words

Insert actual text instead of lorem ipsum

Lorem ipsum dolor is a trusted friend of designers. Dummy text helps people get what the design will look like once it's fleshed out. But dummy text can be dangerous too.

Lorem ipsum changes the way copy is viewed. It reduces text-based content to a visual design element — a shape of text — instead of what it should be: valuable information someone is going to have to enter and/or read. Dummy text means you won't see the inevitable variations that show up once real information is entered. It means you won't know what it's like to fill out forms on your site. Dummy text is a veil between you and reality.

You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like.

As soon as you can, use real and relevant words. If your site or application requires data input, enter the real deal. And actually type in the text — don't just paste it in from another source. If it's a name, type a real name. If it's a city, type a real city. If it's a password, and it's repeated twice, type it twice.

Sure, it's easier to just run down the forms and fill the fields with garbage ("asdsadklja" "123usadfjasld" "snaxn2q9e7") in order to plow through them quickly. But that's not real. That's not what your customers are going to do. Is it really smart to take a shortcut when customers are forced to take the long road? When you just enter fake copy in rapid-fire fashion, you don't know what it really feels like to fill out that form.

Do as your customers do and you'll understand them better. When you understand them better, and feel what they feel, you'll build a better interface.

Lorem Ipsum Garbage

By not having the imagination to imagine what the content "might" be, a design consideration is lost. Meaning becomes obfuscated because "it's just text", understandability gets compromised because nobody realized that this text stuff was actually meant to be read. Opportunities get lost because the lorem ipsum garbage that you used instead of real content didn't suggest opportunities. The text then gets made really small, because, it's not meant to be used, we might as well create loads of that lovely white space.

—Tom Smith, designer and developer (from I hate Lorem Ipsum and Lorem Ipsum Users)


Personify Your Product

What is your product's personality type?

Think of your product as a person. What type of person do you want it to be? Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trusting? As a know-it-all? Or modest and likable?

Once you decide, always keep those personality traits in mind as the product is built. Use them to guide the copywriting, the interface, and the feature set. Whenever you make a change, ask yourself if that change fits your app's personality.

Your product has a voice — and it's talking to your customers 24 hours a day.



Precios y subscripciones capítulo 12

Free Samples

Give something away for free

It's a noisy world out there. In order to get people to notice you amid the din, give something away for free.

Smart companies know giving away freebies is a great way to lure in customers. Look at Apple. They offer iTunes software for free in order to build demand for the iPod and the iTunes music store. In the offline world, retail outlets do the same. Starbucks says a new purchase is stimulated for every five beverage samples they give away to customers. Not too shabby.

For us, Writeboard and Ta-da list are completely free apps that we use to get people on the path to using our other products. Also, we always offer some sort of free version of all our apps.

We want people to experience the product, the interface, the usefulness of what we've built. Once they're hooked, they're much more likely to upgrade to one of the paying plans (which allow more projects or pages and gives people access to additional features like file uploading and ssl data encryption).

Bite-size chunks

Make bite-size chunks: Devise specialized, smaller offerings to get customers to bite. Resolve to sub-divide at least one product or service into bite-size chunks that are inexpensive, easy or fun.

—Ben McConnell and Jackie Huba, authors of Church of the Customer Blog
(from What is customer evangelism?)

Give Away Your Hit Single

Consider giving one of your songs (per-album) as a free promotional download to the world — to be like the movie trailer — like the hit single sent to radio — the song that makes people want to go buy your music.

Don't worry about piracy for this song. Let people play it, copy it, share it, give it away. Have the confidence that if the world heard it, they will pay for more.

—Derek Sivers, president and programmer, CD Baby and HostBaby (from Free Promo Track)


Easy On, Easy Off

Make signup and cancellation a painless process

Make it as easy as possible to get in — and get out — of your app.

If I'm a customer that wants to use your app, it should be a painless, no-brainer process. Provide a big, clear, signup button that pops and put it on each page of your marketing site. Tell folks how easy it is: "From sign-up to login in just 1 minute!"

There should always be a free option so customers can demo the app without entering credit card information. Some of our competitors require a call back, an appointment, or a special password in order to try their product. What's the deal with that? We let anyone try our apps for free at any time.

Keep the signup form as short as possible. Don't ask for stuff you don't need and don't throw a long daunting form at people.

The same principles hold true for the cancellation process. You never want to "trap" people inside your product. While we're sorry when people decide to cancel their Basecamp account, we never make that process intimidating or confusing. "Cancel my account" is a link that's clear as day on a person's account page. There shouldn't be any email to send, special form to fill out, or questions to answer.

Also, make sure people can get their data out if they decide to leave. We make sure customers can easily export all messages and comments in xml format at any time. It's their data and they should be able to do with it what they want.

This is crucial because giving people control over their information builds trust. You're giving them a bridge to their data island. You're allowing them to leave without penalty if they find a better offer. It's the right thing to do and it builds goodwill.

Exit with Ease

Don't hold users against their will. If they want to leave, let them pick up with all of the content they created while they were on your site and leave...for free... You have to let the barn door open and focus on keeping your customers fed, so they want to come back, instead of coming back because they're stuck.

—Charlie O'Donnell, analyst, Union Square Ventures
(from 10 Steps to a Hugely Successful Web 2.0 Company)


Silly Rabbit, Tricks are for Kids

Avoid long-term contracts, sign-up fees, etc.

No one likes long term contracts, early termination fees, or one time set-up fees. So avoid them. Our products bill on a month to-month basis. There's no contract to sign and you can cancel at any time without penalty. And there are never any set-up fees.

Don't try to find "tricky" ways to get more cash. Earn it.



A Softer Bullet

Soften the blow of bad news with advance notice and grandfather clauses

Need to deliver bad news like a price increase? Make it as painless as possible by giving folks plenty of advance notice. Also, consider a grandfather period that exempts existing customers for a certain period of time. These folks are your bread and butter and you want to make them feel valued, not gouged.



Promocionar capítulo 13

Estreno de Hollywood

Ve del teaser al preestreno al estreno

Si una aplicación se estrena en un bosque y no hay nadie para utilizarla ¿hace ruido? El caso aquí es que si lanzas tu aplicación sin ningún tipo de pre-expectación, la gente no se va a enterar.

Para crear ruido y anticipación, hazlo con un estreno al estilo Hollywood: 1) Teaser, 2) Preestreno, y 3) Lanzamiento.

Teaser

Un par de meses antes de tiempo, empieza a dejar pistas. Deja que la gente sepa en qué estás trabajando. Publica un logo. Publica en tu blog algo sobre el desarrollo. Mantente difuso pero planta la semilla. Además, cuelga un sitio donde puedas recoger emails de la gente que se interese.

En esta etapa, deberías empezar a tentar a los especialistas y los enterados. Estos son los tipos que están a la última. Son los que crean tendencia. Apela a su vanidad y su estatus como por-delante-todo. Dile que les vas a conseguir echar un vistazo en exclusiva. Si un sitio como Boing Boing, Slashdot, o Digg enlaza a tu aplicación, conseguirás montones de tráfico y seguidores. Además, tu pagerank de Google también subirá.

Preestreno

Un par de semanas antes del lanzamiento, empieza a exhibir con anterioridad funcionalidades. Dale a la gente acceso "entre bastidores". Describe el tono del producto. Para Basecamp, publicamos capturas de pantalla y recordatorios resaltados, hitos, y otras funciones.

Además, dile a la gente las ideas y principios que hay detrás de la aplicación. Para Backpack, publicamos nuestro manifiesto antes del lanzamiento. Esto mantuvo a la gente pensando y hablando sobre la aplicación.

También puedes ofreces algunos "pases especiales" a unas pocas personas para que puedan empezar a usar la aplicación antes. Te beneficiarás de tener beta testers mientras que ellos sentirás ese cosquilleo de ser el primero en probar algo.

Y una vez más, anima a la gente a apuntarse para que tengas una base de emails a los que bombardear cuando hagas el lanzamiento. Cuando llegó del momento de lanzar nuestras aplicaciones, teníamos miles de correos que tantear, lo que es de gran ayuda para ganar impulso.

Lanzamiento

Llegó el momento del estreno. Ahora la gente puede ir al "cine" a ver tu aplicación. Envia emails a los que se apuntaron. Lanza tu sitio de marketing completo. Difunde tu evangelio tanto como puedas. Haz que los blogs te enlacen. Publica sobre tu progreso: ¿Cuanta gente se ha apuntado? ¿Que correcciones/mejoras has realizado? Demuestra impulso y mantenlo.

El camino hacia el Día del Estreno

Tan pronto como supimos que Blinksale se iba a realizar, empezamos a echar a flote algunos teasers en nuestra lista de correo. Es la gente que nos ha pedido recibir nuestra información sobre nuestros proyectos. Son nuestros fans, si quieres verlo así. Si ya tienes permiso para hablar a un grupo de gente, son el mejor sitio para empezar.

Lo segundo que hicimos fue conseguir permiso para hablar a más gente de nuestro producto. Aproximadamente seis semanas antes del lanzamiento de Blinksale pusimos una página teaser en nuestra web que avisaba de la llegada de una forma más fácil de enviar recibos online. La página dio la información justa para crear emoción y suspense, sin dar detalles delicados que debían permanecer confidenciales. Claramente visible en la página estaba un formulario de registro al boletín de noticias, pidiendo nada más que un correo (mantenlo sencillo) para que los interesados pudieran ser notificados cuando el producto se lanzase.

Difundimos la noticia a aproximadamente una docena de amigos y colegas que pensamos que podrían estar interesados también, y ellos empezaron a difundur la noticia de la página teaser en sus blogs y páginas web. En unos pocos días, teníamos miles en nuestra lista de correo. Era gente extremadamente importante — gente que preguntaba cómo saber más de nuestro producto y que quería saber cuando lo estrenábamos.

Por último, aproximadamente dos semanas antes que hicieramos el lanzamiento, invitamos a un puñado de amigos, colegas, y expertos de la industria a ayudarnos a probar la beta de Blinksale. Esto nos permitio tener el producto delante de gente que creíamos que se podría beneficiar de su uso y que podría ayudarnos a correr la voz cuando los estrenamos. Es importante destacar que no obligamos a nadie a utilizar o escribir sobre el producto. Simplemente queríamos que se viera y que la gente hablare de él cuando se estrenase. Al final, si vas a crear rumores de esta manera, mejor asegurarte de que tienes un producto que puedes entregar. De otro modo, sería como nubes sin lluvia.

Cuando llegó el día del lanzamiento, enviamos un correo a nuestra lista de correo, notificamos a nuestros amigos bloggers, y animamos a nuestros beta testers a decir lo que pensaban. Para para nuestra alegría, el esfuerzo reportó grandes dividendos. Poco después del lanzamiento decenas de miles habían visitado nuestra página y miles de ellos se habían registrado para usar el producto.

—Josh Williams, fundador de Blinksale


Una página de promoción potente

Ve del teaser al preestreno al lanzamiento

La mejor herramiento de promoción es un gran producto. La voz se correrá si tienes una aplicación que la gente encuentre realmente útil.

Aun así, también necesitas una buena página de promoción. ¿Qué deberías incluir en esta página? Algunas ideas:



Ride the Blog Wave

Blogging can be more effective than advertising (and it's a hell of a lot cheaper)

Advertising is expensive. And evaluating the effectiveness of various types of advertising can wind up being even more expensive than the advertising itself. When you don't have the time or money to go the traditional advertising route, consider the promote-via-blog route instead.

Start off by creating a blog that not only touts your product but offers helpful advice, tips, tricks, links, etc. Our Signal vs. Noise blog gets thousands of unique readers a week thanks to the helpful, informative, and interesting bits and anecdotes we post on a daily basis.

So when it came time to promote our first product, Basecamp, we started there. We got the word out on SvN and it started to spread. Folks like Jason Kottke, the BoingBoingers, Jim Coudal, and a variety of other people with popular blogs helped raise the visibility and things took off.

Ta-da Lists is another great example of the power of blog-based marketing. We launched Ta-da with a single post on Signal vs. Noise, and a few weeks later it had been mentioned on over 200 blogs and over 12,000 people had signed up for their own Ta-da account. Word about Backpack spread even faster. Within 24 hours of launch, more than than 10,000 signed up.



Solicit Early

Get advance buzz and signups going ASAP

We've already touched on it but it bears repeating: Get some sort of site up and start collecting emails as soon as possible. Pick your domain name and put up a logo and maybe a sentence or two that describes, or at least hints at, what your app will do. Then let people give you their email address. Now you're on your way to having a foundation of folks ready and waiting to be notified of your launch.



Promote Through Education

Share your knowledge with the world

When a teacher appears as a contestant on Jeopardy, Alex Trebek often comments that it's a "noble profession." He's right. There's definitely something wonderful and rewarding about sharing your knowledge with others. And when the subject you're teaching is your app, it serves a dual purpose: You can give something back to the community that supports you and score some nice promotional exposure at the same time.

As a promotional technique, education is a soft way to get your name — and your product's name — in front of more people. And instead of a hard sell "buy this product" approach, you're getting attention by providing a valuable service. That creates positive buzz that traditional marketing tactics can't match. People who you educate will become your evangelists.

Education can come in many forms. Post tips and tricks at your site that people will want to share with others. Speak at con- ferences and stay afterwards to meet and greet with attendees. Conduct workshops so curious fans can learn more and talk to you in the flesh. Give interviews to publications. Write articles that share helpful information. And write books. ;)

An example from our own history is the Yellow Fade Technique, a method we invented to subtly spotlight a recently changed area on a page. We wrote a post about it on Signal vs. Noise. That post made the rounds and got thousands and thousands of page views (to this day it's doing huge traffic).

The post worked on both an educational and a promotional level. A lesson was learned and a lot of people who never would have known about our products were exposed to them. Another example: During our development of Ruby on Rails, we decided to make the infrastructure open source. It turned out to be a wise move. We gave something back to the com- munity, built up goodwill, garnered recognition for our team, received useful feedback, and began receiving patches and con- tributions from programmers all over the world.

Teaching is all about good karma. You're paying it forward. You're helping others. You get some healthy promotion. And you can even bask in a bit of nobility. So what do you know that the world wants to hear about?

Pay It Forward

The articles and tips section of our blog is one of the most popular sections of our site. Passing on our knowledge about email marketing ensures our customers get the most out of our software. If they can provide a better service to their customers, then they're likely to get more business, which in turn creates more business for us — everyone wins.

Freely sharing our knowledge has also helped position us as experts in the industry and strengthened our relationship with existing customers. They know we care about the quality of their work. Finally, we get loads of targeted inbound traffic from search engines and bloggers who share our articles with their readers. These are people that would never have heard of our software had we not written that article.

—David Greiner, founder, Campaign Monitor


Feature Food

They're hungry for it so serve it up

New or interesting features are a great way to generate buzz for your application. Special interest groups love to chew up "feature food" and spit it back out to the community. Alright, that's kind of an unpleasant analogy but you get the point.

For example, by using Ruby on Rails, a new development platform, we generated a ton of attention for Basecamp within the developer community.

The Ajax elements we used in our applications got lots of buzz and even led to Business 2.0 magazine naming 37signals a "key player in Ajax" alongside big names like Google, Yahoo, Microsoft, and Amazon.

Another example: Bloggers took notice of Basecamp's RSS support since it was one of the first business examples of RSS.

iCal integration, a seemingly minor feature, got us press on a ton of Mac-related sites which probably never would have mentioned the app otherwise.

Small teams have a leg up on integrating new ideas into software. While bigger companies have to deal with bureaucratic bottlenecks, you can rapidly implement new ideas and get attention for using them.

Riding the hype coattails of the technology du jour is an effective and cheap way to build your buzz. That said, don't go adding the latest obscure technology just to gain some notice. But if you are using something new or noteworthy, go ahead and spotlight it for special interest groups.



Track Your Logs

Study your logs to track buzz

You need to know who's talking about you. Check your logs and find out where the buzz is coming from. Who's linking to you? Who's bitching about you? Which blogs listed at Technorati, Blogdex, Feedster, Del.icio.us, and Daypop are hot on your trail?

Find out and then make your presence felt. Leave comments at those blogs. Thank people for posting links. Ask them if they want to be included on your special advance list so they'll be among the first to know about future releases, updates, etc. Collect positive praise and create a "buzz" page at your site. Testimonials are a great way to promote your app since third-party praise is more trustworthy to most people.

If the comments are negative, still pay attention. Show you're listening. Respond to critiques thoughtfully. Something like: "We appreciate the feedback but we did it this way because..." Or "You raise a good point and we're working on it." You'll soften up your critics and put a human face on your product. It's amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists.



Inline Upsell

Promote upgrade opportunities inside the app

Everyone knows to pitch at the marketing site. But the sell shouldn't stop there. If you have a tiered pricing plan (or a free version of your app), don't forget to call out upgrade opportuni ties from within the product.

Tell folks that you'll remove barriers if they upgrade. For example, in Basecamp you can't upload files if you have a free account. When someone tries to upload a file, we don't just turn them away. We explain why file uploading isn't available and encourage them to upgrade to the paid version and explain why that's a good idea. The same approach is used to encourage ex isting customers to upgrade to a higher level account when they max out their current plan.

Existing customers are your best bet for sales. Don't be shy about trying to get repeat business from people who already know and use your product.



Name Hook

Give your app a name that's easy to remember

A big mistake a lot of people make is thinking their app's name needs to be ultradescriptive. Don't worry about picking a name that vividly describes your tool's purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress. Writeboard is better than CollaborEdit.

Also, don't focus group or committee-ize the naming process too much. Pick a name that's short, catchy, and memorable and then run with it.

And don't sweat it if you can't get the exact domain name you want. You can always be creative and get close with a couple of extra letters (e.g. backpackit.com or campfirenow.com).

Easy Does It

Doesn't the tech industry realize that thinking up catchy, self-explanatory names would ultimately benefit it in the same way? They'd sell more of whatever it was, because they wouldn't scare off consumers who think they're being kept out of the high-tech club by a bunch of arrogant engineers. The technology would catch on quicker, too. The new product would be easier to describe, easier to use and easier to buy — which, for the companies, means easier to sell.

—David Pogue, columnist, New York Times (from What's in a Product Name?)


Soporte capítulo 14

Siente el dolor

Derriba los muros que separan el desarrollo y el soporte

En el negocio de la hostelería, hay una enorme diferencia entre aquellos que trabajan en la cocina y aquellos que se encargan de la clientela. Es esencial que ambos se entiendan y empaticen. Por eso las escuelas de cocina y los restaurantes habitualmente tienen a chefs trabajando de cara al público como si fueran camareros, de manera que el personal de cocina pueda interactuar con el cliente y saber lo que es estar en el frente.

Muchos desarrolladores de software se encuentran en una situación similar. Los diseñadores y programadores trabajan en la "cocina" mientras que la gente de soporte técnico se encarga de los clientes. Por desgracia, esto significa que los chefs del software nunca llegan a saber lo que los clientes dicen. Esto es un problema porque escuchar al cliente es la mejor manera de conocer las fortalezas y debilidades de de tu producto.

¿Cual es la solución a este problema? Evita crear muros que separen a tus clientes del equipo de desarrollo y diseño. No subcontrates el soporte técnico a terceros ni a lo reduzcas a centros de soporte telefónico. Hazlo tu mismo. Tú equipo y tú debéis saber lo que los clientes están diciendo. Cuando tus clientes estén molestos, debes saberlo. Debes oá­r sus quejas. Tú mismo debes, también, sentirte molesto.

En 37Signals, todos los emails relativos al soporte técnico del producto son contestados por la gente que desarrolló el producto. ¿Porqué? En primer lugar porque ofrece un mejor soporte al cliente. Ellos obtienen una respuesta directamente desde el cerebro de una de las personas que desarrollaron la aplicación. También nos permiten mantenernos en contacto con la gente que utiliza nuestros productos y los problemas que encuentran. Cuando ellos están frustrados, nosotros también lo estamos. Podemos decir, "Siento tu dolor" y que sea cierto.

Puede que sea tentador confiar que los análisis estadá­sticos revelarán nuestros puntos problemáticos, pero los números no expresan lo mismo que las voces. Debes eliminar la mayor cantidad de capas posible entre tu y la voz real del cliente.

En el frente es donde está la acción. Ve allá­. Haz que tus chefs hagan de camareros. Lee el correo de los clientes, escucha sus frustraciones, toma nota de sus sugerencias y aprende de ellos.

Elimina los intermediarios

Prácticamente todo el desarrollo de Campaign Monitor, su soporte técnico y marketing es realizado por dos personas. Incluso si estamos forzados a expandir el equipo, nunca separaremos el soporte del desarrollo. Respondiendo personalmente a cada petición nos forzamos a meternos en el papel del cliente y a ver las cosas desde su perspectiva.

Es importante entender porque nuestro cliente necesita algo, no sólo lo que necesita. Ese contexto tiene habitualmente un impacto directo sobre como diseñamos las cosas. Elimina los intermediarios. Es mucho más fácil dar a nuestros clientes lo que quieren cuando tus orejas están más cerca del suelo.

He discutido esta disposición con un montón de gente y la primera respuesta que obtengo es: "¿no deberías contratar algún junior para que se encargue del soporte?" Metete en el papel del cliente. Si quieres que tu filete esté cocinado tal y como te gusta, ¿Con quien hablarías antes, con el friegaplatos o con el chef que está, de hecho, cocinándolo?

—David Greiner, fundador de Campaign Monitor


No Necesite Formación

Usa ayuda interna y FAQ de forma que tu producto no requiera un manual o formación especá­fica.

Para usar Yahoo, Google o Amazon no necesitas un manual. Asá­ que ¿porqué no crear un producto que no necesite manual? Procura crear una herramienta que no necesite formación.

¿Cómo puede hacerse esto? Bien, tal y como hemos mencionado antes, la mejor manera de empezar es procurar hacer las cosas de la forma más simple posible. Cuanto más simple sea tu aplicación menos problemas tendrán tus clientes y menos ayuda tendrás que darles. Tras esto, una buena manera de reemplazar el soporte técnico clásico es mediante un sistema de ayuda incluido en el propio uso de la aplicación, asá­ como también mediante FAQs que refieran puntos potenciales de confusión.

Por ejemplo, ofrecemos soporte prioritario en la pantalla que permite al usuario subir un logo personalizado a Basecamp. Algunas personas tenían un problema relacionado con la caché del navegador por el que seguían viendo el logo antiguo en lugar del que habían enviado. Asá­ que al lado del área de "Enviar tu logo" añadimos un enlace a una FAQ que explicaba a los usuarios que debían recargar la página para ver el nuevo logo. Antes de haber hecho esto, recibíamos 5 emails al día sobre este problema. Ahora no recibimos ninguno.



Responde rápido

Agilizar el tiempo de respuesta a las cuestiones de soporte debería ser de máxima prioridad

Los clientes agradecen que sus preguntas se respondan rápido. Están tan acostumbrados a respuestas predefinidas que llegan días después (si es que llegan) que puedes diferenciarte de la competencia ofreciendo una respuesta meditada rápidamente. En horario de oficina respondemos el 90% de todas las peticiones de soporte por email en unos 90 minutos - y habitualmente en media hora. Y a la gente le encanta.

Incluso si no tienes una respuesta perfecta, di algo. Mostrarás tu buena voluntad con una respuesta rápida, honesta y abierta. Si alguien se está quejando sobre una incidencia que no puede ser reparada inmediatamente, di algo como, "Tenemos en cuenta lo que nos está diciendo y nos pondremos a trabajar en ello en el futuro". Es una buena manera de evitar una situación potencialmente negativa.

Los clientes aprecian que seas directo con ellos y habitualmente cambiarán su enfado por educación si les respondes de forma rápida y directa al grano.

Un ejército de muchos

¿Cómo puede un pequeño equipo de tres desarrolladores crear un producto innovador y competir con éxito con los peces grandes? La solución es reclutar un ejército de muchos.

Debes recordar, desde el primer día, que los clientes son tu mejor baza y que son absolutamente vitales para el éxito a largo plazo, asá­ que trata a tu comunidad de usuarios como a la realeza. La mejor manera de competir con los grandes es empezar siendo pequeño y prestar atención a cada uno de tus clientes.

Serán tus clientes los que te alertarán primero de bugs, los que te alertarán sobre las necesidades que aún no has satisfecho y serán los abanderados de tu producto y quienes propagarán tu mensaje.

Esto no significa que tu producto tenga que ser perfecto cuando lo lances. Más bien al contrario, lánzalo pronto y a menudo. De cualquier manera, cuando tus clientes encuentren bugs, asegúrate de enviarles una respuesta agradeciéndoles su aportación.

Los clientes no esperan que tu producto sea perfecto y desde luego tampoco esperan que todas las caracterá­sticas que desean estén implementadas. Lo que sá­ esperan es que estés a la escucha y demuestres que te importa, asá­ que muéstrales que te importa. Es en este área donde la mayor parte de las grandes compañías muestran un gran déficit, asá­ que desarrolla un sentimiento de comunidad pronto.

En Blinklist, cada email de los clientes se responde, normalmente en una hora (a no ser que estemos durmiendo). También tenemos un foro online y nos aseguramos de que cada mensaje y comentario sea reconocido.

Igualmente importante, todos nuestros desarrolladores reciben las observaciones del cliente además de ser participantes activos de las discusiones del foro. De esta forma nos aseguramos, lentamente, eso sá­, de construir una comunidad activa y leal para Blinklist.

—Mike Reining, co-fundador de MindValley y Blinklist


El Amor es Duro

Debes estar dispuesto a decir no a tus clientes

Cuando se trata de pedir caracterá­sticas, el cliente no siempre tiene la razón. Si añadiéramos todas y cada una de las cosas que nos solicitan los clientes, nadie querría nuestros productos.

Si cediéramos a cada uno de los caprichos de nuestros clientes, Basecamp tendría: facturación exhaustiva, gestión del tiempo exhaustiva, agenda exhaustiva, calendario exhaustivo, sistema de interdependencia de tareas exhaustivo, mensajería instantánea exhaustiva, funcionalidad de wiki exhaustiva y cualquier-cosa-imaginable exhaustiva.

Aún asá­, la petición número uno de los clientes en las encuestas es: mantened Basecamp simple.

Otro ejemplo: A pesar de que recibimos algunas quejas, decidimos que ie5 no fuera compatible con nuestros productos. Eso suponía tachar un 7% del mercado. Pero decidimos que era más importante preocuparnos del 93% restante. Arreglar bugs y testear para ie5 no valía la pena. En su lugar haríamos un producto mucho mejor para el resto.

Como empresa de desarrollo de software, tienes que actuar como filtro. No todo lo que sugiere la gente tiene porque ser correcto. Consideramos todas las peticiones, pero el cliente no siempre tiene la razón. Habrá momentos en los que sencillamente tendrás que fastidiar a alguien. C'est l a vie.

En relación con esto, es de suma importancia que tu, como compañía de desarrollo, quieras a tu producto. Y no lo querrás si está lleno de cosas con las que no estás de acuerdo. Es es otra razón más que justifica el vetar aquellas peticiones del cliente que no creas necesarias.



Un Buen Foro

Usa foros o chat para permitir que los usuarios se ayuden entre ellos

Los foros y el chat de grupo basado en web son buenas medios para permitir que los usuarios hagan preguntas y se ayuden entre ellos. Eliminando al intermediario - que eres tú - proporcionas un canal abierto de comunicación ahorrándote algún tiempo en el proceso.

En nuestros foros sobre productos, los clientes envían sugerencias y trucos, peticiones de caracterá­sticas nuevas, historias y mucho más. De vez en cuando nos pasamos por ahá­ para ofrecer ayuda, pero los foros son, principalmente, un lugar para que los miembros de la comunidad se ayuden entre ellos y compartan sus experiencias con el producto.

Te sorprenderá cuanta gente está dispuesta a ayudar.



Haz públicos tus errores

Filtra las malas noticias y quá­tatelas de en medio

Si algo va mal, dá­selo a la gente. Incluso si a primera vista no se habían percatado.

Por ejemplo, Basecamp estuvo fuera de servicio unas pocas horas a en plena noche. El 99% de nuestros clientes no se dio cuenta, per aún asá­ enviamos un post de "caá­da del servicio inesperada" a nuestro blog Everything Basecamp. Pensamos que nuestros clientes merecían saberlo.

Este es un ejemplo de lo que escribimos cuando algo va mal: "Pedimos disculpas por la caá­da del servicio ocurrida esta mañana - hemos tenido algunos problemas con la base de datos que causaron retrasos importantes y caá­das de servicio para algunas personas. Hemos arreglado el problema y estamos tomando medidas para evitar que esto vuelva a pasar...Gracias por vuestra paciencia y, una vez más, disculpadnos por la caá­da del servicio."

Se tan abierto, honesto y transparente como te sea posible. No guardes secretos ni te ocultes en medio de la confusión. Un cliente informado es tu mejor cliente. Además, te darás cuenta de que la mayoría de tus errores no son tan importantes en la mente del cliente. A los clientes no les suele importar darte un poco de aire si saben que estás siendo honesto con ellos.

Una última cosa sobre dar noticias, buenas y malas: Cuando vengan malas noticias, hazlas públicas todas a la vez. Con las buenas, sin embargo, hazlo poco a poco, gota a gota. Si puedes prolongar las buenas vibraciones, hazlo.

Se Veloz, Directo y Honesto

Puede que suene extraño, pero la mejor situación en la que se puede encontrar la empresa es cuando tienes que dar malas noticias. Esto es proactivo y evita que tu compañía tenga que adoptar una posición defensiva y de debilidad.

—Greg Sherwin, Vice Presidente de Application Technology, CNET y Emily Avila, Directora de Calypso Communications (extraá­do de: A Primer for Crisis PR)


Luego de la entrega capítulo 15

Un mes de mejoras

Entrega una actualización importante 30 días después del lanzamiento

Una rápida actualización muestra actividad. Muestra que estás a la escucha. Muestra que tienes más trucos en el bolsillo. Te da una segunda ola de interés. Reafirma los buenos sentimientos iniciales. Te da algo de lo que hablar y ofrece a los demás algo sobre lo que escribir.

Saber que una rápida actualización viene, también te permite centrarte en los componentes cruciales antes del lanzamiento. En lugar de intentar meter unas pocas cosas más a la fuerza, puedes empezar por perfeccionar únicamente el conjunto de elementos centrales. Entonces puedes mostrar el producto en el mundo real. Una vez esté ahá­ fuera puedes empezar a obtener opiniones de los clientes y sabrás que áreas del producto requieren atención a continuación.

Este acercamiento prudente funcionó bien en Backpack. Primero lanzamos el producto base y, unas semanas después, añadimos caracterá­sticas como Backpack Movile para dispositivos portátiles y el tagging, ya que estos elementos eran los más demandados por nuestros clientes.



Que sigan los posts

Muestra que tu producto está vivo en un blog sobre el desarrollo del producto después de su lanzamiento

No dejes de escribir en tu blog tras el lanzamiento. Muestra que tu producto es una criatura viviente manteniendo un blog dedicado que actualices frecuentemente (al menos una vez a la semana, más a menudo si es posible).

Things to include:

Un blog no sólo demuestra que tu aplicación está viva, sino que hace que tu empresa parezca más humana. De nuevo, no tengas miedo a mantener un tono amistoso y familiar. Los equipos pequeños sienten que deben sonar de forma grandilocuente y ultra-profesional. Es casi como una versión de negocios del Complejo de Napoleón. Que no te importe sonar pequeño. Revela el hecho de que puedes hablar a los clientes como a un amigo.

¡Está vivo!

Un blog frecuentemente actualizado sobre un producto es el mejor indicador de que una aplicación web está siendo desarrollada activamente, de que es amada y de que hay luz en casa. Un blog sobre un producto que esté abandonado es signo de un producto abandonado y dice, de la gente al cargo, que están dormidos al volante.

Haz que siga habiendo conversación con los usuarios en el blog sobre el producto y se transparente y generoso con la información que compartes. Deja que la filosofía de tu empresa destaque. Discute y enlaza públicamente a tus competidores. Pon especial atención en las novedades que se aproximan y deja los comentarios abiertos en busca de opiniones.

Un producto viviente es un producto que habla y escucha a sus usuarios. Un blog sobre un producto frecuentemente actualizado muestra transparencia, un sentimiento de comunidad y lealtad a tu marca. Además, la publicidad gratuita es un añadido.

Como editor de Lifehacker, busco novedades constantemente en los blogs de las aplicaciones web que adoro - como los blogs sobre productos de Google, Flickr, Yahoo, del.icio.us y 37Signals. Tiendo a mencionarlos a ellos mucho más que a aplicaciones web que emiten comunicados de prensa subjetivos, salidos de la nada y no mantienen conversaciones abiertas con sus usuarios y fans.

—Gina Trapani, desarrolladora web y editora de Lifehacker, guía de software y productividad.


Mejor, no Beta

No uses "beta" como vía de escape

En estos días, parece que todo está en beta por siempre. Eso es irresponsable. Un interminable estado de beta les dice a los clientes que no estás entregado realmente al lanzamiento de un producto finalizado. Dice "Usa esto, pero, si no está perfecto, no es culpa nuestra".

Las betas pasan el problema a los clientes. Si estás totalmente seguro acerca de la entrega del producto, ¿cómo esperas que reaccione el público?. Las betas privadas no están mal, pero las betas publicas son basura. Si no es suficientemente bueno para el consumo público, no dejes que el público lo consuma.

No esperes hasta que tu producto sea perfecto. Eso no va a ocurrir. Asume la responsabilidad sobre lo que vas a lanzar. Entrégalo y llámalo lanzamiento. De otra manera, sólo estás poniendo excusas.

Beta no tiene sentido

Culpa a Google y demás por causar problemas como este. Por ahora los usuarios han sido entrenados por el conjunto de desarrolladores para pensar que "beta" realmente no significa nada.

—Mary Hodder, arquitecta de información y diseñadora de interacción (tomado de La Definición de Beta)

Siempre

¿Soy yo o siempre estamos en beta?

—Jim Coudal, fundador de Coudal Partners


No todos los bugs se crean igual

Prioriza tus bugs (ignora incluso algunos de ellos)

El que aparezca un bug en tu producto no significa que tengas que entrar en pánico. Cualquier software tiene bugs - son cosas de la vida.

No tienes porque arreglar cada bug instantáneamente. La mayoría de los bugs son molestos, no destructivos. Estas molestias pueden posponerse un poco. Los bugs que provocan errores de tipo "eso no se ve bien" u otros errores sin importancia, pueden dejarse a un lado con toda seguridad. Sin embargo, si un bug destruye tu base de datos obviamente debes repararlo inmediatamente.

Prioriza tus bugs. ¿Cuánta gente está afectada? ¿Cómo de malo es el problema? ¿Este bug requiere atención inmediata o puede esperar? ¿Qué puedes hacer para que tenga el mayor impacto posible sobre la mayor cantidad de gente posible? A menudo, añadir una caracterá­stica nueva puede ser más importante para tu aplicación que reparar un bug existente.

No crees tampoco una cultura de miedo alrededor de los bugs. Los bugs aparecen. No busques constantemente alguien a quien culpar. Lo último que necesitas es un entorno en el que los bugs se deslicen bajo la alfombra, en lugar de ser abiertamente discutidos.

Recuerda lo que dijimos antes sobre la importancia de la honestidad. Si los clientes se quejan sobre un bug, se claro y directo con ellos. Diles que has anotado la incidencia y que estás ocupándote de ella. Si el problema no puede solucionarse enseguida, di porqué y explica que estás poniendo atención en las áreas del producto que afectan a la mayor cantidad de gente. La honestidad es la mejor polá­tica.



Capeando el temporal

Espera hasta que las reacciones viscerales al cambio mueran antes de actuar

Problemas llaman a problemas. Tras introducir una nueva caracterá­stica, cambiar una polá­tica o eliminar algo, las reacciones viscerales, a menudo negativas, aflorarán.

Resiste el impulso de entrar en pánico o cambiar las cosas rápidamente como respuesta. Las pasiones se encenderán al principio. Pero si aguantas este periodo inicial de 24 a 48 horas las cosas, normalmente, se calmarán. La mayoría de la gente responde antes de haber usado lo que sea que hayas añadido (o acostumbrado a lo que has eliminado). Asá­ que prepárate, encaja los golpes y no hagas un sólo movimiento hasta que haya pasado algún tiempo. Entonces serás capaz de ofrecer una respuesta mucho más razonada.

Acuérdate también de que la mayoría de las reacciones negativas son casi siempre más notorias y apasionadas que las positivas. De hecho, es posible que únicamente oigas voces negativas incluso cuando la mayoría de los usuarios se siente feliz con el cambio. No evites, sin embargo, decisiones necesarias, aunque estas sean controvertidas.



Manténte siempre a la última

Suscrá­bete a los feeds de noticias sobre la competencia

Suscrá­bete a feeds de noticias tanto sobre tu producto como los de la competencia (es de sabios conocer las maniobras de tus enemigos). Usa servicios como PubSub, Technorati, Feedster y demás para mantenerte al día (como palabras clave usa los nombres de compañías y productos). Gracias a RSS esta información en constante cambio te llegará directamente, de forma que siempre te mantendrás al día.



Cuidado con el monstruo hinchado

Más maduro no tiene porqué significar más complicado

Con el progreso de las cosas, no tengas miedo a resistir la hinchazón. La tentación tenderá a ser mayor. Pero no tiene porque ser asá­. Sólo porque algo se haga más viejo o más maduro, no tiene porque significar que tenga que hacerse más complicado.

No tienes porque convertirte en un bolá­grafo del espacio exterior que escriba de abajo a arriba. Algunas veces está bien ser un simple bolá­grafo. No tienes que ser una navaja suiza. Puedes ser simplemente un destornillador. No tienes porque crear un reloj de buceo que funcione a 5000 metros si tus clientes son amantes de la tierra que sólo quieren saber que hora es.

No infles por inflar. Asá­ es como las aplicaciones se hinchan.

Nuevo no siempre significa mejorado. En ocasiones hay un punto donde debes parar el desarrollo.

Este es uno de los beneficios clave de construir software basado en web en lugar del tradicional software de escritorio. Los desarrolladores de software de escritorio como Adobe, Intuit y Microsoft necesitan vender nuevas versiones cada año. Y, como no pueden vender las mismas versiones, tienen que justificar los gastos añadiendo nuevas caracterá­sticas. Ahá­ es donde comienza la hinchazón.

Con aplicaciones web basadas en el modelo de subscripción, la gente paga una cuota mensual para usar el servicio. No necesitas seguir vendiendo más y más añadiendo más y más, sólo necesitas ofrecer un servicio continuado y valioso.



Ve con la corriente

Estate abierto a nuevos caminos y cambios de dirección

Parte de la belleza de las aplicaciones web radica en su fluidez. No lo metes en una caja, envías y entonces esperas años para el siguiente lanzamiento. Puedes mejorar y cambiar mientras tanto. Se abierto respecto al hecho de que tu idea original puede que no sea tu mejor idea.

Mira Flickr. Empezó siendo un juego multiplayer online llamado The Game Neverending. Sus creadores se dieron cuenta pronto de que la capacidad de compartir fotos era más plausible que el juego en si mismo (que, eventualmente, fue cancelado). Tienes que estar preparado para admitir errores y cambios en el curso de las cosas.

Se un surfista. Mira el océano. Busca donde rompen las olas más grandes y ajústate a ello.



Conclusión capítulo 16

Arrancamos

¡Hecho!

Bien, ¡lo conseguiste! Con suerte ya estarás preparado mentalmente para comenzar a hacer realidad tu aplicación. Nunca ha habido una época mejor para escribir un software tan bueno con tan pocos recursos. Con la idea correcta, pasión, tiempo y habilidad, sólo el cielo es el lí­mite.

Algunos pensamientos finales:

Ejecución

Cualquiera puede leer un libro. A cualquiera se le puede ocurrir una idea. Todo el mundo tiene un primo que es diseñador web. Cualquiera puede escribir un blog. Cualquiera puede contratar a alguien para hackear código.

Lo que te diferenciará del resto será lo bien que ejecutes. El éxito está basado en una gran ejecución.

En el mundo del software eso implica hacer muchas cosas bien. No puedes ser un gran escritor únicamente si no consigues ofrecer lo que prometes en tu prosa. Una interfaz limpia no cuajará si tu código está lleno de hacks. Una gran aplicación es inútil si por mala publicidad entendemos que nadie sepa de ella. Para conseguir un gran éxito deberás combinar todos estos elementos.

La clave es el equilibrio. Si te inclinas demasiado en una dirección, vas directo al fracaso. Se exhaustivo en la búsqueda de tus puntos débiles y ocúpate de ellos hasta que estés nivelado.

La gente

Merece la pena enfatizar lo que, en nuestra opinión, es el ingrediente más importante cuando se trata de construir una aplicación web de éxito: la gente involucrada en ella. Los Mantras, el diseño epicentral, menos software y todas esas maravillosas ideas no tienen sentido si no tienes la gente apropiada para implementarlas.

Necesitas gente que sienta pasión por lo que hace. Gente que se preocupa de su arte - y que, de hecho, piense en ello como un arte. Personas que se enorgullezcan de su trabajo sin importar las recompensas que obtengan. Personas que trabajan duro en los detalles incluso cuando el 95% de la gente no conoce la diferencia. Gente que quiere crear algo brillante y que no se conformará con menos. Gente que necesita gente. De acuerdo, esto último quizás no, pero nos apetecía introducir un toque Streisand en la mezcla. De todas formas, cuando encuentres personas como estas, no las dejes escapar. Al final, es la gente de tu equipo la que que hará o estropeará tu proyecto - y tu compañía.

Más que Software

Es importante aclarar que el concepto de Getting Real no se aplica únicamente al desarrollo de aplicaciones web. Una vez comprendas todas estas ideas, las verás por todas partes. Algunos ejemplos:

Por supuesto, Getting Real trata sobre escribir buen software. Pero no hay razón alguna dejarlo aquá­. Toma estas ideas e intenta aplicarlas a diferentes aspectos de tu vida. Puede que tropieces con estupendos resultados.

Manténte en contacto

Haznos saber que tal te ha funcionado Getting Real. Envía un email a gettingreal [at] 37signals [dot] com.

Igualmente, puedes mantenerte al día de las últimas propuestas de 37Signals visitando Signal vs. Noise, nuestro blog sobre Getting Real, usabilidad, diseño y otras cosas.

¡Gracias por leernos y buena suerte!



Recursos de 37Signals



Translation

Thanks to the following translators: Luis Lavena, Pedro Visintin, Lucas Fiorio, David Aizpuru Herce, Ismael Celis, Alberto González, Guillermo Señas and Marcos Arias (linguistic correction).