4 steps to epiphany

By Agustín Cuenca | Published: 12 December, 2011

Sorry, this entry is only available in Español.

Posted in Sin categoría | Leave a comment

¿Cuanto me cuesta y cuando lo tienes?

By Agustín Cuenca | Published: 28 October, 2011

En los comentarios de un post anterior me comprometi a escribir una versión larga de como respondemos a esta pregunta, y lo voy a intentar ;-)

En el 99% de los casos los clientes llegan a las empresas de desarrollo con una idea del proyecto que quieren abordar y con esta pregunta en la cabeza. La industria del software lleva años contestando a esta pregunta apoyándose en diferentes metodologías, en la experiencia, etc. La realidad es que hay muchos estudios donde se muestra que estas respuestas fracasan. Un altísimo porcentaje de los proyectos de desarrollo de software se entregan tarde, o incluso no se entregan, (en realidad no se mucho de otras ingenierías pero me da que pasa mucho también, piensa en la cantidad de obras públicas siempre retrasadas).

En mi opinión esa pregunta no tiene respuesta. Lo siento pero hay cosas en esta visa a las que no se puede contestar con certeza. Y la razón es que las especificaciones del proyecto, es decir, lo que hay que construir no están cerradas, falta información de detalle, y además aunque estuvieran cerradas tu proyecto va a avanzar por el camino y lo que pensabas que es importante deja de serlo, lo que pensabas que era simple resulta ser complejo, y además se te ha ocurrido una idea nueva con la que no contabas. Así es que si, y sólo si, tienes especificaciones cerradas entonces te puedo dar un plazo y un precio cerrado de verdad.

En general ante la presión de los clientes los desarrolladores se ven obligados a arriesgar, (estimar lo llamaban en la universidad), y a trasmitir al cliente la falsa sensación de que cuenta con un precio y un plazo cerrado. En realidad es una falsa sensación, pero a la mayoría le vale. El proveedor le da al cliente lo que quiere, y sabe que luego vendrán los cambios, los “poyaques”, las cosas no previstas, etc. El cliente tiene la falsa sensación de seguridad que además en general la necesita para sus jefes o accionistas. Todos nos engañamos a todos, pero aparentemente somos mas felices.

Nosotros preferimos darnos de bruces con la realidad y los últimos años de experiencia en desarrollo de software. A mi me gusta mucho la frase que usan en Alcohólicos Anónimos: “Hola me llamo Agustín y soy alcohólico”, es decir los problemas solo se resuelven si eres capaz de aceptar que lo tienes.  En este caso significa aceptar que tus especificaciones no están cerradas, que no tienes el conocimiento suficiente para poder hacer un plan que acierte.

En realidad lo que hay que hacer no es responder a la pregunta, lo que hay que hacer es cambiar de pregunta. La pregunta adecuada es:

¿Cual es el mejor proyecto que puedo construir con los recursos y el tiempo que tengo?

Como contestar a esa pregunta me da para otro post.

Posted in Gestión clientes, Metodología | Leave a comment

Maximizador vs. Satisfactor

By Agustín Cuenca | Published: 26 October, 2011

En realidad como me pillen los de la RAE seguro que me sacuden yo creo que no existen esos términos en castellano.

Maximizador y Satisfactor son dos malas traducciones de Maximicer y Satisficer , son dos términos que aprendi en el libro “The paradox of choice” y tiene que ver con como nos enfrentamos las personas a las decisiones. Según esta división hay dos tipos de personas:

  • Maximizadores: son los que intentan siempre obtener el máximo de cada decisión. Estudian todas las alternativas, piensan en las ventajas e inconvenientes de cada opción y siempre buscan la mejor respuesta.
  • Satisfactor: son aquellos a los que les basta con que una de las opciones disponibles sea suficiente para ellos, da igual que haya opciones mejoras, la elegida les  es suficiente y  no necesitan mas.
Los maximizadores siempre toman mejores decisiones, si las comparamos con los satisfactores, pero son gente mas infeliz que por lo general nunca están contentos con el resultado final (“a todo hay alguien que gana siempre” que decía mi Madre), y siempre se reprochan no haber buscado algo mejor. Los satisfactores suelen tomar peores decisiones, pero son en general mas felices con ellas.
Es fácil ver que tipo de persona somos, a mi me parece que el mejor ejemplo es en un restaurante de carta larga. El satisfactor pide más rápido, y el máximizador siempre pide el último. Cuando llega la comida, suele acertar mas el máximizador pero es el que suele arrepentirse de lo que ha pedido.
En el desarrollo de proyectos web, suele pasar lo mismo, pero en este caso la diferencia no está en la satisfacción con el proyecto (que también), sino con el éxito del mismo.
Una aproximación de máximos, es posible que consiga una web mas rica y funcionalmente mas completa, pero el precio a pagar es alto porque:
  • La web será mas compleja, lo que hace que la curva de aprendizaje de los usuarios sea mayor.
  • El coste de marketing aumenta, hay mas cosas que explicar.
  • EL coste de desarrollo aumenta, hay mas cosas que hacer.
  • El coste de mantenimiento aumenta.
  • En el arranque del proyecto el numero de cosas con las que no hemos acertado aumenta.
  • Tardas mas en salir a producción, porque hay mucho mas que hacer.
