Continuo con la entrada anterior sobre como se vende el software y que hacer para incrementar las chances de vender nuestros productos, hago esto simplemente imitando lo que hacen otros productos no-software.

Uno de los aspectos más importantes en los que hay que poner atención es sobre la planificación de la obsolescencia de nuestros productos con el fin de volverlos más fáciles de sustituir por nuevas versiones. El que un software alcance rápidamente un estado de caducidad es imprescindible para la empresa que lo desarrolla porque de no ser así las nuevas (versiones) difícilmente se venderían o necesitarían de una enorme energía por parte de todo el aparato comercial para lograrlo.

Si la obsolescencia no se planifica, las versiones viejas se convierten en los principales competidores de las versiones nuevas y esto no resulta muy agradable ni conveniente. Estas situaciones son muy comunes cuando las antiguas versiones de los productos han satisfecho a los clientes (que como ya dije en otra entrada, es mala idea). Por ejemplo, cuando Microsoft lanzó Windows 2003 Server su principal competidor (preocupación) no era linux ni Mac sino su predecesor Windows 2000 Server, la energía hubo que concentrarla en convencer al mundo entero de que Windows 2003 era muy superior comparado con Windows 2000, que era más seguro, rápido, administraba mejor los recurso de almacenamiento, etc.-

Luchar contra nuestros propios productos puede ser desgastante y peligrosa para la empresa, la idea de socavar la imagen de la versión anterior no puede realizarse de manera frontal. Simplemente no puede decírsele a un cliente «Tirá esa basura que te vendí hace no mucho tiempo». La estrategia es plantear mejoras subjetivas o de poco uso práctico o beneficio evidente, ir acercándose a metas inalcanzables, simplemente cambiar para seguir la moda. Siguiendo con el ejemplo anterior (porque ejemplificar con un S.O resulta espectacular), es necesario instalar en la mente del cliente la idea de que existen ciertas características de tipo continuas (y por lo tanto infinitas e inabarcables en su totalidad) que se van mejorando continuamente como «velocidad», «seguridad», «experiencia del usuario», «productividad» y otras. Si se logra esto entonces podremos sortear la lógica que todo cliente hace «si Windows 2003 Server es más seguro que Windows 2000 Server entonces Windows 2000 Server es inseguro».  Con esto podemos dar a entender que «nosotros seguimos; vos te estas atrasando y corres riesgo de quedar obsoleto».  Sea como sea, lo único realmente seguro es que la próxima versión será «más» segura que la actual pero mucho más insegura que la próxima aún si esto no es cierto.

Al final, lo que debe hacerse no es intentar convencer sobre las bondades de la nueva versión (ya que el cambio pocas veces se justifica) sino lograr que el cliente se deshaga de la versión anterior y de esa manera la venta de la «última» versión está más que asegurada. De repente se cae en la cuenta de que no interesan tanto las nuevas características sino el temor a (y hasta cierta vergüenza de) quedar atrasados.

Las versiones deben aparecer con la mayor frecuencia posible aún cuando se diferencien muy poco de las anteriores en sus aspectos internos, pero deben, de ser posible, poseer una estética totalmente diferente. Esto es porque si la última versión del producto X es la 7.0, entonces los usuarios pueden soportar la «vergüenza» de tener la versión 6.0 o tal vez una anterior como la 5.0, pero tener una versión 4.9.8.9 puede convertirse en una humillación insoportable.

Si terminaste de leer, quiero aclararte que no es una cruzada contra nada. Es solo que comparando el software con otros productos (lo hice con los celulares) pude ver que ambos mercados se comportan del mismo modo y quise compartirlo. En cambio mi entrada anterior si fue un verdadero zapateo.

Lucas Ontivero

En esta y en las suscesivas entrada de la serie voy a explicar como se vende el software y cuales son las claves para venderlo exitosamente. Moralistas abstenerse.

Resumen

Como resumen quizás baste con decir que para vender software hace falta lo siguiente:

• Instalar la continua obsolecencia de todos nuestros productos.
• Lanzar los productos  con fechas de vencimiento bien próximas mediante nuevas versiones, extensiones, parches, novedades, etc.
• Incumplir sistematicamente todas las promesas realizadas en el pasado.
• Prometer que la nueva versión cumplirá con las promesas (no preocuparse, creerán)
• Dotar a la marca de cierto estatus social.
• Abrazar la estética y rechazar la ética.
• Aprovechar y cultivar en el cliente el amor por la ignorancia.
• Crear adicción y dependencia en nuestros cliente.

Como se hace

