IT Transformation

Esperando resultados diferentes haciendo lo mismo

2011-11-21T17:08:00.000-03:00

-¿Cómo les fue con la encuesta? ¿Pudieron acceder al link?

-Sí, anduvo bien. Pero hubo mucho “ruido”.

-¿Por qué?

-El instructivo estaba en inglés.

-(Breve pausa) Bueno, por lo menos había un instructivo…

-La encuesta también estaba en inglés.

-(Breve pausa) Bueno, qué le vamos a hacer. La empresa es global y el inglés es la lingua franca del mundo de los negocios…

-Sí, es cierto. Pero tengo gente complicada en mi grupo. Arrancan diciéndote que no saben inglés, que cuando ingresaron a la empresa nadie les dijo que tenían que manejar otro idioma, y terminan con que los sueldos son bajos.

-(Breve pausa) Bueno, la compañía se vendió a un grupo extranjero hace más de 10 años…

-Sí, pero muchos todavía creen que están en esa época…

-La mayoría de la gente de tu grupo es de antes de esa época…Y te aseguro que los comentarios en ese tiempo eran más o menos los mismos.

-(Suspiro de resignación) Es complicado ser jefe…

-Sí, seguro. Pero también es complicado estar en los zapatos de esa gente.

-¿Qué querés decir?

-Que debe ser difícil estar quejándose todo el tiempo desde hace décadas y no querer o no poder hacer nada al respecto.

-Sí, no debe ser fácil. Pero a la compañía también le conviene. Tiene empleados que se quejan de los sueldos, del café, de las oficinas y de otras cosas y que, sin embargo, prefieren quedarse y no ir a trabajar a otro lado.

-Son las leyes del mercado…Buenas o malas, son así.

-(Breva pausa) Lo que pasa es que para muchos es la postura más fácil. No tomo ninguna decisión y delego todo a los demás. Es un círculo vicioso: estoy mal, lo que me pasa no es mi responsabilidad, no hago nada para cambiar, estoy mal, etc.

-Cambiar cuesta…

-¡Por supuesto! El problema es cuando te quejás y no hacés nada. Un poco de catarsis está bien, pero en algún momento hay que cortarla y empezar a hacer algo. Aunque sea para preservar la salud mental…

-Sí, totalmente de acuerdo. Hay algunas variables que uno puede controlar y otras que no. Quejarse durante quince años de no saber nada de inglés básico y no hacer nada al respecto es un buen ejemplo de no hacerse cargo. La carrera depende de uno, no de los demás.

-(Breve pausa y sonrisa) Me recordás un dicho…”No son lo mismo 10 años de experiencia que un año repetido 10 veces”

Comportamiento subversivo en proyectos de software

2011-06-14T20:47:00.001-03:00

Estoy seguro de que la mayoría hemos sido testigos de lo que Johann Rost y Robert L. Glass llaman comportamiento subversivo, un término acuñado por los autores para describir conductas de individuos o grupos que deliberadamente apuntan a un sólo objetivo: conseguir que el proyecto fracase.

Luego de escribir varios artículos aparecidos en la prensa especializada a lo largo de los últimos años, Rost y Glass presentaron a principios de 2011 su libro The Dark Side of Software Engineering (Wiley), en donde analizan distintos aspectos de este problema.

Aquí va el link al capítulo 1: Subversion.

¡Qué lo disfruten!

Agile – It's more Disciplined than you Think

2011-06-06T22:44:00.002-03:00

Aquí va el link a un excelente artículo publicado por Mario Moreira:

http://cmforagile.blogspot.com/2011/05/agile-its-more-disciplined-than-you.html

Volviendo a lo básico

2011-05-30T22:35:00.006-03:00

En mi anterior post describía una práctica real que encontré en una organización. Lamentablemente, no es un caso aislado. Muchas culturas favorecen comportamientos que se contradicen con el sentido común y con el respeto a los tiempos de los demás.

Estoy convencido de que el cambio comienza por uno mismo. Si nosotros no somos ordenados no podemos pretender que nuestros pares y subordinados lo sean. OK, siempre hay alguna crisis. Pero, justamente, si nos gestionamos adecuadamente, podremos reaccionar adecuadamente.

Empecemos de a poco, con algunas cosas obvias que de tanto serlo rara vez se hacen: gestionar efectivamente las reuniones y el correo electrónico.

Reuniones

Ya sabemos que las reuniones consumen tiempo. Los latinos tenemos tendencia a empezarlas tarde, no seguir la agenda (si es que existe) y no “cerrarla”.

Como siempre, la tecnología nos puede ayudar. Las herramientas de colaboración organizadas en torno al e-mail nos facilitan el trabajo:

Al convocar una reunión, incluir siempre el objetivo y la agenda. El objetivo debe ser claro e indicar el resultado esperado de la reunión; por ejemplo, en vez de “Discutir alternativas de implementación” quizás sea mejor “Definir la alternativa a emplear”. La agenda debe incluir una lista de los temas, los oradores y los tiempos asignados.
Al iniciar la reunión, indicar claramente los roles. Alguien deberá coordinarla, facilitando la participación de todos y acotando las discusiones. Generalmente, es quién la convoca. Además, es necesario que alguien registre los resultados de la reunión. No es bueno que sea el coordinador (no se puede hacer todo).
Durante la reunión, mantener el foco. Los latinos tendemos a irnos de tema fácilmente. “OK, comparto tu punto de vista. Pero creo que está fuera del alcance de esta reunión discutirlo. Si te parece, organicemos otra reunión para revisarlo, pero mantengamos el foco en la agenda”. No es fácil de hacer, pero es importante no desviar la cuestión.
Después de la reunión, pasar en limpio las notas y enviar la minuta a los asistentes. Si hay un plan de acción acordado, no hay que perder tiempo y asignar las tareas directamente mediante la herramienta de colaboración empleada.

Por supuesto, seguramente habrá reuniones informales en donde habrá un tema pero quizás no haya agenda y mucho menos minuta. Cabría preguntarse en estos casos si realmente hace falta una reunión o si alcanzaría con intercambiar un par de e-mails o compartir un café.

e-mail

El correo electrónico es una herramienta fundamental de trabajo. Lamentablemente, se usa mal. Un colega me comentaba que estaba recibiendo 150 e-mails por día. En una jornada de trabajo normal, este colega debería leer (y contestar, de ser necesario) casi 19 e-mails por hora. Es imposible.

La sobreabundancia de información es un problema de esta era. Sin embargo, hay algunas estrategias que se pueden aplicar:

El conteo de la bandeja de entrada debería ser cero al final del día. Si recibimos algo que debía ser contestado en el día, ya deberíamos haberlo hecho.
Si lo que recibimos debe ser contestado y puede esperar, deberíamos dejarlo en una carpeta ad-hoc, “Pendiente de contestar”.
Si lo que recibimos debe ser contestado y no puede esperar, contestarlo en el momento. No hay que darle muchas vueltas al asunto.
Si lo que recibimos no necesita ser contestado pero requiere una lectura cuidadosa, dejarlo en una carpeta llamada “Pendiente de lectura”, o algo por el estilo.
Si lo que recibimos es una tarea que nos asignaron, rápidamente generar una tarea en el software de colaboración. Microsoft Outlook, por ejemplo, permite generar una tarea arrastrando un e-mail a la lista de tareas.
Si lo que recibimos es delegable, derivarlo o generar una tarea (según el caso).
Si lo que recibimos es un spam, rápidamente bloquear el remitente para que en el futuro no recibamos más e-mails de él. Esto debería reducir la cantidad de correos que tenemos que leer cada día.
Todos los días, procurar leer y contestar lo pendiente y actualizar el status de las tareas de nuestra lista.

Por supuesto que habrá muchos que argumentarán que no tienen tiempo para hacer esto…Pero la única manera de tener tiempo para hacer cosas productivas es organizarse. Lamentablemente, nos guste o no, hay que aceptar que en nuestra vida laboral, además de ser creativos, debemos ser ordenados.

Prácticas de gestión "dogbertianas"

2011-05-30T22:29:00.001-03:00

El diálogo que sigue es digno de Dogbert. Para quienes no sepan quién es Dogbert, vayan a www.dilbert.com.

Un día estaba tratando de coordinar una reunión con un gerente de tecnología en una empresa “grande”. Usando Microsoft Outlook, constaté su disponibilidad y le agendé una reunión en uno de los huecos que encontré.

Como pasaron los días y no tuve noticias -ni buenas ni malas- me di una vuelta por el escritorio de su secretaria. Transcribo el diálogo:

-Hola. ¿Cómo te va?

-Muy bien…

-Pasaba por aquí y quería consultarte algo…

-¡Adelante!

-Hace unos días le agendé una reunión para la semana próxima a tu jefe, pero no me la aceptó ni me la rechazó… ¿Sabés algo al respecto?

-Vi tu invitación -tengo acceso a su agenda- pero no me dijo nada.

-Ah, OK. Si lo ves, por favor avisale. Es una reunión muy importante y, si bien hay otros invitados, si él no puede venir deberíamos reagendarla para que pueda asistir.

-OK, yo le aviso. Pero mirá que su antecesor -que estuvo por aquí hasta hace un mes atrás- tenía como práctica no aceptar ni rechazar las invitaciones…

-(Sorpresa y breve pausa) ¿Y cómo hacía para organizarse?

-Él decidía sobre la marcha a qué reuniones iba y a cuáles no…

-(Nuevamente, sorpresa y pausa más larga) Pero así los demás nunca sabían si podían contar con él o no…Además, al no bloquear su agenda seguramente no podía evitar que se le superpusieran invitaciones a reuniones en los mismos horarios…

-(Cara de fastidio) Sí, pero él se movía así.

-(Pausa, más larga que la anterior) Bueno, cada uno se organiza como puede. ¿Vos pensás que tu nuevo jefe se manejará igual?

-No lo sé, hasta ahora no me dijo nada.

-Por lo que veo, no está aceptando ni rechazando las reuniones. Asumo entonces que se va a manejar de la misma manera…

-Sí, supongo que sí.

-OK, entonces te hago una última pregunta…

-Dale.

-¿Podrás pedirle que me confirme si puede o no venir?

- Sí, le pregunto. Pero puede pasar que la acepte y que a último momento no pueda asistir.