Yo creo que para lanzar tu proyecto web, la estrategia de los satisfactores es la que aumenta la probabilidad de éxito de tu proyecto.
Posted in General, Metodología | 5 Comments

Medio embarazada

By Agustín Cuenca | Published: 31 August, 2011

No se puede estar medio embarazada. O estas o no estás, pero a medias no es posible.

Lo mismo pasa con esta nueva manera de hacer proyectos, no se puede hacer a medias, o estas convencido de que es la manera correcta, o al menos estas dispuesto a probarlo o si no mejor que no lo hagas.

El desarrollo en proyectos en cascada requiere una serie de procedimientos (reuniones, documentos,etc)  y artefactos (planes de proyecto, baseline, etc.) que cuando haces proyectos de manera ágil dejan de tener sentido.

El ejemplo mas claro es cuando algunos clientes nos piden un plan de proyecto a la manera tradicional. Hemos intentado en mas de una ocasión en dar al cliente que nos lo pedía el plan de proyecto que el esperaba, pero la realidad nos enseña que eso no es posible, entre otras cosas porque:

  • Desarrollando de manera ágil, el plan cambia cada pocos días, y acabas dedicando mas tiempo a actualizar y mantener el plan del valor que te aporta el plan.
  • Fijar objetivos a medio plazo hace que estos cobren mas valor (“están en el plan”) y es posible que las cosas hayan cambiado y ya no aporten tanto valor como cuando hicimos el plan, pero a los humanos no nos gusta equivocarnos, y muchas veces defendemos algo solo por el hecho de que ya lo habíamos defendido antes.
  • Estamos construyendo el mejor proyecto posible con el tiempo y los recursos disponibles, por lo que dedicar tiempo a hacer el plan nos ayuda a ganar en seguridad (en teoría), pero en realidad no aporta nada al proyecto final.

No pretendo en este post hablar sobre como gestionar la falta de un plan tradicional,  lo que si quiero decir es que si necesitas un plan de proyecto, entonces tu modelo de desarrollo debe ser otro. Lo siento, pero tienes que elegir, no puedes tenerlo todo. Si quieres un plan, entonces tenemos que cerrar el alcance y definir lo que quieres hacer para que yo te pueda dar el plan.

No valen trucos del estilo: “Haz el plan mas o menos y no te preocupes que ya lo cambiaremos”. En mi experiencia eso no es así. Ese plan luego se convierte en una espada de Damocles para el que lo escribe.

Trabajar de manera ágil aporta un montón de ventajas, y sin duda creo que es la metodología que mas se adapta al desarrollo de software en las condiciones actuales de mercado y para los proyectos que hacemos en ASPgems, pero tiene algunos costes y estos son:

  • La relación con el equipo de desarrollo (interno o externo) tiene que estar basada en la confianza ( y se confía o no se confía).
  • Tu capacidad de control se ve limitada, en mi opinión control y confianza no pueden coexistir.
  • Te toca trabajar mas, como cliente debes participar en el proyecto casi a diario.

Nosotros seguimos apostando por esta nueva (“solo tiene 10 años ;-) ” ) manera de desarrollar.

Posted in General, Gestión, Metodología | Tagged , , , , | 4 Comments

Por qué hay precios por hora tan distintos entre los proveedores de tecnología

By Agustín Cuenca | Published: 9 March, 2011

El otro día, en el blog de ASPgems hablábamos sobre el valor real de la tecnología en un proyecto web, y comentábamos lo arriesgado que resulta contratar a un proveedor teniendo en cuenta, exclusivamente, el precio por hora.

Creo que este es un tema crucial. De hecho, muchos de los clientes que vienen a contratar un proyecto con nosotros nos explican que, si nuestra oferta es, pongamos por caso, de 40.000 euros, ellos han encontrado ofertas en el mercado por 10.000.

¿Cómo es esto posible?

Que nadie se engañe: no existen grandes márgenes y, por supuesto, nadie da duros a cuatro pesetas.

Estas son las razones por las que existen precios por horas tan diferentes en el mundo del desarrollo web.

1. El proyecto -uno parecido- ya está hecho

Un proveedor de tecnología puede ajustar mucho su oferta -su precio y su plazo de desarrollo- cuando, con anterioridad, ha desarrollado un proyecto muy parecido al actual, y lo “único” que tiene que hacer es coger el código y adaptarlo.

Esta opción puede ser interesante para el cliente cuando el código es realmente válido para sus objetivos, cosa que raramente sucede.

