Published 17 years ago
(updated 14 years ago)
Estrategias de Implantación
Premio Nuevo León a la Calidad
El mes pasado SOFTTEK ganó el premio Nuevo León de Calidad. Esta es la primera vez que una empresa de software gana este premio. Me parece que a veces estamos dando mucha importancia a certificaciones estadounidenses con la finalidad de incrementar nuestras exportaciones pero tal vez estamos menospreciando recursos muy importantes que tenemos en nuestro país.
El Premio Nuevo León de Calidad que se hace disponible en todos los estados de la República y la norma MoProSoft, son opciones que tenemos en nuestro país para establecer márgenes de mejora continua en nuestra industria de software.
Mi experiencia es que estos modelos, aunque no todos están totalmente enfocados al desarrollo de software (MoProsoft sí está ligada directamente al software), se adaptan bastante bien a las ideas de manejo de procesos, toma de decisiones en base a métricas y mejora continua que son la base de todo modelo de calidad, adicionalmente las normas mexicanas tienden a ser más amplias a diferencia de CMMI. MoProSoft abarca no sólo el desarrollo de Software en sí, sino también temas complementarios como la planeación estratégica y prácticas de ecosistema de la organización. Creo que como industria de software deberíamos investigar más sobre estas normas y buscar como pueden apoyar a nuestras estrategias de calidad.
Estrategias de implantación
La semana pasada mientras realizaba una presentación, volvió a surgir la duda de si es mejor hacer implantaciones proyecto por proyecto, o si es mejor implementar prácticas individuales en toda la organización (lo que en métodos numéricos se le conoce como “Depth First o Breath First”).
Lo que yo veo en la industria del software en México es que tenemos comprada la idea de que lo más importante es implementar a profundidad un concepto en un proyecto para después pasar al siguiente. En mi opinión esta es la razón principal por la que los proyectos de implementación fallan. Implementar a profundidad sólo funciona en organizaciones pequeñas, ya que ésta puede hacerse rápido en todos los proyectos, pero en una organización mayor a esto es un fracaso.
Por ejemplo, supongamos que implementamos un modelo para estimar el costo de cambios dentro de los proyectos. Usualmente lo que se hace es tomar los proyectos que tienen la mayor cantidad de problemas con el crecimiento de número de requerimientos y se asigna el proyecto a la persona que tiene más experiencia en estimar para que haga lo necesario para cambiar la forma en la que se está estimando el cambio. Esta persona maneja la resistencia al cambio, el entendimiento de la problemática del cliente en especifico, y seguramente después de algo de trabajo se logrará arreglar la situación con ese primer proyecto y estaremos listos para continuar al siguiente.
Desafortunadamente, los demás líderes de proyecto se sienten atacados por el éxito descrito anteriormente, y se dedican a argumentar que su proyecto es muy diferente y por lo tanto estas prácticas no son aplicables a su proyecto.
Mientras esto sucede, nuestro proyecto inicial termina y nuestro experto en estimación es reasignado como analista en un proyecto dirigido por otra persona, por lo que ya no tiene el control, y tampoco tiene la habilidad de convencer al líder actual de cómo manejar la estimación. Esto hace que se pierda el trabajo y finalmente lo que tenemos es a un experto constantemente asignándose a proyectos en problemas y tratando de sacar adelante la situación.
La otra forma de implementar esto mismo sería: generar un curso del nuevo modelo de estimación, y entrenar a todos los líderes de proyecto. Después se auditan los proyectos para evaluar quien implementó qué, y se crea una estrategia en donde el experto en estimación salta de proyecto en proyecto asesorando a los líderes para que cada vez apliquen mejor el proceso de estimación.
Como primer paso, logramos que todos entiendan que la estimación se logra en base a definir tamaños de los productos, que entiendan cómo calcular líneas de código o puntos funcionales en sus proyectos. Después que entiendan como pasar de líneas funcionales a horas, y así sucesivamente.
Esta estrategia ofrece las siguientes ventajas:
1. Nuestro experto en estimación invierte un tiempo muy parecido al anterior, pero ahora ayudando y convenciendo más que haciendo él mismo.
2. Permite que la responsabilidad de la estimación recaiga en donde tienen que recaer, el líder del proyecto.
3. No se esta detrás de los problemas todo el tiempo. Cuando un líder sale de un proyecto y pasa a otro, el otro líder está más o menos en el mismo nivel que estaba él en su proyecto, por lo que permite que hablen el mismo idioma y que pueda aplicar lo que aprendió en su proyecto anterior para mejorar el nuevo proyecto.
A final de cuentas vamos pasando de un modelo reactivo a un modelo pasivo. ¿Qué nos acerca mas a nuestro objetivo?.
Premio Nuevo León a la Calidad
El mes pasado SOFTTEK ganó el premio Nuevo León de Calidad. Esta es la primera vez que una empresa de software gana este premio. Me parece que a veces estamos dando mucha importancia a certificaciones estadounidenses con la finalidad de incrementar nuestras exportaciones pero tal vez estamos menospreciando recursos muy importantes que tenemos en nuestro país.
El Premio Nuevo León de Calidad que se hace disponible en todos los estados de la República y la norma MoProSoft, son opciones que tenemos en nuestro país para establecer márgenes de mejora continua en nuestra industria de software.
Mi experiencia es que estos modelos, aunque no todos están totalmente enfocados al desarrollo de software (MoProsoft sí está ligada directamente al software), se adaptan bastante bien a las ideas de manejo de procesos, toma de decisiones en base a métricas y mejora continua que son la base de todo modelo de calidad, adicionalmente las normas mexicanas tienden a ser más amplias a diferencia de CMMI. MoProSoft abarca no sólo el desarrollo de Software en sí, sino también temas complementarios como la planeación estratégica y prácticas de ecosistema de la organización. Creo que como industria de software deberíamos investigar más sobre estas normas y buscar como pueden apoyar a nuestras estrategias de calidad.
Estrategias de implantación
La semana pasada mientras realizaba una presentación, volvió a surgir la duda de si es mejor hacer implantaciones proyecto por proyecto, o si es mejor implementar prácticas individuales en toda la organización (lo que en métodos numéricos se le conoce como “Depth First o Breath First”).
Lo que yo veo en la industria del software en México es que tenemos comprada la idea de que lo más importante es implementar a profundidad un concepto en un proyecto para después pasar al siguiente. En mi opinión esta es la razón principal por la que los proyectos de implementación fallan. Implementar a profundidad sólo funciona en organizaciones pequeñas, ya que ésta puede hacerse rápido en todos los proyectos, pero en una organización mayor a esto es un fracaso.
Por ejemplo, supongamos que implementamos un modelo para estimar el costo de cambios dentro de los proyectos. Usualmente lo que se hace es tomar los proyectos que tienen la mayor cantidad de problemas con el crecimiento de número de requerimientos y se asigna el proyecto a la persona que tiene más experiencia en estimar para que haga lo necesario para cambiar la forma en la que se está estimando el cambio. Esta persona maneja la resistencia al cambio, el entendimiento de la problemática del cliente en especifico, y seguramente después de algo de trabajo se logrará arreglar la situación con ese primer proyecto y estaremos listos para continuar al siguiente.
Desafortunadamente, los demás líderes de proyecto se sienten atacados por el éxito descrito anteriormente, y se dedican a argumentar que su proyecto es muy diferente y por lo tanto estas prácticas no son aplicables a su proyecto.
Mientras esto sucede, nuestro proyecto inicial termina y nuestro experto en estimación es reasignado como analista en un proyecto dirigido por otra persona, por lo que ya no tiene el control, y tampoco tiene la habilidad de convencer al líder actual de cómo manejar la estimación. Esto hace que se pierda el trabajo y finalmente lo que tenemos es a un experto constantemente asignándose a proyectos en problemas y tratando de sacar adelante la situación.
La otra forma de implementar esto mismo sería: generar un curso del nuevo modelo de estimación, y entrenar a todos los líderes de proyecto. Después se auditan los proyectos para evaluar quien implementó qué, y se crea una estrategia en donde el experto en estimación salta de proyecto en proyecto asesorando a los líderes para que cada vez apliquen mejor el proceso de estimación.
Como primer paso, logramos que todos entiendan que la estimación se logra en base a definir tamaños de los productos, que entiendan cómo calcular líneas de código o puntos funcionales en sus proyectos. Después que entiendan como pasar de líneas funcionales a horas, y así sucesivamente.
Esta estrategia ofrece las siguientes ventajas:
1. Nuestro experto en estimación invierte un tiempo muy parecido al anterior, pero ahora ayudando y convenciendo más que haciendo él mismo.
2. Permite que la responsabilidad de la estimación recaiga en donde tienen que recaer, el líder del proyecto.
3. No se esta detrás de los problemas todo el tiempo. Cuando un líder sale de un proyecto y pasa a otro, el otro líder está más o menos en el mismo nivel que estaba él en su proyecto, por lo que permite que hablen el mismo idioma y que pueda aplicar lo que aprendió en su proyecto anterior para mejorar el nuevo proyecto.
A final de cuentas vamos pasando de un modelo reactivo a un modelo pasivo. ¿Qué nos acerca mas a nuestro objetivo?.
- Log in to post comments