archivo

Archivo de la etiqueta: competitividad

Tu reputación, tus alianzas, la búsqueda de la oportunidad y tu adaptación a los precios de mercado resultan fundamentales para ser competitivo en un ecosistema tan difícil como es el de los servicios de desarrollo de software o el de sus productos.

Una vez conseguido el contrato, si el mismo se encuentra dentro de unos parámetros razonables de alcance y precio, existirá probabilidad de conseguir beneficios si hay un buen entendimiento con el cliente, en el que se repartan responsabilidades y se conozcan las reglas del juego y si se es productivo (existen, todos los sabemos, infinidad de circunstancias que pueden complicar un proyecto, lo que he hecho es señalar un contexto que, de entrada, puede ser favorable).

Ser competitivo y poder sobrevivir de manera adecuada incluso en períodos de escasez requiere la adopción de una serie de medidas, una de ellas es evitar el despilfarro, entendiéndose éste como todo gasto totalmente innecesario y con bajas expectativas de retorno, siendo su gravedad proporcional al importe y a su posible carácter estructural.

Dentro del ámbito de un proyecto, el despilfarro (generalmente provocado por el cliente, pero en muchos casos alentado por el proveedor) se centrará en el desarrollo de funcionalidades innecesarias, en añadir complejidad adicional, en reinventar la rueda, en la pérdida de un ritmo de desarrollo y en la falta de intención. También lo podremos encontrar en procesos que no se adaptan a la naturaleza del producto a desarrollar y que provoca la generación de entregables sin utilidad real para el proyecto.

A más alto nivel, una organización despilfarra cuando contrata proyectos de desarrollo o productos que no necesita o para procesos que, por su inestabilidad, sería aconsejable esperar tiempos mejores. También se tira el dinero cuando se contratan servicios con un nivel de calidad o servicio superior al que se necesita, esto es equivalente a comprar mucha más comida de la que necesita y a llenar semanalmente el cubo de basura con todo lo que se ha echado a perder o llenar un almacén con más materia prima de la que se necesita incurriendo en los siguientes costes: gasto de almacenamiento y gasto por la materia prima adicional (que se puede deteriorar por el paso del tiempo).

Ese despilfarro se termina convirtiendo en estructural en el momento en que esos sistemas o productos se convierten con más o menos éxito en herramientas de trabajo, lo que obliga a seguir invirtiendo en ellos.

Este crecimiento sin orden y sin medida, basado en la suposición de que cada vez se va a tener más presupuesto, termina por colapsar en el momento en que se interrumpe ese flujo de dinero, que provocará que el mantenimiento y soporte para muchas de esas aplicaciones o productos sea precario o inexistente.

En períodos de abundancia parece que todo vale y nada importa, pero cuando las cosas no van bien, te acuerdas de cada céntimo de euro que has tirado o que tienes comprometido en proyectos, productos o servicios prescindibles. No se trata de mirar por el dinero exclusivamente cuando todo va mal, ya que lo mismo es demasiado tarde, sino de saber qué se está haciendo cuando se tiene éxito.

Por encima de todo lo importante es que si tienes implantada una gestión de procesos, sea efectiva y te funcione. Eso es lo principal, de nada vale ser ortodoxo si después la solución hace aguas.

Ahora bien, si se quiere implantar una gestión orientada a procesos, ya sea desde cero o a partir de una gestión parcial que cubre algunos de ellos (sea efectiva o no), mi recomendación es que utilicemos como referencia un estándar, siempre y cuando la organización pueda obtener un beneficio competitivo en base a las ventajas que voy a indicar a continuación (así como su adecuación al propio tamaño y mercado objetivo de la organización).

Para empezar nos evitamos reinventar la rueda y aprovechamos la experiencia acumulada que supone un estándar. Además, En muchos casos los estándares establecen básicamente líneas base que desarrollas y adaptas para tu organización (evitando de esta forma el antipatrón “martillo de oro“).

Otra ventaja del uso de estándares es que el cumplimiento de nuestros procesos supone una referencia para posibles clientes, ya que estarán auditados, supervisados o certificados por un tercero independiente y los efectos de la aplicación del estándar sobre el funcionamiento de la organización serán conocidos (por toda la bibliografía y experiencia acumulada a lo largo de los años en entidades que lo utilicen).

Algunos lectores del artículo “Desarrollo de software. ¿Qué es caro?, ¿qué es barato?” probablemente serán de la opinión que el mercado en la actualidad impone unas condiciones como consecuencia de la crisis y de la concepción que se tiene sobre nuestra profesión como consecuencia de la continuada crisis del software, en donde si quieres ser competitivo no tienes más remedio que aplicar una política de precios muy agresiva y que eso condiciona en gran medida el resultado de los proyectos.

Es una buena foto de la realidad, no lo puedo negar, pero también es la evidencia del triunfo de la mediocridad, que ha sumido nuestro sector en una espiral que entre todos tenemos que parar, antes de que nuestras condiciones laborales sean todavía más precarias.