Si el proveedor tiene que empezar el código desde 0, la cosa cambia. Incluso si el proveedor es capaz de aprovechar la experiencia anterior, cambiar el foco a un desarrollo para transformarlo en otro no resulta nada sencillo, porque cada desarrollo implica su propias decisiones, válidas exclusivamente para unas circunstancias muy concretas. En resumen, dos proyectos pueden ser parecidos, pero nunca son iguales.

El otro riesgo de esta opción es que acabes metiéndote en un producto ya hecho, con todos los inconvenientes que eso implica, muy particularmente el vendor lock-in.

2. El proveedor está atravesando una situación complicada

Hay proveedores que están atravesando una mala situación económica y, dado que el coste del despido es muy alto, prefieren trabajar sin margen a tener a la gente parada. Esto puede llevarles a “tirar los precios”.

El problema es que si contratas a un proveedor en apuros puedes meterte en un jardín del que luego resulta muy complicado salir.

¿Y si el proveedor quiebra antes de realizar tu proyecto?

Además, es fácil que las empresas que atraviesan dificultades -económicas o de cualquier tipo- acaben convirtiéndose en un foco de tensión: el rendimiento no suele ser el mejor cuando los empleados están pensando en marcharse, o en que pueden quedarse sin trabajo en cualquier momento.

En estas circunstancias, la tensión suele ser máxima, y la motivación, mínima. Todo esto acabará reflejado, de una manera u otra, en el resultado final del proyecto.

3. Bajo sueldo -y baja cualificación y experiencia- de los desarrolladores

La estructura de costes de este negocio es muy sencilla. El coste por hora de una persona se calcula -grosso modo- con la siguiente fórmula:

sueldo + variable + coste de seguridad social / 11 meses de trabajo.

Por lo tanto, el sueldo de los desarrolladores es una variable clave en el precio final de un proveedor.

La horquilla de sueldos es muy amplia. En el mercado hay desarrolladores que cobran desde 12.000 hasta 60.000 euros. Es evidente que un proveedor que contrate los servicios de desarrolladores de “bajo coste” puede ofrecer unos precios mucho más ajustados.

Pero ojo: se engaña quien piense que es lo mismo tener 1 año de experiencia que 10. Un desarrollador excelente, acostumbrado a encontrar soluciones técnicas para casi cualquier problema, y acostumbrado también a tratar y entender al cliente, y a entregar un trabajo de primera calidad, no solo es clave para el precio. También -o sobre todo- es la clave para el éxito final del proyecto.

Por eso deberías pensártelo muy bien antes de dejar tu proyecto en manos de profesionales sin la suficiente experiencia y/o la suficiente motivación.

4. No se ha entendido bien el proyecto

Existe otra razón por la que el precio puede ser más bajo: que el cliente haya solicitado una cosa y el proveedor haya entendido otra muy distinta, de menor exigencia y alcance en comparación con la petición original.

Si las estimaciones del proveedor se han realizado teniendo en cuenta esa aproximación errónea, el resultado final no puede ser más que un fracaso: en plazo, en presupuesto, en alcance, en gestión del proyecto, en relación comercial, etc.

5. Precio de entrada en cliente

En muy contadas ocasiones, un proveedor puede decidir bajar el precio -incluso hasta el extremo de perder dinero- con el único objetivo de entrar, o aterrizar, en un cliente que considera estratégico, con la esperanza de que, en el futuro, le proporcionará muchos otros contratos mucho más rentables.

Esta circunstancia solo puede concurrir en el caso de las grandes empresas; muy raramente en el caso de una pyme (es muy difícil que una pequeña y mediana empresa, y menos un autónomo, sea capaz de demandar un gran volumen de proyectos de tecnología).

6. Gestión del cambio

Hay proveedores que ofrecen un precio exageradamente bajo porque confían en aumentar ese presupuesto inicial utilizando una metodología de gestión de cambios.

El modus operandi suele ser el siguiente: el proveedor es consciente de que las especificaciones iniciales -y el presupuesto asociado a ellas- van a verse superadas muy pronto, en cuanto el proyecto se ponga en marcha. Por eso, su equipo está atento para detectar y gestionar cada cambio. Es decir, cada vez que el cliente solicita un cambio sobre lo inicialmente acordado, el proveedor le hace firmar una ampliación, de forma que la facturación va creciendo y creciendo

Como es evidente, el precio firmado al principio no tiene nada que ver con el precio real, el que se ha pagado al finalizar el proyecto. En este sentido, la oferta inicial -aparentemente atractiva- no es más que un espejismo (o una trampa).

¿Cómo elegir?

Después de analizar las razones por las que, a veces, existe una diferencia tan grande entre los precios de los diferentes proveedores de tecnología, solo queda responder a la pregunta clave:

