Un apretón de manos

En el mercado de competencia perfecta los compradores tienden a aumentar las cantidades compradas de un producto conforme su precio baja y a bajarlas cuando sube, mientras que los vendedores se comportan en forma inversa: aumentan su oferta cuando el precio sube y la retraen cuando éste baja. Así el mercado va encontrando su punto de equilibrio, que es el precio donde los vendedores ofrecen la cantidad de bienes que los compradores demandan. Este mecanismo fue descrito por Adam Smith, quien habló de la increíble capacidad de autorregularse de los mercados, como si estuviesen guiados por una mano invisible.

Sostienen los economistas neoclásicos que el mercado es la forma más eficiente de asignar recursos y que los problemas que ocurren en el mercado se deben precisamente a los intentos gubernamentales de regularlos (y no a la ausencia de regulaciones). Yo encuentro la primera parte de la afirmación más fácil de sostener que la segunda, sobre todo con las noticias de estos días. Los neoclásicos levantan su dedo índice y apuntan al cielo invocando a dios como testigo y nos recuerdan que ellos hablan de los verdaderos escoceses, (sigo teniendo pendiente el post sobre falacias argumentales) pero no es este el tema que quiero abordar, así que volvamos al hilo.

La mejor crítica que se le puede hacer a la idea del mercado de competencia perfecta es que no existe la información perfecta, que los bienes y servicios sí son distinguibles unos y otros y que hay sesgos psicológicos que hacen que los humanos prefiramos algunas cosas sobre otras (sin perjuicio de que las grandes sumas de capital necesario para entrar a proveer determinados bienes o servicios hacen que haya pocos proveedores para muchos compradores). La divergencia entre el mercado real y el mercado de competencia perfecta es, en mi opinión, particularmente notable en el mercado de trabajo.

El mercado de trabajo es ese donde empresas y trabajadores confluimos. Según la idea del mercado de competencia perfecta, cuando la demanda de bienes y servicios baja, las empresas demandan menos trabajadores, lo que haría caer al precio del trabajo (salario), manteniendo el nivel de ocupación. Como eso no ocurre en la realidad y existe ese temita que la teoría clásica no explica muy bien llamado desempleo, la culpa, para nuestros simpáticos amigos amantes de los verdaderos escoceses es de los sindicatos y regulaciones que no dejan que el salario (nominal) caiga, y entonces cae el nivel de empleo.

El mercado de trabajo pudo haberse ajustado a un modelo de mercado regulado por la mano invisible unos cuantos años atrás, antes de la especialización y del enorme peso del conocimiento en la productividad de los empleados. Puedo encontrar muchas diferencias entre el modelo y la realidad, particularmente en aquellas actividades donde el talento (o al menos el conocimiento y la especialización) de las personas es un valor clave para la empresa (el software, por ejemplo).

El empleador invierte tiempo y dinero en el empleado. Lo forma en la manera de hacer las cosas que la empresa ha ido adoptando, apoya su crecimiento profesional, se beneficia de un trabajador cada vez más calificado. El empleado a su vez, también invierte mucho en la empresa (yo diría que más que la empresa en él, no puedo ser objetivo): invierte su renuncia a otras posibilidades de ganarse la vida, invierte tiempo valioso de su vida, invierte sus conocimientos adquiridos con mucho esfuerzo. La ruptura de la relación laboral perjudica a ambos, particularmente si la relación no es reciente (por supuesto, el empleado es la parte más débil y es lógico que esté protegido por la ley).

Así, es probable que la dirección de la empresa se resista hasta último momento a desprenderse de los talentos, de esas personas cuyo conocimiento y habilidad constituyen un activo importante. Como ejemplo, podemos pensar en aquella gran crisis que vivimos por estas pampas hace no mucho: las empresas perdieron más facturación (y margen) que nómina. Esto ocurre, en parte, porque en la empresa existe la expectativa de que las cosas se recuperen y, en tal caso, el conocimiento no va a ser facilmente reemplazable.

