Conflictos de intereses entre equipos de desarrollo y auditorias - 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...