¿Qué tengo que tener en cuenta para elegir al mejor proveedor?

Además de analizar las razones mencionadas, creo que lo más sensato es tener en cuenta estas tres variables:

  • track record: los proyectos que el proveedor ha realizado con anterioridad, las tecnologías utilizadas, etc.
  • referencias de clientes que ya han trabajado con ese proveedor
  • propuesta: cómo se ajusta a nuestras necesidades
  • y la confianza que el proveedor es capaz de inspirarnos
Posted in General | Tagged , , | 1 Comment

Los proyectos necesitan mucho cariño, y pasión por el detalle

By Agustín Cuenca | Published: 8 March, 2011

Lanzar una web no es solo un problema de metodología y tecnología. El proyecto también necesita mucho cariño, dedicación y auténtica pasión por el proyecto y también por el detalle.

Tendemos a pensar que la programación de las funcionalidades básicas es la parte más importante de un proyecto web. Pero, tal y como se encarga de demostrarnos la experiencia, en muchas ocasiones el éxito reside en los pequeños detalles, que acaban consumiendo una parte importantísima del coste final del proyecto, tanto de desarrollo como de prueba y error.

Un ejemplo. Solemos pensar que lo más complejo de un desarrollo es el proceso de búsqueda, el mecanismo para invitar a otros usuarios a que formen parte de nuestra red social, o el matching de intereses. Y es verdad que son desarrollos exigentes. Pero, al fin y al cabo, tienen un coste en recursos acotado.

Por el contrario, la elaboración de los diálogos en las altas y bajas de usuarios, o la gestión de contenidos, son tareas que no son técnicamente difíciles, pero que requieren mucho cariño, y al final se llevan gran parte de nuestro tiempo y nuestro trabajo.

El ejemplo de Charadas

Charhadas es un ejemplo de proyecto realizado con mucho cariño y pasión por el detalle. Su equipo dedica muchas horas de trabajo a la generación de contenidos relevantes, estudia el comportamiento de las usuarias para saber qué hacen, cómo lo hacen, qué necesitan, y cuáles son los contenidos que más les interesan. Incluso les ayudan en la edición.

En definitiva, todo en el sitio web está pensado para el usuario final. Y eso se nota, Charhadas es un sitio en el que hemos participado, y  nos sentimos muy orgullosos de la parte que nos toca.

Puede que el equipo de Charhadas no sea experto en tecnología, pero es que éste no es un problema de tecnología -de eso nos encargamos los proveedores- sino de ponerle cariño y pasión a lo que haces.

Un nuevo enfoque de la regla 80/20

La experiencia con clientes como Charhadas me ha llevado a pensar si no sería bueno revisar la famosa regla del 80/20 para tener en cuenta, también, el tiempo y el esfuerzo que exigen los detalles en cada proyecto.

La regla del 80/20 -inspirada en el Principio de Pareto- viene a decir que, a la hora de realizar cualquier trabajo, incluido un desarrollo web, un 20% del esfuerzo nos permite completar el 80% del trabajo, mientras que con el 80% de esfuerzo restante podemos conseguir el resto, es decir, solo un 20% de nuestros objetivos.

La primera lección que extraemos de esta regla es la siguiente: conviene realizar primero ese 20% de esfuerzo que nos va a permitir completar el 80% de nuestros objetivos. Así, si después ocurre cualquier contratiempo, la mayor parte del proyecto estará finalizado (hacerlo al revés supone un gran riesgo).

Pero quizá podemos ir un poco más allá. En vez de poner el foco en desarrollar el máximo de funcionalidad -el 80%- en el menor tiempo posible, quizá tiene más sentido que nos centremos en ese 20% de funcionalidad que es realmente crítico para nuestro negocio (la que consideramos esencial para realizar nuestra actividad diaria).

De esta manera podríamos dedicar casi todo el esfuerzo posterior a los detalles que, como hemos visto, van a acabar consumiendo buena parte de nuestros recursos, y constituyen un elemento clave en el éxito del proyecto.

Posted in General | Tagged , , | Leave a comment

CISC vs RISC

By Agustín Cuenca | Published: 28 February, 2011

En los primeros días de la industria informática no existían lenguajes de programación de alto nivel, y casi todo el trabajo debía realizarse en lenguaje ensamblador. Como consecuencia de esto, los diseñadores de computadoras se centraron en construir instrucciones que hiciesen lo máximo posible. Así, buena parte de la complejidad del software se incluyó en el hardware. Esta fue la esencia de la conocida como filosofía CISC (Complex Instruction Set Computer), en la que cada instrucción podía ejecutar varias operaciones de bajo nivel, así como operaciones de varios pasos.

Con la llegada de lenguajes de programación más avanzados surgió una nueva estrategia de diseño: unas instrucciones más simples podían permitirnos una gran rendimiento -incluso con un hardware más sencillo- siempre que fuésemos capaces de ejecutar esas instrucciones con gran velocidad. El resultado de este nuevo objetivo -reducir las instrucciones- fue el modelo conocido como RISC (Reduced Instruction Set Computer).