-OK, en ese caso la reagendaremos porque necesitamos que él esté sí o sí.

-OK, le comento. Pero no te puedo garantizar que la acepte o la rechace.

-(Nueva pausa y suspiro de resignación) OK, no hay problema. En todo caso, lo llamo hoy a la tarde y le pregunto qué va a hacer.

-Bueno, probá. Hoy seguramente estará toda la tarde reunido…

-(Bufido de cansancio y resignación…) OK, mejor dejá. No te hagas problema. Nos arreglaremos de alguna manera…

La reunión nunca se hizo y el tema quedó sin resolver. Después de un par de infructuosos intentos para reagendarla, perdí las esperanzas. Evidentemente, había que dejar que el tema a tratar en la reunión se convirtiera en una crisis.

Y, efectivamente, eso fue lo que pasó. Recién allí el tema se trató y se resolvió, pero de la peor forma posible.

Uxor IT, nivel 3

2011-05-17T23:35:00.001-03:00

Uxor IT, una empresa a la que tuve el honor de asesorar entre 2008 y 2009, fue evaluada como una organización de nivel de madurez 3 (ML3) de acuerdo al modelo CMMI.

¡Felicitaciones!

Watts Humphrey, 1927-2010

2010-11-17T22:31:00.001-03:00

El 28 de octubre pasado murió Watts Humphrey, fundador del Software Process Program en el SEI y "padre" del modelo CMM (ver nota).

Ganador de la National Medal of Technology en 2008, Humphrey fue una de las piezas clave en el establecimiento de las bases de lo que hoy conocemos como ingeniería de software.

Addison-Wesley ha publicado la entrevista que en su momento Grady Booch le realizara para The Computer History Museum.

Mejora de Procesos con CMMI-DEV: Una Introducción Práctica

2010-10-28T17:53:00.005-03:00