Dado que las reglas del juego son esas, si queremos cambiar las cosas debemos aceptar la situación tal como es. Puedes ser una empresa de servicios de desarrollo de software excepcional pero para que te conozcan de verdad te tienen que contratar (o por lo menos que lo haga otra entidad muy allegada a aquella) y si la deriva actual ha llevado a una política de precios agresiva tendrás que convivir con ella.

Es conveniente analizar en primer lugar si es posible bajar precios minimizando el impacto sobre la masa laboral, ¿es posible reducir alguna de las partidas de gastos fijos?, ¿es posible mejorar la productividad?, ¿es posible enfocar parte de nuestro negocio a la instalación, soporte y adaptación de productos propios o libres?. Es más que probable que sea posible, en época de bonanza se cometen excesos que se institucionalizan.

Tal vez, si el cliente al que se quiere llegar es interesante, a lo anterior se pueda sumar una reducción de las expectativas de beneficio (siempre de manera sensata, teniendo en cuenta la naturaleza y complejidad del proyecto a realizar).

Otras estrategias interesantes puede ser ofrecer pilotos a precio de coste o a coste cero (sobre todo si nos basamos en la utilización de productos).

Ahora bien, una vez que llegamos al cliente, es nuestra oportunidad. Si queda satisfecho, es más que probable que en el futuro se acuerde de nosotros o que incluso quiera continuar la relación con otro tipo de proyectos. Es en este momento donde podemos empezar a ajustar la política de precios a unos términos más razonables, aunque sea poco a poco, proyecto a proyecto.

¿Estamos condicionados por el mercado? Sí, pero no hay que olvidar que somos en gran parte culpables que el mercado se haya vuelto así y que para darle la vuelta, tenemos que adaptarnos a las reglas del juego, para desde dentro y poco a poco, empezar a revertir la situación.

Productividad. Interesante palabra. Muy estrechamente ligada además a calidad y competitividad.

Pese a todo, olvidada, obviada y reducida a cenizas en muchas organizaciones.

Este antipatrón va sobre la productividad y viene a decir que en todo proyecto no es válida cualquier composición del equipo ni tampoco el nivel de ejecución de los trabajos es el mismo, de manera que nos encontraremos con proyectos donde el rendimiento de un miembro (o varios) del equipo (el antipatrón habla de programadores, pero entiendo que lo hace en sentido amplio, referiéndose al concepto de desarrollador, lo que lo hace extensible a todo el conjunto de personas que participan en él) es muy inferior al esperado, hasta el punto de ser su productividad neta en el proyecto negativa (se debe tener en cuenta que si se llega a ese nivel de productividad, el proyecto mejoraría con el simple hecho de prescindir de estas personas, sin necesidad de sustituirlas por otras; esto, como es lógico, hay que analizarlo en el contexto de cada proyecto: avance, complejidad, capacidad del equipo actual, plazos, etc…).

Dicho en otras palabras se genera más trabajo del que produce, principalmente por introducir una tasa de errores elevadas en el sistema, por codificar con alta deuda técnica, por provocar interrupciones frecuentes en el trabajo de los compañeros, por no asumir de manera adecuada sus responsabilidades, etc…

Quien no tiene en cuenta que esto puede ocurrir en un proyecto y no toma medidas, antes y durante su ejecución, está incurriendo en este antipatrón.

La teoría de la evolución deja patente que aquellas especies que mejor y más rápido se adaptan a su entorno son las que sobreviven.

Esta teoría es aplicable también al mundo de los negocios donde el mercado provoca un ecosistema que cambia continuamente, donde la competencia es feroz y que está lleno de incertidumbre.

Supuestamente en un entorno como este solo quedarán aquellos que se hayan adaptado mejor a su funcionamiento y que más flexibilidad presenten ante el continuo cambio. Solo deberían sobrevivir los mejores (no los más grandes, si no que le pregunten a los dinosaurios) ante las circunstancias que vaya marcando el mercado.

En el desarrollo de software debería pasar lo mismo. De hecho está pasando. En la situación actual de crisis muchas organizaciones lo están pasando muy mal y otras están desapareciendo y esto ha sido provocado en gran medida porque en la época de bonanza económica y burbuja del desarrollo de software (provocada especialmente por la modernización de la administración pública) el principal interés ha sido contar el dinero que se ingresaba mensualmente y no la de establecer unas estructuras para la organización que permitiera su crecimiento y evolución.

Alguna que otra vez he hecho referencia a una cita del libro “Cimas y Valles” de Spencer Johnson (del que recomiendo su lectura) que dice lo siguiente: “Las cimas y los valles está conectados. Los errores que cometes en los buenos momentos del presente crean los malos momentos del mañana. Y tus aciertos en los malos momentos del presente crean los buenos momentos del mañana”.

No puedo estar más de acuerdo con Spencer Johnson.

Según Darwin, esas organizaciones que no han sabido adaptarse deberían desaparecer, sin embargo, no es así y eso realmente es una demostración de por qué en nuestro país no conseguimos un nivel de competitividad medianamente decente.