Hay más en la ecuación que diferencia al mercado de trabajo del modelo regulado por la mano invisible: la asimetría de la información. Si quiero ir a trabajar a otra empresa, ellos no conocen de la lista de logros que he conseguido en la empresa donde estoy actualmente: los puedo contar yo, pero entiendo no ser una fuente demasiado confiable y objetiva sobre mí mismo. Por eso, salvo casos excepcionales, no me van a poder pagar en función de mi experiencia para un puesto similar. Ahora, yo tampoco los conozco a ellos: no se si me adaptaré a su forma de hacer las cosas, no se si mi futuro jefe tendrá los mismos valores que yo. Ambos ignoramos cosas que el otro sabe. Y por eso, ambos queremos cubrirnos con un margen en la remuneración, solo que, obviamente, en sentido opuesto.

Arthur Okun definió esto como un apretón de manos entre empresa y empleado (no encontré ningún artículo que describa rapidamente la tesis del libro).

Como decíamos antes, el apretón de manos, por su propia naturaleza, no deja a las empresas en una posición de absoluta ventaja. Un empleado que ha crecido en una empresa, del que sus superiores conocen sus fortalezas y debilidades, que ha formado su perfil profesional en esa empresa no puede ser reemplazado por el mismo costo. Si este se fuera, la empresa se vería en la obligación de elegir entre pagar más para cubrir la misma posición o pagar lo mismo pero afrontar la incertidumbre sobre el desempeño de quien viene a cubrir la vacante (por ejemplo, por una promoción interna).

Y aquí viene algo así como el reclamo sindical: muchas veces, los empleados recibimos como respuesta tácita o explícita de nuestros empleadores la frase "estás pagado acorde al mercado". Ahá. No me digas. Me estás queriendo decir que yo no conseguiría facilmente un salario superior al que gano por el trabajo que hago en otra empresa o que vos me reemplazarías al mismo costo?. Porque una cosa puede ser cierta, pero la otra no lo es.

Recordar que nuestra relación es un apretón de manos, tanto cuando uno está en posición de defender los intereses de la empresa, como cuando uno está defendiendo los suyos propios, podría contribuir a mejorar enormemente el nivel de satisfacción de los empleados con las empresas, y de las empresas con los empleados.

En el medio del diablo inventó el body shopping. Y sobre eso, no voy a repetir lo que tan bien dice don M. aquí sobre el hijo bastardo de la necesidad de dibujar ciertos indicadores para parecer más eficiente. Dije que no iba a decir nada. Y no pude cumplirlo.

Engañemos a la realidad

Hace un tiempo, hablábamos de Richard Feynman. Feynman fue una persona notable, pero no haremos otra biografía suya aquí, la red está llena de ellas. Un comentario que dejé en un post de Dirección de Proyectos hablando de él fue seguido por una magnífica entrada en ese mismo blog sobre lo que un físico puede aportar a un gerente de proyectos, y eso me motivó a seguir hablando del tema.

Feynman participó en la comisión que investigó el desastre del Challenger, y luego de un informe impecable, concluyó con una frase que debería ser leída y releida por cualquier persona vinculada la gestión de proyectos: "para crear tecnología exitosa, la realidad debe prevalecer sobre las relaciones públicas, porque la naturaleza no puede ser engañada"

Esa frase, que deberíamos tener tatuada en el cerebro, es el corolario del informe que decíamos, donde profundiza sobre las causas últimas del desastre del Challenger. La historia se cuenta en una excelente entrada del blog Historias de la Ciencia. Para los que no tengan ganas de leer el post de Historias de la Ciencia, se puede ensayar una explicación rápida: el Challenger explotó porque las juntas toroidales (unos anillos que aislaban los segmentos de los cohetes aceleradores de combustible sólido) perdían su resistencia cuando antes del lanzamiento eran expuestas al frío (por ejemplo, al frío de una mañana de invierno), cosa que la NASA sabía (o al menos, tenía buenos motivos para intuir).

Para los que no tengan ganan de leer el post de Historias de la ciencia y piensen que con los dos renglones anteriores alcanza, vayan y lean el post de Historias de la ciencia: es uno de los mejores post de uno de los mejores blogs

