¿Se puede fabricar un experto?

Un experto desde mi punto de vista es perfectamente fabricable, sobre todo si consideramos experto a alguien que sabe más que tú sobre una determinada materia y además se adorna con una serie de características que refuerzan esta imagen.

En muchas ocasiones para vender un determinado producto o servicio, este viene acompañado por un experto o grupo de los mismos que son los que han desarrollado el producto, participan en la actividad comercial o te van a ofrecer el servicio. De esta manera se quiere dar una mayor confianza al posible cliente, ya que detrás de lo que te quieren vender hay auténticos expertos que asegurarán que la implantación del producto o la realización del servicio se realizará con éxito.

Este artículo no va en contra de los expertos reales o fabricados, ni mucho menos, al contrario, ya que me parece una estrategia comercial perfectamente válida y que suele producir buenos resultados.

Como comenté al principio se puede vender como experto a alguien que sabes más que tú sobre una determinada temática, es cierto que es un definición muy generalista, pero también lo es el hecho de que funciona, ya que si alguien conoce más que tú sobre algo, siempre va a parecer que sabe más de lo que realmente sabe. ¿Puede ser esto suficiente? Pues depende, puede darse el caso de que realmente seas experto en algo y no termines de convencer (la mujer del César además de honrada, debe parecerlo) o que seas un «experto fabricado» y hayas llegado perfectamente al cliente. Como es algo que va a depender mucho del cliente (también de las dotes con que se venda al experto o este se venda a sí mismo), lo mejor es reforzar su imagen adornándolo adecuadamente (no comento adorno en sentido peyorativo, ya que en muchos casos los expertos fruto de su propio trabajo o de su interés por colaborar o seguir aprendiendo, consiguen un reconocimento plasmable de diversas formas, como comentaré en el siguiente párrafo).

¿Cómo conseguir esos aspectos complementarios? Pues existen formas muy diversas y algunas de ellas pueden requerir bastante trabajo. Algunos ejemplos pueden ser: hacer publicaciones sobre una determinada materia (desde tener un blog, colaborar en varios, participar de manera activa en algunos, participar en foros y grupos de discusión en redes sociales, publicar artículos en revistas especializadas y conseguir el máximo de referencias en artículos escritos por otros, publicar libros (aunque sea en formato electrónico y permitir su acceso gratuitamente), etc…), participar en «bodas, bautizos y comuniones» relacionados con la materia (con asistir y que te vean la cara ya es algo, pero si se consigue aliñar con la realización de algunas ponencias, mejor que mejor), participar en el desarrollo del producto (que aparezca tu nombre como «contributor» suele tener peso), etc… (es cuestión de echarle un poco de imaginación, para conseguir que tu nombre pueda ir ganando relevancia).

En resumen, un producto o un servicio se vende mejor si vienen acompañados de expertos. Esto puede ser bastante importante en las estrategias comerciales y de marketing, sobre todo teniendo en cuenta que los expertos no son cuatro mentes privilegiadas y cotizadas que andan por ahí, sino que para el propósito del producto y del servicio se pueden «diseñar» a medida, es cierto que esto puede ser fruto de bastante trabajo, aunque dependerá mucho de lo que se quiera vender y del tipo de cliente objetivo.

Chidamber & Kemerer

Shyam R. Chidamber y Chris F. Kemerer enunciaron en el año 1994 un total de seis métricas para la medición de la calidad en el desarrollo de aplicaciones orientadas a objetos: WMC (Weighted Methods Per Class), DIT (Depth of Inheritance Tree), NOC (Number of Children), CBO (Coupling Between Object Classes), RFC (Response for Class) y LCOM1 (Lack of Cohesion of Methods).

En este blog, he analizado alguna de sus métricas (o derivadas de las mismas), como por ejemplo LCOM4 y RFC y más adelante seguiré tratando otras de las que fueron enunciadas por ellos.

Esta definición de métricas no cayó en saco roto y ha sido objeto de estudio y discusión desde su especificación, ya que lo primero que se suele plantear cuando se especifican un conjunto de métricas es si realmente sirven para algo y en este caso se trata de comprobar si realmente a partir de ellas se puede saber si un determinado software o componente del mismo puede presentar problemas que influyan en la calidad o no del software (y en su correspondiente deuda técnica).

