archivo

Archivos diarios: enero 22, 2012

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.

Es adaptarse al cambio, adaptarse a un entorno con incertidumbre con un esfuerzo y un tiempo razonable.

Improvisar es ir descubriendo el camino en cada paso, las metodologías ágiles siguen un plan, en sí mismas son un plan, que puede y debe cambiar tanto por el feedback recibido en la realización del proyecto y también por las diversas contingencias que se producirán en el mismo.

Sabemos donde queremos ir, podemos incluso tener prevista una ruta para llegar a él, pero después son las circunstancias las que hacen que nos adaptemos a las mismas, de manera objetiva, razonada y analítica, poniendo el enfoque en el corto plazo, pero sin olvidar el medio y el largo plazo (lo que sembremos hoy condicionará lo que recojamos mañana).

La improvisación es corto plazo, solo corto plazo.

Este antipatrón puede tener tres orígenes:

– El equipo de desarrollo opta por la opción más sencilla (en cuanto a asumir responsabilidades) de acatar la petición de desarrollo que se le ha descrito (con un cierto nivel de detalle que de alguna manera dirigiría la solución hacia un enfoque concreto de implementación), sin entrar en ningún análisis de alternativas de solución. “Me han dicho que haga X y yo hago X”. Típico en entornos en donde los gestores caen en el antipatrón “yes man“.

Es cierto que siempre se podrá utilizar la defensa de “yo he hecho lo que me han dicho”, pero eso puede provocar unos costes y un incremento en la complejidad de la aplicación que puede que no sean sostenibles (al cliente, es posible que no le haga mucha gracia saber que te has gastado una buena parte del presupuesto para implementar una funcionalidad, cuando todavía existen otras muchas por hacer).

Hay que tener en cuenta que el que realiza la solicitud probablemente no sepa las implicaciones que tiene lo que ha pedido y lo mismo considera válidas otras alternativas más simples.

No se trata de no hacer lo que nos piden, sino de buscar la solución más eficiente y productiva para todos.

– Se confía tanto en el criterio de alguien del equipo de proyecto, del área usuaria o el cliente que se decide aplicar la solución propuesta sin aplicar prácticamente ningún filtro sobre la misma.

– El director usuario o el cliente no atienden a razones, quieren lo que piden de una determinada manera y no quieren conocer otras alternativas (por más que se les insista).

En esta situación, lo mejor es dejarle muy claro al que lo ha pedido, los costes que tiene y el impacto en el producto (e incluso en el proyecto). Por tanto, todo por escrito, tanto la solicitud, como la previsión de costes e impacto (lo más probable es que en el futuro haya problemas y es necesario que quede delimitada la responsabilidad).

Seguro que a muchos os suena este antipatrón.

Se dice que existe una gestión gaviota cuando un gestor que no sigue el día a día del proyecto, solo aparece en el mismo cuando se le ha informado (generalmente por parte del área usuaria, del cliente o por algún allegado) de un conflicto, y sin entrar en valorar la situación de manera adecuada y sin escuchar al equipo, hace mucho ruido, da cuatro instrucciones de obligado cumplimiento y se vuelve a marchar.

Esta situación crea desazón en el equipo de proyecto, no se sienten protegidos, no se sienten valorados, considerándose instrumentos, no personas. Además se produce una pérdida de confianza interna (existe temor a tomar determinado tipo de decisiones, a discutir determinados temas con el cliente) y un desgaste importante en las relaciones con el gestor.