Ahora bien, como bien nota Feynman, las juntas toroidales no aparecieron ahí por arte de magia. Tampoco es que hayan estado funcionando como violines bien afinados antes del desastre. Feynman dice que bajo este hecho (esto es, la erosión de las juntas), se escondían unas cuantas debilidades organizacionales (desidia, presión por mostrar resultados), que, en definitiva, crearon el medio ambiente donde el problema de las juntas toroidales pudo aparecer y desarrollarse hasta ser un gran desastre.

El informe en minoría de Feynman en la comisión Rogers me genera cierta sensación de familiaridad, no porque haya trabajado en la NASA o porque me haya explotado algún que otro transbordador espacial. Por supuesto que el recorrido que haremos aquí del informe es liviano y no es excusa para dejar de leerlo entero.

A continuación, las partes del informe que más me han chocado.

El informe cita a los oficiales de la NASA diciendo que, dado que el transbordador es un vehículo tripulado "la probabilidad del éxito de la misión está necesariamente cercana a 1". Esto se llama wishful thinking y nos genera cierta perplejidad que la NASA diga que algo es seguro porque dado que lleva humanos dentro, debería ser seguro. Luego de la sensación de repulsión que nos produce tal muestra de pensamiento irracional de nada menos que los oficiales de la NASA, pensemos las veces que hemos esperado que un software funcione solo porque si no funciona nos echan a todos.

Sigue mencionando Feynman que las juntas toroidales ya habían mostrado erosión en vuelos anteriores. Dado que la erosión solo había llegado a un tercio del radio de las juntas, se concluyó que se estaba operando con un coeficiente de seguridad de tres (la erosión tenía que triplicarse para que la junta cediera). Feynman dice que "el equipo no estaba funcionando como se esperaba, y existe por lo tanto el riesgo de que pueda operar con desviaciones aún más grandes y no completamente comprendidas. El hecho de que un peligro no haya llevado a una catástrofe anteriormente, no garantiza que no lo hará la próxima vez, salvo que éste sea completamente comprendido". Otra vez la NASA dando muestras de wishful thinking y desidia. De nuevo, al asombrarnos de la falta de rigor ajeno, no perdamos de vista que, al mirar comportamientos anómalos del software que desarrollamos, solemos tranquilizarnos pensando que igual son casos esporádicos o poco comunes, o que hay mucho margen para ese aumento de memoria tan raro.

Más allá de las juntas toroidales, el informe en minoría (el informe de Feynman fue en minoría: solo lo firmó él) se ocupa del diseño del motor principal del Challenger, aparentemente no involucrado en el desastre. La forma de diseñar motores de este tipo consiste en ir ensamblando los componentes en una estrategia bottom-up, de forma que cuando se detecta un problema en un componente a un determinado nivel de integración, se puede corregir antes de pasar al próximo nivel de integración. Si algún problema surge en algún momento, se puede aislar y corregir, porque el problema está en aquello que se ha incorporado en el presente paso. El diseño y desarrollo del motor principal del Challenger siguió un procedimiento top-down: el motor se diseñó y se lo ensambló todo junto con pocas pruebas unitarias, lo que dificultó el proceso de encontrar y corregir errores.

Adicionalmente, los procedimientos de certificación se volvieron dudosos: una turbina con una fisura luego de un determinado tiempo de prueba en el banco de pruebas representa una prueba no superada para la FAA. Bueno, para la NASA si las fisuras no habían llevado a una fractura, la prueba había sido exitosa. El que nunca haya participado en un proyecto donde no existían pruebas unitarias, donde los componentes no se podían probar en forma aislada y donde se había redefinido el concepto de 'prueba superada' que tire la primera piedra.

Y por último, el hardware y software de aviónica. El proceso de prueba y verificación del software era estricto y seguro (más allá de que algún iluminado quería recortarlo porque tanta seguridad no era necesaria: la prueba de que tanta seguridad puesta en el desarrollo del software no era necesaria era que el software nunca había generado ningún problema), pero había un problema: el proceso de cambio en el software era tan complicado, que nadie se animaba a reemplazar el hardware y éste, para 1986, ya era obsoleto. No se si alguien le suena esta situación. A mí sí.

