Sunday, 22 February 2015

Construir lo correcto, construirlo correctamente o construirlo rápido

Siempre que desarrollamos un producto, nos demos cuenta o no, estamos haciendo un balance entre construir lo correcto (la funcionalidad exacta que necesita nuestro cliente), construirla correctamente (siguiendo la mejor arquitectura o los mejores estándares), o construirla de la forma más rápida posible.

Por supuesto, todos queremos estar en el punto del centro de la imagen y conseguir los tres aspectos al mismo pero es muy difícil lograr el equilibrio perfecto, cuando no imposible. A menudo debemos ir hacia uno de los lados de la figura para sacar la mejor versión de nuestro producto adelante.


Si nos movemos hacia el punto 1, en la intersección entre construir lo correcto y construirlo correctamente tendremos un producto perfecto con una arquitectura también perfecta pero podemos haber tardado demasiado en construirlo y no tenerlo disponible cuando el cliente la necesita o cuando el mercado lo demanda. Construir un Whatsapp con interfaz web puede estar muy bien justo ahora y hacerse muy popular y hacerse muy popular en poco tiempo pero podría ser demasiado tarde si lo entregamos dentro de un año.

En cambio, si tendemos hacia la intersección del punto 2, crearemos muy rápido el producto correcto partiendo quizás de un prototipo evolucionado pero que podría llevarnos a arrastrar una deuda técnica muy grande. Esta deuda técnica podría hacer que termine siendo inabordable cada vez que queramos construir nuevas cosas sobre una arquitectura base tan pobre.

En la tercera y última de las opciones podríamos construir muy rápidamente un vehículo con una bonita línea deportiva y un gran motor pero olvidamos construir lo correcto: nuestro cliente en realidad necesitaba un producto con algo de capacidad de carga para su trabajo diario.

Según sea nuestro papel en el proyecto todos tenemos cierto sesgo hacia alguno de los círculos. Los dueños del producto, es decir nuestros clientes, tienden a poner todo el foco en construir lo correcto. A su vez los miembros del equipo de desarrollo tienden en cambio hacia construir correctamente, centrándose en las cuestiones de diseño de la arquitectura y de la solución técnica. Por último el Scrum Master tiende habitualmente hacia construir el producto de la forma más rápida posible.

Ese es el papel que suelo tener yo, el de Scrum Master o jefe de proyectos, que solemos andar preocupados por el tiempo en el que vamos a entregar las cosas. En nuestro descargo debo decir que la velocidad es siempre un aspecto importante. Iterar y entregar nuevas funcionalidades más pronto nos va a permitir aprender antes qué es lo más importante a construir ahora y cómo construirlo técnicamente de la mejor forma posible.


Todo esto que comento aquí lo puedes encontrar de forma muy condensada en el vídeo sobre Product Ownership de Henrik Kniberg. No sólo habla de este dilema entre construir lo correcto, construirlo rápido o de la mejor forma posible sino de muchos otros aspectos relevantes para los dueños del producto y directores de proyecto en el cliente. Échale un vistazo, es muy bueno.


Sunday, 15 February 2015

Los artistas de verdad entregan su trabajo (Real artists ship!)

A veces, y no pocas veces, retrasamos entregar nuestro trabajo porque creemos que todavía no está listo, que aún hay que mejorar o corregir cosas, que aún tenemos que seguir trabajando en él. En realidad suele ser miedo a fracasar, a que nuestro producto salga al mercado y que nadie lo compre porque no es perfecto o porque no da la talla. Puede ser también miedo a recibir críticas porque nuestro producto, nuestro libro, nuestro software tiene aún algún error gramatical o un pequeño bug: 'Sólo publicaré la nueva entrada en el blog cuando nadie pueda ponerle ningún pero'. Otras veces se trata simplemente de la parálisis del perfeccionismo.