Un ejemplo de estudio de estas métricas lo tenemos en la NASA que a finales de 2001, publicó un estudio realizado por el Centro Tecnológico de Aseguramiento de la Calidad del Centro de Vuelo Espacial Goddard (principal laboratorio de investigación de la NASA) que tenía como objetivo encontrar la manera o un método de desarrollar software más barato y con una mayor calidad (finalidad esta que es como la piedra filosofal de todos los que nos dedicamos al desarrollo de software).

Para ello en dicho estudio se pretendía seleccionar, del conjunto de métricas que utilizaban para medir la calidad del código, una serie de ellas a las que denominan conjunto ortogonal de métricas orientadas a objetos. Se les llama ortogonales porque cada una de ellas mide características diferentes del código y su diseño y el aspecto u objetivo que quiere medir una, no se ve afectado directamente por variaciones en el valor de la otra (dicho de otra manera, cada métrica tiene una única interpretación que dependerá intrínsecamente de su valor). El objetivo era obtener un conjunto de métricas lo más reducido posible a partir de la cual se pudiera medir la calidad general de un determinado software orientado a objetos. Este conjunto de métricas coincidía con las especificadas por Chidamber y Kemerer.

Calcularon el valor de estas métricas en tres sistemas diferentes desarrollados siguiendo el paradigma de la orientación a objetos, dos en lenguaje Java y el último en C++, para los cuales se disponía de un etiquetado de su calidad, mediante un análisis previo utilizando el conjunto completo de métricas que se estaban utilizando para medir la calidad del software (que es mayor, como es lógico que el conjunto reducido de métricas que se pretenden obtener). Entre las conclusiones que se obtuvieron se encuentra que este conjunto de métricas podía servir para determinar la calidad de un determinado software orientado a objetos.

Esto vino a refrendar estudios realizados anteriormente (por ejemplo, uno realizado por la Universidad de Maryland) en el que se obtuvo como conclusión que este conjunto de métricas resultaba válido.

Sin embargo, el gran problema que encontramos con estas métricas (sucede lo mismo con otras), es la dificultad de poder comparar los valores que se obtienen para cada una de ellas con otros que nos permitan indicar si el nivel de calidad de la aplicación, de una clase o de un método es el adecuado. Esto además se complica porque habría que tener en cuenta también la naturaleza de la aplicación desarrollada y también los umbrales de calidad que una organización estaría dispuesto a admitir. En cualquier caso, en ocasiones el simple valor que se obtiene para una métrica o la comparación de una misma métrica para dos sistemas distintos permite hacernos una idea de su nivel de calidad. Además existen herramientas que para algunas métricas tienen unos valores umbrales por defecto definidos (los cuales además, suelen ser parametrizables).

Orientación al producto: El feedback de los usuarios

Realizar un mantenimiento o evolución de un producto, de espaldas a los usuarios/clientes del mismo es trabajar a ciegas y cuando se actúa de esa manera, lo más probable es que se esté desarrollando un producto que no se adapta al mercado para el que inicialmente fue concebido, lo cual puede ser un riesgo muy importante, sobre todo si el objetivo no es ese, es decir, si el objetivo no es salir del segmento de mercado con el que quieres trabajar o ampliarlo.

A veces puede que no guste lo que los clientes tienen que decirte, pero mejor eso y tener la oportunidad de rectificar, que encontrarte con que tu producto cada vez se compra menos, perder por tanto cuota de mercado y no tener claro cuáles son los motivos reales (más allá de haber mantenido o evolucionado el producto sin tener en cuenta las opiniones de los que lo compran).

La opinión de los usuarios no sólo debe ser fundamental para el desarrollo del producto, sino que además debe registrarse con el objeto de ser estudiada tanto en el presente, como en series temporales, ya que esto además permitirá estudiar tendencias, lo que también puede proporcionar la capacidad de ser más proactivo y acertar más en esa proactividad.