A simple vista, casi cualquier cosa parece más fácil de vender que un desarrollo de software o de un enlatado de software (salvo excepciones como portaaviones, satélites y cepas de alguna que otra enfermedad que pueda acabar con la humanidad), y como técnico me he visto muchas veces tratando de idear la manera de hacer de esta ‘cosa’ algo más vendible, más consumible.

Hago una pregunta, por qué alguien compra algo? La respuesta impensada, en el sentido de que no ha sido muy elaborada, es: para satisfacer una necesidad. Bueno, la verdad es que nadie adquiere algo por una «verdadera necesidad» sino más bien para calmar la frustración que le causa el no poseer ese bien que lo posiciones en algún lugar, el que la persona desea (o al menos puede llegar a) ocupar, en la sociedad. Es la infelicidad que le provoca esa aparente desventaja la que lo impulsa a comprar. Pero que sucede una vez que ese estado de paz consigo mismo es alcanzado? Inmediatamente es reemplazado por nuevas insatisfacciones que hacen que la rueda siga girando y acelerando como un motor al que no se le quita el pie del acelerador. La continua obsolecencia es nuestra mejor amiga y las promesas incumplidas (la mentira) nuestro mejor recurso.

Existe una diferencia, aparentemente fundamental,  con respecto al software (lo único totalmente distinto a todo lo conocido en el universo es el software, o no? -Leer a McConnell aquí y aquí ) y es que nuestros clientes no son tontos, que son grandes empresas, que sus necesidades son «diferentes», que no compran por impulso, ansiedad, porque no se tragan el anzuelo y tantas otras creencias de que nuestra realidad es definitivamente «única» y «distinta». Todo esto es falso y voy a intentar explicarlo haciendo algunas analogías que estimo válidas y quiero compartir:

En primer lugar entiendo que solo algunas poquísimas empresas realmente saben (y pueden) poner en práctica lo que digo en el segundo párrafo de esta entrada. Microsoft es por lejos la más inteligente de todas al poner en práctica desde los conceptos de continua obsolecencia de sus productos (solo basta saber que saldrá un SQL 2008 para conocer la fecha de vencimiento de mi SQL 2005), las promesas semicumplidas, darle cierto status social al comprador, y hasta las prácticas propias del marketing multinivel (partner y capacitación a cuanto quiera formar parte de la red de ventas o mercadeo), la publicidad viral llevada a cabo por la comunidad, y especialmente por los blogs repetidoras que reproducen en sus entradas los más recientes anuncios, y la constante reinvención de la rueda. Cuidado, a todos aquellos que gusten de cazar brujas, les advierto que solo estoy admirando la tremenda capacidad de marketing de Microsoft y su acertada (y compartida) forma de hacer dinero. Pero es que acaso existe otra forma? Claro que no, no se puede, ni se debe, disminuir la velocidad, el solo hacerlo como poco ocasionaria miles de despidos, atrasos tecnológicos, problemas de seguridad y de productividad en todo el mundo, esto justamente es lo que le otorga su indiscutible ética.

En segundo lugar entiendo que solo algunas poquísimas empresas realmente reconocen «por si solas» que necesitan la ayuda de un sistema de software, sino que la mayoría de las veces las soluciones a sus problemas son acercadas por alguien quien les explica como las nuevas tecnologías, y en especial lo WS con orquestadores de lógica de negocios que permiten el fácil diseño, creación y mentenimiento de Enterprise Service Buses, les permitirán integrar todo mágicamente para lograr un B2B con sus partner y cuanta mentira más le venga a la cabeza mientras observa el brillo de los ojos del ingenuo cliente. Es que sí, los clientes en esta industria son ingenuos y tacaños (por suerte para ellos) y por eso eligen siempre, como algunas mujeres y algún que otro hombre, al quien más les mienta y así acumular desepcion tras decepción para caer en la lógica de que el software no paga y de que los informáticos nos un poco inútiles. Esta es la personificación de la culpa que hacen los inmaduros porque es más facil que reconocer que se es estúpido a la hora de seleccionar a los proveedores. Cada cliente tiene el software que se merece y como dijo Deming: hay que acabar con la costumbre de comprar basado en el precio.

