Getting Real Overview
Getting Real Overview
Buy Getting Real in PDF or paperback.
Looking for design, copywriting, or programming help with your project? Check the Gig Board.
¿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 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.
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.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.
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.
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.
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.
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.
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.
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.
Para dejar algunas cosas en claro, estas son nuestras respuestas a los reclamos que comunmente escuchamos:
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.
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.
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.
¿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."
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, MicrosoftEl 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:
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.
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 ProgrammerCampaign 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 MonitorCuando 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)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?
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.
[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ídoHe 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).
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 computacionalA 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.
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)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 & BlinklistCuanto 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.
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.comA 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 RecordsCuanta 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.
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.
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.
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 ProgrammersPara 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