archivo

Archivos Mensuales: diciembre 2012

Forzar a que un equipo de proyecto admita más trabajo que el que soporta su capacidad en un momento dado del tiempo no suele funcionar. Tal vez se desarrollen las funcionalidades pretendidas pero es más que probable que el grado de acabado de las mismas no sea bueno, de tal forma que la calidad del resultado final se resentirá: más bugs, deficiencias funcionales y funcionalidades que no están totalmente rematadas?.

Y no solo eso, será complicado que se respeten los plazos fijados, así como los compromisos adquiridos. El triángulo de hierro es poco maleable y si mueves uno de sus vértices el resto se resiente, esa flexibilidad adicional te la da el esfuerzo adicional del equipo de proyecto que si bien puede salvar la situación durante un tiempo no podrá sostener un nivel de presión y de overtime de manera sostenida sin que afecte a su propia productividad y a la calidad de los trabajos. Esto es un hecho y seguro que lo has vivido en primera persona.

Se llega a este antipatrón, por un lado por el deseo de avanzar más rápido y en muchos casos por la desconfianza en las estimaciones que se realizan. La confianza requiere un tiempo cimentarla, mientras tanto, pide explicaciones si no terminas de entender alguna de las estimaciones y admítela salvo que entiendas que la desviación respecto a lo que debería ser es flagrante (si tienes dudas, dala también por válida), al final, pasado un tiempo, el propio proyecto irá poniendo las cosas en su sitio.

¿Por qué dejar que sea el equipo quién estime? Pues porque es el equipo al que se le exige el cumplimiento de los compromisos. Puedes exigir si ellos establecen sus límites, si los pones tú no solo te arriesgas a los inconvenientes indicados en párrafos anteriores sino que estás dejando la puerta abierta a que te pongan la excusa de que las condiciones que has planteado eran imposibles.

En el fútbol se puede jugar bonito pero la línea entre el éxito y el fracaso la marca el gol. Cuando miras atrás ves los trofeos y partidos ganados y nadie se acuerda de lo bien que jugó el que perdió.

El desarrollo de software es igual. Lo difícil es rematar. Conforme se va avanzando en el proyecto cada vez se ve la portería más pequeña y cada vez la cuesta se hace más empinada. Se juega fácil en tres cuartos de campo, se juega fácil dando toques, pero llegado el momento tienes que ir cerrando tareas y poner versiones del producto en producción.

Jugando bien es más fácil ganar, pero jugar bien no es suficiente. Si te falta gol o le falta a tu equipo, el proyecto se resiente generalmente en la calidad del producto final y en los plazos. Lo primero porque no se terminan de capturar bien las especificaciones y/o no se terminan de rematar bien las tareas y lo segundo porque resulta complicado salir de tu zona de comodidad (al final con o sin problemas te acostumbras a lo que te va deparando el proyecto).

Cuando hay abundancia de peces es mucho más fácil pescar, tanto que si has dado con uno o varios buenos caladeros solo tienes que situarte en sus proximidades y echar las redes.

En un contexto como el actual en el que el número de peces ha disminuido considerablemente, las piezas son cada vez más pequeñas y la competencia va a por todas, se requiere que salgan a la luz habilidades que lo mismo no eran necesarias cuando la pesca era abundante y relativamente sencilla.

En estas situaciones la teoría de la evolución ejerce todo su poder y solo los mejores sobreviven. Para ello la habilidad comercial es un gran punto de partida, pero también juega un factor importante la perseverancia y no bajar nunca los brazos.

Lo que no funciona es quedarte como un paciente pescador en la orilla esperando a que de nuevo vuelvan a picar los peces, ya que lo mismo te tocan solo los que los demás no quieren o incluso aún peor, te vuelves todos los días a casa con el cesto vacío.

Hay antipatrones que superan a otros, estamos ante uno de ellos. Hay algo peor que barrer bajo la alfombra y es saber que personas que están bajo tu responsabilidad lo hacen y no tomar ningún tipo de medida al respecto.

Aquí no vale lo del ojos que no ven, corazón que no siente, aquí estas prácticas son conocidas y sin embargo no se hace nada. Quién las admite, no solo es cómplice, es como si las estuviera haciendo él mismo. Eres lo que proyectas y lo que dejas que se proyecte y ten en cuenta que tus equipos son una extensión tuya.

Existen muchas formas de llegar al éxito, una de ellas es esconder basura y mostrar solo lo bueno o lo que interesa. También pienso que no vale todo y que el éxito conseguido de esa manera no vale igual que el que se alcanza de manera legítima por mucho que sus resultados puedan ser (y suelan ser) incluso mejores.

Si quieres crear una cultura de confianza en los clientes debe empezar por tu propia actitud y a continuación exigir la misma en tus equipos. Alcanzar esa situación es complicado, obliga a tomar decisiones que no son gratas, incluso te puede llevar a una situación de desgaste personal, pero nadie dijo que lo bueno fuera fácil.

