Cultura de cumplimiento
En la cultura del cumplimiento, se confunde el medio con el fin y se olvida que el objetivo del proyecto es conseguir unos buenos resultados.
por Juan Palacio, 28 agosto 06
Dar prioridad “1” a los procesos, en las empresas que la deberían dar a las personas, crea “culturas de cumplimiento” que truecan los medios por los fines; y hace que, inexplicablemente y aunque trabajen bien… seguramente por la mala suerte, o por la competencia, o por la coyuntura o por causas contra las que es imposible luchar, los resultados no acompañen.
Cuando los resultados dependen de la capacidad de las personas y se actúa mirando sólo a los procesos, se crean ecosistemas que camuflan la ineficiencia, porque por mimetismo copian para entornos de conocimiento un principio de calidad válido para entornos industriales:
“La calidad obtenida es el resultado de la calidad de los procesos empleados”
La causa de la calidad de la arquitectura de un sistema (por ejemplo) no hay que buscarla tanto en el proceso o en las herramientas empleadas, como en las neuronas de sus autores.
Por ejemplo, en la gestión de proyectos, la base de conocimiento disponible ofrece a los gestores técnicas y herramientas para ayudarles a ordenar y estructurar las ideas; registrar, consultar y analizar la información:
- Diagramas de Gantt
- Ruta crítica
- Plan de comunicación
- Plan de riesgos
- Plan de calidad
- Plan de recursos
- Matriz de responsabilidades
- Actas de reuniones
- Etc.
Pero esto son las herramientas, y no su trabajo.
La misión del gestor no es: hacer el gantt, el presupuesto, el plan de comunicación, el plan de riesgos, moderar las reuniones…
Cuando esto pasa a ser el trabajo de su cargo; se termina por considerar que quien hace las obligaciones de su puesto, hace su trabajo.
De esta forma hay ingenieros, consultores o gestores que realizan perfectamente su labor, pero… tienen mala suerte y los resultados no les acompañan.
Los directivos son los responsables de la cultura de la organización, y los más indicados para evitar la “cultura del cumplimiento” en actividades para las que el “cumplimiento” no garantiza los resultados, y hace olvidar que el fin de un diseño, de un plan, de una gestión… no es realizarlos según las normas, sino ayudar al ingeniero o al gestor a concebir el mejor plan, diseño o gestión (según los casos).
Si la herramienta es el fin, y los procesos los responsables de los resultados, da igual que las personas sean más o menos aptas o ineptas. Serán estupendos trabajadores si cumplen con su jornada laboral, o mejor aún, si la exceden y “cumplen con el trabajo de su puesto”.
29 agosto 2006, 00:42
Como siempre magnificos los articulos de Juan Palacio, totalmente de acuerdo, se hechaban de menos los articulos por aqui, el veranito que hace estragos supongo…
Como bien dices el seguimiento de unos procesos no es garantia de calidad del software entregado, es necesario sazonar el proceso con talento en cada una de sus fases, y esto lo más de dificil de conseguir y también de medir.
Sin embargo tampoco hay que dejar de lado los procesos, en mi opinión sirven para encauzar el talento y establecer el marco de trabajo necesario, son por tanto condición necesaria pero desde luego no suficiente. En estos contextos tan malos son unos procesos fuertemente restrictivos que ahogen el talento bajo montones de burocracia como unos procesos inexistentes que permitan que el talento se diluya en el caos.
Otro problema que he visto varias veces, y estoy actualmente sufriendo en mis carnes, es el error de enfoque a la hora de medir la calidad de los procesos. Los gestores saben de gestión y miden parametros relacionados con la gestión, cosas como riesgos, recursos, ajuste al plan, planes de prueba incluso, pero sólo llegan a este punto, ¿quien mide los parametros de calidad del sofware que los gestores no entienden?, cosas como, calidad y cantidad de prueba unitarias, ajustes del código a los estándares, calidad del diseño, calidad de la arquitectura, extensibilidad, escalabilidad….
Esto al menos es lo que yo estoy viviendo ultimamente, donde los planes de calidad de la empresa no contemplan ninguno de estos factores. Factores que en muchas casos no se puden medir de forma objetiva y de nuevo requieren talento y expertos en ese area. Me hace gracia que mi jefe me oblige a confeccionar documentos absurdos en lugar de dedicar ese tiempo a refactorizar mi código y hacer más pruebas unitarias, algo que sin duda tendría un efecto considerablemente mayor sobre la calidad del producto final. Es una pena que la mayoría de los gestores de empresas de soft no sepan que es lo tienen entre manos…
PD: perdon por la parrafada, es que el tema de la calidad ultmamente me tiene un poco de los nervios jeje.