¿Por qué sobreviven? Factores hay muchos, pero uno de ellos es la cultura de la subvención (a lo que se suman otras medidas como la reducción de masa laboral y/o salarial, incremento de la jornada laboral, una mayor austeridad, etc…). Lo que no se logra en los negocios te lo proporcionan las administraciones públicas. Como siempre tienes esa carta bajo la manga que te va a salvar, ¿para qué voy a esforzarme por ser más competitivo? ya vendrán tiempos mejores donde vuelvan los ingresos sin necesidad de tanto esfuerzo como ahora.

La supervivencia de estas organizaciones es un ataque directo a la crisis del software porque son entidades que no han sabido y/o no han querido entender la idea de que lo realmente importante para fidelizar clientes y ganar mercado es la calidad del software, junto a la innovación, además de establecer unos procesos internos que permitan dinamizar el funcionamiento de la organización.

Pese a que en casi todo naufragio hay supervivientes, la coyuntura económica actual junto a la aparición de empresas pequeñas pero muy competitivas debería ser un toque de atención para aquellos que siguen con políticas de desarrollo de software negativas y/o con procesos internos inexistentes o inapropiados y que no terminan de cambiar: o te adaptas (y con ello ayudas a todo el sector y a ti mismo, con un enfoque del desarrollo de software orientado a la calidad que permita dar una vuelta a la consideración que tiene el resto de sectores con nosotros) o desapareces.

La cosa está muy mal, estamos perdiendo dinero, si queremos seguir funcionando sin echar a nadie o conservando la mayor parte de la plantilla hay que congelar los salarios o reducirlos e incrementar en algo la jornada laboral.

Cuando escucho esto (cuando sufro esto) me pregunto, ¿alguien se acordó de nosotros cuando las cosas iban muy bien y cuando se ganaba (o se disponía) de mucho dinero?.

Es solo una pregunta retórica.

Tal vez aplicando esa política se reduzcan gastos y tal vez (y con muchas dudas) se consiga incrementar a corto plazo (a largo plazo es otra historia) la cantidad de trabajo ejecutado por día.

Sin embargo la situación es difícilmente sostenible mucho tiempo, de ahí que a este antipatrón se le llame falsa economía, porque al final lo que te puedes ahorrar en gastos lo pierdas en productividad, ya que simplemente se ha ejecutado la política más fácil y no se ha atacado a la naturaleza del problema.

Si no eres competitivo hoy, tampoco lo serás mañana reduciendo salarios y/o incrementando jornadas laborales, lo único que se va a conseguir (y tal vez) retrasar lo inevitable porque finalmente el mercado te pondrá donde te mereces (ni más, ni menos),.

La Administración no ha sido una excepción en la reducción de presupuestos en los departamentos TIC y esto lo está notando notablemente muchas empresas de desarrollo de software que tenían centrado buena parte de su negocio en este tipo de clientes.

Tal y como comenté en el artículo anterior, la clave es racionalizar presupuestos, es decir, que estos estén a la altura de lo que realmente se necesita y del nivel de servicio exigido. En el caso de la Administración Pública hay, por regla general, margen para ello, ya que en muchos casos las competencias informáticas se encuentran distribuidas, lo que dificulta la implantación de una política común y también se ha contado con presupuestos holgados, sobre todo para proyectos y departamentos considerados estratégicos.

La reducción de presupuestos ha afectado a todos, tanto aquellos que lo tenían ya bastante ajustado como a otros que no. En cualquiera de los dos casos ha obligado a priorizar el gasto y también a maximizar lo que se obtiene por cada euro.

¿Qué impacto tiene esto sobre los proveedores? Muy importante, ya que la reducción ha sido drástica y en poco tiempo, lo que ha provocado que tengan que tomar medidas urgentes para adaptarse a este nuevo entorno. ¿Cuáles son esas medidas? Ajustes de plantillas, diversificación del negocio y mejora de los procesos productivos. Su impacto habrá sido más fuerte o no en función de las políticas que fuera aplicando la organización en los últimos años, por ejemplo, si ya se habían encontrado nuevas fuentes de negocio, ya se tiene recorrido una parte del camino.

Ahora tocar competir con más empresas (la diversificación no es solo buscar nuevos tipos de clientes, sino también en ampliar el ámbito geográfico de búsqueda) y el número de proyectos es menor y con presupuestos más ajustados. Esto obliga a hacer ofertas más competitivas y a intentar hacer los proyectos con el mayor grado de satisfacción posible para el cliente, lo cual no resulta posible sin una mejora de los procesos y en la capacidad de producir resultados.

Que te reduzcan el campo de acción es un gran problema pero todavía lo es más si no eres competitivo, lo mismo en época de bonanza se pudo haber ganado más dinero siendo más eficiente y ahora con esa mejora lo mismo ahora esa reducción de ingresos no lo es tanto. En cualquier caso, no se puede seguir igual si tu entorno cambia, los que se adaptan antes y mejor son los que ganan.