Una vez, un director de empresa me dijo que su producto de software estrella se estaba quedando rezagado:

• Tenía varias funciones, pero estaban especializadas en un nicho del mercado.
• No podía ofrecerlo a nuevos clientes u otros giros.
• No tenían a un encargado, que pudiese identificar nuevas tendencias y necesidades para incorporarlas.

Además, estaban retrasados en el mantenimiento correctivo de varias cosas. Entre otras dificultades de gestión de la configuración, de las que no hablaré el día de hoy.

Varias organizaciones, que desarrollan software para terceros o internamente, enfrentan esta dificultad: la brecha tecnológica (aprovechar al máximo la tecnología) se ensancha en lugar de cerrarse. Por esta razón, todas pierden oportunidades de negocio, pues no pueden vender un producto nuevo o sus operaciones internas se ralentizan porque la tecnología no está ahí para apoyarlas.

A continuación te presento algunas de las razones por las que las organizaciones de software pierden oportunidades de negocio.

Sistema ocupado el 100% del tiempo

Muchos hablan de la productividad y cómo aumentarla. El sueño de muchos managers es alcanzar el 100% de la ocupación del equipo, que no haya tiempos muertos y que básicamente todos estén trabajando en horario continuo, sin pausa.

Piensa por un momento: si dedicas todo tu tiempo y concentración a una sola tarea, durante una jornada prolongada, ¿qué sucede con el resto de las actividades? La respuesta es que se quedan esperando hasta que tengas oportunidad de atenderlas.

Los equipos y personas asignados en 100% de su tiempo a actividades planificadas padecerán en estas situaciones:

• En el caso de atender algo urgentemente, tendrán que interrumpir y retrasar el plan
• Las actividades no prioritarias (innovación, investigación) serán relegadas hasta que exista un poco de tiempo
• Intercambiar integrantes entre equipos también causará efectos graves en el plan y retrasos en varias actividades

Lo ideal siempre es buscar un porcentaje de desasignación, que los equipos podrán usar en estas circunstancias.

El principio de Peter

En empresas que se organizan jerárquicamente, las personas solo pueden acceder a sueldos y prestaciones mejores si ascienden en la estructura. Es aquí cuando ocurre lo que formuló Laurence J. Peter: ascenderán al puesto donde alcanzarán su máximo nivel de incompetencia.

Muchos desarrolladores brillantes son ascendidos a puestos de liderazgo y gerencia, como un reconocimiento a sus habilidades (y porque es la única forma de pagarles más), pero en lugar de ganar un buen líder de equipo, pierdes un buen desarrollador. En esta posición, tiene nuevas responsabilidades para las cuales no está calificado y su desempeño será menor.

En otra ocasión, un gerente me dijo que no entendía por qué sus nuevos analistas no eran capaces de adelantarse a las necesidades del cliente, si eran muy buenos desarrolladores. Mi respuesta fue: por el Principio de Peter.

La ley de Parkinson

Existe una práctica muy difundida: estimar un calendario de trabajo y agregarle holgura (en México, lo llamamos “colchón”), esperando terminar en tiempo y usar el tiempo restante en caso de necesidad. El trabajo, en la mayoría de los casos, seguirá la ley de Parkinson y se expandirá hasta llenar todo el tiempo disponible, a veces excediéndolo. Cuando esto sucede, los niveles de asignación de las personas empiezan a aumentar hasta alcanzar el 100%, pues lo que se quiere es cumplir con el deadline (o sufrir una penalización menor). A veces, empezarán a asignar más personas al proyecto con tal de acabarlo, y les sucederá la Ley de Brooks, de la que hablaré después.

Ciclos de retroalimentación muy largos

La mejor retroalimentación siempre será la del cliente y el usuario utilizando el producto de software. Por lo tanto, mientras más pronto la obtengamos, más pronto podremos incorporar mejoras o saber necesidades nuevas.

Muchos equipos de software, por su forma de trabajo, toman mucho tiempo para obtener esta retroalimentación. Algunos creen que lo están haciendo bien porque están validando elementos intermedios (documentos, imágenes, demostraciones de funcionalidad parcial), pero reitero: la mejor retroalimentación será la del cliente y el usuario usando el producto. Cualquier cosa que no sea el software final no provee una validación muy útil.

Comunidades que no comparten el conocimiento

Yo estoy convencido que la información y el conocimiento deben de difundirse. Muchas organizaciones creen algo diferente y esto causa que lo que saben se queda solamente con un grupo pequeño de personas. Muchas soluciones, problemas, y otros datos importantes que pueden ayudarle a compañeros de trabajo, otras unidades, y a la organización completa se guardan en secreto.

Cuando las organizaciones no generan una cultura de compartir la información todas las oportunidades importantes que se encuentran allí son desperdiciadas.

¿Qué hacer?

Hay muchas tareas por realizar para esta situación: las que están relacionadas con el uso del tiempo, la estructura organizacional, las prácticas de ingeniería y de administración. No será lo más sencillo de lograr porque hay mucho que hacer.

Yo me enfocaría primero en el uso de la información. La formación y promoción de las comunidades de práctica ayudará a que las ideas fluyen libremente en la organización. El conocimiento compartido ayuda a crecer, si dejamos que las personas digan lo que piensan y aporten sus ideas encontraremos seguramente varias oportunidades allí que podremos aprovechar y hacer nuevos negocios y productos con ellos.

¡Hasta la siguiente entrega!