Obtener el feedback de los usuarios y utilizarlo para desarrollar el producto no es incompatible con planteamientos proactivos, de hecho es recomendable que exista una cierta proactividad, ya que muchas veces aunque se desarrolle un producto acorde a lo que el mercado requiere, si se llega demasiado tarde puede que se pierda mercado. Pero eso sí, la proactividad debe sustentarse como comenté en el párrafo anterior en el estudio de las demandas y necesidades del usuario, además de tener en cuenta la propia evolución del mercado.

RFC y el acoplamiento entre clases

La métrica RFC (Response for class) forma parte, como sucede con el caso de LCOM4 del conjunto de métricas enunciadas por Chidamber y Kemerer y que tienen como objeto obtener valores de referencia sobre el diseño orientado a objetos de una determinada aplicación.

En el caso de RFC lo que se mide es el acoplamiento entre clases, ya que su valor se obtiene a partir del número total de métodos que pueden potencialmente invocados en respuesta a un mensaje enviado a un objeto de la clase, es decir, el número de métodos que pueden ser ejecutados, cuando un método de la clase es invocado.

Dicho de otra manera, vendría a ser el número de métodos de una clase más el número de métodos de otras clases que son invocados por métodos de la clase (no contando más de una vez cada método, es decir si un método de una clase Y puede ser invocado por tres métodos de una clase X sólo se suma una unidad).

¿Qué es el acoplamiento? Es el grado de dependencia entre clases, por lo que cuando nos encontramos con situaciones donde el acoplamiento es alto crecerán las posibilidades de que el mantenimiento de las clases sea más complejo, ya que un cambio en el comportamiento de un método puede afectar a todos los que lo llaman y un cambio de interfaz del método puede provocar la necesidad de modificar el código de los métodos que lo llaman. También se considera que clases con un acoplamiento alto son más complicadas de entender y dificultan las tareas de testeo.

Un ejemplo de acoplamiento, fuera del mundo de la orientación a objetos, lo tenemos por ejemplo en la dependencia entre una aplicación y una serie de objetos (por ejemplo tablas o vistas) de un esquema de base de datos de otra, en este caso, sobre todo si las aplicaciones son gestionadas por equipos distintos y todavía no están lo suficientemente maduras, se correrá el riesgo permanente de que un cambio en el modelado de datos provoque que la aplicación que hace uso de ellos deje de funcionar adecuadamente. Además se podrá ver afectada por otros factores (cambio de instancia del esquema, cambio de sistema de gestión de base de datos, etc…).

El acoplamiento entre clases es inevitable, ya que los objetos cooperan y precisamente ofrecen servicios a través de sus APIs públicas para poder ser utilizados por otros. No se trata por tanto de eliminar el acoplamiento ya que eso no será posible, sino de intentar conseguir niveles de acoplamiento entre clases bajos, ya que permitirán reducir el número de efectos colaterales en el mantenimiento del sistema, haciendo más sencillas estas tareas y reduciendo las tasas de errores en tiempo de compilación y en tiempo de ejecución (cuando se cambian comportamientos a los métodos). Además de tener en cuenta en el diseño de las clases la existencia de un bajo acoplamiento, se pueden utilizar diferentes estrategias, como por ejemplo la creación de clases donde se centralice ese acoplamiento e incluso se implementen en las mismas fachadas que orquesten llamadas a métodos, de manera que tengamos algunas clases que sí tendrán valores altos o muy altos de RFC, pero que a cambio permitirá que se reduzcan el RFC de un buen número de clases.

A través de Sonar se puede obtener la media de RFC de la aplicación, de cada paquete de la misma y del conjunto de clases que la conforman. Se trata de medias aritméticas puras, sin aplicar ningún tipo de ponderación o umbral de valor de RFC de una clase.

Ahora viene la pregunta de siempre en este tipo de métricas, ¿a partir de qué valor se puede considerar que un RFC es demasiado alto?. Como sucede en el resto de métricas (salvo algunas excepciones como LCOM4) hay interpretaciones para todos los gustos, también como sucede con las otras, queda bastante claro cuando un RFC es muy alto y un RFC es muy bajo, por lo que «desde lejos» se pueden apreciar valores que pueden recomendar el estudio del nivel de acoplamiento de determinadas clases. Se pueden considerar aceptables valores de RFC <= 50.

