archivo

Archivos diarios: enero 1, 2013

Contratar proyectos de desarrollo de software mediante subasta o teniendo como principal criterio el económico es un error. Aplicar este criterio es dar por supuesto que las personas juegan un papel secundario en el desarrollo y que lo que realmente importa son las dinámicas y los procesos.

No se trata de gastar por gastar sino de saber en qué estamos invirtiendo el dinero, si lo haces sin tener en cuenta la solvencia técnica del equipo, de las personas o de la organización (más lo anterior que esto) sencillamente no sabes lo que estás haciendo.

La diferencia entre un buen desarrollador de uno que no lo es (o que todavía no lo es porque le falta adquirir conocimientos y experiencias) no son ni veinte ni treinta euros la hora, es mucho más, lo que nos dedicamos a esto sabemos que la distancia entre uno y otros es del orden, como mínimo, de decenas de veces. No se trata solo de la capacidad de ejecutar trabajo sino de lo efectivo que resulta, de la calidad del código generado y de la cantidad de errores que se produzcan.

Y esto no solo afecta a los programadores, sino a cualquier perfil.

El criterio económico puede influir en caso de que la solvencia técnica sea similar, en este caso es donde podríamos empezar a aplicar el factor calidad/precio, no obstante ten mucho cuidado si la diferencia de precio es excesiva porque nadie regala nada, se hacen muchas cosas con tal de conseguir un contrato y lo que no se te cobra ahora te lo cobrarán después.

Cuando asumes una responsabilidad lo tienes que hacer con todas sus consecuencias.

Este antipatrón surge cuando se dan las siguientes circunstancias:

– Tratan de evitar decisiones que pueden ser comprometidas, evitando el riesgo y aquellas que pueden provocar conflictos con los componentes de tu equipo y con los compañeros. Se prefiere no hacer nada o dejar que sean otros los que se muevan, de esta forma, si algo sale mal no es culpa suya (ya tratará de demostrar que no ha tenido nada que ver y que sus planes eran otros) y si sale bien, seguro que saca beneficios de la situación.

La inacción como norma no funciona porque la mayoría de las veces los problemas no se arreglan solos. Por otro lado, si tienes una responsabilidad no debes dejar que otros se quemen por ti. Puedes delegar, pero cuando delegas sigues siendo el máximo responsable.

– Cuando se equivocan, no suelen asumir su error, o solo lo hacen cuando saben que el impacto ha sido mínimo. Para ello se intenta esconder el error y dejar que sea el paso del tiempo quien lo termine de ocultar definitivamente (es la práctica más habitual porque es la que menos ruido causa). Si el fallo no se puede esconder tienden a minimizarlo y a achacarlo a causas externas, generalmente al entorno o al contexto, porque de esta forma no encontrará quién rebata sus argumentos. En última instancia, si no tienen otra posibilidad, tratarán de echar la culpa directamente (o compartiendo la responsabilidad) a una persona o a un equipo, por lo general, más débil y con pocas posibilidades de defensa.

– Pocas veces dan la cara por su equipo cuando es necesario (no de cara a la galería), ya que hay que tener en cuenta que estos conflictos serán a veces con un tercero (un cliente o un proveedor) y otras con personas o equipos dentro de la organización, que incluso se pueden encontrar en un orden jerárquico superior.

El desarrollo de software es una continua toma de decisiones, en las que se acierta y se falla, y en las que los errores a veces son graves. Intervienen personas, organizaciones distintas, en situaciones además en la que puede existir mucha presión y desgaste, además de intereses contrapuestos, en este contexto, los malentendidos y conflictos salen a la luz tarde o temprano. No aceptar esto, es no aceptar la realidad de nuestro día a día, si no estás dispuesto a asumir la responsabilidad que te van a encomendar, lo mejor para ti y para la organización es que no la asumas.

Nos encontramos con un cumplidor cuando su principal afán en un proyecto de desarrollo de software es cumplir con las normativas, procesos o metodologías que la organización ha definido para guiar y/o acompañar al proceso de desarrollo de software, dejando en un segundo plano al producto software que se está desarrollando.

Consecuencias:

– El cumplidor siempre tendrá un salvoconducto para cuando las cosas vayan mal: “todos los entregables de la metodología se han realizado tal y como indica la normativa, se han realizado todos los seguimientos y reportes que vienen en ella, por lo que si el proyecto ha ido mal no será porque no he respetado el proceso de desarrollo”.

– La cultura que se impone es la de cumplir los procesos por encima de desarrollar productos software de calidad que satisfagan las expectativas de los usuarios.

El problema no es respetar las normas sino en utilizarlas como escudo en lugar de tratar de sacar el proyecto hacia adelante. Salvo que los procesos te maniaten, siempre tienes un margen para tomar decisiones y para negociar internamente la modificación puntual de algunos aspectos normativos en el proyecto, en definitiva, tienes la oportunidad de aportar valor al proyecto y no de seguir a rajatabla una receta.

Si en la organización no se toman medidas, proliferarán más y más cumplidores, muchos de los cuales tendrán la excusa perfecta en la rigidez de los procesos. Está claro que es un problema de actitud por parte de estas personas pero saca a la superficie un problema de fondo mucho mayor que no es otro que la estrategia de desarrollo de software dentro de la organización y la evaluación del trabajo de los técnicos y gestores.