Resumiendo, y simplificando, el modelo CISC defendía un procesador capaz de realizar operaciones muy complejas: sumar enteros, hacer comparaciones, saltos, etc. En cambio, la arquitectura RISC estaba basada en instrucciones muy pequeñas pero de ejecución muy rápida, y con diversos mecanismos de comunicación entre las diversas instrucciones.

La filosofía RISC y la web

La pugna entre ambas arquitecturas, CISC y RISC, se hizo famosa en los años 80. Fue una discusión muy potente -con su lista de pros y contras, sus partidarios y detractores- que más adelante cayó en el olvido. Cada modelo tuvo su propio recorrido, pero creo que viene a cuento hablar del tema porque, en mi opinión, la filosofía RISC tiene mucho que ver con la esencia de la Red.

Y es que, si lo pensamos bien, Internet es un claro ejemplo de arquitectura RISC: tiene unos pocos protocolos de comunicación muy simples, que interactúan entre sí para formar soluciones más complejas. El caso paradigmático es el del HTTP, un protocolo realmente sencillo, que funciona con HTML, un lenguaje también muy sencillo, pero que incluye mecanismos de comunicación que nos permiten construir sistemas, servicios y operaciones realmente potentes.

La filosofía RISC y las pymes

Creo que esta misma filosofía, basada en la sencillez de uso, en la velocidad y la agilidad, y en la posibilidad de construir soluciones más potentes a partir de las inter-relaciones entre elementos simples, constituye la más apropiada para las pymes.

El modelo tradicional de ERP -más cercano a la filosofía CISC- puede tener sentido para las grandes empresas (el caso paradigmático es SAP). Pero nuestra experiencia nos ha demostrado que los autónomos y las pymes no necesitan una aplicación enorme, capaz de hacerlo todo y, por tanto, difícil de aprender y manejar, y con un coste de adquisición y mantenimiento demasiado alto.

Por eso, a la hora de diseñar y construir las herramientas que después utilizarán las pymes en su trabajo diario, nosotros apostamos por el modelo RISC. Nuestro objetivo es construir aplicaciones sencillas, fáciles de usar, que no hacen todo, pero que hacen lo esencial, y que incluyen mecanismos de comunicación -para compartir datos, colaborar en red, etc.- que nos permiten aprovechar al máximo las potencialidades naturales de la web.

La filosofía RISC y tu startup.

Yo creo que también es aplicable al diseño de tu nuevo proyecto emrpesarial, o tu nueva web. Puedes adoptar una estrategia CISC, en al que tu web tenga de todo, como opciones para todo, y trabajando en preveerlo todo, pero yo creo que es mejor adoptar una estrategia RISC en tu web.

Elige un conjunto pequeño de funcionalidades, y esas hazlas muy bien. Trabájalas a fondo, depura su facilidad de uso y luego deja que los usuarios te vayan enseñando como combinarlas. Los usuarios te van a enseñar como quieren combinar las funcionalidades, y con eso tu podrás ir mejorando y añadiendo cosas nuevas si son necesarias.

Empezar con una estrategia RISC en tu web te hará la vida mas fácil y te permitirá centrarte en lo que es realmente importante.

Posted in General | Tagged , , | Leave a comment

Diferencia de temperatura

By Agustín Cuenca | Published: 21 February, 2011

Si echamos una rana a un recipiente con agua hirviendo, ésta saltará fuera y podrá salvar su vida. La diferencia de temperatura le permitirá reconocer el peligro, y le hará reaccionar.

En cambio, si dejamos la rana en un recipiente con agua fría, y empezamos a aumentar la temperatura muy poco a poco, de forma gradual, hasta que el agua alcance el punto de ebullición, la rana irá adaptándose a las circunstancias, y al final morirá sin hacer nada por escapar del recipiente.

Según parece, esta hipótesis, formulada por algunos científicos de finales del siglo XIX, no se ajusta con exactitud a la realidad: la rana trata de escapar en los dos casos. Pero también es cierto que se ha convertido en una anécdota muy conocida, y sigue siendo una buena metáfora para explicar las dificultades que las organizaciones encuentran para percibir los cambios cuando son pequeños, y los riesgos que entraña acomodarse, adaptarse a las circunstancias sin cuestionar el marco de referencia.

Adaptarse a los cambios no es suficiente

Los seres humanos solo percibimos los cambios cuando éstos son muy bruscos o, por decirlo según la metáfora, cuando existe una gran diferencia de temperatura entre la situación anterior y la actual.

Cuando los cambios son graduales, y se producen muy poco a poco, simplemente nos adaptamos a ellos sin cuestionarlos demasiado. Nos vamos acostumbrando, hasta que nos acaban pareciendo completamente normales, tal y como le sucede a la rana con el aumento de temperatura.