Editorial Nueva Librería (http://www.nuevalibreria.com.ar/site/libros/libro.php?id=92783) acaba de publicar mi libro, Mejora de Procesos con CMMI-DEV: Una Introducción Práctica.

Como indica el título, el propósito de la obra es proveer un panorama general del modelo CMMI-DEV, posibles interpretaciones a sus prácticas y algunas ideas para su implementación.

Ya está disponible en las librerías de la UTN y de UNLP y en los próximos días saldrá a la venta en las principales de microcentro. También se puede comprar on-line en el sitio de Nueva Librería.

Service Science, Management & Engineering

2010-05-20T22:38:00.002-03:00

Para los que se preguntaban qué estaba haciendo IBM respecto a la gestión de servicios basados en tecnología informática, aquí está la respuesta:

http://www.ibm.com/developerworks/spaces/ssme?pageid=800

Esta esfuerzo académico y de investigación busca proveer un enfoque multidisciplinario para el diseño, desarrollo y provisión de servicios, claros pilares de la economía actual.

El sitio incluye varios artículos, presentaciones y links a universidades y centros de investigación que están encarando iniciativas similares en otras partes del mundo.

Gestión de Servicios de TI

2010-02-05T19:52:00.001-03:00

A fines del año pasado fui invitado por Juan Gabardini a dar una charla en Exactas de la UBA acerca de la gestión de servicios basados en TI. Preparamos el tema junto a mi amigo y colega Jorge Mazzini, que lamentablemente por problemas de agenda no pudo asistir.

Aquí está el link para bajarse la presentación: http://www.exactas.uba.ar/uti/wp-uploads/2009/12/charla-servicios-ti-uba-14.pdf

Un poco más de Hoshin Kanri

2010-02-05T19:42:00.000-03:00

Aquí va el link a un muy esclarecedor artículo de Enrique Yacuzzi, de la Universidad del CEMA: La Gestión Hoshin: Modelos, Aplicaciones y Caracterísiticas Distintivas.

Hoshin Kanri: Lo que Occidente no termina de entender

2009-09-14T16:07:00.005-03:00

Es interesante observar como Occidente, a lo largo de los años, ha intentado explicarse el aplastante éxito de las empresas japonesas: Algunos autores han argumentado que fue la aplicación de las técnicas de control estadístico enseñadas en los cincuentas por Deming y Juran; otros, sostienen que en realidad el éxito reside en el uso de TQM y Lean, junto a otros viejos conocidos tales como JIT, QFD, Kaizen, etc., etc.

Algunos observadores (entre ellos David Hutchins) aclaran que estas herramientas no deberían ser aplicadas aisladamente. Según ellos, el éxito de las empresas japonesas reside en el proceso de gestión estratégica que las integra, llamado Hoshin-Kanri.

Este método es una adaptación del ciclo PDCA popularizado por Deming en Japón. En pocas palabras, consiste en definir la estrategia en forma colaborativa y "bajarla" a acciones concretas para el día a día. Para la fase D del ciclo, Hoshin Kanri confía en las herramientas de TQM/Lean.

A través de este método, las organizaciones consiguen alinear sus esfuerzos detrás de unos pocos objetivos a mediano/largo plazo, los que se traducen en acciones concretas para el corto.

En este contexto, TQM/Lean se transforman en el cómo, mientras que Hoshin Kanri es el qué.

En próximos posts trataré de ir profundizando este muy interesante enfoque.

¿Por qué son malos los servicios?

2009-08-13T16:28:00.004-03:00

Estamos en una economía signada por la provisión de servicios. Sin embargo, son muy pocos los que toman conciencia de la importancia de diseñarlos. Resulta muy natural diseñar un producto, pero diseñar un servicio suena como algo raro.

En nuestro país tenemos muchos ejemplos de servicios mal pensados y pésimamente implementados. Los encontramos todos los días, en los lugares más diversos: en el consultorio del médico, en el banco, en los organismos públicos, en las mesas de ayuda...

En muchos casos, es uno el que tiene que hacer el follow-up de los trámites: "Ah, estábamos por llamarlo para avisarle que..."; "Cruce enfrente y saque fotocopias de las páginas 2 y 3"; "Tiene que traer una copia del resumen de cuenta"; etc; etc.

¿Tan difícil es organizarse? ¿Tan difícil es entender que si somos una empresa de servicios tenemos que diseñarlos para que nuestros clientes/usuarios tengan una experiencia agradable y no se vayan agobiados o desalentados por la mala experiencia de tener que interactuar con nosotros? ¿Tan complicado es publicar en la web los requisitos para realizar un trámite o para solicitar un servicio?

Lo mismo es válido para los servicios entre áreas internas: ¿Cómo hago para reportar un incidente con una aplicación?; ¿Cómo hago para pedir una PC?; ¿Cómo hago para...?

Es fácil demostrar cuán negativamente impactan los servicios que se brindan mal. No sólo hay problemas con la imagen de las organizaciones ("Me atendieron remal") sino también consecuencias económicas: duplicación de esfuerzo, información redundante, mal clima general por la desorganización, focalización en lo urgente y no en lo importante, etc., etc...

Las soluciones son relativamente fáciles: hay que diseñar la experiencia del usuario/cliente, definiendo los atributos del servicio y estableciendo los procesos adecuados para proveerlo. De más está decir que al usuario/cliente no le interesa si su pedido está trabado en un departamento determinado o en está detenido en el proceso de aprobación: Lo único que considerará en su evaluación es si lo atendieron amablemente, si le pidieron la información indispensable y no tuvo que repetir 25 veces lo mismo ante otros tantos interlocutores, y si el servicio recibido y los tiempos estuvieron acordes con los estipulados por el proveedor ("En 48. hs lo visitará uno de nuestros técnicos").

Entre tantas cosas que andan dando vueltas por ahí, hay un modelo de capacidades para la tercerización de servicios con fuerte base tecnológica. Se llama eSCM (eSourcing Capability Model) y fue desarrollado por el IT Services Qualification Center de Carnegie Mellon (la misma universidad de CMMI, pero en la facultad de Ciencias de la Computación). Vale la pena darle una mirada. Aquí está el link.

Estoy cansado del movimiento ágil...

2009-08-07T14:12:00.005-03:00

En mi anterior post reproducía algunos comentarios de Ivar Jacobson acerca del movimiento ágil. Creo que sus dichos reflejan lo que muchos pensamos: las principales ideas del movimiento ágil ya forman parte (o al menos deberían) del background de la mayoría de la gente (de ahí a que las pongan en práctica es otro tema). Se habla tanto de "agilidad" que prácticamente ha perdido su significado (lo mismo está pasando con lean).

Por esa misma razón, creo que no tiene sentido ya hablar de "ágil" versus "no ágil." Los que estamos en este negocio desde hace años sabemos que para cada problema hay un enfoque determinado; para un desarrollo pequeño, de baja complejidad, las herramientas deben ser forzosamente sencillas. Para emprendimientos más complejos, el enfoque debe ser diferente. En todos los casos debemos ser ágiles y estar en condiciones de adaptarnos.

Por supuesto que debemos aceptar que en todos estos años hemos aprendido mucho. Algunos "evangelistas" que se inmolan en el púlpito olvidan que el enfoque "tradicional" era el único que había para desarrollar software, aunque en general lo que se hiciera fuera "codificar y probar". Lo que muy bien ha hecho el movimiento ágil fue integrar ideas que estaban dando vueltas desde hace mucho, tomar prestadas algunas otras de otros dominios (por ejemplo, del desarrollo de productos) y agregar las suyas. Su filosofía y las prácticas que propone ya forman parte del cuerpo de conocimiento de la ingeniería de software.

Lo que creo que nunca terminaremos de entender como profesionales es cuánto es suficiente. Me he topado con gente que no entiende que el planeamiento debe ser gradual y progesivo y piden "planes detallados" cuando no es el momento. O supuestos "especialistas" que hacen planes de proyecto con tareas tan granulares que duran menos de quince minutos ("Agendar reunión"). O gente que quiere cerrar los requerimientos antes de empezar con el desarrollo y se consume la mitad del tiempo y los recursos en preparar una propuesta de proyecto. Hace años que sabemos que en la mayoría de los proyectos los planes y los requerimientos se irán refinando en forma progresiva. Me causa un poco de gracia cuando algunos agilistas acusan al ciclo de vida en cascada de todos los males de este mundo. La verdad, no he visto en veinte años un proyecto con ese ciclo de vida (y dicho sea de paso, muy pocos con algún ciclo de vida). ¿Alguien vio alguno?

En el otro extremo, me he encontrado con desarrolladores que no pueden estimar el esfuerzo de hacer algo. Sus argumentos son que simplemente no pueden hacerlo. "OK, pero estamos hablando de una componente de tal tipo, de tales características, para hacer esto". "No puedo hasta que no lo haga". ¿No es de locos? Por supuesto que el desarrollo de software es buena medida exploratorio, pero sigue siendo imporante para el negocio hacer pronósticos. "¿Vamos a gastar 20 pesos o dos millones de dólares?".

En definitiva, creo que el único camino es balancear constantemente lo que sabemos y aplicar adecuadamente las herramientas. Los extremos son malos...

Jacobson habla del movimiento ágil

2009-07-28T17:33:00.002-03:00

Acabo de topar con un muy interesante post de Ivar Jacobson de abril de este año. Hace allí algunas reflexiones acerca de la saturación que está produciendo el movimiento ágil en algunos actores. Aparentemente, la gente está empezando a aburrirse de todo lo que tenga la etiqueta "ágil" (últimamente, casi todo).

Jacobson no está en contra del movimiento ágil, pero llama a tener una actitud un poco más equilibrada para balancear la práctica con la postura de los evangelistas desenfrenados.

Uno sólo de los párrafos da para iniciar un debate que probablemente sea interminable:

"Fortunately agile has grown up a bit – and the zealots have mostly been replaced by more reasonable proponents who know that there are many good things in agile approaches, but they need to be blended with other things to really be successful."

Que lo disfruten.

40 años de ingeniería de software. ¿Valieron la pena?

2009-07-15T19:08:00.004-03:00

Tom DeMarco acaba de publicar un excelente artículo en donde presenta algunas reflexiones con motivo de cumplirse cuarenta años de la famosa conferencia de la OTAN en la que se presentó por primera vez el término ingeniería de software.

DeMarco hace una profunda autocrítica del papel que jugó su libro Controlling Software Projects: Management, Measurement, and Estimation en el establecimiento de una obsesión colectiva en torno a la predictibilidad y el control, aspectos que se tornaron en algo demasiado relevante dentro de la ingeniería de software.

A continuación, reproduzco algunos de los párrafos más importantes:

"...strict control is something that matters a lot on relatively useless projects and much less on useful projects."

"Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to Control them, no matter how assiduously we apply ourselves to control."

"Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."

DeMarco concluye su artículo con una clarificadora reflexión:

"Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been."

Una crítica al sistema lean

2009-07-14T08:48:00.003-03:00

En estos últimos días he estado leyendo un excelente libro llamado "Myths at Work", en donde se analizan y critican varias de las creencias más arraigadas en el management moderno, tales como la globalización, la participación de la mujer en el mundo del trabajo,el sistema lean, etc.

Más allá de estar de acuerdo o no con todo lo que los autores plantean, creo que es muy interesante el análisis que hacen de cada uno de los temas. La mayoría de las veces se adoptan escuelas de pensamiento como si fueran "modas", lo cual genera expectativas desmedidas que después no se cumplen y que terminan "quemando" el tema. El mundo de la tecnología está repleto de ideas que prometieron resolver todos nuestros problemas y que luego cayeron en el olvido.

Hay muy buenas ideas en el movimiento lean, pero hay que sopesar -como en todo los órdenes de la vida- todos sus aspectos. Los autores de este libro lo hacen y demuestran que no todo es color de rosa.

Se pueden consultar algunos capítulos en Google Books.

Value Driven Planning

2009-07-06T11:51:00.002-03:00

Tom Gilb ha publicado una excelente presentación acerca de la complementación entre los métodos ágiles y Evo. Se puede descargar aquí.

¿Se puede controlar un proceso creativo?

2009-06-12T18:54:00.010-03:00

Muchas de las críticas que se le hacen a CMMI -y que se le hicieron en su momento a SW-CMM- han tenido que ver con la viabilidad de aplicar las técnicas del control estadístico a procesos de desarrollo de software, una disciplina conocimiento-intensiva que gira en torno al diseño y a la creatividad y no alrededor de la fabricación repetitiva de un mismo tipo de producto [Curtis-2008a].
Uno de los principales críticos, por ésta y otras razones, ha sido el movimiento Ágil. Para sus proponentes, no tiene sentido controlar un proceso que, por su naturaleza, se ubica al borde del caos (ver [Anderson, pág.9] y [Schwaber, pág.102]). Según ellos, debido a la natural complejidad del desarrollo de software, se impone la aplicación de otro tipo de control de procesos, llamado control empírico. La idea principal detrás de este punto de vista es que no hay una teoría que explique el fenómeno observado: la única opción posible es observar y adaptar los procesos en función de los resultados obtenidos. En esta visión, no hay procesos definidos (al menos, con el nivel de detalle esperable de una organización madura) ni predecibles.
Sin embargo, no todos en la comunidad ágil piensan lo mismo. David Anderson, uno de los creadores del método FDD (Feature Driven Development) y autor de Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results [Anderson], asegura que un proceso empírico puede arrojar resultados de una precisión similar a la esperada en un proceso definido.
Para Anderson, no siempre el desarrollo de software está al borde del caos: siempre es posible la planificación y la predicción de los resultados dentro de ciertos límites de incertidumbre. Un proceso convergente -ya sea éste empírico o definido- mostrará con el tiempo un comportamiento predecible. En cambio, un proceso divergente se comportará en forma caótica y será imposible de controlar.
Anderson concluye asegurando que es necesario controlar a los procesos para que las organizaciones puedan obtener resultados económicos superiores. De ninguna manera, según su punto de vista, puede confiarse únicamente en los controles reactivos tan populares en los métodos ágiles [Anderson, cap.32].
Ideológicamente más cerca de CMMI, Bill Curtis -co-autor de SW-CMM, People CMM y del reciente Business Process Maturity Model [OMG]- ha cuestionado la aplicabilidad de los grafos de control -una de las herramientas que está en el mismo corazón de la gestión cuantitativa- a los procesos de desarrollo de software [Curtis-2008b], ya que en general las fuentes de datos empleadas son de naturaleza heterogénea.
Curtis plantea que un sistema compuesto por una persona produciendo piezas de código de similares características y bajo las mismas circunstancias tendrá un comportamiento similar a un proceso con causas comunes de variación. Sin embargo, la situación sería otra si las piezas que se le asignaran a esta persona fueran de diferente dificultad. En este caso se estaría introduciendo en el proceso una fuente de variación que alteraría su desempeño, sus límites de control y su predictibilidad. La única solución viable sería desagregar los datos de manera tal de poder construir un grafo de control para cada una de las diferentes complejidades de los componentes.
La situación se tornaría más complicada en el caso de involucrar a más personas en el proceso, ya que aparecerían nuevas fuentes de variación (la productividad y la capacidad de trabajo podrían no ser las mismas en todos). Esto implicaría construir más grafos de control para mantener la homogeneidad de datos, lo cuál sería claramente impracticable.
Curtis y su coautor concluyen afirmando que son otras las herramientas estadísticas que deberían usarse en estos casos, caracterizados por múltiples fuentes de variación. El grafo de control no sería el más aplicable en dichas situaciones.
Esta conclusión es sumamente relevante, ya que las raíces de CMMI en la industria manufacturera son muy profundas. En ella, los supuestos de Walter Shewhart se cumplen y el grafo de control es la herramienta más adecuada. La situación sería completamente diferente en la industria del software.
Buscando el equilibrio
Claramente, el debate está lejos de finalizar. La comunidad informática debe encontrar el punto medio que le permita equilibrar la necesidad de predecir resultados -un imperativo del management de cualquier organización- con la de disponer de procesos ágiles y adaptables.
Varios trabajos ([Dutton], [Fritzsche], [Paulk-1], [Glazer]) puntualizan que en realidad hay más similitudes que diferencias entre los métodos ágiles y CMMI. De hecho, muchas de las prácticas propuestas por el movimiento ágil son una reinterpretación de prácticas existentes en la ingeniería de software y en otras industrias desde hace años y no necesariamente son incompatibles con CMMI.
Probablemente, los puntos más conflictivos sean los relacionados con las áreas de proceso de los niveles 4 y 5. La afirmación de que debe aplicarse un control empírico sobre los procesos contradice el precepto básico de CMMI de que los procesos deben ser controlados estadísticamente. Sin embargo, la recomendación del modelo de seleccionar cuidadosamente cuáles subprocesos controlar pareciera no entrar en conflicto con los preceptos del movimiento ágil.
De todas maneras, el debate continúa y probablemente continuará por bastante tiempo más. Lo que está claro por el momento es que de la discusión surgirá un nuevo enfoque para gestionar el desarrollo de software, basado con seguridad en las mejores ideas de las diferentes escuelas.

Referencias

[Anderson]
David J. Anderson
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
Prentice Hall, 2004

[Curtis-2008b]
Bill Curtis, Bob Raczynski
Software Data Violate SPC’s Underlying Assumptions
IEEE Software, Mayo/Junio 2008

[Dutton]
Jeffrey L. Dutton, Richard S. McCabe
Agile/Lean Development and CMMI®
Systems & Software Consortium
Presentación en la SEPG Conference 2006
http://www.sei.cmu.edu/cmmi/adoption/pdf/dutton.pdf

[Fritzsche]
Martin Fritzsche, Patrick Keil
Agile Methods and CMMI: Compatibility or Conflict?
e-Informatica Software Engineering Journal, Volume 1, Issue 1, 2007
http://www.e-informatyka.pl/e-Informatica/attach/Issue1/Vol1Iss1Art1eInformatica.pdf

[Glazer]
Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum
CMMI® or Agile: Why Not Embrace Both!
CMU/SEI-2009-TN-003
http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

[OMG]
Object Management Group
Business Process Maturity Model - Version 1.0
OMG, 2008

[Paulk-1]
Mark Paulk
Extreme Programming From a CMM Perspective
IEEE Software, Vol.18, Nro.6; noviembre/diciembre 2001
[Schwaber] Ken Schwaber
The Enterprise and Scrum
Microsoft Press, 2007

Los famosos 14 puntos de Deming

2009-06-05T17:21:00.002-03:00

Es sorprendente ver cuán vigentes se mantienen hoy las ideas de Deming. Las dejo en inglés:

Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.
Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
End the practice of awarding business on the basis of price tag. Instead, minimise total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
Institute training on the job.
Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of an overhaul, as well as supervision of production workers.
Drive out fear, so that everyone may work effectively for the company.
Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
Eliminate slogans, exhortations, and targets for the workforce asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
a. Remove barriers that rob the hourly paid worker of his right to pride in workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
b. Remove barriers that rob people in management and engineering of their right to pride in workmanship. This means, inter alia, abolishment of the annual or merit rating and management by objective.
Institute a vigorous program of education and self-improvement.
Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.

Servicios de TI

2009-04-28T09:55:00.004-03:00

La semana pasada, junto a Jorge Mazzini y Héctor Sambucetti, participé de un webinar organizado por el Foro Help Desk. El tema fue el diseño de servicios basados en tecnología informática.
La charla tuvo muy buena aceptación -participaron cerca de 250 personas- y promete expandirse en tres cursos que se estarán lanzando próximamente.
El video y el audio de la charla pueden descargarse aquí.

Eclipse Process Framework

2009-03-11T09:07:00.005-02:00

Gratamente me ha sorprendido la versatilidad del Eclipse Process Framework para especificar procesos. Es una herramienta libre basada en el Rational Process Composer de IBM.

Si bien puede parecer complicada al principio, es muy fácil de usar cuando se entienden algunos puntos clave. De ahí en más, el camino es en bajada. Los sites generados lucen sumamente profesionales y se resuelven automáticamente muchas relaciones (roles vs. actividades, roles vs. artefactos, etc.) que de otra manera habría que construir a mano.

No puedo menos que reomendarlo.

¡Ya salió CMMI for Services!

2009-03-03T00:19:00.004-02:00

El SEI acaba de publicar -increíblemente, antes de lo estimado- la nueva constelación de CMMI, llamada CMMI for Services o CMMI-SVC.

Claramente inspirado en ITIL y en IT-CMM, este nuevo trabajo busca cubrir el vacío dejado por CMMI-DEV en todo lo relacionado con el desarrollo de sistemas de servicio y su posterior gestión.

El reporte está disponible para su descarga en http://www.sei.cmu.edu/publications/documents/09.reports/09tr001.html.

Una CMDB para todos...

2008-12-10T16:50:00.007-02:00

Una herramienta open source muy interesante, con la cual se pueden empezar a dar los primeros pasos en el (complejo) mundo de la administración de la configuración, es OneCMDB.
Desarrollada por Lokomo Systems AB, esta CMDB ofrece la funcionalidad necesaria para empezar a registrar información acerca de los ítems de configuración y sus relaciones. Adicionalmente, provee una interfaz GUI bastante completa y una API para desarrollar los conectores que uno crea necesarios (por ejemplo, con el software de Service Desk).
Hay por el momento una versión stand alone solamente; la multiusuario está prometida para más delante.
¡Que la disfruten!

¿Qué crisis?

2008-11-28T11:20:00.003-02:00

En temporadas de recesión, el camino fácil para reducir costos es despedir personal. Sin embargo, eso suele dar resultados únicamente en el corto plazo. ¿No sería mejor examinar los procesos y la estructura de la organización para encontrar oportunidades que nos permitan mejorar nuestra estructura de costos?.

Los costos de la no calidad
¿Cuál es el costo en el que incurrimos para resolver problemas derivados de la falta de calidad en nuestros productos y servicios?¿Cuál es el volumen de los incidentes reportados a nuestra mesa de ayuda?¿Cuáles son los orígenes de esos incidentes?¿Podemos hacer algo para evitar que se repitan?
Claramente, el proceso de "Problem Management" propuesto por ITIL nos puede ayudar a encontrar las respuestas.

Los temas estratégicos
¿Qué porción de nuestro presupuesto está dedicado a proyectos alineados con la estrategia del negocio?¿Cuál es la dedicada a "mejoras menores"? Muchas organizaciones tienen portafolios desbalanceados, en donde más de la mitad del presupuesto se gasta en proyectos dedicados a resolver requerimientos poco relevantes para el negocio: un nuevo reporte, un nuevo campo en una pantalla, etc. ¿Puede el usuario sobrevivir sin ese pequeño cambio?¿Puede acotarse el monto a gastar durante el año a temas no estratégicos? Invertir en temas relevantes para el negocio obviamente traerá beneficios para todos. Los procesos de planificación estratégica y de gestión de carteras son los que deberíamos estar mirando.

Las estructuras ineficientes
¿Cuántos roles hacen más o menos lo mismo en distintos lugares de la organización?¿No podemos fusionar roles similares?¿Cómo podemos hacer para obtener sinergia? En muchas organizaciones, por temas políticos, suelen "replicarse" funciones similares en distintos lugares de la organización. ¿No sería mejor dejar de lado las disputas domésticas y empezar a pensar en cómo beneficiar a la organización?

Los interesados
Estructuras eficientes, mejores procesos. Eso es lo que necesitamos para reducir costos y beneficiar a todos los interesados en la organización: sus empleados, sus accionistas y, por supuesto, sus clientes. Mejores procesos, mejores productos, más valor.

Algunos comentarios acerca del SEPG LA 2008...

2008-11-21T19:03:00.005-02:00

La semana pasada (12-14 de noviembre) tuvo lugar en Mar del Plata la conferencia SEPG Latin America 2008, auspiciada por el SEI y el ESI.

No había tenido la oportunidad de ir a ninguna de estas conferencias (se organiza una vez al año en EEUU; además de la latinoamericana, hay una versión europea y otra australiana. Más info: http://www.sei.cmu.edu/sepg/), con lo cual fui con muchas (aunque no desmedidas) expectativas.

En este tipo de congresos, la satisfacción/insatisfacción personal depende en buena medida de las presentaciones a las que uno haya decidido asistir, lo cual está claramente influenciado por lo prometido en el programa, si se conoce o no al expositor (aunque sea de nombre), la predisposición de uno mismo, etc. En mi caso, tuve la suerte de elegir un conjunto de charlas que a la larga resultó equilibrado.

Como suele pasar, algunas de las presentaciones no estuvieron a la altura de lo que se esperaría (sentí eso con algunas catalogadas como "advanced") mientras que otras ofrecieron más de lo prometido (por ejemplo, en las que se presentaban datos de experiencias reales). Algunos de los "Gurúes" me decepcionaron un poco, pero sobre todo por los temas presentados (que podrían haber sido otros). En la vereda de enfrente, hubo paneles muy interesantes, como por ejemplo el de los lead appraisers discutiendo acerca de las posibles interpretaciones de CMMI en el contexto de las PYME.

En resumen, el balance es positivo. Siempre se puede mejorar.

CMMI® or Agile: Why Not Embrace Both!

2008-11-20T10:35:00.002-02:00

El SEI acaba de publicar un excelente artículo acerca de la integración entre dos enfoques aparentemente distintos: CMMI y los métodos ágiles. se puede descargar en este link.

Agiles 2008

2008-10-31T18:23:00.002-02:00

La semana pasada (20-25 de octubre) tuvieron lugar en Buenos Aires las primeras jornadas ágiles en latinoamérica (http://www.agiles2008.org) Fueron días con charlas muy interesantes que creo que a todos los asistentes nos "movieron el piso" y nos dejaron pensando acerca de la validez de nuestras prácticas actuales de desarrollo de software.
¡Sigan así!

Lo que nos faltaba...

2008-07-25T19:37:00.003-03:00

La OMG ha publicado recientemente la primera versión del BPMM (Business Process Maturity Model) Un extracto de la introducción nos orienta en su alcance:

"Introducing the BPMM specification will address at least five current challenges to the success of enterprise systems:
• Management has few standards for appraising the maturity of their business process workflows and needs proven methods for identifying the risks process weaknesses pose for deploying enterprise IT projects and achieving business objectives.
• Management has few proven methods for appraising the fidelity between how tasks are actually performed and how they are described in model-based representations of process workflows. This problem compromises the validity of system requirements, the accuracy of use cases and model-based representations, and the effectiveness of the application in use.
• Management is often unaware of the extent to which organic growth or acquisitions have resulted in multiple ways of performing similar tasks. The creation of standard, tailorable processes simplifies the requirements for enterprise applications and as a result will reduce the complexity of enterprise systems.
• Organization’s have few proven methods for appraising a supplier’s capability for delivering outsourced IT and other business services within the parameters claimed in a proposal. Further they need a proven basis for specifying contractual requirements for improvements in a supplier’s business processes.
• Management needs guidance on how to implement the business process foundations required for organizational agility and lower operating costs..."

Veremos cómo sigue...Parece interesante.

¿Mejoramos o certificamos?: El lado oscuro de CMMI

2008-07-25T16:08:00.004-03:00

Siempre llega ese mail matador preguntando "¿Cuál es el costo de 'certificar CMM'?" Mi respuesta invariable es (obviamente): depende.

Lo positivo de la tan mentada Ley de Promoción de la Industria del Software es que ha puesto en el radar de las PYMEs modelos de referencia y estándares como CMMI e ISO9001:2000 que, más allá de las razonables discusiones acerca de su verdadera efectividad, ofrecen un camino posible para mejorar los problemas de calidad típicos en muchas empresas.

Las consecuencias negativas creo que tienen que ver con poner la certificación por encima de la estrategia del negocio. Por supuesto que alcanzar un determinado nivel de CMMI o salir airosos de una evaluación tienen un valor muy importante, pero hacerlo simplemente por obtener una exención impositiva es garantía de no obtener todos los beneficios que potencialmente podrían conseguirse.

Pensémoslo como un proyecto de inversión. ¿Quién invertiría, digamos, u$s50.000 (por poner un número) en una iniciativa de "mejora y certificación de calidad" sin tener en claro cuál será el retorno de la inversión? ¿Bajaremos costos?¿Mejoraremos la calidad de nuestros productos?¿Venderemos más? Las respuestas a esas preguntas son las que nos deberían permitir calcular los beneficios estratégicos y económicos de un proyecto de este tipo. Y digo "estratégico" porque justamente es uno de los factores clave en todo esto.

Hace ya varios años, Kaplan y Norton propusieron el balanced scorecard y su compañero strategy map (http://en.wikipedia.org/wiki/Balanced_scorecard) como herramientas para modelar y medir el grado de cumplimiento de la estrategia del negocio. Más allá de sus distintas variantes, lo interesante del enfoque es que permite vincular los diferentes aspectos de las organizaciones y alinear sus actividades en pos de una sola meta: satisfacer los objetivos estratégicos.

El mapa estratégico agrupa los objetivos del negocio en cuatro dimensiones (puede haber más o menos), los que a su vez están relacionados entre sí por relaciones de causa-efecto. Para simplificar un tema complejo en pocas palabras: para poder ser exitosos económicamente necesitamos tener más clientes y/o que los clientes que ya tenemos compren más. Para ello, tenemos que ofrecerles un mejor producto/servicio y, sobre todo, una mejor "experiencia" integral con nuestra empresa (calidad del servicio de soporte, por ejemplo, o consultores entrenados, o personal educado y preparado, etc.) A su vez, para conseguir esto deberíamos identificar cuáles son los procesos que potencialmente más impacto tendrían (por ejemplo, un mejor proceso de desarrollo o de soporte, un proceso de ventas más eficiente, etc.) Adicionalmente, además de procesos adecuados, necesitaremos personal preparado y motivado.

El otro componente de este enfoque, el balanced scorecard, nos ayuda a cuantificar estos objetivos midiéndolos a traves de una o más métricas. El proceso de gestión se transforma entonces en un conjunto de ciclos de negocio en donde el cumplimiento de la estrategia se va evaluando periódicamente y, de ser necesario, se hacen ajustes (de la estrategia o de los objetivos).

Es fácil de entender entonces que lo ideal sería poder emplear herramientas como las mencionadas para identificar qué procesos mejorar y en qué grado. La relación entre la mejora de procesos y su impacto en la estrategia y en las finanzas de la empresa queda así -para bien o para mal- claramente expuesta. Puede ser entonces que el proceso que querramos mejorar no sea el que más impacto tenga en las operaciones de la compañía...

En definitiva, primero deberíamos pensar cómo los procesos mejorados (y no la "certificación" de procesos) contribuirán a la salud de la compañía. Las herramientas para hacerlo están disponibles...

Algunas ideas para ir hacia ML2 (2da. Parte)

2008-04-14T13:30:00.007-03:00

Si bien es un poco arriesgado generalizar, ya que cada organización es un mundo diferente, intentaré a continuación hacer algunas (humildes) recomendaciones que me han resultado adecuadas en el pasado y que podrían llegar a servir a los lectores para alcanzar el nivel 2 de CMMI:

Tenga una estrategia de negocio
Puede parecer una obviedad, pero muchas compañías (sobre todo las pequeñas) que dan sus primeros pasos en la mejora de procesos no tienen demasiado claro para qué lo están haciendo. Nadie debería empezar una iniciativa como ésta sin tener en claro en qué medida apuntala o refuerza la estrategia de la organización.
Antes de avanzar en formalizar un programa de mejoras deberíamos determinar en qué medida éste se alinearía con los objetivos estratégicos de negocio. ¿Nos permitirá reducir costos, aumentar ingresos, mejorar la atención a nuestros clientes?¿Nos dará más flexibilidad, nos hará más ágiles?¿Venderemos más?¿Le resultaremos más atractivos a nuestros clientes? Preguntas como éstas son las que deberíamos plantearnos para determinar si vale la pena o no embarcarnos en un esfuerzo como este.

Genere un ambiente propicio al cambio y a la integración
Las organizaciones suelen transmitir mensajes contradictorios. Si estamos diciendo que cambiar la manera en la cual trabajamos es importante y prioritario, debemos generar un ambiente en donde:

Las sugerencias e ideas de la gente sean escuchadas (aunque a los gerentes no les guste lo que digan);
La gente pueda participar en el proceso de cambio;
La adhesión al cambio sea recompensado (y no penalizado);
Haya recursos para que el cambio efectivamente tenga lugar;
La dirección y los mandos medios sostengan el proceso de cambio.

Quienes están en mejores condiciones de identificar y proponer mejoras a los procesos actuales es la gente que está en las trincheras, sosteniendo el funcionamiento del negocio con su esfuerzo personal. Debemos trabajar con ellos (y no contra ellos) si queremos que la mejora se materialice en algo concreto. Ningún programa de mejoras funciona si no se les da participación activa a sus principales destinatarios.

Formalice el programa de mejoras
Como decíamos con anterioridad, las organizaciones de nivel 1 carecen de los mecanismos para manejar adecuadamente sus proyectos, inclusive aquellos relacionados con la mejora de procesos. El primer paso que debería tomar antes de comenzar es establecer un alcance y un plan muy claros, para que nadie sea tomado por sorpresa. Adicionalmente, será necesario establecer una estimación real del esfuerzo y la duración necesarios para cubrir todas las áreas de proceso de este nivel, objetivos a mediano y largo plazo (“¿Cómo seguimos después de alcanzar nivel 2?”), y un mecanismo para administrar el programa de mejoras (roles y responsabilidades, actualización del plan, monitoreo y control, etc.). En definitiva, hay que implementar -en el contexto del programa de mejoras- las prácticas de gestión de proyectos que habremos de implementar como resultado de ejecutar el programa de mejoras...
Muchas organizaciones optan por implementar algunas de las prácticas incluidas en las áreas de proceso OPD (Organizational Process Definition) y OPF (Organizational Process Focus), correspondientes al nivel 3. Esto es bastante habitual y, si bien pareciera ser una medida a contrapelo del modelo, ya que estaríamos implementando algo de nivel 3 antes de las áreas de proceso de nivel 2, es perfectamente aceptable (aunque nada fácil de mantener en el tiempo...)

Olvídese un poco del modelo
Algo bastante habitual es encontrar organizaciones completamente obsesionadas con CMMI. Todos sus esfuerzos están puestos en cumplir con los objetivos del modelo, siempre al pie de la letra y con una mínima interpretación. Es así que terminan produciendo procesos extremadamente burocráticos e impracticables, con un mapeo prácticamente uno a uno con las áreas de proceso de CMMI.

De más está decir que esta obsesión, como muchas otras en otros órdenes de la vida, no suele ser demasiado sana. Si bien hay que tener presente al modelo, de manera tal de tener una directriz que guíe nuestros esfuerzos de mejora, deberíamos ponerlo en un segundo plano y enfocar toda nuestra energía en definir procesos que agreguen valor a nuestra organización. Siempre será necesario interpretar al modelo (por ejemplo, cuál es nuestra definición de proyecto vs. la definición de proyecto que propone CMMI) y hacer muchas concesiones para poder poner en práctica sus ideas.
Por otro lado, en general hay otros requerimientos con los cuales los procesos que definamos deberán cumplir. Siempre encontraremos que hay políticas y procedimientos organizacionales con los cuales será necesario cumplir (por ejemplo, cómo formalizar un contrato con un proveedor suele ser algo establecido por el sector de asuntos legales). También nos encontraremos en situaciones en las que será necesario mejorar procesos que no están incluidos en el alcance de CMMI (por ejemplo, la resolución de incidentes en producción), pero que son prioritarios para poder poner orden en el entorno en el cual se ejecutan los proyectos de desarrollo.
Por lo tanto, pensar únicamente en el modelo y especular si cumplimos o no con tal área de proceso de contar con una minuta de reunión más o menos es como estudiar “para zafar”. Si nos sacamos la presión del “examen” de encima, nuestra mente estará mucho más abierta, podremos pensar “fuera del modelo”, y, en consecuencia, el camino será mucho más fácil.

Identifique productos y servicios.
Es bastante difícil comenzar a definir procesos si no tenemos claro cuáles son los productos y servicios que ofrecemos a nuestros clientes/usuarios. A pesar de que probablemente suene raro que alguien no sepa qué es lo que produce su compañía, es bastante común encontrarse con actores con distintas visiones del negocio al cual se dedica la organización. Llegar a un consenso al respecto es sumamente importante, ya que facilita la identificación y mejora de procesos.
En general, las organizaciones de software o de IT en general, además de desarrollar soluciones suelen velar por la atención de incidentes en producción. También atienden consultas de los usuarios respecto a las aplicaciones, los orientan acerca de cómo usar la tecnología en el negocio, apoyan las actividades de preventa, y una larga lista de etcéteras. Está claro que cada uno de estos productos/servicios requieren procesos diferentes. Aún dentro de la misma familia, ligeras variaciones de los mismos productos/servicios podrían requerir procesos diferentes.

Identifique procesos.
A pesar de su opinión en contrario, la organización de nivel 1 para la cual seguramente Ud. está trabajando tiene procesos. Todas las organizaciones los tienen, más allá de su formalización.
Lo que no debería hacerse nunca es comenzar desde cero. Es mucho más fácil observar cómo se hacen las cosas hoy y ver de qué manera pueden mejorarse. A partir de los productos y servicios identificados será mucho más fácil encontrar los procesos empleados por la organización y, a partir de este punto, empezar a trabajar en mejorarlos.
Una de las tantas cosas que se van aprendiendo con los años es que la mayoría de las veces es necesario mejorar procesos que no están incluidos en el alcance del modelo. Un ejemplo clásico es el tratamiento de incidentes en producción: Si no hay un proceso para manejar este tipo de actividades, muy difícilmente pueda trabajarse en mejorar los procesos relacionados con los proyectos. La razón es sencilla: Podemos tener un muy buen proceso para gestionar nuestros proyectos, pero si no hay un proceso para manejar el resto de las cosas que hacemos, rápidamente nos dedicaremos únicamente a trabajar sobre lo urgente (los incidentes, en nuestro ejemplo), dejando de lado las actividades de mediano y largo plazo (los proyectos).
Esto también está directamente emparentado con la teoría de las restricciones [1]: Todos los sistemas, inclusive las organizaciones, tienen solamente un único punto más débil que el resto. Hacia él debería orientarse la mejora.

Defina tipos de proyectos.
Las organizaciones suelen ejecutar distintos tipos de proyectos. Algunos son más complejos o riesgosos, mientras que otros son más rutinarios y sencillos; algunos duran meses o años y consumen centenares de meses-persona, mientras que otros pueden durar un par de semanas y consumir no más de unas decenas de horas-hombre.
El esquema que definamos para administrar los proyectos debe tomar en consideración estas características. Claramente, no será lo mismo, por ejemplo, un proyecto de desarrollo de una nueva aplicación (o de evolución de una ya existente) que un proyecto de mantenimiento de rutina. En el primero de los casos, el enfoque de gestión de proyectos deberá ser más elaborado para poder lidiar con los riesgos y complejidades típicos de este tipo de emprendimientos. En el segundo, probablemente bastará con un método de trabajo más directo.
Queda claro, entonces, que aplicar prácticas demasiado sofisticadas en proyectos pequeños o poco riesgosos generará deseconomías de escala, burocracia innecesaria y, con toda seguridad, resistencia en las personas que deberán gestionarlos.
Definir el proceso para manejar los “grandes” proyectos es relativamente fácil. El problema que enfrentan muchas organizaciones es qué hacer con los proyectos “pequeños”, que suelen ser amplia mayoría en la cartera de proyectos.
Algunas organizaciones han encontrado la solución a este problema “reinterpretando” la definición de qué es un proyecto. En vez de manejar múltiples “mini-proyectos” independientes -lo que claramente implica un esfuerzo extraordinario-, han encontrado mecanismos que les permiten agruparlos en entidades más grandes -proyectos o programas- con el propósito de obtener economías de escala en las actividades de gestión.
Por ejemplo, si sabemos que durante un año necesitaremos realizar mejoras menores a una aplicación, cada una de las cuales llevará poco tiempo y esfuerzo (pero, probablemente, en su conjunto representarán una suma relativamente importante), podríamos definir un proyecto de “mantenimiento”, con un presupuesto y duración fijos y un alcance “variable”: A medida que durante el año nos vayan llegando pedidos de “mejora” de nuestros clientes o usuarios, los manejaremos como unidades de trabajo que deberán ser incluidos en el plan del proyecto.
En algunas software factories el enfoque adoptado es similar. Se establece un contrato de mantenimiento con el cliente, en el cual el proveedor se compromete a tratar pequeñas adaptaciones a uno o varios sistemas bajo determinadas condiciones (horas-hombre, calidad, etc.) y durante un periodo dado. Desde el punto de vista de CMMI, el “proyecto” es este contrato.
En estos casos, las actividades de planificación y monitoreo quedan establecidas a nivel del contrato. Por ejemplo, en vez de un plan para cada una de las adaptaciones solicitadas por el cliente, se mantiene un plan general para todo el contrato. En él habrá al menos un puñado de tareas relacionado con cada uno de los pedidos del cliente, mientras que las actividades de administración del proyecto estarán a nivel general.
Si interpretáramos los objetivos y prácticas de CMMI al pie de la letra, probablemente nos veríamos tentados a definir un proyecto para cada uno de estos “mini-proyectos” que acabamos de mencionar. Cada uno de ellos debería tener, en consecuencia, su propio plan (todos los planes: de administración de requerimientos, de aseguramiento de la calidad, del proyecto en general, etc.). Las actividades de gestión quedarían instanciadas para cada “mini-proyecto”, lo que llevaría a, por ejemplo, generar un informe de avance para cada uno de ellos. Claramente, esto es inviable.

Defina cómo nacen los proyectos (gestión de demanda)
En muchas organizaciones, la inmadurez se refleja no sólo en cómo son conducidos los proyectos sino también en cómo nacen. No es algo común encontrar organizaciones que cuenten con procesos formales para canalizar las necesidades de los clientes/usuarios, evaluarlas, y -finalmente- transformarlas en proyectos que agreguen valor a la organización.
En muchas áreas de sistemas es bastante común encontrarse con usuarios finales que tienen acceso directo a los desarrolladores para hacer sus pedidos, lo que claramente trae graves consecuencias. En primer término, el backlog de temas por atender queda oculto en la agenda de cada departamento o silo organizacional dentro del área de sistemas, o, lo que es peor, en la de algún individuo. En segundo término, los proyectos nacidos de esta manera difícilmente estén alineados con las verdaderas necesidades de la organización, ya que no es posible realizar un análisis estratégico bajo estas condiciones. Por último, es muy difícil balancear la carga de trabajo, ya que algunos grupos podrían estar saturados mientras que otros podrían tener capacidad ociosa.
En las compañías dedicadas al desarrollo de software la situación no es demasiado distinta. Los vínculos entre el área comercial y el área de desarrollo no suelen ser precisamente fáciles, con lo cual es bastante habitual encontrar proyectos que han sido “vendidos” a los clientes sin la más mínima evaluación por parte del resto de los actores de la organización (desarrollo, soporte, etc.)
Si bien este tema no encuentra un correlato directo en el modelo, la experiencia indica que es muy difícil poner orden en los proyectos si éstos nacen de manera descontrolada. Es como pretender que en una fábrica se construya todo lo que se pida: Si no hay un filtro al inicio es altamente probable que la capacidad de producción se vea superada y que cualquier intento por establecer un plan sea en vano.
Las organizaciones que han conseguido resolver estos problemas han puesto en marcha procesos que permiten manejar adecuadamente la demanda de sus usuarios/clientes, de manera articulada con la gestión de las carteras de IT (ver siguiente sección para más información al respecto).
Algunas de ellas han implantado comités de sistemas, cuya función es centralizar los pedidos de nuevos proyectos de IT y facilitar su evaluación. a través de los cuáles deben realizarse todos los pedidos relacionados con proyectos de IT. En general, este comité es el encargado de hacer un primer filtro, en el que se verifica, entre otras cosas, si el nuevo desarrollo requerido está o no alineado con los objetivos estratégicos de la organización.
De manera similar, en las empresas de tecnología informática suele ponerse en marcha un proceso de preventa que se encarga de gestionar la demanda de los clientes y canalizarla hacia equipos encargados de evaluar la posibilidad de ejecutar estos nuevos proyectos.

Establezca un marco de trabajo para la gestión de la cartera de proyectos y para la gestión de proyectos
El tema de IT portfolio management (o gestión de carteras) se ha puesto relativamente de moda en estos últimos años[2]. La idea es que los proyectos y los demás activos de la organización (aplicaciones, piezas clave de la infraestructura, recursos humanos, etc.) sean administrados tan concienzudamente como una cartera de inversiones (de hecho, lo son en la práctica). Por consiguiente, cada proyecto que se quiera encarar en la organización deberá:

Estar alineado con la estrategia del negocio;

Hacer buen uso de los restantes elementos en la cartera;

En resumen, así como la gestión de proyectos tiene que ver con todo lo relacionado con la planificación y control de un proyecto, la gestión de cartera tiene como propósito planificar y controlar la cartera de proyectos y demás activos de la organización. Como puede verse, la gestión de cartera es el compañero ideal de la gestión de demanda que se describe en el apartado anterior.

¿Para qué nos sirve la implementación de un proceso de este tipo? A nivel estratégico, está claro: nos permitirá concentrarnos en aquellos proyectos que son importantes. A nivel táctico, el orden general que promueve (los proyectos no cambian permanentemente de prioridad, se balancea la demanda con disponibilidad de recursos, etc.) permite que sean aplicadas prácticas básicas de gestión en los proyectos que incluidos en la cartera. El pretexto de mucha gente perteneciente a organizaciones de nivel 1 es “no puedo planificar porque me cambian las prioridades todo el tiempo”, o bien “planificamos pero siempre ingresan nuevos proyectos que destruyen la planificación que hicimos”. Con este enfoque, al menos las cosas deberían empezar a ordenarse.
Además de establecer un marco para la gestión de la cartera, es obvio que será necesario definir cómo serán administrados los proyectos. En función del tamaño y/o complejidad de los proyectos (ver la recomendación anterior, Defina tipos de proyectos.) será necesario establecer un marco que contemple como se planificarán y controlarán los proyectos. Inevitablemente, será necesario definir un marco de trabajo que permita:

Estimar esfuerzo, costos y duración sobre la base de los requerimientos identificados (presumiblemente, con distintos grados de precisión según la madurez de la demanda realizada[3]);
Establecer el ciclo de vida del proyecto, con fases, hitos y entregables;
Desarrollar un plan de proyecto (incluyendo el cronograma) con el suficiente nivel de detalle para efectuar un control razonable de las actividades;
Mantener comunicaciones entre el equipo de proyecto y los restantes interesados (usuarios, clientes, auspiciantes, etc.) acerca del avance del proyecto.
Buscar, evaluar y seleccionar proveedores de productos y servicios necesarios para la ejecución del proyecto.

En definitiva, la organización deberá establecer un marco de trabajo más o menos general que describa cómo serán administrados los distintos tipos de proyectos. Si bien no debería profundizar en los aspectos relacionados con el desarrollo del producto en sí, este marco deberá describir las actividades de planificación, monitoreo y control con el suficiente nivel de detalle como para llevar adelante los proyectos. Si bien su alcance es más amplio, el PMBOK [PMI] es una buena fuente para consultar prácticas más o menos generales que podrían aplicarse en este caso. Volveré sobre este tema en una futura entrega.

Identifique y desarrolle líderes de proyecto
Esta recomendación puede parecer trivial, pero es bastante común encontrarse con organizaciones que tienen muy buenos recursos humanos, pero ninguno (o pocos) con los conocimientos, habilidades y ganas de ser líderes de proyecto.
Esto es lógico, ya que en las organizaciones de nivel 1 el énfasis está puesto en las actividades técnicas, por lo que son más valoradas las habilidades de desarrollo de software (y de lucha contra el fuego) que las de gestión.
Es imposible establecer un proceso de manejo de proyectos si no hay alguien que cubra el rol de gerente, jefe o líder (póngale el nombre que quiera). Alguien tiene que planificar, organizar y controlar los proyectos.
Seguramente, entre sus colaboradores debe haber personas con interés en este tipo de actividades. Entrénelos si es necesario.
No caiga en el error de promover a ese puesto (que no necesariamente debe ser jerárquico, sino más bien funcional) a personas que no estén suficientemente preparadas (lo cual es solucionable) o que no tengan vocación (lo cual es muy difícil de solucionar). El daño que pueden llegar a provocar en el programa de mejoras es enorme.

Establezca prácticas y herramientas de administración de la configuración
Como decía en la sección Administración de la Configuración (CM), esta es, probablemente, una de las disciplinas más difíciles de implementar. Si bien el tema da para escribir un libro entero (hay muchísimos y muy buenos[4]), me gustaría incluir aquí algunas recomendaciones.
Por un lado, es importante que se defina un ciclo de cambio que claramente describa cómo y de dónde se toman (o se crean, en el caso de que sean nuevos) los ítems de configuración (componentes de software, planes, especificaciones, etc.) de los proyectos, en qué lugar se modifican y verifican, y cómo se incorporan a la línea base (en el caso de software, cómo se pone en producción). Este ciclo -probablemente, un procedimiento de bajo nivel- deberá estar integrado al ciclo de vida (o a los ciclos de vida) de los proyectos, al proceso de reparación de emergencia (no incluido en CMMI-DEV, pero probablemente a incluir en CMMI-SRV), y al proceso de despliegue y puesta en producción.
Por otro lado, la implementación de una herramienta que facilite estas cosas es casi fundamental. Quizás la administración de la configuración de los documentos pueda realizarse de manera manual o con un simple administrador de versiones. Pero para gestionar las componentes que forman parte del software, contar con una herramienta parece ser algo imprescindible.
Lo más importante que podría recomendarle es: ¡Empiece pronto!

Inicie un programa de métricas
“Lo que no se mide no es administrado”, reza el viejo adagio. Definir y poner en marcha un programa de métricas que permita obtener un conjunto muy básico de indicadores es de fundamental importancia para poder monitorear y controlar los procesos de la organización y para poder evaluar el avance de la iniciativa de mejoras.
Las métricas definidas deberán estar alineadas con objetivos organizacionales y tendrán que tener metas asociadas. Sin objetivos y metas claramente establecidos es habitual caer en el error de medir aquello que resulta más fácil.
Adicionalmente, la complejidad de iniciar y sostener un programa de métricas radica en al menos tres aspectos cruciales:

Por un lado, será necesario disponer de un procedimiento más o menos formal para recoger los datos base, consolidarlos, generar las métricas, analizarlas, validarlas y publicarlas.
Por el otro, debe quedar claro que las métricas tienen utilidad para la organización. Para ello, será necesario describir cómo van a consumirse y en qué contexto. Si las métricas se generan pero no se emplean en ningún proceso o no se toman decisiones en función de ellas, rápidamente perderán su utilidad y, lo que es peor, generarán la sensación de que medir no es una tarea que se tome en serio.
Por último, la disponibilidad de datos suele ser una de las falencias de muchas organizaciones. Un software de time-reporting o una aplicación de gestión de proyectos pueden ser mecanismos muy útiles para registrar datos y obtener algunas métricas básicas. Generar datos en forma manual y en base a la observación es un trabajo muy tedioso, poco integrado a las actividades del día a día, y muy costoso.

Establezca un marco de aseguramiento de la calidad
Una vez establecidas las políticas, los procesos y los estándares, será necesario monitorear su cumplimiento y tomar acciones correctivas en caso de detectar desvíos. Esto es sumamente importante, ya que le permitirá a la organización institucionalizar los cambios y evaluar los beneficios del programa de mejoras.
Muchas organizaciones se ven tentadas a asignar este trabajo -que puede llegar a ser visto por algunos como algo meramente mecánico- a personal junior o poco calificado para la tarea, algo totalmente desacertado.
El proceso de aseguramiento de la calidad es una pieza crítica, sobre todo en organizaciones que están empezando a dar sus primeros pasos en los niveles iniciales de madurez. A través de él, las organizaciones consiguen que los proyectos y las demás actividades comiencen lentamente a alinearse a los nuevos procesos, estándares y políticas. Será necesario asignar esta responsabilidad a alguien con el suficiente peso político para ser respetado por sus pares y por sus superiores.
En general, las organizaciones implementan este proceso identificando “puntos” de auditoría de calidad en determinados hitos o momentos de los proyectos. En esos puntos se procede a controlar la existencia y adecuación de determinados artefactos (planes, especificaciones, etc.), y a examinar cualquier otra evidencia que permita constatar la adhesión al proceso (minutas de reunión, imputación de horas al proyecto, etc.) Usualmente, el asegurador de calidad dispondrá de checklists para realizar su trabajo, los cuales le ayudarán a determinar qué aspectos evaluar.
Lo que no debe olvidarse es que el proceso de aseguramiento de la calidad (cualquiera sea el nombre que se le asigne) no solamente deberá ser empleado para auditar a los proyectos: hay otras actividades que deberán ser evaluadas, inclusive el mismo proceso de aseguramiento de la calidad.

No se olvide de las prácticas genéricas
En una organización con procesos institucionalizados encontraremos que:

Las políticas organizacionales se cumplen;
Se respetan los planes y las descripciones de los procesos;
Se proveen los recursos necesarios para realizar el trabajo (herramientas, personal y económicos);
Hay responsabilidades y autoridades claramente asignadas para ejecutar los procesos;
La gente tiene los conocimientos necesarios para ejecutar los procesos eficazmente;
Los resultados del trabajo (artefactos, productos) están puestos bajo administración de la configuración;
Los principales interesados están identificados e involucrados en la ejecución de los procesos;
Se monitorea la ejecución de los procesos y se toman medidas correctivas de ser necesario;
Los procesos y sus resultados (servicios, productos) son objetivamente evaluados con el propósito de determinar su adhesión a las descripciones del proceso, los objetivos y los estándares, tomándose acciones correctivas en el caso de detectarse no conformidades.
Las actividades, el estado y los resultados de la ejecución de los procesos son revisados por la dirección de la organización, tomándose acciones correctivas en caso de ser necesario.

Las prácticas genéricas son las que permiten arribar a una situación como la descripta. Ellas son las que proveen los mecanismos para que la organización emplee los nuevos procesos de manera rutinaria. También son las que proveen los mecanismos de “autocontrol” para evitar caer en los viejos hábitos al producirse algún evento indeseado.No deberíamos olvidarnos de las prácticas genéricas al diseñar nuestros procesos. Algunas de ellas son bastante fáciles de resolver; otras merecerán un análisis más detallado (como por ejemplo la GP 2.9 Evaluar Adhesión Objetivamente en el área de proceso PPQA, o la GP 2.2 Planificar el proceso en el área PP). Lo que no deberíamos hacer es acordarnos de ellas hacia el final del programa de mejoras. Deberían ser una prioridad desde el primer día.

Referencias

[1] http://en.wikipedia.org/wiki/Theory_of_constraints#Software_engineering
[2] Ver por ejemplo, [Kendall] y [Maizlish] para una explicación más detallada.
[3] En función de cómo haya sido definido el proceso de gestión de demanda, puede ser necesario realizar estimaciones preliminares (ordenes de magnitud) antes de que haya un pedido formal de iniciar el proyecto.
[4] Ver, por ejemplo, Configuration Management for Software, de Compton, Conner y Callahan; Van Nostrand Reinhold Company (1994). Un muy buen punto de entrada es http://en.wikipedia.org/wiki/Software_configuration_management

Algunas ideas para ir hacia ML2 (1era. parte)

2007-12-19T10:46:00.001-03:00

Poner en funcionamiento las prácticas vinculadas a las áreas de proceso de este y de cualquier otro nivel de madurez implica poner en marcha un programa de mejoras que debería ser encarado como cualquier otro proyecto de la organización. Será necesario formular metas claras y realizables, establecer un plan de trabajo creíble, y asignar recursos humanos, tecnológicos y financieros.

Como comentaba en una entrada anterior, una organización de nivel 1 no posee las habilidades básicas necesarias para gestionar adecuadamente sus proyectos. Esto agrega una dimensión extra de complejidad, ya que será muy difícil encarar el programa de mejoras con estas carencias en el área de gestión. Claramente, este es el principal riesgo que deberemos enfrentar al iniciar las mejoras en este tipo de organizaciones.

Otro de los temas más complicados es el relacionado con la gestión del cambio. Las organizaciones tienden a mantener el status quo y a la gente le cuesta mucho salir de su área de confort. Implantar prácticas como las que nos ocupan implicará cambiar costumbres muy arraigadas en la gente. El cambio no ocurrirá simplemente porque a un gerente se le ocurra ordenar “¡Háganlo!”. Deberemos planear concienzudamente cómo gestionaremos el cambio y cómo haremos para que las mejoras introducidas perduren en el tiempo.

Gestionar el programa de mejoras y gestionar el cambio organizacional son, en la práctica, las dos caras de la misma moneda. En definitiva, un programa de mejoras es exitoso porque puede impulsar y sustentar los cambios en la cultura de trabajo de la gente.

Adentrémonos ahora en algunas sugerencias más puntuales.

Las Organizaciones del Nivel Inicial de CMMI-DEV

2007-11-07T12:59:00.000-03:00

Una síntesis de las características de las organziaciones de nivel 1

En términos generales, las organizaciones del nivel 1 carecen de un ambiente estable para desarrollar sus productos. Las crisis recurrentes y el caos son tan normales que lo usual para ellas es estar “apagando incendios” todo el tiempo. La gente está constantemente resolviendo los temas “calientes” del momento: incidentes en producción, consultas de los usuarios, respuestas urgentes a licitaciones, actividades de preventa, demostraciones no planeadas, etc. Si queda algo de tiempo, trabajan en sus proyectos de desarrollo.
Es fácil entender, entonces, porqué a estas organizaciones les resulta prácticamente imposible cumplir con los compromisos que contraen con sus clientes y proveedores. En ellas es habitual que los proyectos no cumplan con sus cronogramas y excedan (a veces muy ampliamente) los presupuestos establecidos. La funcionalidad prometida a los usuarios no siempre es entregada en forma completa y la calidad de los productos suele ser bastante dudosa.
Este comportamiento recurrente podría ser adjudicado a que el aprendizaje es prácticamente inexistente en este tipo de organizaciones. Cada proyecto se encara de manera distinta, sin considerar los errores cometidos en el pasado. No hay memoria y, tampoco, una evaluación subjetiva de las propias limitaciones operativas. En este contexto, los resultados (calidad, costos, fechas de entrega...) son muy difíciles de predecir.
Todo por cierta dosis de “pensamiento mágico” que suele manifestar el management: las cosas se harán porque simplemente creemos y decimos que se van a hacer. Es así que se establecen fechas de entrega y presupuestos sin ningún (o con escaso) sustento lógico: cumpliremos con nuestros compromisos simplemente por el hecho de que nos hemos puesto esa meta. Los proyectos (si es que existe el concepto de proyecto en estas organizaciones) suelen ser iniciados sin considerar la disponibilidad de los recursos necesarios para su ejecución. En cierta medida, los gerentes de las organizaciones de nivel 1 suscriben a la “Teoría X”: los empleados son vagos y evitarán trabajar siempre que puedan.[1] Por esa razón deben establecerse metas “ambiciosas” (léase: imposibles de cumplir).
A pesar de todo lo dicho, estas organizaciones pueden tener éxito y desarrollar buenos productos (o, al menos, aceptables). El único problema radica en el costo al que lo consiguen: usualmente, son los gestos heroicos de la gente -que trabaja largas horas sin descanso y, normalmente, gratis- los que permiten cumplir con las metas y los compromisos irrazonablemente establecidos.
En resumen, los problemas más graves de las organizaciones de nivel 1 no son de origen técnico. Claramente, no es una cuestión de proveer más y mejores herramientas de desarrollo. Ninguna de ellas podrá suplir las nefastas consecuencias de una pobre administración de proyectos y de una mala gestión de la organización en general.
Es por estas razones que la transformación de una organización de nivel 1 en una de nivel 2 implica un profundo cambio en la mentalidad de quienes ocupan posiciones de management: directores, gerentes, jefes de sector, líderes de proyecto, líderes técnicos, etc. La manera en la cual realizan las actividades de gestión es tóxica y debe ser mejorada.

En definitiva, para iniciar el camino hacia nivel 2 hace falta una gran dosis de humildad para aceptar que no somos tan buenos gestores como creíamos.

[1] La “Teoría X” y la “Teoría Y” fueron propuestas por Douglas McGregor del MIT Sloan School of Management en su libro “The Human Side of Enterprise”

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.

Los cinco niveles de CMMI-DEV

2007-05-17T18:20:00.000-03:00

En general, los niveles de madurez suelen explicarse en orden creciente; tomaremos aquí una dirección distinta y los explicaremos exactamente al revés: desde el nivel cinco al nivel uno.

Imaginémonos por un momento que estamos en una organización de nivel cinco. En este tipo de organizaciones, como dijimos en la entrega anterior, los procesos son analizados para eliminar las causas comunes de variación, o sea, aquellas que tienen que ver con la misma naturaleza del proceso, no atribuibles a causas externas. Las variaciones en las salidas de los procesos son al azar, pero se encuentran controladas estadísticamente (podemos predecir los resultados de los procesos con cierto nivel de confiabilidad)

Para poder haber arribado a este nivel, la organización debería primero haber eliminado las causas especiales de variación, aquellas que tienen que ver con causas externas, como por ejemplo falta de entrenamiento del personal, problemas con las herramientas, etc. Este tipo de causas no son aleatorias: Si examináramos los resultados podríamos ver las tendencias que claramente nos indicarían que las variaciones tienen un origen concreto. En una organización de nivel cuatro, entonces, las causas especiales de variación son identificadas y eliminadas.

Para poder llegar a identificar causas de variación necesitamos tener un proceso estándar: difícil sería poner bajo control estadístico un proceso que no se encuentre mínimamente formalizado.
Así llegamos al nivel tres, en el cual los proyectos emplean un proceso productivo adaptado del proceso estándar de la organización. Las actividades técnicas y de gestión son realizadas de acuerdo a políticas, procesos y procedimientos formalizados en algún tipo de estándar organizacional profundamente arraigado en la cultura. La gente está entrenada y dispone de recursos para poder hacer su trabajo. También hay una infraestructura básica (personal, herramientas, etc.) para definir y mejorar el proceso productivo.

Pero para poder arribar a semejante situación es necesario pasar por una etapa previa: difícilmente podamos introducir en una organización prácticas estándar relacionadas con la ingeniería del producto (análisis, diseño, etc.) si no ofrecemos un contexto en donde ellas puedan ser correctamente ejecutadas. Ese es el foco del nivel dos: poner en orden las prácticas relacionadas con el manejo elemental de los proyectos.

En el nivel dos, los proyectos de la organización siguen algún tipo de proceso para realizar las actividades relacionadas con la gestión del proyecto (planificación, control), para administrar los requerimientos y las configuraciones, y para medir y analizar la calidad de los productos y el desempeño de los procesos. También hay prácticas de aseguramiento de la calidad que permiten garantizar que cada proyecto sigue sus propios estándares.
En el nivel dos no importan tanto las técnicas y los métodos que empleemos para desarrollar y construir nuestros productos y servicios: Lo importante es que podamos tener un mínimo de capacidad de gestión de proyectos.

Y así llegamos al nivel uno: La situación aquí es caótica. No tenemos procesos (no al menos en el sentido del modelo) y la performance de los proyectos depende profundamente de la buena voluntad y la capacidad de la gente.

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.

Procesos estadísticamente controlados

2007-05-17T18:12:00.000-03:00

Continúo publicando algunos extractos del texto en el que estoy trabajando.

Uno de los principios fundamentales de la calidad total –sobre los cuales está basado CMMI-DEV- es el de control estadístico de procesos. Según él, la variabilidad de un proceso puede ser controlada y, por consiguiente, sus resultados pueden ser predecibles[i]. Que los resultados de un proceso sean predecibles no quiere decir que sean idénticos, sino que estos variarán dentro de límites conocidos.

Procesos estables
Las características de todos los procesos y productos presentan algún tipo de variación cuando las medimos a lo largo del tiempo. Dicha variación puede tener dos fuentes: la misma naturaleza del proceso (la variación normal o natural del proceso, relacionada con la interacción entre sus distintos componentes –personal, maquinaria, materiales, métodos y ambiente-) por un lado, y las causas relacionadas con alguna causa específica por el otro (las variaciones especiales). La variación normal del proceso (llamada causa común de variación) tiene un comportamiento al azar, pero con un patrón estable y dentro de ciertos límites. Si un proceso presenta únicamente este tipo de variación estaremos ante un proceso estadísticamente controlado.
La variación especial, por el contrario, no tiene un patrón de comportamiento que pueda ser identificado. El impacto de este tipo de variaciones en la performance del proceso y en las características del producto son importantísimos, a tal punto que es imposible predecir los resultados.
Las variaciones especiales no tienen su origen en el proceso, sino en causas externas tales como el medio ambiente, el material de input al proceso, personal no capacitado, métodos o herramientas incorrectamente usados, etc.
Una vez que las variaciones originadas en causas especiales sean removidas, nos encontraremos con un proceso estable (estadísticamente controlado) Una vez alcanzado este estado, podremos optimizar el proceso, reduciendo la variabilidad o “corriendo” la media. Como veremos en las próximas entregas, las organizaciones de nivel de madurez 5 de CMMI se esfuerzan en remover las causas comunes, mientras que las de nivel 4 se enfocan en remover las especiales.

[i] William Florac, Robert Park, Anita Carleton; Practical Software Measurement; CMU/SEI-97-HB-003.

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University

Una breve descripción de CMMI-DEV (SM)

2007-05-16T15:32:00.000-03:00

Desde hace un par de meses vengo trabajando en un texto introductorio a CMMI que espero publicar este año. Aquí va una primera entrega.

Una breve descripción de CMMI

El Capability Maturity Model Integration (CMMI[SM] de aquí en adelante) es un marco de referencia que las organizaciones pueden emplear para mejorar sus procesos de desarrollo, adquisición, y mantenimiento de productos y servicios. Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University (www.sei.cmu.edu), CMMI es la nueva generación de una línea de modelos de madurez que se inició a principios de los noventa con el famoso CMM-SW (Capability Maturity Model for Software Engineering).

Basados en los principios de la calidad total (TQM) popularizados por autores como Crosby, Deming y Juran, estos modelos proponen un conjunto de prácticas que las organizaciones pueden adoptar para implantar procesos productivos más efectivos. Son llamados modelos de madurez porque proponen
adoptar dichas prácticas en forma gradual: primero deben ponerse en práctica áreas de proceso pertenecientes a un nivel determinado, para luego, sobre esta base, introducir las correspondientes al nivel siguiente. Como puede apreciarse en la figura de la izquierda, antes de introducir prácticas de un nivel determinado deben estabilizarse las prácticas del nivel anterior. Es así que, por ejemplo, antes de introducir el área de proceso RSKM-Administración de Riesgos (perteneciente al nivel 3 ó definido) deben estabilizarse las relacionadas con la gestión del proyecto (PP-Planificación del Proyecto y PMC-Monitoreo y Control del Proyecto, pertenecientes al nivel 2 ó administrado).

Un modelo de referencia no es la descripción de un proceso
Llegados a este punto, es importante hacer una aclaración: CMMI, como su nombre lo indica, es un modelo que propone un conjunto de best practices que pueden emplearse para evaluar y mejorar procesos; de ninguna manera debe suponerse que estamos ante la descripción de un proceso. Será nuestro trabajo definir el proceso productivo de nuestra organización –que seguramente tendrá una estructura completamente diferente a la de CMMI- de manera tal que cumpla con los atributos y mejores prácticas propuestos por el modelo.

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University

Presentación del blog

2007-05-16T15:06:00.000-03:00

¡Hola a todos!

Como ya habrán visto en la cabecera, desde hace unos cuantos años me dedico al tema de calidad y mejora de procesos en organizaciones de IT. Durante todo este tiempo he ido aprendiendo de los aciertos y de los errores, así que la idea es volcar aquí algunos comentarios que puedan ayudarlos a transitar el difícil camino del cambio en las organizaciones.

Seguimos en contacto.

Sergio

Me sumo a la blogósfera...

2007-05-11T20:19:00.000-03:00

Finalmente, me sumo a esta movida. Espero ir publicando temas interesantes, relacionados con mi trabajo de consultoría.

¡Hasta pronto!