archivo

Archivo de la etiqueta: beneficios

Steve Jobs no se equivocaba cuando comentó que: “Nuestra creencia es que si seguimos poniendo grandes productos frente a los clientes, estos seguirán a abriendo sus billeteras”.

Además de las incontestables cifras de venta de Apple y de sus rotundos éxitos continuados, hay otro hecho objetivo y es que la capitalización bursátil de Apple supera a la que tienen Google y Microsoft juntos.

La estrategia es simple: Este tipo de beneficio tan rotundo viene a través de la calidad del producto y de la experiencia de usuario (y cumplimiento de sus expectativas) y no a través de otras políticas (productos de menos calidad a menor precio).

Con esas otras políticas también se puede ganar dinero, pero la competencia en ese segmento es mucho mayor y los márgenes de beneficio menores, ya que ante productos de calidad similar decidirá el precio en la mayoría de los casos.

En el desarrollo de software, existe una mediocridad (y tal vez sea incluso generoso con este apelativo) generalizada, basada en productos software de mala calidad que se encuentran alejados de las expectativas del usuario y obtenidos en un contexto de desgaste en los proyectos entre cliente y proveedor.

En este mundo que entre todos hemos creado, se ha convertido el precio en el elemento que marca la diferencia, lo que a su vez repercutirá con el paso del tiempo en una reducción de ese estándar de calidad y en consecuencia de la visión que tiene el mercado respecto de nuestros trabajos.

Quien haya trabajado en proyectos de desarrollo de software y sepa la problemática real de los mismos no se plantea tanto los hitos económicos como el nivel de calidad del producto porque sabrá que al final un producto de calidad deficiente terminará costando muchísimo más dinero que uno de gran calidad (y no solo por el coste directo del mismo, sino también por el impacto que tiene en la producción la utilización de un producto ineficiente y con errores).

¿Es suficiente realizar estos planteamientos al cliente para que acepte el desarrollo de sistema de información aplicando una metodología ágil, teniendo en cuenta que lo mismo está acostumbrado a contratar según un modelo clásico y monolítico y existen otros proveedores que pueden aceptar esas condiciones?.

Si el cliente no conoce los beneficios de la aplicación de los principios ágiles y su instrumentación mediante metodologías podrá ver el enfoque que se plantea alejado de la ortodoxia y ya sabemos todos lo complicado que resulta salir de la zona de seguridad aunque te vaya mal en ella.

Por tanto, si existe la oportunidad de hacer pedagogía con los clientes y mostrarles las ventajas de un enfoque ágil en el desarrollo de software, no solo te estarás ayudando a ti, sino también a toda la profesión y a todo el sector.

No obstante, el desarrollo iterativo incremental ofrece diversas cartas bajo la manga que pueden resultar muy atractivas para el cliente (y también para el proveedor):

– ¿Por qué no incluir en el contrato la posibilidad de que el cliente pueda dar por finalizado el proyecto antes de ejecutar todo el presupuesto?.

Esto se puede plantear de muy diversas formas: Darle la oportunidad a que lo pueda hacer en cualquier momento, a que lo pueda hacer con un mínimo de un % del presupuesto ejecutado, etc… En cualquier caso, el proveedor debería tener como compensación, además de lo ya ejecutado, un % del presupuesto restante (salvo que se haya pactado que un incumplimiento del acuerdo de nivel de servicio pueda suponer que esa compensación se elimine).

En este planteamiento todos ganan:

Si el cliente no está contento puede anular el proyecto, si el proveedor tiene una versión del producto que le parece suficiente no tiene por qué seguir invirtiendo en funcionalidades que lo mismo van a ser innecesarias.

El proveedor en el primer caso, no conseguirá los ingresos inicialmente estimados, pero a cambio se evita el camino a ninguna parte y lleno de desgaste al que iba el proyecto. En el segundo caso, el proveedor obtiene como premio además del beneficio por el trabajo ejecutado, el % extra de la compensación (sería como una prima por hacer las cosas bien).

– ¿Por qué no abordar un modelo relacionado con el esfuerzo necesario para realizar la tarea en el que todos ganen?.

En este caso al esfuerzo planificado se le aplica un buffer de esfuerzo, de manera que si el esfuerzo es t, nos quedemos con un rango válido de [t-buffer,t+buffer]. Si se consigue terminar la tarea con un tiempo entre [t-buffer,t] el beneficio se reparte entre cliente y proveedor y si la tarea termina con un tiempo entre [t,t+buffer], se reparten los gastos.

