archivo

Archivos diarios: junio 19, 2011

No es lo más importante del desarrollo de software siguiendo principios ágiles, sin embargo, no se pueden entender desarrollos ágiles en sistemas con deudas técnicas elevadas o en proyectos donde la calidad del código sea deficiente.

No es lógico establecer un contexto que favorezca un desarrollo ágil y sin embargo se descuide la arquitectura del software y la codificación, teniendo en cuenta que el código lo comparte todo el equipo de proyecto que realiza tareas de programación.

Con respecto a la calidad del código, Martin Fowler, comenta lo siguiente en su libro “Refactoring: Improving the Design of Existing Code”: “Cualquier tonto puede escribir código que un ordenador pueda entender. Los buenos programadores escriben código que los humanos puedan entender”.

Si yo fuera proveedor de servicios de software intentaría tener invertido una buena parte de mis proyectos en plazo fijo, es decir, en proyectos donde facture por horas. En este tipo de trabajos, salvo que se gestionen muy mal o la calidad del servicio sea deficiente, se ganará dinero, tal vez no tanto como en otros, pero la seguridad de tener cubierto una buena parte de tu presupuesto, también tiene su valor.

Tanto se ha trabajado así entre clientes y proveedores que incluso en los proyectos orientados a cumplir un servicio, los proveedores siempre ponen sobre la mesa las horas cuando ven que existe una desviación en el presupuesto.

Si se contrata un servicio, debe estar por encima del esfuerzo ejecutado, ya que eso es lo que se ha contratado, un presupuesto cerrado.

El adjudicatario del servicio medirá internamente los costes del proyecto basado en las horas y el avance del mismo y también puede expresar al cliente su preocupación por las desviaciones en el presupuesto y ese es el límite al que se puede llegar.

Si las desviaciones son consecuencia de que el proyecto no va sobre las líneas especificadas en el contrato, sí que resulta razonable negociar y tal vez intercambiar unas tareas por otras o cambiar presupuesto de los trabajos.

Sin embargo poner sobre la mesa las horas y ser esa la base para una nueva negociación es un error. Si están justificadas plantea las causas y no tengas problemas en intentar que se te escuche. Si no hay una justificación en el proyecto, mi recomendación es que se asuman los errores y no se intenten compartir con el cliente, ya que al desgaste que se produce en el desarrollo normal del proyecto, se le añadirá otro que puede hacer muy complicadas las relaciones en el mismo y hará más difícil alcanzar los objetivos y si estos no se consiguen nadie terminará contento, nadie gana, aunque se consigan beneficios económicos.