No pretendo yo agotar las lecturas de un informe producido por muchos años de experiencia de alguien de la talla intelectual de Feynman. Sin embargo, su lectura nos ha servido para tratar de extender por la organización los siguientes conceptos:

• No pienses que las cosas van a salir bien porque no te merecés las consecuencias de que salgan mal.
• No decidas que cierta anomalía es perfectamente aceptable y que no vas a invertir esfuerzo en corregirla sin antes explicar y explicarte el mecanismo que lleva a la anomalía observable. Puede haber una bomba atómica bajo la alfombra.
  
• Diseñá de abajo hacia arriba, probando cada componente independientemente y preparate para el proceso de debug, que va a hacer inevitable.
  
• Diseñá para el cambio: la plataforma de hoy tendrá que ser reemplazada mañana.

Y se honesto, porque, al fin y al cabo, la naturaleza no puede ser engañada.

Diseñando experimentos o experimentando diseños

Hubo un tiempo que fue hermoso, y fui libre de verdad. En ese tiempo era un técnico, me perdía entre arquitecturas y optimizaciones, y las fechas, rentabilidades, calendarios, ofertas no eran mi problema. Mi responsabilidad se limitaba a aquellas cosas que hacía yo directamente. Estaba en la gloria. Además, como solo mi trabajo era mi responsabilidad, podía hacerme el vivo.

Magnificadas y embellecidas por la memoria, de esa época tengo recuerdos como el que sigue.

Una programadora del equipo se acercó a D., intuyendo lo peor. No se por qué se acercó a D. , siendo que yo era la interfaz más amable de ambos y nos sentábamos uno al lado del otro (yo era algo así como el arquitecto de aplicaciones y D. el de base de datos). Ella, que sabía lo que seguía, le dijo a D.: "esta query anda lenta" y se dispuso a aceptar con resignación su destino. D. ni siquiera levantó la cabeza del monitor y dijo "ahá. y que querés hacer..." (D. siempre citaba a Tom Kyte diciendo "no optimices queries, comprendé la pregunta").

Hasta aquí, la morocha (dije que la programadora era morocha?. Bueno, era morocha y de ojos verdes) tenía una oportunidad. No es que D. fuera muy amable, tampoco es que la curvilinea figura de esta chica lo conmoviera, sino que él siempre intentó ser justo. Ella no se dio cuenta que tuvo una oportunidad de ser rediminda y dijo "no, es que quería ver si desde la base podíamos hacer algo para que ande más rápido". Era exactamenet lo que D. estaba esperando para reconfirmar que toda oportunidad otorgada es una pérdida de tiempo: "algo así como poner el parámetro turbo=true? no, todavía no existe. Te aviso cualquier cosa".

Se puede decir que D. era (es) un tipo áspero. Que no hay necesidad de andar presumiendo de lo que uno sabe, porque uno en algún momento uno tampoco supo. Pero creo que en esta oportunidad el problema no era con la ignorancia, sino con un concepto problemático: la performance no importa, la performance se agrega después, es como la cobertura de un helado, y además es algo que depende del DBA.

A D. lo irritaba esa postura. A mí también. El origen de mi molestia tiene que ver con que considero que no se puede evitar el pensar la arquitectura al principio del proceso de desarrollo del software (lo que no implica, claro, que uno no tenga que pensarla durante todo el proceso), no importa cuan ágil sea uno (de todas formas, el paso de planear la arquitectura se evita más por desordenado que por ágil, se reconoce desde la comunidad ágil que la fase de architecture envisioning es necesaria), particularmente si uno no quiere encontrarse al final del proyecto con que algo anda más lento de lo esperado, o algo peor.

Se podría argumentar que ese no es un problema hoy en día: hay arquitectos, fases para definir la arquitectura, sectores de arquitectura, libros sobre arquitectura y toda una parafernalia sobre el asunto. Me permito pensar que todo eso, o bien es insuficiente, o bien está mal dirigido.