En el caso de que se superen los límites, habría que estudiar, antes de aplicar cualquier medida el motivo de tal desviación.

Para tu organización puede ser ganar dinero, para el cliente puede ser informatizar un proceso para mejorar en productividad y eficacia, para tu jefe puede ser subir un par de peldaños más, pero para tu equipo el objetivo debe ser la satisfacción del usuario.

En realidad debería ser el objetivo de todos los que participan en el proyecto.

Con respecto al proveedor, hay que tener claro que quien tiene una empresa quiere beneficios y a ser posible mayores que los que tendría invirtiendo ese dinero en otros negocios, en renta fija, en bolsa, etc… Sin embargo, hay que tener en cuenta que los beneficios de hoy pueden ser las pérdidas de mañana y que las pérdidas de hoy pueden ser los beneficios de mañana.

Centrarse en los resultados de un proyecto concreto por lo que ha ganado o por lo que se ha perdido es un error, es una visión cortoplacista. Es necesario analizar cómo ha transcurrido el proyecto en su conjunto y cuál ha sido el nivel de satisfacción de los usuarios y del cliente.

Si el cliente y/o el usuario ha quedado insatisfechos, puede que los pierdas y ese beneficio que has obtenido en el proyecto, lo mismo mañana no es nada, porque te tocará buscar otro cliente, que lo mismo lo encuentras o no y si lo encuentras lo mismo resulta nefasto.

Si el cliente y/o el usuario quedan contentos, la puerta siempre quedará abierta. Si has tenido pérdidas, analiza los motivos, pero de la manera más objetiva que te sea posible, ¿por qué se han producido pérdidas?, ¿se ha presupuestado mal?, ¿quién ha presupuestado mal?, ¿el proyecto ha sido mal dirigido?, ¿el equipo de trabajo no ha sido productivo?, ¿se han pedido más cosas que las inicialmente previstas?, ¿se ha cambiado la orientación del proyecto a lo largo de su desarrollo?, ¿el problema ha sido la metodología?, etc…

Las causas pueden ser muchas y es necesario conocerlas, obtener un feedback que pueda ser útil para un futuro para la propia organización en sí, para el equipo de proyecto o para el trato con ese cliente o con ese tipo de clientes. Este análisis se debe hacer tanto perdiendo como ganando dinero, sin embargo, casi nunca se hace, lo cual te condena a repetir una y otra vez los mismos errores.

Se ha podido perder dinero, pero si se aprende de los errores, el enfoque para el siguiente proyecto puede y debe ser distinto. Para otro proyecto con el cliente, si parte del problema (sea mucho o poco) ha sido debido a él, es cuestión que se le plantee en el próximo trabajo las mejoras que se entienden que se deben realizar para que todos terminen contentos, este planteamiento debe hacerse con tacto y teniendo en cuenta la relación que se mantenga con el cliente.

Si piensas que el planteamiento es utópico es que tal vez no lo has intentado y si lo has intentado y el cliente o clientes no atienden a razones, es más que posible que no hayas tenido suerte con los que has trabajado, pero ten por seguro que en el mercado sí que hay clientes sensatos porque un modelo de desarrollo de software que tiene más posibilidades de salir bien es aquel en el que todos ganan.

“Nosotros cobramos acorde a lo que factura el negocio del fútbol” es una respuesta muy repetida en los futbolistas cuando se les pregunta si piensan que ganan demasiado.

Tras ella hay un gran error, porque si bien los ingresos son importantes, más importante son los beneficios. Si se gasta más de lo que se ingresa, de nada vale lo que entra en la caja.

Por tanto, si cogemos los balances de los clubes de fútbol de categoría profesional se podrá apreciar que la mayoría presentan pérdidas (y algunas de ellas lo suficientemente importantes como para haber acudido a un concurso de acreedores), por lo que si los futbolistas que se consideran, y con razón, los protagonistas de todo esto, deberían tener en cuenta que su salario debería estar acorde con la posibilidad de obtener beneficios (o al menos quedarse a la par) por parte de las entidades a las que pertenecen.