El problema es que esa adaptación -un tanto acrítica- a las circunstancias que nos rodean puede llevar a nuestras organizaciones en la dirección equivocada. Puede conducirnos a un callejón sin salida como el que describe la metáfora: La temperatura del agua va aumentando. Poco a poco, nos vamos acomodando a la situación (algunos incluso lo encuentran agradable al principio). Pero llega un momento en el que el calor se hace asfixiante, y ya no queda más remedio que salir de allí. Entonces nos damos cuenta de que nuestros músculos no funcionan, y de que ya no tenemos capacidad de reacción. Nuestra organización está anquilosada y ya no es capaz de moverse. El cambio resulta entonces demasiado costoso. Exige un esfuerzo tan grande que provoca rechazo entre la gente, y genera muchas resistencias.

Moraleja. Si no conseguimos saltar fuera del recipiente -cosa que cada vez es más complicada- puede sucedernos como a la rana: el agua comienza a hervir y nosotros seguimos dentro cuando ya es demasiado tarde.

El peso del legado anterior

No resulta fácil cambiar nuestros modelos mentales. En el proceso de facturación de las pequeñas empresas encontramos un ejemplo muy claro del peso que  sobre nosotros sigue ejerciendo la costumbre, el legado anterior. Todavía hoy, la mayoría de las pymes y autónomos guardan las facturas y los tickets de compra en un sobre, y se los entregan a su gestor a última hora, a finales del mes, o del trimestre.

Se produce entonces un auténtico caos, absurdo e innecesario. Es una forma de hacer las cosas que no tiene sentido, mucho menos cuando existen soluciones online como FACTURAgem, que permiten realizar todo ese trabajo poco a poco y de forma ordenada. El gestor se evitaría todo ese lío, y el autónomo tendría la información actualizada, y la podría gestionar en cualquier momento y desde cualquier lugar.

¿Cuál es el problema? Que hay que saltar fuera del agua caliente, fuera del recipiente de nuestros modelos mentales; que debemos abandonar la zona de confort, el área en la que nos sentimos cómodos. Nos hemos ido metiendo allí poco a poco, y al final nos hemos quedado encajonados, sin capacidad de reacción.

Adopción tecnológica en las empresas

¿Cómo empiezan las metodologías de desarrollo software? Al principio no existía una metodología definida. Cuando  el agua estaba fría, las cosas se hacían sobre la marcha, un poco “a tontas y a locas”. Pero un poco más adelante llegaron los análisis funcionales, y la metodología en cascada comenzó a hacer furor, hasta el punto de que hoy, ahora mismo, sigue metida en la cabeza de todo el mundo. Por eso, cuando un cliente nuevo, que todavía no nos conoce, se acerca a nosotros, casi siempre nos dice algo parecido a lo siguiente: “Bueno, yo te doy las especificaciones y ya éstá, tú te arreglas”.

¿Qué es lo que ha pasado? Que muy poco a poco, sin buscarlo y sin quererlo, hemos entrado en un recipiente donde el agua está hirviendo. Nos hemos metido en un sistema que no funciona, que prácticamente nunca produce los resultados esperados -más de un 80% de los proyectos de desarrollo se entregan con retraso- y, lo que es más grave, además hemos tomado esa realidad que nos encorseta como algo imprescindible y necesario.

Es muy curioso, por ejemplo, cómo funciona nuestra percepción de seguridad. Cuando trabajamos utilizando metodologías ágiles, parece que no existe ninguna seguridad sobre el resultado que vamos a obtener, que estamos todo el tiempo en el alambre. Sin embargo, basta con que las palabras se encuentren escritas en un documento firmado, con forma de contrato, para convencernos de que esa seguridad existe, de que las cosas tienen que salir bien a la fuerza… La realidad demuestra que no es así.

Nos han ido calentando el agua muy poco a poco. Hemos ido entrando en el bucle de la contratación tradicional, y ahora no nos atrevemos a salir, porque fuera hace frío, porque si salimos nos sentimos perdidos e inseguros.

¿Qué hace falta en el desarrollo software? Saltar fuera del agua. Tomar conciencia de que estamos en agua  hirviendo, y que si seguimos haciendo las cosas como las hemos hecho hasta ahora, nos vamos a cocer, y no vamos a llegar a ningún sitio.

Posted in General | Tagged , , , , | 1 Comment

El proceso comercial

By Agustín Cuenca | Published: 17 February, 2011

“Bueno, Agustín, porque vienes muy recomendado y me han dicho que sois muy buenos, que si no, esto que me cuentas no te lo contrataríamos. Suena demasiado diferente, demasiado nuevo y demasiado arriesgado”.

