archivo

Archivos Mensuales: enero 2012

Una estrategia clásica para intentar hacerte imprescindible dentro de una organización es que ciertos detalles relevantes de tu trabajo o de tus proyectos los conozcas exclusivamente tu, de manera que si se les ocurriese en algún momento echarte esa información se iría contigo, lo mismo que si decides irte a otra empresa (en este caso el objetivo no es mantener tu puesto de trabajo sino ir consiguiendo cada vez, unas mejores condiciones laborales).

Por ese motivo, existe mucha reticencia en estas personas a documentar lo que hacen o a compartir con otros sus conocimientos.

Este antipatrón se produce cuando una organización siendo consciente de que esta problemática existe no toma medidas para evitar o por lo menos reducir esta cautividad o dependencia con determinados trabajadores.

Hay que tener en cuenta que el problema no es solo que determinadas tareas o proyectos queden desprotegidos, sino que la actitud de los Job Keeper resulta absolutamente negativa dentro de las actividades diarias dentro de una organización, porque esta persona no colaborará con otros compañeros cuando esto suponga compartir parte de la información o conocimientos que él considera valiosos y puede comprometer el funcionamiento de la misma cuando no estén presentes en su puesto de trabajo (vacaciones, visitas a clientes, etc…).

No hace mucho, estuve conversando con un usuario que quería hacer modificaciones significativas en un sistema de información, algunas de ellas eran totalmente razonables y otras, las más complicadas, se trataban de situaciones que se podían dar, pero que tras analizar la situación se podían producir una o dos veces al año (si acaso) y que en el caso de que se produjeran su no tratamiento en el sistema de la manera más óptima, no tendría consecuencias significativas.

Después de analizar con el usuario, los pros y los contras (incremento de la complejidad del sistema, esfuerzo (dinero) necesario para llevarlo a cabo, etc…), dijo finalmente “es cierto que si estos casos se producen se van dar en contadas ocasiones y no merece la pena hacer los cambios en la aplicación”.

Por tanto, en este caso, lo más productivo fue tomar la decisión de no implementar funcionalidades que no eran absolutamente necesarias (y no caer en antipatrones como por ejemplo “funcionalitis acechante“) y dedicar la atención y esfuerzo a aquellas que sí eran importantes.

Existe mucho respeto en entrar a valorar con los usuarios sus propias peticiones, pero es algo que es necesario y que el mismo usuario o cliente agradecerá en la mayoría de los casos (le ahorrarás dinero y tendrá un producto de mayor calidad). Es cierto que muchas veces no te harán caso, incluso en otras les podrá sentar mal, pero poniendo en una balanza beneficios y riesgos, merece mucho la pena intentarlo.

Otro error muy típico consiste en criticar ante el cliente o ante la competencia el trabajo o la actitud de otros compañeros de tu organización o el resultado de determinados proyectos de tu empresa.

Es cierto que todos podemos tener momentos de debilidad en los que de alguna u otra forma necesitamos desahogarnos, pero hay que tener mucho cuidado con quién se hace y qué es lo que se dice, porque puede ser que más adelante nos tengamos que arrepentir.

Es un antipatrón en el que se cae con relativa frecuencia y que tiene consecuencias económicas muy negativas para la organización que acepta el trabajo (en el caso de que se trate de una contratación a un cliente) y muchísimo esfuerzo para el equipo de proyecto afectado por el mismo (ya sea por el motivo anterior o porque un directivo o gerente de tu organización te lo asigna).

Se trata de aceptar proyectos que se venden (es curioso, pero muchas veces es el cliente el que vende al proveedor) como algo muy simple (solo hay que…), en los que no se realiza un análisis a alto nivel de su complejidad o viabilidad y que después resulta que es mucho más complejo y que requerirá mucho más esfuerzo que el inicialmente previsto.

Como decía en el primer párrafo, también se puede producir dentro de una organización cuando el gestor de turno te pide el favor de que le dejes un hueco a un nuevo proyecto que es muy sencillito y que apenas le va a quitar tiempo…

