Conflictos de intereses entre equipos de desarrollo y auditorias

Las actividades auditoras y evaluadoras (bug testers, Q&A, usabilidad, etc.) y el trabajo de desarrollo son tareas diferentes y con perspectivas diferentes. Las conclusiones de un informe de auditoria pueden encarecer un proyecto o retrasarlo, tienen implicaciones demasiado delicadas que hacen recomendable que sean realizadas por empresas independientes o por equipos autónomos.

Nadie puede ser un buen juez y parte interesada al mismo tiempo, sobre todo cuando hay intereses económicos de por medio. Al igual que las auditorias de calidad tipo ISO son realizadas por entidades independientes, los testers de código y los análisis y propuestas de usabilidad deben ser realizados por equipos externos e independientes.

No se trata de dudar de la profesionalidad de nadie, sino de separar tareas incompatibles. Aunque finalmente el responsable del proyecto adopte la decisión que considere oportuna para el negocio (sacrificando lo que considere necesario), esta decisión debe ser tomada tras disponer de toda la información posible sobre las consecuencias.

Objetivos del jefe

Todos conocemos cual es el objetivo principal de cualquier responsable de empresa informática. Ganar dinero.

Para conseguirlo los objetivos son conseguir un producto de calidad, funcional, que agrade a los clientes, fácil de usar, y terminarlo lo antes posible. Sin embargo al ser el objetivo principal â??ganar dineroâ?, el resto de objetivos pasan a ser secundarios y supeditados a este. Desde el punto de vista del responsable estos objetivos secundarios son condiciones â??desgraciadamente necesariasâ? para conseguir el objetivo principal.

Sin embargo, este noble objetivo no es directamente compartido por todos los miembros de la empresa de la misma manera.

Objetivos de los empleados

El objetivo principal de cualquier empleado es ganar su salario a final de mes, si es posible agradando a sus superiores para ser objeto de una subida de salario y mantener alejado el espectro del despido.

Nos encontramos en una situación donde los empleados, pongamos en este caso programadores, se encuentran con un conflicto de intereses.

Por un lado, sus superiores saben muy bien como constatar cuando un producto lleva retraso, pero ignoran la cantidad de bugs que quedan por resolver en el código y el nivel de usabilidad del producto.

Consecuencias del conflicto de interés

Cuando un producto se acerca a su fecha límite, no es raro encontrar â??hacksâ? (chapuzas) que no funcionan prácticamente más que en el ordenador del programador y en el de su superior, para que cuele.

No exagero, en una de las versiones de Microsoft Word habían acumulado durante el desarrollo tal retraso que cuando uno de los programadores tuvo que programar la función que daba la altura de una línea de texto, hizo return 12; que coincidía con la altura en píxeles de la línea cuando sólo se usa el tipo de letra por defecto, pero que falla en prácticamente todos los demás casos.

Igualmente, cuando un programador tiene el tiempo justo (e incluso cuando no), su prioridad no será conseguir el producto final más usable, sino el más rápido de programar.

Hoy en día en muchas de empresas existe un departamento de Q&A completamente independiente del departamento de programación, con jefes independientes, y donde el producto no puede salir a la calle sin la aprobación de Q&A.

Es necesaria también la creación de un departamento de usabilidad, o en su defecto la contratación de una consultoría completamente independiente, cuyo objetivo se reduzca exclusivamente a conseguir la mejor interfaz para el producto.

La necesidad de separar el diseño de la interfaz del equipo de programación es todavía más imperiosa que la de separar los tests de la aplicación, ya que si bien un programador conoce perfectamente el tipo de bugs sutiles que pueden aparecer en una aplicación y tienen el conocimiento técnico necesario para encontrarlos (por lo menos cuando no son los suyos), los programadores en general no han sido formados en absoluto en la creación de interfaces de usuario.

Un equipo de desarrollo puede reaccionar negativamente cuando los tests y el diseño de la interfaz se externalizan, ya que pierden competencias, incluso llegan a pensar que los departamentos externos les están intentando sabotear. Se cuenta que en Microsoft uno de los responsables de desarrollo casi llego a las manos con uno de los testers, ya que creía que estaba saboteando sus esfuerzos para terminar el producto informándole de montones de bugs.

En realidad la única actitud aceptable es de agradecimiento hacia estos equipos externos. Alguien ha encontrado un fallo que era *tu* responsabilidad, y lo ha hecho antes de que el cliente pueda verlo. Por eso, hay que estarle agradecido.

Sin embargo, la típica reacción es mas bien de cabreo. ¿Por qué? Porque entra en contradicción directa con tu objetivo como empleado: hacer que los managers crean que el trabajo está terminado en la fecha que pidieron.

Sin embargo hay gente que valora que le digan en qué se equivoca. Donald E. Knuth paga a aquellos que encuentren cualquier error en sus programas, o incluso fallos en sus libros (incluyendo faltas de ortografía). El último bug encontrado en su programa TeX data del 94 o 95, aunque hay rumores de que alguien ha descubierto un nuevo bug 🙂

Con la usabilidad pasa exactamente lo mismo, solo que además si se saca del equipo de desarrollo, se les quita una responsabilidad que hasta ahora siempre ha sido suya.

Por ejemplo, si hacer algo más usable necesita mas trabajo (y este es generalmente el caso, a pesar de que el resultado final sea más sencillo). El programador se encuentra en el mejor de los casos frente a un problema a resolver. En el peor de los casos ni siquiera se ha dado cuenta de que hay un problema de usabilidad (recordemos que es un experto en juntar unos y ceros, poner ifs y elses, pero nadie le ha enseñado a crear programas usables).

¿Qué hacer? ¿Terminar antes con algo menos usable, o retrasar aun mas el proyecto (recordemos, siempre va con retraso) para hacer algo mas usable? Teniendo en cuenta que el manager probablemente sea incapaz de distinguir la buena usabilidad de la mala, pero si conoce perfectamente la fecha de entrega, la respuesta es bastante clara…

Costes de la auditoria

Aunque los beneficios de la auditoria sean evidentes, los costes que implica tener un equipo dedicado únicamente a estas tareas o contratarla externamente pueden desanimar a muchos. Sin embargo hay maneras alternativas de reducir estos costes.

Con Internet es relativamente fácil reclutar equipos de testers que a cambio de beneficios (sorteos, licencias gratuitas, etc. ) que suponen costes reducidos, pueden detectar gran parte de los bugs del programa.

La auditoria de usabilidad es algo más compleja, porque aunque los testers suelen informar de cuando tienen problemas evidentes para comprender como funciona algo concreto, solo personas formadas en el área suelen detectar problemas de mayor entidad o proponen soluciones.

Una opción es disponer en la empresa a una persona encargada de la usabilidad aunque no sea a tiempo completo, pero siempre autónomo del equipo de desarrollo. Otra posibilidad es optar por las pequeñas consultoras de usabilidad y consultores independientes que existen en España que pueden resultar una opción más económica y ágil que las grandes consultoras.