Básicamente se define productividad como la relación entre la producción obtenida (servicios, productos, ..) y los recursos empleados en la producción (materiales, personal, tiempo, etc.).
Lamentablemente, en muchas ocasiones se asocia mentalmente “productividad”, a “lo que produce cada empleado”, es decir, “lo que se obtiene de cada sueldo” por lo que la forma de aumentar la productividad es que los empleados “trabajen mucho y cobren poco”. Aunque eso desde luego reduzca los costes, es tan erróneo como plantear que “se aumentará la productividad si no se compran ordenadores”, ya que “reducimos los costes” o que “el reparto se haga andando, para evitar la compra y mantenimiento de vehículos”.
Creo que en ámbito de las TI (como casi en cualquier otro sector por otra parte) los elementos más importantes para mejorar la productividad son la organización y la documentación. Desde luego también es importante el contar con buenos profesionales y con buenos instrumentos (tal como he argumentado anteriormente [La "barrera del sonido"]y[El altísimo coste del “ahorro” en ordenadores y equipamiento], aunque no dentro del enfoque de la productividad).
Sin embargo el mejor técnico y el mejor ordenador son casi inútiles en una entorno de trabajo desorganizado e ”indocumentado”, y lamentablemente eso es algo demasiado habitual.
Algunos ejemplos
Quizá el ejemplo más claro que conozco de cómo mejorar la productividad es este:
Un banco de alimentos creado tras unas inundaciones en Nueva York, organizado por una persona de buena voluntad y con mano de obra voluntaria mejoró espectacularmente su productividad (cantidad de lotes de comida repartida) simplemente organizando mejor su trabajo y con unos mínimos costes.
Por otra parte, en el aspecto negativo, hay muchos ejemplos de tiempo perdido por falta de organización o documentación.
Por ejemplo:
- ¿Quién no ha tenido que rehacer un proyecto porque, tras estar parcial o incluso totalmente desarrollado, un área con la que no se ha contado introduce nuevo requisitos o vetos debido a que no se cumple ciertas características? Si el proceso de definición de un nuevo proyecto (con todos sus intervinientes y momentos de intervención) estuviera definido, no se produciría esta pérdida. Todo esto es un coste evidente que afecta negativamente a la productividad Ya que el resultado obtenido puede haber costado en ocasiones el doble de lo que costaría con un circuito bien definido.
- ¿Quién no ha sufrido retrasos debido a que no está especificado quien debe aprobar/revisar/arreglar/instalar algún elemento? En ocasiones todo un equipo implicado en un proyecto tiene que esperar a que se confirme (o improvise) un circuito. De nuevo, son muchas horas perdidas debido a esta carencia. Incluso aunque el equipo implicado pueda ocuparse en otras tareas, siempre hay un tiempo empleado en la búsqueda, hay una pérdida de tiempo hasta que se decide que ”no se sabe” y sobre todo, de oportunidad al no cumplirse plazos.
- Otro ejemplo habitual es la no disponibilidad de un ordenador cuando se incorpora un empleado. Estos retrasos pueden llegar a ser de 1 mes, y es evidente que, dado que es necesario un preaviso en su empresa por parte del futuro empleado, preparar el nuevo contrato en la empresa contratante, etc. se dispone de al menos 15 días desde que se sabe que se va a contratar a una persona concreta para un puesto concreto. Un circuito bien organizado puede asegurar que todo el equipo y elementos necesarios estén disponibles. De nuevo es un problema organizativo que, de no estar bien estructurado, es muy costoso.
Realmente no es tan difícil y merece la pena
Todos estos escenarios representan costes que hacen que la productividad (recordemos, producto obtenido frente a costes/recursos aportados) se reduzca y que con un mínimo de organización pueden minimizarse. Puede argumentarse que es difícil calcular los costes, pero no lo es tanto.
Por ejemplo que un nuevo empleado esté 2 semanas sin ordenador (es decir unas 80h improductivas), asumiendo un salario de solo 24.000€, lo que implica unos costes de unos 20€/h, equivale a 1600€. En el caso de un proyecto que hay que modificar o retrasar, desde luego es más difícil, pero puede hacerse una estimación de riesgos (al igual que las compañías de seguros con los accidentes) teniendo en cuenta el coste total del proyecto y la probabilidad de cambio (que puede afirmarse que es casi “inversamente proporcional a la calidad de la organización”).
En cuanto a la documentación, suele estar igualmente “olvidada”. La documentación, en el mejor de los casos está en una herramienta de colaboración, y en la mayoría, en una carpeta de red o incluso en los equipos personales. No es demasiado habitual que esté en un gestor documental, que como su nombre indica, es la herramienta adecuada para gestionar documentos. Parece ridículo tener que recordarlo, pero lamentablemente pocas empresas tiene su documentación en un gestor documental.
El resultado es que se emplea mucho tiempo buscando documentación (o bien porque puede estar en múltiples localizaciones, o bien porque no puede localizarse al estar incorrectamente catalogada y clasificada, con los metadatos adecuados o no está clara la última versión.
Todo ello conlleva pérdidas de tiempo, y en el peor de los casos, toma de decisiones incorrectas al basarse en documentación obsoleta, por ejemplo asumir comportamientos de versiones anteriores, o funcionamiento bajo versiones de infraestructura (Sistema Operativo, base de datos, versiones de java, servidores Web o J2EE,..) obsoletas o fuera de soporte.
Mención aparte merece la “calidad” de la documentación, independientemente del lugar en que se almacene o la corrección de su catalogación. Aunque cada vez es menos frecuente, sigue siendo bastante habitual que el “becario” o alguien “que pasa por allí”, se encargue de la documentación de muchos proyectos tecnológicos. Como consecuencia, esa documentación en muchas ocasiones simplemente detalla lo que hace la aplicación (cosa que por otra parte puede verse viéndola trabajar) y los componentes que tiene (lo que puede verse revisando el código fuente y el paquete de instalación) pero no explica realmente el funcionamiento interno, o porqué se han tomado ciertas decisiones. Es decir la información realmente importante y que conocen los perfiles más implicados en el desarrollo y con más experiencia.
Al final la productividad en muchos casos se reduce a la mitad (y no es exageración, he visto proyectos que han duplicado la carga de trabajo prevista, debido a problemas como los anteriores), algo que podría evitarse simplemente con mejor organización y documentación.