Volvamos al principio, que es la arquitectura?. Yo tengo una definición de arquitectura: “la arquitectura de un sistema es el conjunto de decisiones de diseño que tienen un impacto profundo en la calidad del mismo” (en realidad, como todos las cosas que valen la pena, ya alguien la pensó antes).

Por eso, creo que la fase de pensar la arquitectura, de decidir las características más importantes del sistema antes de comenzar la construcción y no esperar que las decisiones tomadas por un grupo de desarrolladores sobre la marcha sean acertadas, es ineludible. De todas maneras, creo que una vez más conviene bajar a detalle y preguntarse que significa obtener una visión de la arquitectura. No creo que unos modelos en papel alcancen para tomar decisiones importantes, particularmente cuando uno incorpora componentes nuevos (no recuerdo ningún proyecto en los últimos años en los que no haya tenido por lo menos un componente nuevo). La solución viene dada por construir diseños experimentales que sometan a la arquitectura propuesta a condiciones extrapolables a las que soportará una vez implementada.

Las características que normalmente deseo observar al someter a una arquitectura a un experimento son:

• El comportamiento bajo alta carga.
• La posibilidad hacer andar en forma aislada los componentes, como forma de poder detectar y corregir problemas una vez que esté el sistema implementado.
• El comportamiento ante situaciones límite, como caídas de equipos, operaciones maliciosas, errores en otros componentes.
• La facilidad de implementar cambios en la arquitectura (reemplazar un componente por otro).
• Cierta seguridad sobre la estabilidad de los componentes. Si bien no tengo demasiado cariño por la costumbre de gritar ‘hay un bug en Oracle’ ante el primer error que uno cometió en una query, me he encontrado con algunos productos open source con algún que otro error (un memory leak, por ejemplo). Y me he encontrado con que MS se pasa algunos estándares por el forro, y agrega algunas condiciones a las del estándar....
• Y el más importante, nuestras suposiciones sobre el funcionamiento de lo que vamos a usar son razonables? O sea, podemos estar seguros que, al menos en lo importante, nuestro diseño no va en contra de algunas limitaciones de la tecnología?
  

Bien, el problema es que esto es mucho más fácil de enunciar que de hacer. Diseñar un experimento significativo y a la vez sencillo es una habilidad que requiere conocimiento, práctica, y hasta diría que talento. Si es difícil hacerlo, escribir unas guías sobre como hacerlo es aún más difícil, pero concluímos que hacer el esfuerzo (más adelante explico el por qué, además de porque consideramos que aporta valor) de explicitar algunas guías para definir experimentos valía la pena. Acá va un resumen de los pasos de la guía:

1. Identificar las interfaces relevantes: pueden ser algunas pantallas, mecanismos de IPCs e integración (colas de mensajes, web services)
2. De las pantallas identificadas, abstraer la presentación y pensar unicamente la interfaz de la operación
3. Desplegar el software de base. Acá me refiero a desplegar todo el software de base, no un poco, particularmente si uno no lo conoce. Me refiero a base de datos, appl. server, broker de mensajes, todo.
4. Implementar mocks de cada interfaz relevada. El mock, de acuerdo a cada caso, puede ser una clase que simplemente no haga nada y tenga un sleep o similar para simular el delay de procesamiento o una clase que haga algunas operaciones contra el soft de base, sin mayor lógica, simplemente para obtener tiempos reales de operaciones en el soft de base
   
5. Conseguir un simulador de carga (o hacer al menos un par de scripts en ant, nant o shell) que tire transacciones.

A partir de ahí, ir variando las condiciones y ver que sucede (algunas ideas):