También es posible obtener valores relacionando el RFC de una clase y su número de métodos (NOM). En programas realizados en Java Se pueden considerar aceptables valores de RFC/NOM <= 10.

El coste por hora de los participantes en los proyectos de desarrollo de software

Al final, aparezca por medio o no el taxímetro o se enfoquen los trabajos orientados al servicio, siempre estará de fondo el coste por hora de los proyectos de desarrollo de software.

En este artículo me voy a centrar en el proveedor. El objetivo del mismo será obtener el máximo beneficio posible al proyecto. Además, desde mi punto de vista no debería conformarse sólo con eso, por lo que el objetivo debería ser algo así como obtener el máximo beneficio posible al proyecto, consiguiendo en el cliente el máximo grado de satisfacción posible.

Como satisfacción del cliente y máximo beneficio no van siempre de la mano es necesario intentar alcanzar el mayor equilibrio posible en esa situación y para conseguirlo, además de personas que sepan desarrollar el proyecto (gestión, análisis y construcción) y de tratar y negociar con el cliente de la mejor forma posible, se necesitará que internamente los costes de producción del producto sean los menores posibles, ya que de esta forma el margen será mayor, por lo que se cumplirá el objetivo de obtener un beneficio (incluso importante) en el proyecto, se podría considerar que conseguir un beneficio por encima de un umbral esperado o de un umbral medio de beneficios es equivalente a conseguir los máximos beneficios posibles en el proyecto, es decir, no se trata tanto de alcanzar la cima, como de saber que te encuentras cerca de la misma.

Sobre esto es interesante añadir que dado que todos los proyectos no se venden igual, ni todos los proyectos son iguales y cada cliente es un mundo, mantener unos umbrales de beneficio iguales en todos los proyectos, puede ser considerado incluso una salvajada, ya que existirán proyectos donde para acercarse a esos umbrales o incluso para intentar que las pérdidas sean las menores posibles, habrá que hacer un sobreesfuerzo descomunal por parte de quienes participen en los mismos. No digo que no sea interesante fijar un umbral a partir del cual el beneficio se considere aceptable, ya que sin referencias todos nos perdemos, sino que en determinados proyectos que se sabe a ciencia cierta desde que se ganan o desde que suceden unos determinados eventos en el mismo que no se va a poder conseguir, se planteen unos objetivos realistas a su naturaleza que incluso puedan ser complicados de cumplir, pero por lo menos que no sean imposibles. El problema estará si esto que debería ser una excepción se convierte en la norma, en este caso hay un problema y muy serio.

Volviendo a la reducción de los costes de producción se puede conseguir de diversas maneras, como por ejemplo: utilización de generadores de código, reutilización de código (incluso de bloques enteros de software) y documentación, subcontratar partes del proyecto a otras empresas que tienen menores costes de producción y por supuesto utilizando de la forma más adecuada los recursos humanos de la organización, de manera que el personal asignado al proyecto sea el más apropiado acorde a las tareas que hay que realizar. Esto por supuesto no es fácil, ya que no sólo requiere de la capacidad de acertar con el personal, sino que además éstos estén liberados de un proyecto, puedan ser compartidos con otro proyecto o se puedan desasignar de aquel o aquellos en los que esté trabajando. Por tanto, es más realista indicar que hay que saber elegir lo mejor posible de aquellos que en cada momento sean elegibles (más tarde lo mismo quedan liberados recursos que pueden ser de utilidad, por lo que no se trata de una elección estática, ya que de la misma forma que los proyectos son algo vivo, también lo puede ser el equipo de personas que trabaja en el mismo).

