archivo

Archivo de la etiqueta: management

Se puede tener talento, ser un gran desarrollador y todo eso puede marcar la diferencia, no lo dudo. Sin embargo, el contexto en el que toda esa aptitud presenta y aprovecha todo su potencial es cuando a eso se le suma la implicación, las ganas.

No se trata de una frase hecha, tampoco pretendo generalizar y que solo con talento no se puedan conseguir cosas, sin embargo, si hacemos media aritmética es la actitud la que permite sacar partido a esa calidad y es la actitud la que acorta distancias e incluso permite superar a talentos que deciden no acompañar ese potencial con trabajo y con un enfoque adecuado del mismo con el resto de personas de su equipo y del proyecto.

Por eso valoro el talento pero también valoro las ganas y la capacidad de trabajar con otras personas. Debe haber un equilibrio y dar la oportunidad a que personas con menos conocimiento y experiencia tengan la posibilidad de evolucionar.

En proyecto largos, complicados (complejos o no), es fundamental la implicación personal en el proyecto y con tus compañeros. Todos sabemos como son los proyectos, sus dientes de sierra, los momentos buenos, los regulares y los malos. Es cierto que es complicado mantener una línea constante todo el tiempo, somos personas, será la actitud personal la que conseguirá tener el mayor rendimiento posible incluso en circunstancias donde no sea sencillo.

Muchos de esos talentos, de esas referencias que están en tu equipo de proyecto o en tu organización, lo son porque otras personas le dieron la oportunidad de desarrollarse profesionalmente y de adquirir los conocimientos y experiencia necesaria. No olvidemos que el aprendizaje tiene un efecto motivador muy importante y que ayuda a la implicación de las personas en el equipo, lo que hace también que aquellos que tengan más conocimiento, sigan tratando de hacer su trabajo de la mejor manera posible y seguir progresando.

Utilizar el dinero como motivador suele ser eficaz a corto plazo, a medio y largo plazo resulta fatal para tu departamento u organización.

¿Por qué? Pues porque lo excepcional se convierte en costumbre y al cabo del tiempo ya no será suficiente para motivar o no tendrá el mismo efecto. Además, en el momento en que falta ese ingreso se suele obtener el efecto contrario: reducción del rendimiento por falta de motivación.

De esta forma se crea en la cultura de que lo que realmente mueve a los profesionales de la organización es el dinero y no el interés por el trabajo que se realiza en la misma, el propio afán del desarrollador por mejorar o la pasión que puede sentir por su profesión.

Otro problema lo tenemos en que la persona tenderá a ir a por los objetivos que le permiten obtener la recompensa, dejando de lado otros que pueden ser igualmente importantes para la organización. La persona se convierte en cumplidor pero en cumplidor de lo que le interesa, de lo que le hace ganar más dinero.

Estoy hablando de recompensas sistemáticas y no de retribuciones justas. Soy de la opinión de que un profesional debe estar pagado acorde a sus méritos, conocimientos y experiencia (aunque raras veces se pague a los profesionales siguiendo esos criterios). Tampoco estoy en contra de las retribuciones variables siempre y cuando las mismas se realicen siguiendo criterios objetivos y estén al alcance del conjunto de empleados de la organización.

La transformación, al adaptación al cambio, la aplicación de un nuevo enfoque, implica el abandono de un modelo, de una serie de prácticas, de una cierta manera de hacer las cosas.

No se trata de abandonarlo todo, no se trata de empezar de nuevo, sino de saber que el cambio solo viene a través del cambio y que, por tanto, no es posible alcanzarlo si en lugar de mirar adelante, no dejas de mirar atrás. Llévate en tu mochila todo tu conocimiento y experiencias y todo aquello que pienses que te puede resultar de utilidad en el viaje, pero ten en cuenta que su capacidad es limitada y que tendrás que renunciar o prescindir de prácticas o conductas antiguas para dar espacio a lo que viene a sustituirlas.

