El proceso a seguir.

El proceso a seguir. Problemas en la definición de procesos.

por Luis R. Cuellar el 25 de septiembre de 2007

Visitas: 61

Calificación promedio: (0 voto)

En nuestra charla anterior hablamos sobre el significado de crear una organización orientada a procesos con el objetivo de generar resultados repetibles en forma eficaz y eficiente, facilitar la comunicación y generar un “framework” para administrar el conocimiento. Esto suena muy bien, pero si es tan buena idea, ¿por qué no se hace en todas las compañías? Esto se debe a problemas tanto de definición como de implantación. En esta ocasión hablaremos de los problemas de definición y en nuestra siguiente charla hablaremos de problemas de implantación.

El Proceso Perfecto

Un elemento que he encontrado en forma consistente en el área de sistemas, es lo mucho que nos maravilla definir procesos, y a su vez la gran falta de entusiasmo para operar los mismos. El mercado está lleno de consultores, libros, maestros y “jefes” de corazón, vendiendo la solución a todos nuestros problemas. Esto sugiere la idea de que existe un conocimiento mágico, un proceso perfecto o una única solución al problema de desarrollo de software. Creo que esta por demás decir que este proceso, ¡NO EXISTE!

En los últimos años he apoyado a varias organizaciones a alcanzar niveles de CMM y Seis Sigma. Una estrategia que he visto comúnmente es la de juntar a los grandes expertos de la organización para definir la metodología perfecta que servirá de guía sobre lo que tienen que hacer todos los demás. Esta estrategia tiene tres riesgos importantes:

1. Existen pocos incentivos a escuchar lo que actualmente sucede en los proyectos. La premisa de estos grupos acostumbra ser: “Todo lo que hacemos actualmente está mal y tenemos que definir algo nuevo para arreglar todos nuestros problemas”. Lo ideal es iniciar con aquello que actualmente funciona, asegurar que entrenamos a toda la organización para hacer el trabajo de la misma manera, y sólo cuando no estamos haciendo algo para controlar una práctica clave debemos definir algo nuevo. En la práctica, el problema de definir un proceso es diez por ciento del problema de implantarlo, por lo que si ya existe y se conoce es mejor sólo documentarlo.

2. Los nuevos procesos ya no se mejoran posteriormente. Después de todo, ¿quién puede mejorar el proceso si los mejores ya lo definieron? Desafortunadamente el proceso perfecto no existe, una de los características básicas de la definición debe de ser su facilidad de modificarse. Desde la definición se debe de estar consciente de la importancia de definir algo flexible y fácil de modificar, que se adecue a la problemática actual y futura.

3. La definición se tarda meses y después ya nadie tiene tiempo de implantar los procesos en la organización. El que define debe continuar con la implantación. Si la dirección define, es porque ellos van a implantar. Sino, entonces no deberían estar definiendo.

Otra estrategia es la de comprar un proceso en el mercado e implantarlo en la organización. En este caso es vital contemplar cómo se capacitará o modificará el proceso una vez que el consultor termine su trabajo.

En este punto permítanme ser lo más claro posible: NO EXISTE EL PROCESO PERFECTO. Muchas veces es mejor implantar un proceso que toda la organización esté dispuesta a seguir, en lugar de uno que un consultor diga que es el mejor proceso jamás generado. En el momento en que estamos cambiando a una organización orientada a procesos, estamos trabajando con la idea de que estos procesos son dinámicos, por lo que se requiere gente encargada de mantenerlos actualizados constantemente y entrenando a los equipos de trabajo en forma constante.

BestPractices

Personalmente siento que el término “BestPractice”, es uno de los grandes frenos de la industria de software. Creado con finalidad de mercadeo, el término lleva consigo la idea de una “solución mágica” que resuelve tus problemas; que de todas las soluciones que existen en el mundo, es la mejor. Sin embargo, todas las prácticas tienen un valor con respecto a su contexto. Una práctica que fue exitosa en un ambiente abierto y con pocas restricciones puede ser inoperable en una organización con fuertes niveles de control. Desafortunadamente, cuando queremos definir nuestros procesos, todas estas grandes prácticas se atraviesan en nuestro camino generando dudas, ya que queremos que lo que definamos suene impactante cuando lo presentemos a nuestros clientes y empleados.

Conclusión

Lo que busco decirles con todo esto es: no existe un proceso perfecto; no existe la solución mágica que sólo tengan que copiar y obligar a su gente a seguir. El mejor proceso que podemos definir es uno que sea sencillo de aprender, operar y fácil de mejorar, que controle de alguna manera el trabajo que hacen actualmente, y que las personas estén dispuestas a implantar ellos mismos en sus proyectos. La próxima ocasión platicaremos sobre la implantación de los procesos, sus problemáticas y cómo beneficiarse al máximo de la estrategia de implantación.

Acerca del autor

Luis R. Cuellar es Director de Calidad a nivel mundial de SofttekInformation Services. Luis esreconocidopor la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

BPM. Desde la Perspectiva de un Desarrollador.

por Ernesto Méndez Solís el 21 de noviembre de 2007

Visitas: 2228

Calificación promedio: (0 voto)

Como consultor en el desarrollo de software, es muy común ser asignado a proyectos en los que participan consultores de otras empresas formando de esta manera equipos de trabajo interdisciplinarios y multiempresa; unos se encargan de la administración y metodología del proyecto, otros más del análisis, diseño, modelación, desarrollo, documentación y pruebas, por mencionar solo algunas de las diferentes tareas involucradas. Fue de esta manera que fui asignado a participar en un proyecto en el que había que automatizar el flujo de un proceso administrativo de una empresa dedicada a la comercialización, industria perteneciente al sector conocido como retail.

Así que me integré al equipo, que estaba conformado por tres diferentes empresas y fui asignado a la fase de desarrollo. Solo requería tener conocimientos básicos de programación orientada a objetos

...