archivo

Archivos Mensuales: julio 2012

Cuando en una organización, departamento o equipo de trabajo no existen objetivos, existiendo no se comunican o existiendo y comunicados son papel mojado porque nadie se encarga de medirlos, de hacer que se cumplan y se ignoran, llega el caos.

En esta situación de caos, cada uno hace la guerra por su cuenta y se deja a voluntad del individuo o de equipos concretos tomar decisiones que no solo puedan ser beneficiosas para un proyecto o tarea concreta sino también para otras personas, equipos y la organización. Es cierto que esa voluntad la tienen muchas personas pero también es cierto que otras muchas solo velarán por sus intereses y no solo relacionados con su rol en la organización, sino por sus propios intereses personales.

En el caos, el esfuerzo se fragmenta en diversas direcciones, en muchos casos opuestas y eso impide el progreso de la organización en su conjunto. Se pueden conseguir victorias individuales, tal vez ganar alguna batalla pero tarde o temprano la guerra se perderá ante rivales más organizados o que incluso teniendo tus mismos problemas sean más poderosos que tu.

El desarrollo de software no es solo son procesos, metodologías, arquitecturas, programación, etc… hay algo más, mucho más importante que es la relación entre las personas que intervienen en el proyecto.

Si falla esa relación, esa comunicación entre las personas, esa búsqueda de un objetivo común, esa necesidad de trabajar juntos para alcanzarlo difícilmente va a funcionar todo lo demás por muy bien que se trabaje.

También está el bagaje profesional y personal, ese background que te ayuda a intentar tomar las mejores decisiones (aunque no siempre se acierte) incluso en contextos complicados y/o que no son conocidos por nosotros.

Si se trabaja como un equipo se tendrá la capacidad de integrar el background de todos, si no es así no es ya que no se aproveche ese talento y esa experiencia sino que esas diferentes visiones tenderán a convertirse en fuerzas que empujan en distinto sentido y provoca situaciones de bloqueo en el proyecto, desgaste, etc…

Ken Schwaber considera que no todo son procesos y metodologías, sino que hay algo más: “Una metodología te dice lo que tienes que hacer, un proceso es un framework que establece algunas restricciones. Una metodología no puede decirle a la gente que hacer cuando nunca han estado allí”. Es decir, tras la metodología quedan los desarrolladores (las metodologías son generalizaciones y no pueden tener en cuenta cada situación concreta de un proyecto) que son los que al final tienen que tomar las decisiones.

De las diferentes restricciones que podemos encontrarnos en un proyecto, la económica y los plazos son de las que más condicionan el devenir del mismo.

Por ese motivo la calidad exigida debe ser congruente con las restricciones de partida y los cambios que pudiera haber de las mismas a lo largo del proceso de desarrollo.

El usuario determinará un estándar de calidad que será el resultado de sumar sus expectativas junto a especificaciones sobre otros aspectos que pueda tener fijadas la organización (normativa de desarrollo, normativa de calidad del software, etc…).

Ese estándar no se consigue con el mismo esfuerzo por parte de todos los posibles proveedores. Quienes lo consigan con menos esfuerzo tienen más margen para incrementar la calidad del producto y para obtener más beneficios (o al menos beneficios) en el proyecto.

Si no existe proporción entre ese nivel de calidad exigido y las restricciones se verán afectadas todas las variables de manera que por ejemplo se superará el coste necesario para desarrollar el producto (lo que se concretará en una mayor asignación económica al proyecto, una reducción del alcance o una disminución de la calidad), los plazos y la calidad se verá afectada porque el overtime y la presión impactan directamente contra la misma.

El problema lo tenemos en que no suele existir proporcionalidad entre las restricciones y, en general, el alcance del proyecto (y como parte de ese alcance la calidad) ya sea motivado por el cliente solo o en compañía del proveedor cuando este realiza ofertas a la baja ajenas a cualquier atisbo de realidad.

Comenta Ken Schwaber que: “No, no estoy intentando cambiar la organización por completo, pero cambios en el desarrollo de software cambian a la organización”.

¿Es Scrum quién cambia parte de la organización o es parte de la organización la que debe cambiar para aplicar Scrum? Desde luego que para aplicar Scrum (de verdad) la organización debe realizar cambios para que sea efectivo, el ejemplo más claro lo tenemos en la existencia de un Product Owner que realmente se sienta comprometido con sus funciones y también lo es que la organización se realimenta del uso de Scrum y eso va más allá de la calidad o no del software que se desarrolla, sino del cambio de mentalidad que supone: trabajo en equipo, equipos multidisciplinares, cooperación, comunicación, retrospectivas, adaptación al cambio, etc…