De hecho lo fácil es mirar para otro lado y esperar solo la frialdad de los resultados sin interesarnos en conocer cómo se han alcanzado los mismos. En el momento en que este esquema se desmorona prácticamente no hay solución salvo que te dediques a explorar otros clientes o mercados, ya que en tus relaciones solo quedará desierto.

El triángulo de hierro delimita la calidad final del producto software siempre y cuando las variables que lo componen den la oportunidad de que por lo menos el proyecto tenga alguna oportunidad.

Los enfoques clásicos de desarrollo están orientados al cumplimiento de una agenda, lo que no quita que en los enfoques ágiles se tengan en cuenta también esos parámetros, la diferencia se encuentra principalmente en el grado de flexibilidad que se aplica a los mismos.

Una de las variables es el alcance. Conforme se va avanzando en el proceso de desarrollo, el usuario se empezará a dar cuenta de especificaciones que ha realizado y que son incorrectas o mejorables, así como de nuevas funcionalidades que entienden que serán necesarias. El usuario presionará para que se incorporen todas, incluso en aquellos casos en los que se tenga que “tirar” desarrollo ya realizado.

Si no se gestiona adecuadamente el alcance y en consecuencias, las expectativas, del usuario, el proyecto correrá un riesgo importante. Si se dice a todo que sí y no se ajusta la carga de trabajo a la capacidad que se puede asumir: tanto en tiempo como en presupuesto, el producto se resentirá (reducción de la calidad) y las relaciones entre las partes también (desgaste como consecuencia de condiciones impuestas sin negociación, como consecuencia de expectativas insatisfechas, como consecuencia de la presión, etc…).

De tanto tensar la cuerda termina por romperse lo que puede dar lugar a un proyecto que se quede a medias en el que funcionalidades importantes se han quedado fuera o sin rematar, motivado principalmente por el hecho de no haberse realizado una adecuada gestión de prioridades, ya que el cliente daba por hecho de que todo lo que estaba pidiendo iba a entrar.

Este es un antipatrón para clientes y proveedores. Ambos pierden, los primeros por no buscar un equilibrio entre lo que se quiere y lo que se puede y los segundos por no saber o querer gestionar estas situaciones.

Una sesión de Brain storming tiene como objetivo la generación de nuevas ideas ya sea para resolver un problema o para generar nuevas alternativas de negocio. Es un proceso constructivo.

El Blame storming no tiene como objetivo construir, solo sobrevivir (mantener un status o un puesto de trabajo), a nivel individual o de un conjunto de personas, justificando actuaciones que han fracasado echando la culpa a terceros (personas concretas, clientes, proveedores o el entorno) de todo lo que ha pasado.

La finalidad es reunir pruebas contra ellos que puedan servir para argumentar por qué se ha fracasado, evitando mencionar todo el conjunto de decisiones, malas prácticas y actuaciones propias que han influido en el resultado final.

Si el Blame storming funciona, nada cambiará, se ha fallado por culpa de otros, por lo que podemos seguir actuando de la misma manera. El camino para la mejora continua pasa por asumir los errores y sus consecuencias para de esta forma aprender de ellos, por lo que el Blame storming solo lleva a más de los mismo, a seguir acumulando proyectos o líneas de actuación que van mal y que golpean la cuenta de resultados de la organización.

Detectar a quién o quienes hacen esta práctica es fácil, nunca la culpa es de ellos y siempre hay una excusa, además, llegado el momento no dudan en señalar a otros, por lo general más débiles y/o que no se encuentran en su organización y que no tienen la oportunidad de rebatirle.

Todo lo que suponga vender o mantener un contrato a través de la mentira o de las medias verdades, de entrada debería considerarse un antipatrón porque el fin, en este caso, no justifica los medios.

Los cebadores de estadísticas se encuentran cómodos en contextos en donde la persona que tendría que valorar la calidad real de los trabajos se basa casi de forma exclusiva en el análisis de datos que le proporciona el proveedor de servicios, sin utilizar una fuente alternativa que audite realmente esos datos y/o sin comprobar de primera mano la calidad de los servicios y si el presupuesto que efectivamente se está destinando se ajusta a las necesidades reales o no.

Los Acuerdos de Nivel de Servicio (ANS) son un interesante instrumento de gestión pero si no se verifica la información que se suministra no vale para nada, tampoco sirve para nada si no se trabaja con ellos para ajustarlos al contexto existente en cada momento: lo mismo es cierto que es servicio es excelente pero la carga de trabajo real no justifica la inversión que se está realizando.

Es muy fácil cebar estadísticas y es muy fácil quitarse tareas de encima, “arrojándolas al otro lado del muro” y que el minutero deje de contar (y que le empiece a contar a otros).

Si en tu organización te encuentras con cebadores de estadísticas valora bien la fugacidad del dinero que te hace ganar y de si es posible que también te estén haciendo lo mismo.