Uno de los aspectos, que desde mi punto de vista debe ser tenido en cuenta a la hora de elegir el equipo es tener conocimiento de las tareas que hay que realizar en el proyecto y de las exigencias a nivel de calidad del cliente. Supongamos que el proyecto es técnicamente simple, si el proyecto es así, no se requirirá de personal con una altísima cualficación para realizarlo, ya que lo mismo este personal es capaz de realizar las tareas dos veces más rápido, pero lo mismo, su coste por hora es demasiado alto y es más interesante tenerlo en proyectos más complejos o en proyectos donde se puedan obtener mejores márgenes. Incluso si se decide para un desarrollo de esas características contar con personal de altísima productividad en la codificación (y por ello, supuestamente con un salario acorde a esas características y por tanto con un mayor coste por hora), no querrá decir que algunas tareas consideradas más simples o triviales no puedan ser desarrolladas por personal que todavía no tiene esa cualificación y por tanto con un coste por hora menor, de manera que ese recurso se centre en los aspectos más problemáticos o pueda ser compartido por más proyectos.

Sin embargo, si para la realización del proyecto se hubiera optado por personal de la organización con altos costes por hora o que la dedicación de estos al mismo fuese mayor que la necesaria, salvo que el proyecto estuviera muy bien vendido y/o que la productividad del equipo hubiera alcanzado cotas muy altas, conseguir el umbral de beneficio esperado podría considerarse como algo quimérico y de esta forma al esfumarse el margen que podría permitir cierta flexibilidad con el cliente y un esfuerzo para intentar conseguir un producto con la mayor calidad posible, empezaría a peligrar ese equilibrio entre beneficios y satisfacción del cliente, hasta el punto de que no haya ni lo uno ni lo otro.

Analizar a posteriori, ¿es ventajista?

En muchas tertulias de fútbol, se critica diciendo que son ventajistas a aquellos que realizan un análisis de un partido, de una alineación o de unos cambios una vez que éste ha finalizado y se conoce el resultado y lo efectivas que fueron las decisiones que se tomaron.

No estoy de acuerdo con dichas críticas porque el análisis que permite sacar conclusiones es el que se realiza a posteriori ya que permite observar el resultado de aplicar una serie de decisiones, comportamientos y trabajso sobre una determinada tarea u objetivo, ¿acaso se puede hacer una crítica de una película sin haberla visto antes?, ¿son ventajistas los críticos de cine?.

A posteriori uno se da cuenta de los errores que ha cometido y piensa, ¿cómo es posible que se me haya escapado esto o aquello?, ¿cómo es posible que haya cometido esos fallos?, pese a que pueda dar rabia, tanto si es autocrítica como si la crítica viene del exterior, es lo que hay, se ha podido hacer mejor, siempre es posible hacerlo mejor, pero hay que ser consecuentes con los resultados y aprender de los errores, ya que de esta manera será posible el crecimiento.

A veces ganando se pierde y perdiendo se gana

Ganar y perder pueden parecer términos absolutos, algo binario, o se gana o se pierde. Pero, ¿realmente es así? Pues depende de lo que se ha ganado y de lo que se ha perdido y de cómo se ha ganado y de cómo se ha perdido.

Por este motivo, a veces una victoria es la antesala de una serie de derrotas y una derrota la antesala de una serie de victorias.

Visto de esta manera ganar y perder en términos discretos puede ser algo binario, sin embargo, el tiempo no se detiene en esa victoria o en esa derrota y de cómo hayamos salido de las mismas y del aprendizaje obtenido de ellas dependerán mucho los próximos resultados.

En la euforia de la victoria y en la fustración de la derrota, siempre debe quedar margen para la humildad, porque a partir de ella siempre se puede construir, porque parte del reconocimiento de que siempre es posible mejorar y que esa mejora requiere de más de nosotros mismos.

Las dudas no son productivas

No es malo dudar ya que en muchas ocasiones no se tiene clara cuál es la mejor opción. Es mejor, a veces, pensar sobre las alternativas antes de tomar una decisión.

¿A partir de cuándo una duda deja de ser productiva? A partir del momento en el que el tiempo necesario para tomar la decisión supera un máximo tolerable (o cuando no se toma una decisión). ¿Cuál es el máximo tolerable? En muchos casos no hay un límite temporal para decidirse por una de las opciones, en otros sí. En el caso de que no se tenga un umbral de tiempo claro, ya será el instinto de cada cual el que empezará a notar cuándo se está empezando a perder demasiado tiempo (tanto a él mismo, como a las personas que dependen de sus decisiones) y lo que es peor a que se pueda llegar demasiado tarde a algo por no haber tomado la decisión en el momento en que se debería haber tomado y que ese llegar demasiado tarde suponga perder un negocio, no cumplir unos plazos o cualquier otro aspecto que tenga consecuencias negativas.