Esto es lo que me dijo un cliente hace unos días, justo al acabar nuestra primera reunión. Venía recomendado por otro cliente muy satisfecho, y todo marchó bien. Pero sus palabras me hicieron reflexionar sobre nuestro proceso comercial, y sobre lo difícil que resulta convencer a alguien en el primer encuentro, especialmente cuando el método de trabajo que propones es novedoso, diferente a todo lo anterior.

De hecho, unos días más tarde tuve una reunión con otro cliente que, en esta ocasión, no venía recomendado. Estuve una hora con él. Y nada más acabar pensé: “Las probabilidades de que nos dé el proyecto son casi 0”.

¿Por qué? Porque en una hora no da tiempo a explicarle nuestro modelo, y mucho menos a convencerle de que trabajando así el resultado final del proyecto va a ser infinitamente mejor. Una hora es muy poco tiempo cuando necesitas cambiar un modelo mental fuertemente arraigado.

El modelo tradicional

En el mundo de la industria del software, el funcionamiento tradicional es el siguiente: el cliente tiene un problema y, para resolverlo, elabora unas especificaciones. Acto seguido, envía esas especificaciones a un proveedor de tecnología y le pregunta cuánto cuesta realizar el trabajo.

¿Qué nos ocurre en ASPgems? Que  sabemos, por experiencia propia, que esa forma de trabajar no sirve. Al menos, no para nosotros.

Las especificaciones hechas al principio valen para lo que valen: para orientarse en la oscuridad, cuando todavía no sabemos casi nada. Pero, desde luego, esas especificaciones no pueden ni deben convertirse en una guía del proyecto. Si nos empeñamos en seguirlas al pie de la letra, el fracaso del proyecto está asegurado.

¿Qué es lo que proponemos nosotros?

Uno de los elementos más relevantes de nuestra metodología es que intentamos superar la confianza ciega en las especificaciones para establecer una relación de confianza y colaboración con el cliente. Una relación que nos permita alcanzar un objetivo común.

Por lo tanto, el primero objetivo de nuestro proceso comercial es establecer una relación de confianza, una relación entre personas, que no puede basarse en un documento o en un contrato.

Cuestión de confianza

Todavía recuerdo el único curso de ventas que he hecho en mi vida. Por aquel entonces estaba en el Grupo Santander. Lo impartía un tipo que se llama Jesús Cacho. Nada más llegar nos dijo a las 7 u 8 personas que estábamos allí:

-Bueno, yo no empiezo el curso hasta que no me deis cada uno 50 euros.

-Pero qué dices- le contestamos.

-¿Queréis aprender de verdad? Pues dadme 50 euros, porque si no tenéis interés esto no funciona.

Le dimos los 50 euros. Al final del curso nos los devolvió. Lo que el tipo quería demostrar es que cuando la gente tiene interés por algo de verdad, el dinero no es lo más importante. La confianza es un tejido mucho más fuerte, un elemento esencial en cualquier relación.

¿Cuál es el problema con el que nos estamos encontrando?

Si no conseguimos convencer al cliente, y establecer lazos de confianza con él, el proyecto no puede salir bien. Eso lo hemos comprobado. El problema es que mucha gente llega a nosotros con el modelo mental que he descrito al inicio, es decir, con lo que tradicionalmente se hace en la industria del software: “Oye, tengo esta lista de funcionalidades. Hazme una propuesta”.

Y nosotros tenemos que explicarles que las cosas no son así, que así las cosas no funcionan. Nunca lo han hecho, y la prueba está en el elevadísimo porcentaje de fracaso que se registra en los proyectos de desarrollo software.

Tenemos que ser capaces de convencer a los clientes de que el proceso tiene que cambiar, de que tenemos que encontrar la manera de establecer una relación basada en la confianza, una comunión de objetivos que, solo más adelante, se traducirá en una propuesta y en un precio. Ese objetivo común debe estar en la base de un nuevo modelo de relación muy diferente al tradicional esquema de cliente-proveedor.

A la primera es muy difícil…

Convencer a alguien de que las cosas pueden y deben realizarse de una forma diferente a como se han hecho desde hace años no resulta sencillo. Quizá por eso, buena parte de nuestros clientes son repetidores, es decir, ya han trabajado con nosotros, nos conocen y valoran nuestra forma de trabajar. De hecho, el año pasado tuvimos una tasa de clientes que repiten muy cercana al 70%

También se acercan a nosotros muchos clientes recomendados por otras personas que han trabajado con nosotros, o que lo siguen haciendo. Un amigo les ha dicho: “Vete a hablar con esta gente, que son muy buenos”.

En el resto de los casos, tenemos que construir una relación de confianza prácticamente desde 0, algo que no resulta sencillo, mucho menos si disponemos, exclusivamente, de una sola reunión inicial.