Cierto profesor de alfarería en una escuela de arte dividió a sus alumnos en dos grupos y les dijo lo que tenían que hacer para obtener un 10 en su asignatura. Al primer grupo les dijo que tenían que hacer 100 jarrones para obtener la máxima calificación pero al segundo grupo les dijo que si querían obtener ese diez deberían hacer el mejor jarrón. Este último grupo dedicó todo el tiempo a teorizar y a leer sobre las mejores técnicas para hacer jarrones pero en realidad los mejores jarrones los hizo el primer grupo. Habían dedicado su tiempo a practicar y practicar haciendo 100 jarrones mejorando así su técnica. Lo mismo pasa con tu blog, con tu aplicación o con ese diseño al que llevas tiempo dándole vueltas. Deja que se encuentren con los verdaderos usuarios y que ellos den el visto bueno.

El mundo del software está llena de productos que se desarrollaron durante años hasta tener todas las funcionalidades que el cliente pudiera imaginar, diseñados tal como fueron concebidos por sus creadores. Lamentablemente cuando salieron al mercado éste tenía sus propias ideas y necesidades. Muy poca gente usaba todas las características de la aplicación. Otras en cambio eran muy demandadas pero nadie había pensado en ellas cuando se diseñó.

Ya se sabe, lo perfecto es enemigo de lo bueno. Cuando tengas un producto pequeño pero que ya puede ser útil, lánzalo al mercado (ship), exponlo al público, gánate tus primeros clientes. Ellos te dirán lo que echan en falta. Aprende de eso, lanza luego una segunda versión, luego una tercera. Si con la primera versión no consigues hacerte con una pequeña cartera de clientes, quizás no sea el momento o lugar para tu producto. Por lo menos aprenderás un montón de cosas que antes no sabías y no habrás perdido meses y meses de tu trabajo.


Sunday, 8 February 2015

Más vale pedir perdón que pedir permiso

Cuando comencé mi primer trabajo el único consejo que me dio mi padre fue 'No te pases el día preguntándole a tu jefe qué hago ahora. Echa un vistazo y tú mismo verás un montón de cosas por hacer'. He intentado seguir este consejo en todos los trabajos que he tenido hasta ahora y quizás sea el que mejor me haya funcionado. Siempre es mejor contestar a tu jefe que ya has terminado lo que nos encargó y que has comenzado otra tarea que quedarnos esperando porque Pérez está de vacaciones o porque nadie nos dijo que podíamos comenzar ya.

En cada organización y en cada trabajo tenemos que tomar muchas pequeñas decisiones en las que otro tiene las competencias, ese otro es el que siempre ha hecho estas cosas o es el que más sabe del asunto. Pero ahora no está y tenemos que seguir trabajando. Podemos pasar a otra tarea pero pronto volveremos a toparnos con una decisión que nos impide seguir avanzando. Como resultado todo está comenzado y nada acabado. Volver a esas tareas pendientes unas horas, días o semanas después tiene un coste adicional que nos mantiene en nuestro pequeño caos diario.

Uno de los gurús en técnicas de gestión ágiles y el rediseño de organizaciones explicaba en una de sus charlas una analogía que muy bien puede servir para lo que quiero explicar en esta entrada: Si somos parte de un equipo de rugby y durante el juego la pelota pasa rodando delante de nosotros ¿vamos a pararnos y esperar a que el pateador (kicker) venga y le dé una patada hacia delante? Él es el que mejor golpea la pelota. Por supuesto que no, vamos a correr hacia ella a intentar darle la mejor patada que hayamos dado en nuestra vida. Por mal que lo hagamos la pelota siempre estará un poco más cerca del campo contrario.

Podemos pararnos a esperar a que el pateador patee, a que el diseñador diseñe, a que el de la ventanilla de al lado resuelva el problema o a que la señora de la limpieza quite la mancha del suelo. Hagámoslo nosotros mismos, resolvamos el asunto lo mejor que podamos. Los perfiles profesionales son cada vez más borrosos y todos debemos aprender a hacer de todo. Si lo hacemos así, las cosas empezarán a funcionar un poco más deprisa y, cuando menos, habremos adquirido algo más experiencia y un montón de puntos de vista diferentes.

¿Cómo saber cuándo es algo que podemos resolver nosotros mismos o realmente debemos esperar por alguien? Si cometemos un error y puede arreglarse con un simple 'Lo siento, me equivoqué', no hay duda, adelante, hazlo. Es cierto que siempre hay un riesgo de meter la pata pero ¿qué ganamos cruzándonos de brazos?


