archivo

Archivos diarios: septiembre 2, 2011

Los departamentos de calidad del software de las organizaciones requieren una comunicación continua y fluida con los departamentos de desarrollo.

Esto es absolutamente necesario para tareas logísticas ya que es recomendable que calidad conozca el planning de los proyectos para poder organizarse de manera adecuada pero lo es y de manera más importante para que los procesos de calidad no se desvíen del proceso real de desarrollo de software de una organización.

Es decir, si se sube o se baja los umbrales generales de calidad debe hacerse de forma consensuada ya que de lo contrario la falta de alineación va a ir provocando una fractura entre los equipos de trabajo ya que van a tener visiones y objetivos diferentes, ese fractura se traducirá en una menor flexibilidad entre las partes, a malentendidos y a parones en el trabajo.

Una vez consensuados unos patrones de calidad del software hay que respetarlos, si desde desarrollo queremos respeto por nuestro trabajo debemos también respetar el trabajo del equipo de calidad porque sus tareas son importantes y lo serían más si le diéramos el peso y el soporte que realmente necesitan.

Ahora bien, surgirán excepciones, productos que hay que pasar a producción en un plazo determinado, que es inamovible y que va a provocar (con el riesgo que supone) que el producto no sufra más controles de calidad que los aplicados en el proceso de desarrollo (que distan de ser óptimos, desgraciadamente, en la mayoría de los casos) o bien que la revisión sea muy superficial (y sin tiempo para corregir incidencias). Estas excepciones deben ser consensuadas también con calidad para que sobre todo conozcan el motivo de la no aplicación de las reglas y normas pactadas.

Ya he escrito algunos artículos sobre la problemática de considerar imprescindibles a determinadas personas en una organización o que efectivamente puedan llegar a ser difíciles de sustituir sin un impacto importante.

Llegar a ese punto es fomentar el individualismo, la creación de cotos privados, de parcelas de “poder”, cuando el desarrollo de software es un trabajo en equipo o por lo menos debería serlo para intentar conseguir unos resultados mejores (es cierto que se habla demasiado de las bondades del trabajo en equipo en el desarrollo de software, que sabemos que funciona y que ofrece buenos resultados y sin embargo la organización predominante dentro y fuera del proyecto son los grupitos que resulta hasta más perjudicial que el individualismo).

También he comentado en alguna ocasión que el principal responsable de la existencia de imprescindibles es la propia organización que no ha sabido retener o repercutir su conocimiento en más personas del equipo.

Hay que entender que en toda organización destacan determinadas personas, es hasta positivo que así sea, pero una cosa es destacar y aprovechar todo ese potencial y otra que exista dependencia del mismo.

Sobre este hecho Weinberg realiza la siguiente reflexión: “Si un gestor quiere ejecutar un proyecto de manera estable haría bien en seguir la siguiente máxima: si un programador es indispensable, deshazte de él lo antes posible”.

Partamos de la base de que la mayor parte de los sistemas de información que desarrollamos no tienen que estar de manera obligatoria en una fecha concreta en producción. El cliente te lo podrá exigir, pero realmente en la mayoría de los casos se tratan de fechas de referencia y no están ligadas a un hito especial.

Esto es simplemente estadística, ya que también todos hemos trabajado en desarrollos que sí tenían que estar en un día o semana concreta y existían razones de peso que lo justificaban.

Lo que quiero expresar en el inicio de este artículo es que hay que relativizar las fechas de entregas y tener en cuenta que hay aspectos más importantes que pueden justificar un retraso (siempre dentro de unos términos razonables).

No quiero decir que las fechas no estén para cumplirlas, ya que si se fijan y se pactan es para algo, entre otras cosas para no perder el enfoque del proyecto (enfoque que se diluye cuando no se cierra la fecha de entrega de un producto), lo que quiero decir es que cuando haya un retraso hay que estudiar los motivos, ¿es causa exclusiva del proveedor?, ¿de los usuarios?, ¿del director técnico del cliente?, ¿todos han tenido que ver en una determinada proporción?, ¿ha sido provocada porque los plazos exigidos al equipo de desarrollo son incumplibles ya que no están acordes al alcance del proyecto y los recursos disponibles?.

Una vez determinada la causa es posible tomar decisiones para intentar evitar nuevos retrasos o incluso intentar recuperar parte del camino perdido, sin embargo en la mayoría de los casos resulta muy complicado recuperar los retrasos, entre otras cosas porque no siempre se informa al cliente a tiempo y porque los plazos suelen ser bastante ajustados.

Si la fecha final del proyecto se puede retrasar, mi consejo es que se haga. Si el retraso es responsabilidad del proveedor, ya habrá tiempo de ajustar cuentas (cada palo que aguante su vela), pero no se debe caer en el riesgo de poner en marcha de manera precipitada un producto, ya que por cada paso que se de hacia adelante en este sentido probablemente se tengan que dar varios para atrás.

Si el retraso es lo suficientemente importante como para la fecha objetivo no sea admisible, es conveniente aplicar las prioridades que se hayan establecido sobre los requisitos (si se está desarrollando siguiendo metodologías ágiles, habrá sido el camino adoptado desde el principio del proyecto) y afrontar varios hitos de entrega.