Un diseño más interactivo

Hay palabras que sirven para detectar cuando un cliente no tiene su idea clara, no tiene experiencia o no sabe lo que quiere.

La reina de todas esas palabras para mí es: “interactiva/vo”.

“Que permite una interacción, a modo de diálogo, entre el ordenador y el usuario.”
RAE

Típicas frases en las que se suele incluir dicha palabra:

  • Quiero un diseño más interactivo.
  • Necesitamos una aplicación, debe ser muy interactiva.
  • Nuestro valor diferencial es crear un producto con funcionalidades que ofrecen una mayor interactividad de la que se puede encontrar en los productos de nuestra competencia.

Las palabras interactiva, interactivo e interactividad son tan difusas que evitan hacer el ejercicio de pensar en resolver o incluso detectar los problemas que intentamos resolver en cada proyecto.

Si alguien te ofrece un presupuesto para hacer algo interactivo, sin entrar en el detalle que define el alcance de dicha “interactividad”, prepárate para una gran decepción.

foto por Mint Digital

Mercados de productos Open Source para desarrolladores

Ayer en Twitter se forjó un debate interesante inciado por Christian Soronellas, sobre este tema, concretamente sobre el cobrar por desarrollar productos y componentes de software para otros desarrolladores.

twit_chr

Esto me hizo recordar que, en el sitio web de Symfony en Español, Javier Eguiluz hizo una encuesta que tenía como objetivo recoger feedback para saber si la comunidad estaría interesada en desarrollar bundles (componentes de desarrollo) de pago. Estos fueron los resultados.

Otro tema interesante se lo leí a Álvaro Ortiz el otro día también en Twitter y me pareció una idea bastante chula: un servicio que pagase a los desarrolladores por solucionar issues pendientes en repositorios Open Source de github.

twit_furilo

El tweet de Álvaro se inspiró en el servicio GitTip, un crowdfounding en el que puedes pagar a desarrolladores en agradecimiento a su trabajo.

Volviendo al tema de los mercados, en algunas plataformas Open Source ya existen marketplaces que están funcionando bien, sobre todo en soluciones de eCommerce donde el valor que dan dichos componentes es muy claro ya que puede ahorrar costes y tiempos de desarrollo al desarrollador pero sobre todo al cliente final. Un ejemplo de mercado de este tipo es el Magento Connect.

En otras tecnologías emergentes, como Xamarin, podemos ver mercados de componentes que aparentemente también funciona muy bien.

Quizá uno de los principales impedimentos que tenemos en la comunidad PHP en comparación por ejemplo a la de Xamarin o quizá la de .net, es que históricamente los desarrolladores que han optado por esta tecnología no están acostumbrados a pagar por este tipo de cosas.

Sin embargo, creo que el mercado ha cambiado, o al menos está cambiando. Por dos motivos:

La expectación del cliente final ha cambiado

Los requisitos actuales para construir software web son mucho más exigentes que hace siete años.

A pesar de que cada vez hay más clientes que siguen la filosofía Lean o ya son conscientes de la importancia de desarrollar un producto mínimo viable, para ciertos servicios el optar por utilizar sistemas como Joomla o WordPress puede salir caro ya no a largo, sino a medio plazo.

Cada vez más, los servicios online requieren ser desarrollados con calidad, pero también en tiempos muy ajustados, sobre todo en mercados como el de Internet donde el time to market es importante.

Las herramientas han cambiado

Esto es una causalidad de lo anterior. Las herramientas se han adaptado a metodologías que nos permiten ser más productivos y adaptarnos a cambios drásticos del cliente.

En el mundo PHP, en menos de tres años, hemos visto aparecer no sólo frameworks como Symfony2, sino utilidades como composer que han dado un salto de calidad en nuestros hábitos de desarrollo.

Los frameworks nos están llevando a adoptar buenas prácticas de desarrollo como TTD, BDD o el uso de Inyección de dependencias. Esto nos hace posible desacoplar partes de nuestro código y poder por fin, acercarnos a una reutilización de calidad, calidad en el sentido de mantenimiento.

Teniendo en cuenta estos dos puntos, veo muy favorable, sobre todo mirando a largo plazo, el hecho de que nos planteemos de forma seria el rentabilizar esos desarrollos que podemos reutilizar en varios proyectos, ahorrando tiempo al cliente sin perder calidad.

Al igual que comentaba Javier Eguiluz en el resultado de la encuesta anteriormente citada, veo muy importante el crear un mercado de este tipo. Probablemente muchas de las cosas que echamos de menos en Symfony2 estarían resueltas y con mantenimiento gracias a dicho mercado.

Eso sí, si todos lo viésemos claro, el reto entonces sería cómo hacerlo, cómo vender esos productos.

Ahí van algunos puntos que veo que darían para un debate:

