Últimamente he estado trabajando en la revisión de un algoritmo de coste que utilizamos para valorar el esfuerzo del desarrollo sobre una nueva arquitectura. Precisamente por estar en un nivel de madurez inicial dicha arquitectura, se hace indispensable la revisión periódica y el ajuste si es necesario.

Nos gusta disponer de un modelo algorítmico con el que realizar valoraciones rápidas del trabajo del equipo. Es un golpe de efecto sobre los Jefes de Proyecto que aparecen por la línea pidiéndonos aproximaciones sobre nuestra participación en un proyecto en las fases inciales.

Bien a lo que iba. Poder disponer de un modelo de este tipo, calibrado bajo control estadístico y la mejora continua, no sólo es una herramienta eficaz para la planificación de proyectos. A veces olvidamos  que ese modelo también sirve como estándar del rendimiento del equipo.

Hoy mismo hemos acabado de revisar los datos de seis meses de trabajo y hemos conseguido mediante regresión, añadir al modelo el último tipo de tarea de desarrollo que no estaba contemplada en el algoritmo. Índice de correlación del 0,85. Creo que tendrá precisión suficiente.

Pero esa ecuación lineal que hoy hemos inferido a partir de nuestros datos estadísticos, no solo nos ayuda a ser más rápidos calculando nuestro costes, sino que también es un indicador de rendimiento del equipo. La ecuación ha sido modelada a partir de las estimaciones  y los esfuerzos reales que hemos dedicado a ese tipo de tareas.  Si el modelo predice “10 horas” para unas variables determinadas, esa predicción se ajusta al rendimiento que hemos llegado durante esos seis meses en este tipo de tareas de desarrollo– más menos dos desviaciones estándar que para este modelo es “1 hora” – . Si el esfuerzo real llega a ser “8 horas” para esa predicción, es que estamos siendo más eficaces que durante esos seis meses. Si, por el contrario, el esfuerzo real fueran “12 horas”, seria que estamos rindiendo por debajo de lo habitual. Algo ocurre y seguramente merece ser estudiado.

El control estadístico de procesos es una herramienta increíble para un Line Manager. Le permite saber cual es el significado de tener un equipo “en plena forma física”, “por debajo del rendimiento óptimo” o “sobreentrenado”.

Parece que la afición por el deporte invade mis pensamientos. ¡Vaya!

No lo creo. Creo que la eficiencia en desarrollo de software va más ligada al valor que aporta ese software al negocio. Es decir, al retorno de la inversión que obtenemos al desplegar ese software en producción. Entonces, ¿qué modelos de gestión de Sistemas de Información habilitan ese punto óptimo en el que cada despliegue de software es valor añadido al negocio y no un simple coste más?, ¿aquellos en los que se da un uso táctico a los SI, y en los que se minimizan los costes derivados de su construcción y mantenimiento, o aquellos modelos en los que se incorpora los SI como parte de la ingeniería estratégica de la empresa y como una unidad de negocio más que debe contribuir a los beneficios?.

Si la visión estratégica de la compañía contempla los conceptos de agilidad y capacidad de respuesta al mercado como su “raison d’être”, ¿no será más adecuado alinear el modelo de gestión de lo SI a esos conceptos como máxima prioridad, que hacerlo con el control del gasto y la reducción de costes?

El software no es una commodity. La tecnología como arma estratégica puede ser una ventaja competitiva demoledora. Una evolución de arquitectura técnica o un avance tecnológico mal enfocado, pueden dar al traste la voluntad de alinear los SI con los objetivos de negocio en el medio plazo si estos no forman parte de la estrategia empresarial: ¿tiene sentido invertir en aplicaciones de escritorio si nuestra estrategia es vender únicamente por canales directos como Internet en un futuro? Sabemos que orientar los SI hacia un tipo de arquitecturas u otras puede suponer inversiones muy importantes. ¿No sería mejor hacerlo de acuerdo a la estrategia empresarial?

Cada vez más las empresas operan en mercados más complejos que requieren un cantidad de información enorme para el soporte a la toma de decisiones inmanejable si no se utiliza software para la gestión de esa información. Ese software debe estar perfectamente alineado con la estrategia empresarial y por tanto diseñado específicamente para cumplir unos objetivos de negocio.

El software no es una commodity, el petróleo si lo es. Yo tengo la necesidad de poner gasolina en mi coche para que funcione. Seguramente buscaré la gasolinera más cercana o dónde el combustible sea más barato. Y lo haré porqué todas las gasolinas son iguales para mi coche y las gasolineras se encuentran por doquier. Si hacemos eso con los SI, puede ser que empiecen a toser los inyectores del motor que mueve la compañía y no podamos alcanzar la velocidad deseada. Ya nos entendemos.

A common Line Manager responsibility is to evaluate team members efficiency and productivity and promote them through their career path. This context gives the Line Manager some “power” the Project Manager never has over the project team. The project team is created ad-hoc for the project and its members came from different functional lines – obviously, I’m talking about multifunctional projects, not isolated projects -. And they know they will return to their functional “homes” when the project is over, where they’ll be evaluated and promoted by their functional boss.

From a social perspective, the interface Line Manager-Functional team is easier to manage than the Project Manager-Project Team interface. That “little” piece of “power” the Line Manager has, makes the whole Functional team adapt to the leadership style of their Functional boss.  Sometimes you could think you’re a social champion in this type of scenario. If this happens to you, dont build your hopes on.