La agilidad requiere tener esa capacidad. En el proceso de adaptación al cambio tendrás que mirar dentro de ti, dentro de los proyectos en los que has participado y verás cosas que no te gustarán, de errores que cometiste y que te hacen ponerte las manos sobre la cara, debes entender que es parte del proceso y que nadie es infalible y debes comprender que han sido parte del camino que te ha llevado hasta aquí y que te han dado el suficiente conocimiento y madurez para ser mejor.

Algunos de los lectores habituales de este blog se preguntarán: “en un proyecto de desarrollo de software, ¿no tenemos que estar siempre atentos (alertas) a la necesidad de adaptarnos al cambio?, ¿no es la rápida capacidad de adaptación una ventaja competitiva?, ¿por qué haces un planteamiento tan rígido?”.

Por este motivo me he decido a darle una segunda parte al artículo publicado ayer.

Una organización siempre tiene que estar atenta a la oportunidad y a los movimientos del mercado. Llegar antes que los demás, si se aprovecha adecuadamente, te puede hacer ganar mucho dinero. Llegar un poco tarde te puede convertir en algo insignificante.

Esto es evidente y en nada contradice con lo comentado ayer. ¿Qué quise decir? Algo tan simple como que el desarrollo de software no hace milagros y que la agilidad es efectividad e intención. Una cosa es que un proceso tenga que cambiar para adaptarse a un nuevo contexto o para adelantarse o coger ventaja a la competencia y que eso pueda suceder en cualquier momento (cuando surge la oportunidad) y otra que tengamos que partir con unas condiciones que se sabe que no llevan a ningún sitio.

Para competir tienes que funcionar bien, si organizativamente eres un desastre difícilmente puedes competir con alguien, salvo que tengas un gran producto y/o unos grandes clientes (que en ningún caso van a ser eternos).

El software debe ir después de ese trabajo de reingeniería y a partir de ahí crecer (y cambiar, si es necesario) juntos. Si lo haces antes puede suponer una resistencia ya que tienes que repartir el enfoque entre los cambios organizativos y el desarrollo de software (perderá siempre el proyecto) y el coste será mayor.

Todas las medidas que supongan un obstáculo a la comunicación entre los componentes de un equipo de trabajo o entre equipos de trabajo diferentes suponen una resistencia importante al proyecto de desarrollo de software.

Se pueden establecer ciertas reglas orientadas a conseguir un mayor orden y una comunicación más eficiente pero es necesario evitar todas aquellas que creen entre personas y equipos que den lugar a que la comunicación sea mayoritariamente asíncrona (cuando no prácticamente inexistente) provocando un distanciamiento entre los equipos (no se trata de un hecho físico ya que pueden estar distanciados equipos que incluso trabajan en la misma sala), la aparición de antipatrones como: “Arrojar al otro lado del muro y que las funcionalidades se desarrollen o las decisiones se tomen sin contar con toda la información disponible lo que dará lugar a unos mayores costes debido al más que probable incremento del número de iteraciones necesarias para tener el producto.

A veces la comunicación se deteriora por conflictos entre personas o entre equipos que provocan que como medida de autodefensa se pongan como un escudo que dificulta o impide la comunicación. Por el bien del proyecto y de las personas que participan en él este tipo de situaciones hay que atajarlas cuanto antes y no dejarlas ir porque cuando se entra en enfrentamientos personales los mismos no terminan por arte de magia cuando acaba el proyecto.

También los gestores cuando no tienen una visión global tienen mucha que ver con el aislamiento de los equipos de trabajo.

Frederick Brooks en su libro “The Mythical Man Month” comenta lo siguiente: “Entonces, ¿cómo se comunicarán los equipos unos con otros? De tantas formas como sea posible”.

Los desarrolladores tenemos la costumbre de mirar las estructuras de nuestra organización como algo en lo que siempre hay demasiada gente, las cuales, por regla general, no sabemos muy bien qué es lo que hacen.

Buena parte de eso sucede cuando, entre otras razones, se exige al proyecto un margen que consideramos desproporcionado o cuando nos damos cuenta que el equipo de proyecto hubiera necesitado alguna persona más.