Se le llama Guerra de Vietnam por su analogía con la misma: guerra supuestamente fácil y corta que se cobra una alta tasa de víctimas.

Se basa en la adopción de técnicas, tecnologías, metodologías, etc… por el simple hecho de estar a la moda o haber sido el tema principal del último curso o conferencia a la que has asistido, sin realizar un análisis riguroso de las ventajas e inconvenientes que tiene la aplicación de las mismas.

Es muy parecido al patrón “Blowhard Jamboree“, con la diferencia de que este último está más orientado a seguir los criterios de una determinada persona o actor importante o de prestigio (al menos para el que lo sigue, mientras que “anunciado en televisióń” no está tan centrado en la persona que lo cuenta.

Estar al día en las tendencias tecnologícas, de ingeniería del software, etc…, resulta muy interesante ya que en muchas ocasiones ser un early adopter proporciona una ventaja competitiva interesante y en otras probablemente se pueda mejorar la forma en la que se está trabajando.

En el caso de conferencias, cursos, certificaciones, etc…, pasa exactamente lo mismo, si han sido interesantes seguro que has adquirido una serie de conocimientos que pueden ser muy provechosos.

El problema no es aprender, no es conocer nuevos contextos o enfoques, el problema es aplicarlos a ciegas.

Defiendo absolutamente la posibilidad de que en una organización se pueda progresar horizontalmente de manera que técnicos que disfruten con la programación y con la ingeniería del software puedan tener la oportunidad de conseguir mejores condiciones laborales si su desempeño, experiencia y conocimientos les hace merecedores de ello.

Lo anterior es absolutamente compatible con una carrera profesional de índole más técnica orientada a la arquitectura del software.

Es posible que a un programador solo lo puedas vender dentro de un umbral precio/hora (es el reverso tenebroso de los proyectos tipo taxímetro o bolsa de horas), pero en proyectos donde prestas un servicio tener a desarrolladores altamente cualificados, motivados y productivos puede ser la diferencia entre ganar o perder dinero.

Un apunte: No hablo de sobredimensionar la cualificación de los equipos, ya que eso puede jugar incluso en contra del proyecto ya que puede provocar en algunos casos (proyectos de complejidad medio o baja) pérdida de motivación y de rendimiento, lo que unido a mayores costes, puede hacer que el proyecto no sea tan rentable como cabría pensar y encima tienes ocupado en el mismo a gran parte del potencial de tu organización.

Cuando el coste/hora y no la productividad es la que marca los pasos, se pueden llegar a tomar decisiones poco comprensibles como que arquitectos software o analistas orgánicos centren su esfuerzo en definir arquitecturas, frameworks o diseños y dejen a un lado el día a día de la programación.

Todos sabemos como evoluciona el mundo del desarrollo de software y eso hace que ese tipo de decisiones se consideren un antipatrón, ya que cuanto más alejado esté un arquitecto de la realidad de la codificación, más alejadas se encontrarán sus soluciones de las necesidades que pueda tener el equipo de programadores y el proyecto.

La creatividad desmesurada que nos caracteriza puede provocar que el arquitecto elija soluciones más teóricas (cuando no experimentales) que prácticas, alejando al proyecto del objetivo de simplicidad máxima que cumpla las expectativas del usuario. Este defecto lo tiene cualquiera que realice análisis, diseños o arquitecturas y empeora sensiblemente cuando se está alejado del día a día de los proyectos (un analista que no trata con usuarios y con sus problemas, tenderá a hacer soluciones más complejas).

Nos encontraríamos ante una situación concreta del antipatrón “responsable ausente“. En este caso, el gestor a modo de sortilegio establece una líneas generales para el desarrollo del proyecto y desaparece, apareciendo solo cuando existen problemas en el proyecto y generalmente como reacción ante las quejas de uno o más stakeholders (antipatrón “gestión dirigida por disparos“).

Nadie es imprescindible, pero si cada uno desempeña su rol en el proyecto de manera adecuada existirán más posibilidades de que todo salga bien.