1. Ejecutar lo construido en (5) y verificar límite de capacidad de procesamiento (ese momento donde las colas no entran en régimen: al margen, la utilidad de los modelos de colas para el análisis de performance, tema para otro post)
2. Bajar intempestivamente un componente y ver cuan fácil es determinar el problema
3. Determinar que posibilidad hay de ejecutar aisladamente un componente construido sin el software de base (obviamente, con máquina virtual y sistema operativo, unicamente)
4. Medir el consumo de memoria de los componentes, particularmente de los nuevos (si pusimos un nuevo framework, medir el consumo de memoria en la máquina virtual, por ejemplo)
   

Un experimento (o prueba de concepto, o como se desee llamarlo) es un entorno controlado donde podemos generar variaciones planificadas y observar los resultados. Es sencillo de enunciar, pero diseñar un experimento razonablemente significativo es algo que requiere práctica, conocimiento del dominio y no se si talento natural ( sí, se que todo parece indicar que no somos una tabla rasa, pero tampoco es que don Pinker se haya impuesto por tanto).

Aún así, y dado que teníamos que cumplir, pensamos que sería útil hacer el esfuerzo de escribir un manual, o al menos unas guías, que ayuden a quien tenga que hacerlo a diseñar un experimento. Al fin y al cabo, que sea difícil de aprender, no significa que no valga la pena de ser enseñado, no?

Por qué todo esto?. Basicamente porque existe en CMMI L3 un área de proceso llamada ‘Decision Analysis and Resolution’. Como además de la certificación siempre tuvimos como norte que el proceso sirva, además, para que mejoremos la calidad de nuestros productos, nos atrevimos a perder tiempo pensando en el proceso de desarrollo además de la estrategia para el SCAMPI.

En la próxima parte de este post veremos como encaja esto en la process area de 'Decision Analysis and Resolution'.

La pregunta más estúpida

El Large Hadron Collider es una magnífica oportunidad para que un montón de gente muestre el grado de su imbecilidad. Me siento en la obligación de aclarar una obviedad: imbecilidad no es ignorancia. Es perfectamente normal, lógico, entendible, no entender qué se está buscando con el LHC ( recomiendo seguir el link si se desea una explicación sencilla y rápida del LHC) porque la física de partículas es realmente compleja (y aunque Mario Bunge se enoje, yo diría que es terriblemente antiintuitiva). Lo que constituye imbecilidad es decir, como una conductora de televisión que esta mañana he tenido la mala suerte de escuchar (solo por querer saber la temperatura exterior antes de salir de casa), que es contradictorio que se llame la máquina de dios cuando están tratando de demostrar que dios no existe.

Sin llegar a las cotas increibles de estupidez que ha demostrado esta mujer, se puede plantear una pregunta estúpida, la pregunta más estúpida: para que sirve todo eso?. Esta pregunta no es estúpida cuando es sincera y el post de Dirección de Proyectos linkeado más arriba la responde. Esta pregunta es estúpida cuando va acompañada de un dejo de crítica porque "con todos los problemas acuciantes que tenemos que resolver, gastar tanto dinero en eso... que terrible".

No voy a negar que tenemos problemas acuciantes que resolver, pero es ridículo pretender saber con anticipación la utilidad de la investigación básica. Es incluso probable que no la tenga, pero solo podremos encontrar conocimiento útil si buscamos conocimiento, a secas. Me sorprende lo poco extendido que está este concepto, incluso entre gente que aceptaría que un negocio con una rentabilidad garantizada a priori es una quimera (o una estafa). Bueno, la investigación es un negocio sin rentabilidad garantizada a priori, pero con una historia de éxitos impresionantes.

Me gusta la anecdota que cuenta Steven Weinberg en "El sueño de una teoría final": la reina de Inglaterra, luego de recorrer el laboratorio de Michael Faraday y asombrarse con unos juguetitos electricos, le preguntó a éste: y todo esto para qué sive?. Faraday le dio la mejor respuesta que he escuchado a esta pregunta: y para que sirve un recién nacido, majestad

Sin llegar a lidiar con cosas de la complejidad del CERN, me gusta trabajar en empresas que entienden que la investigación es, por un lado necesaria si se pretende mejorar el estado actual de las cosas, y por el otro que no se puede saber a priori para que servirá el conocimiento obtenido.