Los futbolistas tendrán razón en decir que ellos cobran los que los clubes están dispuestos a ofrecerles y es cierto, los principales culpables de estos salarios son quienes están dispuestos a pagarlos, pero eso no quita que me produzca algo de urticaria cuando se habla de que se cobra lo que el negocio del fútbol genera, ya que efectivamente, se genera mucho dinero, pero no el suficiente para mantener ese nivel tan alto, de lo contrario los futbolistas ganarían mucha pasta, los equipos no tendrían pérdidas y todos felices y contentos.

No digo que la culpa de todo la tenga el salario de los futbolistas, aunque supongan un porcentaje importante del presupuesto de los equipos, ya que evidentemente tras el éxito o el fracaso económico está la gestión de los dirigentes del fútbol que son los que gestionan los ingresos y toman las decisiones sobre las inversiones y gastos. En última instancia son ellos los que deciden qué se hace con el dinero que entra.

Soy muy aficionado al fútbol y pienso que es totalmente compatible lo que digo con gustarme este deporte. Yo consumo y pago fútbol, es un espectáculo o divertimento más, lo cual no quita que piense que gran parte de la estructura que lo sustenta está mantenida con alambres y que se vive por encima de las posibilidades reales.

He utilizado el fútbol como un ejemplo de que los ingresos no justifican nada. Es absolutamente necesario que toda empresa para subsistir tenga ingresos, pero después hay que saber gestionarlos y saber gestionar adecuadamente toda la maquinaria productiva y de negocio para de esta forma seguir teniendo ingresos (y a ser posible aumentarlos) reduciendo en lo posible los gastos comunes y de producción para de esta forma tener un margen de beneficios aceptable.

Es en cierto modo lógico el miedo a crecer de muchas empresas dedicadas al negocio de las TIC, ya que ese crecimiento viene ligado en la mayoría de los casos a un incremento de los recursos humanos lo que provoca necesariamente que los objetivos anuales en cuanto a facturación crezcan proporcionalmente a los mismos (y además que se mejoren algunos mecanismos como la gestión de cobros, para evitar en la medida de lo posible gastos financieros por faltas puntuales de liquidez, la productividad, el control de gastos, etc…).

Por tanto, el crecimiento debe ir de la mano de dos aspectos fundamentales:

1) Un mayor esfuerzo y eficiencia comercial. Esto pasa en las empresas grandes y chicas, para subsistir tienen que vender servicios y esas ventas deben ser proporcionales al tamaño de la empresa y a la estructura de las mismas.

2) Una mejora en la gestión y una reestructuración de la empresa. Si la empresa tiene cien empleados no es lo mismo que si tiene quinientos, por lo que la forma de gestionar la empresa, la estructura orgánica y funcional de la misma e incluiso los procedimientos deben ser distintos. Si se intenta gestionar una empresa de quinientos empleados aplicando las mismas técnicas y recursos de gestión que una empresa de cien, los problemas pueden ser tan importantes que incluso podrían afectar a la propia viabilidad de la empresa.

Una vez indicados algunos de los inconvenientes y/o riesgos, por otro lado lógicos, que puede provocar el crecimiento de las empresas, vamos a ver a continuación, algunos de los beneficios:

1) Imaginemos que una empresa tiene una facturación anual de 4 millones de euros con un margen de beneficios que se sitúa alrededor del 20%. Supongamos que gracias al crecimiento la facturación anual pasa a ser de 6 millones de euros, situándose los beneficios también en torno al 20%. Se ha pasado por tanto de unos beneficios de 800.000 euros anuales a unos beneficios de 1.200.000 euros anuales. Esos beneficios de 400.000 euros de más, lo agradecerán accionistas y/o socios, los cuales podrán invertirlos en sí mismos y/o en la misma empresa (subir el sueldo y/o promocionar a los empleados, reforzar o crear un departamento de I+D, reforzar la estructura de la empresa, mejorar los procesos, realizar fichajes que mejoren el nivel medio de la empresa, etc…).

2) No conozco a ningún trabajador que se conforme (otra cosa es que por las razones que sean no tenga más remedio) con tener siempre el mismo sueldo. Esto implica que o bien la empresa va incrementando periódicamente el sueldo de los empleados o se va a encontrar con que períodicamente los empleados se van a ir marchando de la empresa, con el riesgo que eso supone (contratar a personal, probablemente con menos experiencia y que tardarán unos más y otros menos en alcanzar un nivel similar a los que se han ido marchando, lo cual lo sufrirá directamente la empresa y la calidad de los servicios que presta). Este incremento anual de la masa salarial puede ser asumido por una organización, sin modificar su nivel de crecimiento, durante un tiempo, pero al final llega a ser insostenible, es decir, o se crece o se debe empezar a asumir la marcha de talento de la organización.