Producto y soporte

Desarrollas el producto y lo vendes. Pero es ahí cuando empieza todo, sobre todo si es basado en tecnología open source. No voy a decir que el código no vale nada, porque probablemente me mataríais, pero sinceramente creo que lo más valioso es estar detrás dando soporte y updates al producto.

El soporte es lo más caro del desarrollo de un producto y sin soporte, la experiencia es mala y tu producto es percibido como humo.

Hay muchos ejemplos de cómo enfocar esto, aunque como siempre, creo que sería posible darle una vuelta de tuerca al asunto.

Precio y forma de cobro

Teniendo en cuenta lo anterior, es clave poner un precio acorde a lo que vas a ofrecer. Es muy posible que si te equivocas en el precio, cuanto más vendas, más dinero pierdas.

El precio no se puede decidir en una mañana echando un café, es uno de los puntos más difíciles a la hora de crear un producto.

En un mercado de este tipo podríamos llegar a pensar que la guerra de precios es inevitable, pero al ser desarrolladores, sabemos diferenciar de forma muy directa qué producto tiene mejor calidad o soporte, que al final son los baremos más adecuados para medir si un precio es adecuado o no.

Distribución y licencia

Si hablamos de productos Open Source orientados al desarrollador y de que los updates son una parte muy importante, no sería descabellado el pensar que lo natural sería dar acceso al repositorio a nuestros clientes de pago.

Si esto nos parece exagerado o nos da pánico, gracias a composer podemos crearnos nuestro propio repositorio de paquetes privado para composer con la utilidad Satis.

Por último, podríamos optar por la manera tradicional de descarga vía zip y que nuestros clientes gestionen las actualizaciones de forma manual.

En el tema de las licencias tengo muchísimas dudas, incluso después de haberme leído unas tres veces este genial libro sobre el tema. Es un punto importante que nos sirve para proteger el producto de una forma más efectiva que cosas como la encriptación de código, que yo personalmente rechazo completamente.

En resumen, creo que crear mercados de este tipo son muy importantes para desarrolladores de PHP, tanto de Symfony como de otros frameworks y daría para un debate muy interesante e incluso para un evento en el que contar experiencias reales vividas al vender productos de este tipo.

Ya no vale con crear un producto

Quien haya trabajado conmigo desarrollando servicios para Internet, ya sea proveedor, cliente o socio, sabrá la importancia que le doy a crear comunidad entorno al producto o servicio que se esté desarrollando.

Con comunidad no me refiero a followers en twitter o facebook, sino a personas reales, de carne y hueso, que cuando ven cosas que has hecho o avances, sientan tal afinidad con tu proyecto, que se alegren hasta tal punto que la consecuencia sea difusión, por boca a boca o por redes sociales.

Estoy convencido de que ya no vale con crear un producto, o servicio, y desarrollarlo. Además hay que forjar una cultura, y sobre todo una historia, en torno a la empresa o al proyecto.

Por mi experiencia, creo que esto hay que hacerlo antes de que el producto esté terminado. El problema suele ser el tener la percepción de que estás vendiendo humo, pero si realmente vas en serio y sabes hacerlo ver, tus usuarios van a saber apreciar la autenticidad y conseguirás que tengan el recuerdo de una historia, la historia del comienzo del proyecto, de la que ellos han sido testigos e incluso se han sentido partícipes.

Esto puede verse como tremendamente costoso, cosa que sin duda alguna lo es, ya que requiere una constancia, cuidado de detalles y crear un contexto, una personalidad natural del proyecto, para que todo tenga un sentido.

Lo cierto es que esto no todas las personas o empresas son capaces de hacerlo y no se puede forzar.

Sin duda, las empresas y líderes que entiendan esto van a conseguir estar a años luz de su competencia, incluso cuando esta parezca tener un producto mejor, más barato o esté invirtiendo cantidades abismales en publicidad de buscadores.

A mí me encanta trabajar con personas que tienen ese punto creativo, pero a la vez tienen suficiente experiencia para saber lo que el mercado realmente quiere y priorizar con los pies en el suelo.

Creo que esta va a ser la forma de vender productos tipo aplicaciones móviles, juegos o servicios web B2C.

Me ha inspirado a escribir esta entrada en mi blog, el mimo y cuidado con el que el equipo de desarrollo de Crystal Dinamycs que trabaja en la nueva y renovada saga de Tomb Raider está aplicando lo que comento.

Presupuestos

Esta semana mi socia Irene Vidal de 4Visions, ha publicado un post sobre el trabajo de presupuestar.

Irene es una gran profesional del mundo de la traducción y comenta algo a lo que estamos ya acostumbrados por desgracia en otros sectores como puede ser el de desarrollo o consultoría: lo frustrante que es invertir tiempo en hacer un presupuesto que luego no obtiene respuesta o que quede en el olvido.