¿Quiere decir esto que el problema son las estructuras? Mi opinión es que no se puede echar la culpa a un concepto. Una estructura de entrada no tiene por qué ser buena o mala, son los resultados y lo que aportan lo que realmente les da valor o se los quita y eso va más allá de si la estructura es más o menos densa.

Mantener una estructura con muchas personas tiene un gran coste pero eso sería secundario si los beneficios cualitativos y cuantitativos que proporciona los compensa.

Si una organización funciona no solo es gracias al trabajo de los desarrolladores, de la misma forma que si fracasa tampoco es de manera exclusiva su responsabilidad. El éxito o el fracaso es la consecuencia del trabajo de muchas personas, no lo olvidemos, y eso es así aunque tu proyecto sea el que más beneficio y prestigio aporte a tu organización.

Tu reputación, tus alianzas, la búsqueda de la oportunidad y tu adaptación a los precios de mercado resultan fundamentales para ser competitivo en un ecosistema tan difícil como es el de los servicios de desarrollo de software o el de sus productos.

Una vez conseguido el contrato, si el mismo se encuentra dentro de unos parámetros razonables de alcance y precio, existirá probabilidad de conseguir beneficios si hay un buen entendimiento con el cliente, en el que se repartan responsabilidades y se conozcan las reglas del juego y si se es productivo (existen, todos los sabemos, infinidad de circunstancias que pueden complicar un proyecto, lo que he hecho es señalar un contexto que, de entrada, puede ser favorable).

Ser competitivo y poder sobrevivir de manera adecuada incluso en períodos de escasez requiere la adopción de una serie de medidas, una de ellas es evitar el despilfarro, entendiéndose éste como todo gasto totalmente innecesario y con bajas expectativas de retorno, siendo su gravedad proporcional al importe y a su posible carácter estructural.

Dentro del ámbito de un proyecto, el despilfarro (generalmente provocado por el cliente, pero en muchos casos alentado por el proveedor) se centrará en el desarrollo de funcionalidades innecesarias, en añadir complejidad adicional, en reinventar la rueda, en la pérdida de un ritmo de desarrollo y en la falta de intención. También lo podremos encontrar en procesos que no se adaptan a la naturaleza del producto a desarrollar y que provoca la generación de entregables sin utilidad real para el proyecto.

A más alto nivel, una organización despilfarra cuando contrata proyectos de desarrollo o productos que no necesita o para procesos que, por su inestabilidad, sería aconsejable esperar tiempos mejores. También se tira el dinero cuando se contratan servicios con un nivel de calidad o servicio superior al que se necesita, esto es equivalente a comprar mucha más comida de la que necesita y a llenar semanalmente el cubo de basura con todo lo que se ha echado a perder o llenar un almacén con más materia prima de la que se necesita incurriendo en los siguientes costes: gasto de almacenamiento y gasto por la materia prima adicional (que se puede deteriorar por el paso del tiempo).

Ese despilfarro se termina convirtiendo en estructural en el momento en que esos sistemas o productos se convierten con más o menos éxito en herramientas de trabajo, lo que obliga a seguir invirtiendo en ellos.

Este crecimiento sin orden y sin medida, basado en la suposición de que cada vez se va a tener más presupuesto, termina por colapsar en el momento en que se interrumpe ese flujo de dinero, que provocará que el mantenimiento y soporte para muchas de esas aplicaciones o productos sea precario o inexistente.

En períodos de abundancia parece que todo vale y nada importa, pero cuando las cosas no van bien, te acuerdas de cada céntimo de euro que has tirado o que tienes comprometido en proyectos, productos o servicios prescindibles. No se trata de mirar por el dinero exclusivamente cuando todo va mal, ya que lo mismo es demasiado tarde, sino de saber qué se está haciendo cuando se tiene éxito.

Decía Aristóteles que: “El cambio en todas las cosas es dulce”.