Afecta sobre todo a los usuarios pero también a los desarrolladores y nos lo encontramos tanto en enfoques clásicos como ágiles.

Cuando nos aproximamos a al definición de la primera entrega que va a producción (en el caso de un enfoque iterativo incremental se han podido liberar previamente versiones parciales que no han llegado a producción), el usuario empezará a querer incorporar funcionalidades que considera necesarias aún sabiendo que no son imprescindibles (los desarrolladores que en esto no deberían intervenir, pero que ya conocen el negocio, se convierten incluso en cómplices), sin tener en cuenta que tras esta versión, vendrán otras en las que podrán ir incorporando estas funcionalidades según las prioridades que establezcan.

Si este antipatrón se materializa presenta como inconveniente que se asuma una mayor capacidad de trabajo que la que el equipo puede soportar, lo que provocará, además del correspondiente overtime, una versión del producto con un peor acabado: más errores y más deuda técnica, y que no se cumplan los compromisos adquiridos ya que probablemente alguna funcionalidad no de tiempo a tenerla lista (esto último puede parecer menos importante pero no lo es, ya que la confianza está muy ligada al cumplimiento de los compromisos).

Es un ejemplo claro de que más es menos cuando se toman decisiones que no son compatibles con las posibilidades del equipo de proyecto.

Son muchos proyectos en los que he tenido la oportunidad de trabajar con equipos de proyectos distintos de diferentes proveedores. En esos proyectos ha pasado y me he encontrado de todo.

He participado en proyectos con mucho desgaste en las relaciones con el proveedor en los que durante meses ha existido tormenta y casi ningún día de calma.

La mayoría de vosotros, independientemente del “bando” en el que se encontréis: cliente o proveedor, habréis vivido situaciones similares.

No hace mucho un amigo me comentó que desde su punto de vista se era demasiado permisivo con los proveedores y que a su juicio se debería aplicar sobre los mismos “mano dura”.

Con respecto a la aplicación de “mano dura” es importante que tengáis en cuenta en primer lugar cuál es vuestro rol en la organización a la que pertenecéis. Probablemente tengáis como jefes a una infinidad de personas en diferentes niveles por lo que vuestra “mano dura” se puede quedar en nada si los que están por encima tuya no te respaldan y/o llegado el momento no se quieren mojar. ¿Qué quiero decir esto? Si amenazas con no pagar, con penalizar o con rescindir el contrato o decides pasar de la amenaza a los hechos, el asunto se termina escalando tanto en cliente como en el proveedor y se llega a una instancia donde se toma la decisión final y en la que pintarás bien poco.

Al final si no te dan la razón te encontrarás con respecto al proveedor en una situación peor que la que existía antes de comenzar este proceso.

Cuando no se tiene una visión del día a día del proyecto los criterios para respaldarte o no en tu postura son absolutamente distinto a los tuyos y lo normal es que la gente no se complique la vida.

La “mano dura” no sirve en el día a día de un proyecto. Creo más en la firmeza, en el respeto y en la comunicación. Es cierto que a veces no hay ni respeto ni comunicación y que eso al final da lugar a un desastre. Tu puedes querer calidad en los trabajos pero si el proveedor no entiende eso como necesario (solo le interesa imputar más y más horas) da igual como te pongas y da igual las veces que lo discutas (te podrán hacer caso a corto plazo pero a la larga volverán a las andadas). ¿Qué hacer en ese caso? Si la situación no se reconduce se debe escalar, una vez que se hayan apurado las vías de diálogo y hacer las recomendaciones oportunas a tus superiores, después que ellos actúen (esa responsabilidad está en su nómina) y por supuesto tener muy en cuenta lo que ha pasado de cara a un futuro. En cualquier caso hay que tratar de darle la salida más digna posible al proyecto.

Existen muchas formas de modelar la realidad, todas ellas válidas. Sin embargo el hecho de que sea válida no quiere decir que el modelo de datos sea bueno.

Un modelo de datos más complejo de lo necesario será a la larga una fuente de problemas porque aunque esté escondido en las capas más profundas de la aplicación condiciona sin lugar a dudas todo lo demás.

A veces el modelo lo hace complejo el desarrollador, otras muchas veces el usuario que pretende almacenar información o relacionar entidades que después no va a poder mantener. Es conveniente hacerle ver al usuario si efectivamente esa complejidad adicional que va a introducir le va a aportar algún valor y si incluso aportándole van a tener recursos suficientes para mantener los datos actualizados y con calidad.

El desarrollo de software requiere cooperación e interacción, no se trata en este caso de contaminar al usuario sino de hacerle reflexionar sobre la situación, a veces una segunda o tercera pensada evita malgastar esfuerzos presentes y futuros.

Los modelos de datos deben ser lo más simples posibles sin que se pierda información que el usuario necesita (realmete) para su gestión. Si hay que dedicar algo más de tiempo en él es una inversión que al final será amortizada.