Hace tiempo en mi twitter puse lo siguiente

Creo que esto es algo inevitable, hay quien cobra por hacer el presupuesto, pero en servicios fuera de consultoría esto es impracticable y no da buena imagen.

Otra opción es recordar cada cierto tiempo si hay novedades sobre el presupuesto, llamar al cliente cada cierto tiempo y hacer un seguimiento en definitiva de estos temas abiertos. Es un trabajo muy importante pero sólo es practicable cuando el cliente realmente quiere trabajar contigo y no esté buscando el mejor precio sin importarle quién le haga el trabajo.

Por lo general, como comenta Irene, los que más piden presupuestos para luego no dar señales de vida, son los que quieren invertir el menor tiempo y dinero posible o los que nunca van a desarrollar el proyecto.

Pero hay algo incluso peor que nos sucede a los que nos dedicamos al mundo del software: nos piden presupuestos sin saber lo que quieren.

Es habitual recibir emails del tipo, “Necesitamos un presupuesto orientativo para programar un sitio web como verkami.com”, “necesitamos un programador para desarrollar un clon de pinterest”.

Evidentemente este tipo de clientes no sabe ni de precios, ni que un programador no le va a hacer un trabajo correcto de diseño, ni lo que va a necesitar a nivel de estrategia, ni los problemas de escalado, ni que el desarrollo de ciertos proyectos pueden llegar a durar años, ni de los problemas a la hora de cobrar a sus usuarios, entre otras muchas cosas.

Me ha llamado la atención este update en twitter de Marcos Labad de Acilia, en el que hace un comentario que resume perfectamente este hecho.

Esta es la razón por la que he empezado a ofrecer mi servicio de diseño de producto en Simettric. Presupuestar o desarrollar un sitio web o un software sin tener claro al detalle qué es lo que se quiere, priorizado y detallado está abocado al fracaso.

Muchos hemos caído en este error en el pasado, yo en varias ocasiones, por tener confianza con el cliente o por permitir que se asumiese que estaba todo dicho o por las razones que sean, y finalmente siempre terminas aprendiendo que no has podido calcular el precio de forma realista, el cliente no tiene la percepción de lo que cuesta hacer el proyecto y en el peor de los casos, quedar fatal por no haber dejado las cosas claras.

Ahora bien, ¿debe un desarrollador o una agencia de desarrollo definir el producto, la estrategia (sí en algunas ocasiones asumen que esto también es labor de un desarrollador) e incluso definir el backlog de forma gratuita? Mi respuesta es NO.

Evidentemente es un NO con la boca muy llena, ya que hay clientes a los que no se quiere perder bajo ninguna costa, pero en mi caso particular he aprendido que si no cobras ese trabajo o si no dejas claro que ese trabajo tiene un coste, terminas regalando una responsabilidad final que dependiendo del cliente puede llevarte a una rotura emocional, tuya y de tu equipo, a mitad del proyecto que evidentemente afecta al mismo.

Por mi parte he elaborado un servicio en el cual no sólo se sacan requisitos, doy bastante más valor añadido e incluso entro en temas como asesoramiento de precios y otras cosas dentro del modelo de negocio. Esto hace que los clientes valoren mucho más el trabajo que conlleva entender la complejidad de enfrentarte a un proyecto en internet y qué tipo de información necesitan programadores y diseñadores para no tener conflictos a medio plazo que eviten que el proyecto se desarrolle con el éxito esperado.

Existen clientes que no quieren que este trabajo lo haga el profesional que se va a encargar de ejecutar el desarrollo, pero esto no excluye para que deba hacerse antes de plantearse un diseño o evidentemente, un desarrollo para el proyecto. Sin este trabajo en mi experiencia el proyecto puede convertirse en un infierno desmotivante para todos los involucrados, que rápidamente deja de ser rentable y viable.

Responsables de producto y su dominio

“Puede ser peligroso para un responsable de producto tener demasiada experiencia en un dominio concreto.

Digo esto porque un responsable de producto que haya invertido mucho tiempo en conocer un dominio concreto puede caer en una trampa común de la dirección de producto: creerá que puede hablar a su consumidor target pensando que está más cerca de él de lo que realmente está.

No es imposible para alguien que tenga mucha experiencia en un dominio concreto hacerlo correctamente, pero deberá trabajar muy duro para tener la mente abierta a otras opciones y desarrollos.

No digo que no necesites experiencia en un dominio para hacer un buen trabajo con tu producto, de hecho comprender el dominio de tu producto perfectamente es esencial, y no me refiero a un conocimiento superficial. Pero creo que buenos responsables de producto pueden adaptarse más rápidamente que la mayoría a nuevos dominios si se enfocan de forma agresiva en el proceso de aprendizaje de los mismos.”

Marty Cagan.