Por tanto, se realimentan, pero como decía se requiere previamente de una apuesta por este modelo de trabajo.

Para Brian Kernighan el control de la complejidad es la esencia de la programación.

Complejidad supone más esfuerzo en la construcción y en el mantenimiento, más probabilidad de que existan errores y sistemas de información más complicados de utilizar para el usuario.

La complejidad es resistencia al progreso en el desarrollo y resistencia cuando se trata de adaptarnos al cambio.

La complejidad es agotadora para los desarrolladores y una carga que lleva el producto durante todo su ciclo de vida.

Es necesario hacer un esfuerzo en todas las etapas del proyecto, desde su concepción hasta su entrega con el objetivo de encontrar la solución más simple que satisfaga las expectativas del usuario (y que permita un mantenimiento lo más simple posible ajustado a las características del sistema).

Buscar lo más simple implicará entender bien los procesos de fondo que informatiza el sistema, pensar en el usuario, pensar en el software es susceptible de ser modificado en todo su ciclo de vida, pensar en que hay que ser prácticos (tanto desarrolladores como usuarios) y no llenar el producto de funcionalidades que no se utilizan o que van a tener un uso residual.

A la hora de realizar una estimación existen dos problemas principales, primero la ingerencia de los gestores de proyecto y de los responsables funcionales que normalmente pretenden acomodar los plazos a sus necesidades (que lo mismo son las necesidades reales del proyecto) y segundo cuando el equipo de proyecto pierde la objetividad y opta por actitudes demasiado optimistas o pesimistas (defensivas) al margen del contexto real del proyecto.

Si la estimación no se ajusta a los plazos deseables en el proyecto y no es posible mejorar esos tiempos metiendo más personal, intentando aplicar algunas estrategias que puedan mejorar la productividad o cualquier otra posible solución, lo mejor es negociar bien otros plazos o una reducción de las expectativas del sistema para ese marco temporal.

Es cierto que, en algunos casos (menos de los que creemos y admitimos), los plazos son los plazos y no tendremos más remedio que convivir con ellos, en esos casos hay que buscar fórmulas para intentar llegar a ellos, sin renunciar a eliminar toda funcionalidad que no sea absolutamente necesaria para conseguir los objetivos (aunque se tenga que desarrollar más tarde).

Todos, y me incluyo, nos sentimos tentados a intervenir en las estimaciones, pero es algo que tenemos que intentar evitar, salvo que sea algo tan evidente que nos haga actuar (si no entendemos algo, tenemos que preguntar, si vemos que algo es disparatado, hay que pedir explicaciones y si procede, rechazar la estimación).

Para Jeff Sutherland: “Las personas que están realizando el trabajo son los que siempre deben estimar el trabajo” y la experiencia me ha demostrado que así debe ser.

Para mantener enfoque en una tarea o en un proyecto tan importante es encontrar motivación en lo que estamos haciendo como que nos resulten indiferente todo aquello que pueda ser una distracción. Es decir, prestar atención a otras tareas o asuntos en el ámbito laboral que no tienen nada que ver con nuestro objetivo actual.

Y realmente no sé que es más sencillo si tener motivación u olvidarse de todos aquellos factores, elementos, tareas, circuntancias, etc… que nos pueden robar energía, atención y tiempo.

No tengo claro qué puede resultar más fácil pero sí que conozco las consecuencias de no centrarme en los objetivos principales por no abandonar otro tipo de tareas que pese a que puedan ser necesarias otros han considerado que no lo son. Al final se traduce en sobreesfuerzo y mal reparto del mismo, echar más horas de las necesarias y dedicar menos tiempo a hacer un trabajo de calidad en los proyectos que ahora deberían tener toda mi atención. De esta forma parece que nunca se echan suficientes horas porque al final tu trabajo no lo hace nadie y te toca a ti hacerle frente.

¿Por qué no mostrar indiferencia cuándo otros sí que lo hacen? Por el sentido de la responsabilidad que tiene cada uno y por el deseo de hacer las cosas bien. Por ese motivo resulta tan complicado dejar de lado tareas que impactan en el enfoque que deberíamos tener en los nuevos objetivos que nos han marcado.