Getting Real Español

• capítulo 1 Introducción
• capítulo 2 La línea de inicio
• capítulo 3 Mantente ligero
• capítulo 4 Prioridades
• capítulo 5 Selección de características
• capítulo 6 El Proceso
• capítulo 7 La Organización
• capítulo 8 El Personal
• capítulo 9 El Diseño de la Interfaz
• capítulo 10 El Código
• capítulo 11 Las Palabras
• capítulo 12 Precios y subscripciones
• capítulo 13 Promocionar
• capítulo 14 Soporte
• capítulo 15 Luego de la entrega
• capítulo 16 Conclusión

---

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.

• Haciéndolo Real habla de saltarse todo el material que representa lo real (gráficos, cajas, flechas, esquemas, etc.) y en realidad crear el objeto real.
• Haciendolo realidad es menos. Menos masa, menos software, menos características, menos papeleo, menos de todo lo que no es esencial (y la mayoría de lo que tú crees que es esencial en realidad no lo es).
• Haciendolo Real es permanecer pequeño y ser ágil.
• Haciendolo Real comienza con la interfaz, las pantallas reales que la gente va a usar. Comienza con lo que el cliente experimenta realmente y se construye hacia atrás a partir de ahí. Esto te permite hacer la interfaz correcta antes de crear el software inadecuado.
• Haciendolo Real habla de iteraciones y de reducir el coste del cambio. Haciéndolo Real habla del lanzamiento, ajuste y mejora continua, lo que lo hace una perfecta aproximación al software basado en la web.
• Haciéndolo Real entrega sólo lo que los clientes necesitan y elimina todo lo que no.

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.

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 ...

• Líneas de tiempo que toman meses e incluso años
• Especificaciones funcionales que sean pura fantasía
• Debates sobre escalabilidad
• Reuniones de grupo interminables
• La "necesidad" de contratar docenas de empleados
• Números de versión sin sentido
• Itinerarios que predicen el futuro perfecto
• Un sinfin de opciones y ajustes
• Soporte subcontratado
• Pruebas de usuario irreales
• Papeleo innecesario
• Jerarquías de arriba hacia abajo

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...

• La importancia de tener una filosofía
• Porque permanecer pequeño es algo bueno
• Cómo construir menos
• Cómo ir de una idea a la realidad rápidamente
• Cómo proveer de personal a tu equipo
• Por qué debes diseñar desde dentro hacía fuera
• Por qué escribir es tan crucial
• Por qué debes hacer menos que tu competencia
• Cómo promocionar tu aplicación y difundir la palabra
• Los secretos para soporte exitoso
• Consejos para mantener el ímpetu en marcha despues del lanzamiento
• ... y mucho más

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."

---

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:

• Menos funciones
• Menos opciones / preferencias
• Menos gente y estructura empresarial
• Menos reuniones y abstracciones
• Menos promesas

---

¿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.

---

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.

---

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:

• Priorización

  Tienes que visualizar qué es realmente importante. ¿Qué estará incluído en la entrega inicial? Esto fuerza una restricción que te obligará a tomar decisiones asertivas en vez de andar sin rumbo definido.

• Realidad

  Definir las espectativas es la clave. Si tratas de corregir el tiempo, presupuesto, y alcance, no estaras en condiciones de entregar un buen nivel de calidad. Seguro podras probablemente entregar algo, pero ese "algo" es lo que realmente quieres entregar?

• Flexibilidad

  La capacidad de cambio es la clave. Tener todo ajustado hace más difícil el cambio. Agregando flexibilidad al alcance introduciremos opciones basadas en tu experiencia real construyendo el producto. La flexibilidad es tu amiga.

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

---

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 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.

---

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...

• Contratos a largo plazo
• Plantilla excesiva
• Decisiones duraderas
• Reuniones sobre otras reuniones
• Un proceso denso
• Inventario (físico o mental)
• Estar limitado un hardware, software, o tecnología concretos
• Formatos de datos propietarios
• El pasado rigiendo el futuro
• Planes de acción a largo plazo
• Políticos de oficina