Yesterday I was leading a brainstorming with some functional managers. We were trying to anticipate our user’s business needs in order to make a proposal for an information system evolution. This was a tiny effort in the inception phase of a new project. The fact was that the Line Managers rebate every single idea that seems to be a threat to the systems they’re accountable for. This is obviously something normal and a this is a must for a Line Manager. What I want you to imagine is the difficulty of manage the meeting and lead the crew to the goal. They’re personnel the Project Manager don’t have any authority over them. You don’t have any “power” over them. They will never adapt your leadership style. The Project Manager must adapt to them and negotiate every single step toward the common goal. This may be very stressful.

Sometimes I miss working with my functional team. But putting my Project Manager hat on, is always more challenging and definitely more fun. 

Mientras la competencia en el mercado donde opera la empresa no es salvaje, los productos que se ofertan pueden ser diseñados e implementados por una o dos de esas estructuras funcionales. Esta fase organizativa es un paraíso para los Product Managers. El producto se diseña y con métodos de gestión informales se puede conseguir que la línea funcional lo implemente en el calendario adecuado y el coste propuesto.

Pero pasa lo inevitable: el mercado empieza a ser más exigente y la competencia obliga. Y se demandan productos más complejos. A los Product Manager les cuesta mucho más el diseño de esos productos. Han de intervenir múltiples líneas funcionales y el mecanismo de gestión informal no sirve: los productos salen tarde y/o fuera de coste. En esta fase se intentan colegiar la mayoría de las decisiones de diseño y implementación. No resulta extraño ver en una misma sala a varios jefes de línea funcional, Product Managers y Senior Management cada vez que aparece un conflicto o se tiene que tomar una decisión que afecta a todas las estructuras funcionales.

Es entonces cuando se introducen políticas y métodos para coordinar el diseño y la implementación de productos complejos y mejorar la eficiencia. La organización hace un giro hacia la gestión formal del desarrollo de productos.  Los departamentos tienen canales y métodos de comunicación oficiales para comunicarse entre ellos. Se rellenan formularios y documentos y la información fluye. Mientras esa información circula en la dirección descrita en los métodos de la organización y las decisiones las toman aquellos para quienes se diseñó ese flujo de información no hay problema. Pero no hay plan que aguante el contacto con el enemigo…

La realidad es que durante el desarrollo de ese tipo de productos aparecen imponderables: cambios tácticos obligados por el mercado, cambios estratégicos diseñados por la misma organización, conflictos habituales que surgen en las organizaciones, etc… Y la mala noticia es que las políticas y los métodos nunca resisten esos cambios. Si nos empeñamos en utilizarlos, los proyectos se demoran y necesitan de nuevo la presencia constante de Senior Management. Mal asunto.

Y ese es el caldo de cultivo del que surgen los Project Managers y el punto de inflexión donde una organización se plantea evolucionar su estructura funcional pura hacia una organización tipo matrix. Pero eso es ya otra historia y el post se está haciendo demasiado largo.

Más sobre ello próximamente.

Podremos debatir entre nosotros cuales son las mejores prácticas para personalizar el proceso de desarrollo en un contexto determinado, pero es de indudable valor conocer los modelos de gestión de proyectos como el PMBOK o los de mejora continua como CMMI-Development.

Discutiremos si es apropiado en la organización implementar prácticas ágiles o no. Y es posible que acabemos implementado alguna de ellas. Algunos PM o Managers con suerte podrán utilizar una metodología ágil como Scrum, Kanban o XP completamente en sus equipos. Otros tendremos que conformarnos con identificar agujeros negros en la definición del proceso de desarrollo de la organización e introducir alguna práctica ágil en algunos de los equipos del proyecto.

De todas formas, bajo mi punto de vista, el Jefe de Proyecto, sea tradicional o con cierta tendencia a implementar prácticas ágiles, es no solamente necesario sino imprescindible. Estoy hablando, por supuesto, de organizaciones con cierto tamaño en las que vamos a encontrar varios Functional Manager que van a participar en el proyecto.

Si tienes la suerte de estar en un equipo pequeño, el mejor proceso siempre será “haz lo que sea necesario para entregar valor a tu empresa, barato, rápido y con la calidad suficiente”.

Por qué el 2009? Bueno, creo que el año que dejamos atrás será uno de los importantes para la ingeniería del software, para la forma en que creamos aplicaciones. Dos hechos relevantes han ocurrido durante este año, aunque se han ido gestando en años anteriores :

1.El Departamento de Defensa de los Estados Unidos de América ha autorizado el uso de un nuevo modelo de adquisición de software basado en un ciclo de vida iterativo y incremental, en 10 proyectos de IT durante el año 2010. El anterior modelo data de 1977 y está basado en ciclo de vida en cascada. Podeis leerlo en el post de Jesse Fewell.

2.El PMI, ha dado apoyo a la creación en su seno de una comunidad para “dotar a los miembros del PMI de los conocimientos y habilidades sobre prácticas “Agile” en gestión de proyectos.

Dos hechos que parecen indicar que las prácticas “Agile” van ocupando cada vez más un puesto relevante en la ingeniería del software. Y creo que eso es muy importante para los que creemos que muchas de esas prácticas no sólo son necesarias sino indispensables para la gestión de proyectos en ciertos tipos de sectores.

Más el año que viene.