Pero como es posible embaucar a alguien de esa manera!?. La respuesta es la que vemos todos los dias, con la confienza (principal activo de las organizaciones, pero claro!) que genera la imagen es con lo que se defrauda. Con el nombre, la chapa, las certificaciones (sí, para eso sirven), con las credenciales de cualquier tipo, con los curriculums brillantes (y a veces inflados), con las placas en las paredes, con las instalaciones de estilo ultramodernas, con los proyectores de las salas de reuniones y el powerpoint, con el speech, con las sonrisas, con las frases de siempre como «nuestros clientes son estos (ordenados en millones de euros facturados)» y con el sutil «podes llegar a ser como ellos» (lo que te dice que ni siquieras ‘sos’ o ni existis) que implica, con todo este arsenal de recursos es que se vende el software. Y es por esto que empresas con poca estética y mucha ética no puedan vender productos excelentes mientras que empresas con nada de ética y mucho de estética se cansen de vender o estafar mientras que alimentan el círculo de la insatisfacción y la creación de nuevas necesidades.

Parece loco pero no es así, cuantas veces escuchamos frases como «vamos a ver si le podemos enchufar tal o cual porquería»? (a veces solo los desarrolladores tienen conciencia de que es una porqueria). Pero es lícito achacarle toda la culpa a los clientes? no son ellos (o su satisfacción) «lo más importante»?. Veamos:

Los clientes presumen de su ignoracia con respecto al todo lo que al software se refiere. «El software no es nuestro negocio» y «no me hace falta saberlo». Esto es un crimen, una especie de apología de la ignorancia. Buena suerte, que te vaya bien, contame luego como te fue, si?

Lo anterior logra su objetivos, ahora el cliente es un analfabeto. Pero al ser un completo ignorante no sabe lo que se necesita, no comprende «qué es» el software, no sabe si lo necesita realmente o no, no comprende si conlleva mucho, poco o nada de esfuerzo ni quiere saberlo. Es hora de quitarle el caramelo al niño!. Pero como si todo esto fuera poco, el cliente no está dispuesto a pagar nada por algo que no sabe ni para que lo quiere. Entonces los precios bajan hasta llegar a la situación actual en la que existe mucho software subvaluado, con informáticos mal pagos, con precios según la cara del cliente y la estampa del vendedor.

 (Continuará…)

Lucas Ontivero

Hace ya mucho tiempo que desarrolladores, testers, project leader, capacitadores, pensadores, hasta el SEI y en general todos los actores de la industria del software, venimos enfrascándonos en discusiones casi mortales por defender alguno de los extremos de la dicotomía «ágiles vs. maduros» o «ñoño vs. trajes». Estas charlas se suceden todo el tiempo y en todo lugar, en las cafeterías de las empresas, en las oficinas, en las horas de almuerzo, en los blogs, revistas, todo el mundo habla de lo mismo.

Que es ser ágil y que es ser maduro? ¿Puedo ser como el señor de la foto? y si implemento SCRUM soy más ágil o simplemente me habilita a autodenominarme como tal? ¿Una empresa que implementa CMMI level 5, está condenada a tardar 1.000 años en proveer un producto costosísimo a un cliente agotado?

Así planteada la discusión entre dos extremos, uno blanco y el otro negros, casi nadie distingue la infinidad y continuidad de la escala de grises intermedios y se toman posiciones más rápido que en la bolsa de valores, a favor de una u otra fase, según las preferencias de la tribu a la que se pertenece, y es cierto que ningún hobbista (termino utilizado por Bill G. y que refleja como pienso sobre los apasionados del soft) puede alucinarse con CMMI, es casi como ver un adolecente ultraconservador, ni puede a un MBA simpatizarle la idea de una metodología «liviana», con poca o ninguna «evidencia» de «control». Así que existe un perfil de los «ágiles» y los «maduros» que, sin perjuicio de sus justificaciones, parece hacer de sus ideales algo irreconciliable, pero que sin embargo forman las dos caras de una misma moneda porque ambos se centran en los aspectos administrativos que rodean a la escritura de código, a mi entender, el verdadero proceso de convertir capital y trabajo en software de valor para el cliente.

La discusión entre si ser agiles o formales es una de las más estériles en las que he participado por lo siguiente:

• Sus promesas son marketineras y contradictorias: basta solo con ver los charts que muestran tanto los ágiles como los formales para darse cuenta que los dos prometen lo mismo, mayor productividad/calidad y menores costos/defectos/rework. Es claro, al menos uno está mintiendo.
• Esto es quizás producto de la ausencia de verdaderos científicos (actuales) del desarrollo de software. Faltan personas que experimenten realmente con desarrolladores, al mejor estilo tayloriano, para determinar a ciencia cierta cuales son las mejores formas de desarrollar. Si hoy existiese un Taylor del software yo no tendría dudas como: ¿como deben distribuirse los escritorios?, ¿donde deben estar los pizarrones?, ¿cuantos mails por hora puede recibir un desarrollador antes de perder totalmente la concentración?, ¿cuantas claves distinta puede manejar?, ¿como lo afectan las políticas de paga/performance?, ¿cuantas tools, tareas, meetings puede manejar simultáneamente?, etc., etc. 
• La adhesión de una empresa a alguna de estas alternativas se debe más a la tendencia (quien hace más ruido), moda, afinidad cultural con alguna de las corrientes, necesidad de certificarse y cualquier otra, más que por cuestiones de fondo y esto en gran mediada se debe a la falta de credibilidad sobre las promesas realizadas por ambas, en el caso de los agiles porque no presentan números y en el caso de los formales porque los números presentados parecen estar peleados con la realidad.