La masa la reducen...

• Forma de pensar "Just-in-time"
• Miembros del equipo multitarea
• Aceptar las limitaciones, no tratar de aumentarlas
• Menos software, menos código
• Menos funcionalidades
• Tamaño de equipo pequeño
• Simplicidad
• Interfaces simplificados
• Productos de código libre
• Formatos de datos abiertos
• Una cultura accesible que haga fácil admitir errores

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.

---

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.

---

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:

• Una empresa de diseño que llevar
• Trabajo actual para clientes
• Una diferencia de 7 horas (David estaba programando en Dinamarca, el resto de nosotros estabamos en Estados Unidos)
• Un equipo pequeño
• Ninguna financiación externa

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.

---

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.

---

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:

• Basecamp: La administración de proyectos es comunicación
• Backpack: Amarrar los cabos sueltos de la vida
• Campfire: El diálogo grupal vía Mensajería Instantánea apesta
• Ta-da List: Compitiendo con una nota post-it
• Writeboard: Word es demasiado

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.

---

Ignora los detalles al comienzo

Trabaja desde grande a pequeño

Nos fascinan los detalles.

• El espacio entre objetos
• La sangría perfecta para los textos
• El color perfecto
• Las palabras perfectas
• Cuatro líneas de código en vez de siete
• 90% versus 89%
• 760px versus 750px
• $39/mes versus $49/mes

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.

---

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.

---

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.

---

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."

---

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...

• 1. Say no.
• 2. Force the feature to prove its value.
• 3. If "no" again, end here. If "yes," continue...
• 4. Sketch the screen(s)/ui.
• 5. Design the screen(s)/ui.
• 6. Code it.
• 7-15. Test, tweak, test, tweak, test, tweak, test, tweak...
• 16. Check to see if help text needs to be modified.
• 17. Update the product tour (if necessary).
• 18. Update the marketing copy (if necessary).
• 19. Update the terms of service (if necessary).
• 20. Check to see if any promises were broken.
• 21. Check to see if pricing structure is affected.
• 22. Launch.
• 23. Hold breath.

---

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.

---

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.

---

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.

---

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.

---

"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.

---

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.

---

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.

---

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.

---

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:

• They break your work day into small, incoherent pieces that disrupt your natural workflow
• They're usually about words and abstract concepts, not real things (like a piece of code or some interface design)
• They usually convey an abysmally small amount of information per minute
• They often contain at least one moron that inevitably gets his turn to waste everyone's time with nonsense
• They drift off-subject easier than a Chicago cab in heavy snow
• They frequently have agendas so vague nobody is really sure what they are about
• They require thorough preparation that people rarely do anyway

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

• Set a 30 minute timer. When it rings, meeting's over. Period.
• Invite as few people as possible.
• Never have a meeting without a clear agenda.

---

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...

• A new simple feature
• A small enhancement to an existing feature
• Rewriting some help text to reduce the support burden
• Removing some form fields that you really don't need

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.

---

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.

---

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:

• Quality of work
  Many programmers can talk the talk but trip when it comes time to walk the walk. With open source, you get the nitty gritty specifics of a person's programming skills and practices.
• Cultural perspective
  Programing is all about decisions. Lots and lots of them. Decisions are guided by your cultural vantage point, values, and ideals. Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you've got a cultural match. If there's no fit here, each decision will be a struggle.
• Level of passion
  By definition, involvement in open source requires at least some passion. Otherwise why would this person spend free time sitting in front of a screen? The amount of open source involvement often shows how much a candidate truly cares about programming.
• Completion percentage
  All the smarts, proper cultural leanings, and passion don't amount to valuable software if a person can't get stuff done. Unfortunately, lots of programmers can't. So look for that zeal to ship. Hire someone who needs to get it out the door and is willing to make the pragmatic trade-offs this may require.
• Social match
  Working with someone over a long period of time, during both stress/relaxation and highs/lows, will show you their real personality. If someone's lacking in manners or social skills, filter them out.

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.

---

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.

---

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.

---

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.