Es dulce si se asimila el cambio, si se entiende que es inevitable porque cada día el mundo sigue girando.

Si no se asimila y se entiende que la situación actual es la adecuada y no va a cambiar es cuando llegan los problemas. Tal vez la situación sea adecuada, confortable, positiva, dulce incluso, y es bueno disfrutarla y sacarle todo el provecho posible, pero se debe estar dispuesto y, sobre todo, preparado, para el cambio.

La tecnología está en continua evolución, las personas también. Las organizaciones deben ser conscientes de eso, quien antes era un competidor insignificante tal vez sea hoy quien te esté quitando el mercado y lo peor no es eso, cada día surge nueva competencia más adaptada al contexto actual.

Los sistemas de información no son ajenos a los cambios, teniendo en cuenta que soportan procesos organizativos y que estos se van a ir modificando. El software tiene sentido si existe un usuario, si el usuario y/o su contexto, cambia, evoluciona y sabemos que es una característica inherente, podemos decir que la necesidad de cambio es también inherente al software.

En ocasiones se tienen expectativas demasiado altas de lo que una aplicación puede conseguir.

Se cree que, invirtiendo el dinero suficiente (que generalmente será menos del que realmente se necesita) se conseguirá tener una aplicación que, de un plumazo, te resuelva todos los problemas: que consiga integrar toda la información y que además, ésta sea de calidad, que resuelva los problemas organizativos y que permita incrementar la productividad en términos exponenciales.

El error se encuentra en varios puntos:

– El software lo hace inteligente las personas y para ello se tiene que acertar en las especificaciones de lo que se tiene que hacer. Todos sabemos que eso es complicado y que se requiere, generalmente, un enfoque iterativo incremental para conseguir, a través del feedback, ir acercándonos progresivamente a una solución deseable.

El recorrido puede ser más o menos largo y en medio pueden existir problemas, tales como un desgaste en las relaciones entre desarrolladores y responsables funcionales, que el presupuesto se agote, que el responsable funcional cambie y con él el enfoque que se le estaba dando al sistema, que cambien las prioridades de la organización, etc…

– La calidad de los datos es el resultado del trabajo que hacen las personas con la aplicación. Puedes desarrollar validadores, implementar mil restricciones, que al final siempre quedará todo en manos de los usuarios. Por tanto, se trata de un problema de carácter organizativo que el software puede ayudar a controlar/gestionar pero no se podrá ir mucho más lejos de ahí.

Hacer el software muy restrictivo, en ocasiones, no se ajusta a la realidad de funcionamiento de la organización, que requiere, precisamente, una mayor flexibilidad, a la vez que hace más complejo el software. Cuántas veces nos hemos encontrado, por ejemplo, con aplicaciones con infinidad de perfiles que hacen su administración y mantenimiento más engorroso, cuando en realidad, todo se hubiera resuelto con muchos menos.

– Si la organización no funciona, si cada departamento quiere funcionar de manera autónoma, sin una visión global, ¿qué se pretende que solucione el software?. Esta situación empeora cuando ese comportamiento lo tenemos en organizaciones con múltiples sedes dispersas geográficamente.

Si las personas no hacen un esfuerzo por solucionar este problema, ¿se pretende que sea una aplicación la que lo resuelva?.

Para Peter Drucker: “No hay nada tan inútil como hacer eficientemente algo que no debería haberse hecho”.

El desperdicio de esfuerzo, en muchas ocasiones, tal vez la mayoría, realizado con la mejor de la intenciones, hace mucho daño a los proyectos de desarrollo de software.

Querer avanzar demasiado deprisa, desarrollando nuevas funcionalidades cuando hay otras que todavía no están maduras y que dependen entre sí, querer abarcar más de lo que se puede, trabajar con demasiadas hipótesis no validadas. Todo ello es susceptible y, de manera muy probable, de generar desperdicio.

Y no se trata de falta de interés, esfuerzo o competencia, sino de no saber administrar adecuadamente los tiempos, de no priorizar bien y de no saber decir que no.