Por esto es que existen 2 perfiles de empresas que se deciden por lo ingenieril y 2 perfiles que se deciden por lo ágil. En el primer caso estos son, la pyme que quiere (o a la que le exigen) certificarse para quizás exportar y la empresa de trayectoria reconocida que quiere certificarse. Muchas de las pymes han logrado darle la fama a CMMI de certificación comprable y han popularizado los cursos intensivos, de entre treinta minutos y una hora, «Lo que te van a preguntar en el Assessment». Muchas de las compañías reconocidas, en cambio, han sido las que le han dado la fama de lenta, pesada y burocrática aun cuando ellas ya eran compañías lentas, pesadas y burocráticas mucho antes de certificarse. Por el otro lado, los que se deciden por alguna metodología ágil, son pymes desordenadas que pretenden justificar su desorden aduciendo ser agiles y las empresas (o equipos) que desean realmente ordenarse.

Parece cierto que las empresas tienen un «perfil» que muchas veces las condicionan en sus elecciones respecto de la metodología a utilizar, como es claro que existen para ambos bandos, apóstoles y verdades a medias. Pero una verdad que no se lee muy seguido, ya que no se encuentra en ninguno de los dos extremos, es que ni CMMI, ni SCRUM, ni RUP, ni XP son la solución. Y es justamente por lo antes dicho, muchas de las grandes empresas que hoy implementan CMMI ya eran muy burocráticas antes de lograr la certificación y muchas empresas que implementan alguna metodología de las llamadas ágiles ya contaban con una cultura de trabajo dinámica y veloz antes de «ordenarse». Por esto es que cuando se hablamos de la pesadez y lentitud del CMMI, en gran parte estamos hablando en realidad de la lentitud y pesadez de las empresas que lo implementan y no tanto del modelo en si. De igual manera, cuando hablamos de lo ágil que es SCRUM, seguramente nos estamos refiriendo a los atributos de dinámica, practicidad y velocidad en el desarrollo de software que poseen las empresas que lo incorporan a sus prácticas operativas y no tanto de si la manera en que gestiona los requerimientos es o no una maravilla.

Resumiendo, las discusiones sobre las metodologías, no dejan ver, a mí entender, problemas ambientales, administrativos y operativos de los que depende en mayor medida el éxito de los proyectos. Según mi experiencia, lo que más condiciona la productividad del staff, como así también la calidad, el tiempo de entrega y el costo de los productos de trabajo de una consultora de software, es la «CULTURA organizacional». Es como  se acostumbra a pensar y actuar en esa empresa, sus herramientas, el ambiente (hasta la iluminación, ventilación, disposición de los escritorios, edad promedio de la gente, oficinas con música o sin música, con o sin acceso a internet, messenger, carteles en las paredes o sin carteles, de camisa y corbata o de bermudas, con oficinas dispersas por muchos pisos o planas, etc.), sus políticas no escritas con respecto a los proyectos, con respecto a los clientes, con respecto a los compañeros, sus criterios de selección de personal, sus niveles jerárquicos, el nivel de rotación, la estabilidad de los equipos de proyectos, etc.

No son pocas las empresas que implementando a conciencia todas las recomendaciones de los institutos de calidad internacionales, y obteniendo sus certificados correspondientes, fallan en lograr valor real para sus clientes. También es sabido que muchísimas empresas fallan en este objetivo independientemente de haber implementado alguna metodología ágil. En otras palabras, esto no asegura nada.  Solo la experiencia, la experimentación, la intransigencia en nuestra voluntad de mejora y nuestra gente pueden lograr los milagros que muchas empresas necesitan. Cada empresa debe ser o al menos poseer un laboratorio y la masa critica para crear sus propio sistema, refinar su cultura y por qué no importarla (no solo traer un CEO de una empresa que admiramos) y mejorar todo todo el tiempo.

Lucas Ontivero