Como consecuencia de todo esto, nuestro proceso comercial requiere más tiempo del habitual. No nos basta con una sola reunión. No basta con un: “Voy, te cuento lo que quiero hacer y me marcho”. Tenemos que vernos otra vez, tenemos que conocernos, tenemos que hablarlo, un poco como durante el noviazgo. Y las herramientas de las que disponemos  son las reuniones iniciales de proyecto y las reuniones de definición.

Cómo construimos una relación de confianza

¿Cómo generamos confianza con los clientes que llega sin referencias?

En algunos casos el cliente nos cuenta la idea de negocio que tiene. Nosotros le damos feedback: esto se puede hacer, esto no; esto lo hemos hecho y no funciona…

A mí me gusta decirles a los clientes que tenemos más experiencia en lo que “no funciona” que en “lo que funciona”. Es normal que sea así. De lo contrario, el mercado estaría plagado de empresas que triunfan al a primera, lo cual no es posible. Lo que funciona es mucho más difícil de detectar. Lo que no funciona, en cambio, es mucho más común, pero puede ser más que suficiente para trabajar en la buena dirección.

También sabemos mucho sobre los objetivos que debemos marcarnos en el proyecto. Cuando un cliente llega y dice: “Voy a comprar tráfico en Google Adds a un céntimo de euro”, nosotros le decimos: “Esto no es así. El coste de adquisición del cliente medio se a a poner en torno a los 5 o 10 euros para un servicio freemium, te pongas como te pongas”.

Así es como vamos tejiendo una relación de confianza, basándonos en nuestra experiencia profesional, y en un diálogo sincero y productivo con el cliente. A través de estas conversaciones el cliente comprueba que realmente sabemos de lo que estamos hablando.

A partir de ahí, el resto es mucho más sencillo.

Posted in General, Gestión clientes, Metodología | Tagged , , | 8 Comments

Pero, ¿y si se cae Internet?

By Agustín Cuenca | Published: 27 January, 2011

Casi siempre que hablo de aplicaciones online con la gente -especialmente si esa gente no ha crecido con la web- aparece una pregunta que acaba protagonizando la conversación:

-Pero, ¿y si se cae Internet?

Es cierto que, sin conexión a Internet, las aplicaciones en modo SaaS -software como servicio- no pueden funcionar. Pero no es menos cierto que las tasas de disponibilidad de Internet son, hoy por hoy, altísimas. Es mucho más probable, por ejemplo, que se vaya la luz. E incluso si esto sucede podemos seguir trabajando con la batería del portátil y con una conexión 3G.

Esta reacción de desconfianza no es nueva. Cuando las primeras aplicaciones informáticas llegaron al mercado, mucha gente pensó: ¿y si se va la luz?, ¿y si el programa deja de funcionar?, ¿y si se estropea el ordenador? Eran riesgos muy pequeños en comparación con las ventajas que la nueva tecnología proporcionaba. A esas alturas, el cambio ya era inevitable, y negarlo carecía de sentido. Pero no faltaron las resistencias.

Por eso, en última instancia, preguntarse ¿y si se cae Internet? es algo así como preguntarse ¿y si nos quedamos sin agua en Madrid? Es algo que podría ocurrir, sí. Pero es poco probable. Y nadie puede construir su vida en función del peor escenario posible. Al menos, no sin dejarse cosas muy importantes en el camino.

Al final, el auténtico problema es que el miedo a una amenaza más bien vaga y remota -que se caiga Internet- nos impida disfrutar de las ventajas que nos aportan las aplicaciones online.

Como acabo de decir, las ventajas son muchas, pero creo que vale la pena destacar una: con las aplicaciones en modo SaaS, las máquinas están administradas por expertos, y el usuario no tiene que preocuparse ni de la instalación ni del mantenimiento.

Los profesionales que gestionan la aplicación se encargan de la seguridad, de realizar los backups, de mantener los firewalls, de las correcciones de errores, los procesos de deploy, etc. Son tareas complejas y costosas para alguien no experto. Tareas que antes pesaban como una losa en las organizaciones pequeñas, aquellas que no podían permitirse un departamento informático, y que no podían disfrutar, por tanto, de la tecnología necesaria para competir.

Afortunadamente, nada de esto sucede ahora. La tecnología está disponible para todas las pymes y autónomos. Lo único que necesitamos es un cambio de mentalidad.

Nuestro centro de procesamiento de datos

El uso de aplicaciones SaaS ha cambiado incluso el aspecto físico de las empresas. En este sentido, es muy interesante la sorpresa que se llevan algunos clientes cuando visitan nuestra oficina. Yo les acompaño abajo y les digo:

-Os voy a enseñar nuestro centro de procesamiento de datos, el lugar en el que tenemos todas nuestras instalaciones informáticas.

Cuando entramos en la sala y les muestro lo único que hay allí, dos routers, se quedan con los ojos como platos.

Pero es así. Esa es toda la infraestructura física que necesitamos tener en la oficina.

Posted in General | Tagged | 6 Comments