Para qué sirve el libro que estás leyendo?. No deberías leer libros en el horario de trabajo, tenemos demasiado que resolver antes de empezar a investigar.

El valor ganado

Scott Ambler, entre otros, critica el uso de Earned Value como métrica para los proyectos de desarrollo, y como siempre, con muy buenas razones:

• Se tiende a asumir que toda tarea realizada es valor ganado, así, por ejemplo, llegamos a que ganar el 90% del valor nos cuesta el 90% del esfuerzo y el último 10% de valor otro 90% ( me encantan esos proyectos donde siempre estamos finalizando.)
• Es difícil usar el EV para el software, ya que el nivel de interdependencia de los componentes es alto.

Repasando el earned value, la forma de calcularlo es asignarle un valor a cada tarea, definir una política de suma (es decir, si puedo sumar un 50% de la tarea o solo sumo tareas completas), y luego, con el avance, recolectar lo terminado y hacer una suma de los valores de cada tarea terminada.

Yo siempre pensé que me gustaba el Earned Value, de hecho, iba a escribir un post para defenderlo. Lo que ocurre es que estuve años diciéndole Earned Value a otra cosa. Suele pasar, sucede lo mismo cuando digo que soy liberal y me saludan como compañeros de ideología cada personaje... (no, no voy a hablar de política, pero soy liberal, humanista, y ... bueno, si les interesan sigan los links al think tank de Paul Kurtz ).

Volviendo, mi earned value se basa en lo siguiente:

• Primero, no toda tarea aporta valor. Hay tareas necesarias para laburar pero que, luego de terminarlas, no tengo algo de software que mostrar. Sería delirante decir que tengo dos mil pesos de earned value porque terminé de conectar mi entorno de desarrollo. Después de tener mi entorno de desarrollo up & running, mi earned value es cero. Todavía no gané ningún valor.
• Yo entrego productos, no tareas cumplidas. Por lo tanto, el earned value se incrementa cuando termino una parte del producto, no cuando termino una tarea (y por cierto, terminado es terminado, no es terminado pero me falta probarlo)
• Lo que me dice cuan cerca estoy del objetivo es la distancia que me separa del mismo, no cuanto recorrí para llegar a él. Mi objetivo no es estático, aún cuando trabaje con BRUF, ya que manejo el cambio. Entonces, mi EV no lo voy a comparar con la estimación original, sino con la estimación actual de acuerdo a la configuración actual del producto que debo entregar
• El software sí puede dividirse en piezas: si tengo una lista de componentes a realizar, un diseño de alto nivel y una lista de funcionalidades, es que cada una de esas tiene alguna entidad propia. Y como tal, puedo decir que cada una de ellas está implementada o no está.

Claramente, en un proyecto ágil 'puro', donde no se cierren los requerimientos al principio, el earned value no tiene sentido. Pero como argumenté en otro post, me veo obligado a trabajar con lo que Ambler llama BRUF.

Y así tengo un gráfico con una linea que representa el valor actual del producto a construir (es decir, la sumatoria del valor de todos los componentes que representan la configuración actual del producto a construir) y una linea que representa el valor ganado (la valorización de aquellos componentes terminados y útiles para la configuración actual del software). Esto implica, claro, que el valor ganado puede bajar y que el objetivo no es estático. Acá hay un ejemplo del gráfico en cuestión:




Por supuesto, hay más datos que tal vez valgan la pena volcar en el gráfico (la valorización de las tareas que no aportan valor directamente al producto, por ejemplo), pero por ahora lo uso así.

La forma de medir el avance de un proyecto siempre es un tema complicado. Lo que subyace, me parece, es uno de los dos grandes problemas que también subyace al tema de las estimaciones: no tenemos una buena forma de medir el tamaño del producto de nuestro trabajo (como nota al margen, no creo que lo ignoremos por tontos, sino por recién llegados).

Y esto que tiene que ver con el earned value?. Bueno, para mí es el earned value: es el valor que logré ganar. Ah... que la definición era otra?. Bueno, podría ser. Ya comenté que soy liberal?