Esta entrada apareció por primera vez en desencadenado.com como post invitado.

Sunday, 1 February 2015

Google+ como herramienta de gestión de proyectos

En algunos países herramientas como Basecamp son muy populares para llevar la gestión de sus proyectos pero que tienen un coste elevado para proyectos medios o pequeños (3,000$ al año en el caso de Basecamp). En la empresa en la que trabajo hemos buscado opciones que nos permitan obtener un buen número de las ventajas que obtendríamos si usásemos la herramienta de 37signals pero a un precio más bajo. Como resultado de esta búsqueda hemos encontrado a la red social Google+.

Aprovechando que en la empresa en la que trabajo cada empleado cuenta con una cuenta de Google Apps for Business para nuestro correo corporativo, Google Drive o Google Calendar hemos pensado en dar una oportunidad a esta red social de Google como herramienta para la gestión de nuestros proyectos. Aunque ya la habíamos usado para proyectos más pequeños, es en éste en el que le hemos dado un uso más intenso. Llevamos ya unos cinco meses teniendo a G+ como herramienta de apoyo. Les cuento aquí el uso que le hemos dado y las ventajas que nos proporciona:

Google+ para la comunicación

En lugar de estar enviado un email tras otro a todos los miembros del equipo con las noticias o los eventos del proyecto simplemente entramos en G+ y escribimos una nota en la comunidad del proyecto. Esta comunidad es una especie de círculo privado al que sólo hemos dado acceso a los miembros del proyecto y en el que podemos ver un panel con todas las entradas escritas anteriormente.

Cuando una nueva nota es escrita en el panel del proyecto una pequeña notificación nos llega a nuestra cuenta de correo en forma de campana. De esta manera estamos siempre avisados de que hay una novedad en el proyecto.

En esta otra imagen pueden ver un ejemplo de notificación al equipo de trabajo sobre la planificación de los sprints. En cada sprint se envía la planificación prevista y unas horas antes de un evento se publica un recordatorio de lo que tenemos previsto para ese día: una demo, pre-demo, tests, etc. En este caso es la planificación genérica para los sprints por lo que ha sido marcada (stick) para que figure siempre en la primera posición de todas las entradas:

En la esquina superior derecha hay una imagen que indica que esta entrada se marcó con el hashtag #Planificación, como se hace en Twitter, para que podamos buscar por ella de forma más fácil.
En esta otra imagen un compañero anuncia que acaba de finalizar el despliegue en el entorno de demo de la milestone nº 8 por lo que ya está disponible para nuestra demo interna antes de ser liberada al cliente.


Wiki y repositorio de documentos

No solo ponemos anuncios y notificaciones en esta web del proyecto sino que también lo utilizamos como repositorio de información y de documentos. Google+ permite adjuntar documentos a las entradas que publicamos o añadir enlaces. Está limitado a sólo 2GB de información por cuenta pero de momento nos está siendo más que suficiente. También hace sus funciones como wiki ya que podemos encontrar soluciones a problemas que han surgido durante el desarrollo. Aquí por ejemplo tienen una entrada sobre un bug en Windows que impide que se muestren bien unas páginas modales de la aplicación y su posible solución:


 Acceso móvil en la nube

Google+ está en los sistemas cloud de Google por lo que podemos acceder a ellos desde cualquier parte no solo desde nuestras oficinas. Además, en cualquier dispositivo móvil podemos instalar la app de Google+ y acceder a toda esta información, documentos y eventos con solo un par de clics. No necesitamos ninguna VPN o escritorio remoto para acceder a nuestras carpetas de red.

¿Te animas a usar Google Plus para tus proyectos? Haz una prueba primero con tu cuenta de Gmail. Podrás crear una cuenta de Google+ asociada al email haciendo clic en el enlace +Tú que aparece en la parte superior derecha de la página de Gmail. Desde ahí crea una nueva comunidad (clic en Inicio/Comunidades/Crear comunidad), asocia a los miembros del proyecto que quieras (tendrás que invitarlos primero a usar G+) y ya lo tienes todo listo para empezar a gestionar tus proyectos.