3) Tiene una gran relación con el punto anterior el nivel de responsabilidad. Existirán muchos empleados de la organización que quieran asumir un mayor nivel de responsabilidad, ya que a la mayoría de las personas no le atrae realizar siempre el mismo trabajo (y además ese incremento en el nivel de responsabilidad, viene parejo en la mayoría de las casos con un incremento salarial), evidentemente si una empresa tiene cien empleados no todos pueden ser analistas funcionales, jefes de proyecto, arquitectos, gerentes, responsables de I+D, etc…, pero si la empresa crece, lo hará también el número de perfiles de alto nivel y permitirá a su vez promocionar el resto de perfiles. Por tanto, de igual forma que en el punto anterior, o se crece o se debe empezar a asumir la marcha de talento de la organización a otras en los que sí puedan ocupar esos puestos de mayor responsabilidad.

¿En cuántos proyectos en los que ha participado o desarrollado tu organización habéis empezado desde cero, es decir, desde el framework (si es que hay framework)?.

Si se tiende a cero, mala cosa, por muy potente o poderoso que sea el framework.

Me pongo a analizar algunas empresas desarrolladoras de software de éxito, sobre todo alguna emergente en los últimos años y no me canso de ver el mismo producto base revendido hasta la saciedad o bien adaptaciones del mismo (sin ser productos excepcionales, ni novedosos). Por muy baratos que los vendan (que además no siempre se venden baratos), el beneficio es prácticamente íntegro.

Hay muchos proyectos que por necesidades del cliente sí que se tienen que hacer desde cero e incluso con variaciones en el framework si así lo estiman las normas de desarrollo del cliente. En esto no entro. Sí que entro en otros proyectos donde el cliente tenga unas normas de desarrollo más relajadas y lo que le interese sea obtener un producto que colme sus necesidades, con un precio y plazo de ejecución razonable.

Salvo proyectos muy específicos, en la mayoría de los casos siempre hay partes que se pueden reutilizar de un proyecto a otro. En muchos posts he hablado ya no solo de la necesidad de disponer de un framework lo más potente posible, sino de disponer de un catálogo de componentes de más alto nivel reutilizables. En este post voy más allá, existirán proyectos donde lo que se puede reutilizar es la misma aplicación en sí, variando lo que se tenga que cambiar en la capa cliente (ya sabemos todos que simplemente cambiando la capa cliente una misma aplicación puede parecer otro totalmente distinta aunque la funcionalidad sea la misma) y en la capa de negocio o de acceso a datos. Para que un analista pueda hacer eso, necesita tener un conocimiento general de las aplicaciones que se desarrollan en la casa. Es por esto (aunque el objetivo no sea enseñar los productos para que se reutilicen) por lo que muchas empresas, de vez en cuando (una vez cada cuatro meses o semestralmente), hacen unas jornadas de divulgación entre los empleados, enseñándole a los mismos los proyectos más significativos que han terminado su ejecución en ese período o que están a punto de terminar.

También es cierto que es más complicado reutilizar cuando eres agente pasivo en una contratación, es decir, ganas un concurso (con esto no quiero decir que no se pueda reutilizar, pero digamos que la iniciativa, la lleva como es lógico el que contrata y te puede poner una serie de restricciones en el proyecto que te impidan en gran medida la reutilización), pero es más sencillo si eres agente activo, es decir, tienes un software que resuelve una temática concreta de un negocio y lo vendes a un tercero. Eso sí, en el acuerdo de venta debe quedar muy claro, hasta donde va a llegar la personalización, ya que en caso contrario, te puedes encontrar con que te desvistan entero el producto y sea lo mismo que empezar desde cero.

Este fin de semana ha tocado currar, tengo muchos frentes abiertos, algunos con un plazo muy exigente y quería cerrar o medio cerrar alguno.

Finalmente he conseguido casi cerrar uno y hubiera sido imposible tenerlo listo si no hubiera planificado desde un principio cómo quería hacerlo y no hubiera invertido el tiempo necesario en montar una infraestructura que me facilitase la reutilización de los recursos que iba generando.