Si no se tiene el instinto para notar cuándo se está empezando a dudar demasiado o no se adquiere con la suficiente experiencia, quiere decir que esa persona no está capacitada para tomar decisiones en su ámbito de actuación, por lo que otra persona debería tomarlas por él y por tanto no está preparado para tener el puesto que tiene. Eso no quiere decir que la persona no pueda ser válida para la organización, lo mismo lo es y mucho, pero en otro puesto donde sí se le pueda sacar partido a su verdadero potencial.

La toma de decisiones están en el sueldo y por tanto en él está la posibilidad de equivocarnos y atenernos a las consecuencias. Yo considero que es peor no tomar una decisión que equivocarse por haberla tomado, aunque supongo, que opiniones sobre esto habrá muchísimas.

Un software sin incidencias

Si de un determinado programa no se reciben incidencias, consultas o quejas pueden pasar dos cosas: que está muy maduro o no se utiliza (o tiene un nivel de uso prácticamente marginal).

Por regla general y desde mi experiencia, cuando se dan este tipo de circunstancias, es la segunda opción la que prevalece, ya que los usuarios de un software que se utiliza siempre dejan tras de sí ruido, poco o mucho, pero ruido al fin y al cabo, y suele ser, además, directamente proporcional al número de usuarios que lo utilizan, la rotación de los mismos y la complejidad del sistema.

Por este motivo, cuando una de las aplicaciones que coordino no genera este tipo de tráfico lo tomo siempre como una señal de alarma ya que lo más probable es que haya algo que no terminase de ir bien, ya sea la aplicación, la gestión del cambio, las directrices de uso de la herramienta, la atención a usuarios, el proceso de mantenimiento correctivo y evolutivo o una combinación de esos factores y otros muchos que pueden intervenir.

Ley de Parkinson

La Ley de Parkinson enuncia que: «el trabajo se expande hasta llenar todo el espacio de tiempo disponible para completarlo».

Me parece muy interesante reflexionar sobre esto porque esta forma de actuar que es muy común en todos nosotros repercute directamente sobre nuestra productividad.

Esta Ley está intimamente ligada al Principio de Pareto, pese a que no habla de proporciones entre esfuerzo y resultado, ya que viene a decir que cuando no se dispone de fecha de fin para realizar una tarea o esta es superior a la que realmente necesitaría para realizarse, ésta tiende a dilatarse buscando conseguir mejoras que realmente aportan muy poco para el esfuerzo que requieren.

Por este motivo, es muy importante plantearse plazos realistas (no sobredimensionar) para realizar las tareas, si bien no todas, sí aquellas que sean repetitivas y aquellas otras que sean más urgentes o prioritarias en cada momento, de lo contrario, como nos sobra tiempo, terminaremos perdiéndolo, sacándole brillo a algo a lo que no le hace falta, revisando aspectos que no requieren revisión y en general, realizando actividades que no suelen servir para nada y que si bien nos puede hacer sentir activos, la realidad es que hubiéramos aprovechado mejor ese tiempo con otra tarea o simplemente viendo en la tele nuestra serie de televisión favorita.

Y lo peor de todo es que nos damos cuenta de que estamos perdiendo el tiempo y no le ponemos solución (¿o no hemos tenido esa sensación cuando por ejemplo estamos revisando una presentación y empezamos a añadirle o a cambiarle imágenes, a mirar si el texto está perfectamente alineado, si es mejor dividir una diapositiva en varias (o al revés), etc…?.

Es muy importante comprender que el esfuerzo por alcanzar la perfección no merece la pena, por un lado porque nunca vamos a llegar a conseguirla y por otro porque llegado un punto, para avanzar muy poquito hay que invertir un esfuerzo que no se corresponde con los logros que se van a obtener.