Buscar este blog

domingo, enero 30, 2011

El timo del cacheo y la obediencia a la autoridad

En las últimas semanas he empezado a leer "El efecto lucifer", uno de los libros que tenía en la lista de "para leer" desde hace casi un año. Se trata de un libro de Philip Zimbardo que resume su experiencia en el campo de la psicología del mal y la psicología situacional que lo provoca. Hace un repaso de su célebre Experimento de la Cárcel de Stanford, de la prisión de Abu Ghraib y otros casos reales y experimentales más o menos conocidos (Asch, Milgram, Tercera Ola, nazis, genocidio de Ruanda...)

Aunque aun no he terminado de leerlo, puedo asegurar que es uno de esos libros que te cambian el esquema mental del mundo, pero el motivo de esta entrada no es comentarlo, sino mencionar un engaño basado en la predisposición de las personas a obedecer a la autoridad. Es un timo que llama la atención por el número de veces que ha sucedido y por las opiniones de los investigadores. He escaneado el texto con Onlineocr (funciona muy bien tanto con fotos como con escaneos), para que cada cual juzge donde más ha visto ese tipo de comportamiento o dinámica (trabajo, asociaciones, partidos políticos...) y si debería preocuparse por ello o estar alerta.


El llamado «timo o engaño del cacheo» se ha perpetrado en varias cadenas de restaurantes de comida rápida de todos los Estados Unidos. Este fenómeno demuestra el poder de la obediencia a una autoridad anónima pero que parece ser importante. El modus operandi es que el encargado o la encargada del establecimiento recibe una llamada telefónica de un hombre que se identifica como agente de policía y que dice llamarse, por ejemplo, Scott. Necesita urgentemente su ayuda en un caso de robo por parte de un empleado o una empleada de su establecimiento. Durante la conversación insiste en que se le dé el tratamiento de «señor». Antes ya ha reunido información pertinente sobre los procedimientos y los detalles del establecimiento. También sabe cómo obtener la información que desea mediante preguntas guiadas con habilidad, como hacen los buenos magos y los «mentalistas» profesionales. Es un buen timador.
Al final, el agente Scott obtiente de la encargada el nombre de una nueva empleada joven y atractiva y le dice que ha estado robando del establecimiento y que cree que en este mismo momento ya lleva algo encima. Quiere que se la aísle en la trastienda y se la retenga allí hasta que él o sus hombres puedan venir a buscarla. La empleada es retenida allí y el «señor agente», que habla con ella por teléfono, le da la opción de que se desnude y la registre allí mismo una compañera de trabajo o de que espere a que la lleven a comisaría para que la desnuden y la registren allí. Invariablemente, la chica dice que la registren en ese mismo momento porque sabe que es inocente y que no tiene nada que ocultar. El presunto policía habla luego con la encargada y le dice que la haga desnudarse y que la registre a fondo, incluso en el ano y en la vagina, en busca de drogas o de dinero robado. Mientras, el «policía» insiste en que le explique con el máximo detalle todo lo que ocurre y, en la mayoría de los casos, las cámaras de videovigilancia van grabando estos sorprendentes acontecimientos mientras se van desarrollando. Pero esto es sólo el principio de una pesadilla para la joven e inocente empleada y de un bario de excitación sexual y de poder para el llamante-voyeur. 
En un caso en el que declaré como perito y en el que la afectada era una asustada estudiante de instituto de dieciocho años de edad, a esta situación básica se le habían añadido una serie de actividades cada vez más bochornosas y sexualmente degradantes. Siguiendo las instrucciones del que llamaba, la chica tuvo que ponerse a saltar y bailar desnuda por la sala. , Luego, el que llamaba dijo a la encargada que fuera a buscar a un empleado varón de más edad que vigilara a la víctima para que ella pudiera volver a desempeñar su tarea en el restaurante. La situación degeneró hasta el punto de que el que llamaba insistió en que la chica se masturbara y le I hiciera una felacíón al compañero que supuestamente debía retenerla en la trastienda mientras la policía se encaminaba hacia el restaurante. Estas actividades sexuales siguieron más de dos horas mientras esperaban a que llegara la policía, algo que, naturalmente, no llegó a suceder. 
La singular influencia de esta «autoridad ausente» tienta a muchas personas que se ven en esa situación hasta el punto de que llegan a vulnerar la política de la empresa y, probablemente, también sus principios éticos y morales humillando y abusando sexualmente de una empleada joven, honrada y, con frecuencia, religiosa practicante. Al final, el personal acaba siendo despedido, algunos son denunciados, se presenta una demanda a la empresa, las víctimas quedan gravemente afectadas y los autores de estas patrañas —en un caso un ex oficial de prisiones— acaban siendo atrapados y encarcelados. 
Una reacción razonable cuando se tiene conocimiento de este engaño es centrarse en la disposición de los encargados y de las víctimas y calificarlos de personas ingenuas, ignorantes, crédulas, raras. Pero cuando nos enteramos de que esta patraña se ha llevado a cabo con éxito en sesenta y ocho establecimientos similares de comida rápida de media docena de cadenas diferentes y en treinta y dos estados distintos, y que han caído en el engaño muchos encargados de restaurantes de todo el país con víctimas tanto de sexo masculino como femenino, nuestro análisis no puede 'basarse simplemente en culpar a las víctimas, y debemos reconocer el poder de las fuerzas situacionales que intervienen en este engaño. Así pues, o debemos infravalorar el poder de «la autoridad» para generar obediencia de una clase y en una medida que a veces es difícil de entender. 
Donna Summers, que fue despedida de su puesto de encargada de un McDonald's de Mount Washington, Kentucky, por haber caído en este engaño, expresa con claridad uno de los principales temas de El efecto Lucifer sobre el poder situacional. «Lo ves desde fuera y te dices: "Yo nunca lo habría hecho". Pero si no has estado en esa situación y en ese preciso momento, no tienes ni idea de lo que harías. Ni idea.» 
En su libro Making Fast Food: From the Frying Pan into the Fryer, la socióloga canadiense Ester Reiter llega a la conclusión de que la obediencia a la autoridad es el rasgo más valorado para trabajar en los establecimientos de comida rápida. «El proceso de línea de montaje intenta, de una manera muy deliberada privar a los trabajadores de todo pensamiento o criterio. Son apéndices de la máquina», dijo en una entrevista reciente. Dan Jablonski, un agente especial del FBI retirado que investigó estos engaños como detective privado, dijo: «Usted y yo podemos estar aquí sentados juzgando a esa gente y decir que eran unos imbéciles de tomo y lomo. Pero no se les ha enseñado a usar el sentido común. Se les ha enseñado a decir y a pensar: "¿En qué puedo servirle?"»

Nota: Esta entrada la publiqué originalmente en mi bitácora de Barrapunto.

martes, enero 04, 2011

Interrupciones y ruido en el desarrollo de software



Al hilo del resumen que encontré sobre Peopleware, y dándole vueltas a como mejorar mi flujo mental, me he puesto a pensar en que a lo largo de mi carrera, he tenido la interesante desgracia de encontrarme trabajando en diversos entornos ruidosos y con una gran cantidad de interrupciones. De todos ellos, creo que ha habido tres que han sido especialmente representativos en cuanto a lo que suponen para el desarrollo de software, tanto el ruido como las interrupciones.
De estos tres casos, una vez enfriados a base de tiempo para un análisis mínimamente objetivo, puedo decir que tenían, en mi opinión, las siguientes características:
  1. El primer caso lo experimenté trabajando en un entorno con más ruido de conversaciones y teléfonos del deseable, pero relativamente amortiguado con algunos metros de distancia. Muy pocas interrupciones, y muy informales.
  2. En segundo caso, el entorno era muy ruidoso, con montones de conversaciones al lado, y varias decenas de interrupciones diarias tanto in situ como de correo. Un caso bastante extremo, la verdad.
  3. En el tercer caso, el entorno no era más ruidoso que cualquier otro en el que haya estado, pero había muchísimas interrupciones in situ. Telefónicas y de correo sin embargo, había muy rara vez.
En todas las ocasiones, tuve que realizar trabajo de análisis, diseño e implementación de las aplicaciones que tocaban en cada momento y en todos los casos hice un análisis de mi estancia, inmediatamente tras cambiar de empleo, como de costumbre, para tratar de aprender de errores propios y ajenos (una pseudo tarea de cierre y evaluación del proyecto que casi nadie lleva a cabo por lo que veo). Así que este artículo se centra exclusivamente en la relación entre ruido, interrupciones y desarrollo de aplicaciones.
Y una vez comentado el contexto creo que puedo pasar a exponer las siguientes opiniones que me he formado a base de estas y otras experiencias:
  1. El trabajo de análisis y diseño admite mejor el ruido que la implementación. En mi caso puedo, por ejemplo, realizar documentación o establecer la arquitectura de una solución, con un nivel medio de ruido. Sin embargo para programar necesito muy poco ruido y/o cascos (como manera de aislarme), o la tarea se ve muy mermada en eficacia.
  1. El análisis y diseño admiten interrupciones en ventanas de tiempo [x] relativamente pequeñas, quizá de media hora. Estas interrupciones merman estas tareas, pero no hasta un punto excesivo que eche por tierra horas de trabajo. En cambio la programación (la que se haga bien, no parchear algún desastre) muchas veces requiere de un par de horas como poco sin prestar atención a nada más o puedes irte directamente al bar y la productividad habrá sido similar pero con algo más de alegría.
Supongo que otras personas habrán tenido experiencias similares o diferentes, pero estas son las que tengo de primera mano, así que tengo pocas razones para discutirlas. Por otro lado, el por qué el ruido y las interrupciones afectan de determinada manera a mi trabajo, merecen al menos un intento de explicación. Y aquí es donde van mis dos céntimos.

Creo que la razón de esta diferencia entre las necesidades de concentración de una y otra tarea, se debe a que las tareas de análisis y diseño, son tareas de alto nivel, abstracciones (por definición incompletas), a menudo incorrectas y/o, ambiguas (un poco al hilo de las leaky abstractions de Joel Spolsky), tareas además más “naturales” en el sentido de que no requieren de un marcado ciclo de trabajo tan formal (ojo, no digo que no sea formal pero hay un trecho) y dependiente de la tecnología (IDE/compilador, base de datos, flujos de trabajo con sistemas de control de versiones…) como la implementación en código y bases de datos. Por tanto las tareas de diseño y análisis son más flexibles para con los ciclos de abandono y retomado propio de las interrupciones. Yo diría (en un sentido positivo aunque no lo parezca) que el análisis y el diseño de los sistemas informáticos, especialmente en cuanto a software, son tareas incompletas y erróneas por definición, y como otros trabajos de diseño, se sustentan muy bien sobre el papel.
Sin embargo, en la implementación, cuando el programador recoge las especificaciones y diseños del analista (uno mismo en caso de que el analista y el programador sean la misma persona), y se pone a codificar, se acaba encontrando con todas las omisiones, ambigüedades y errores que han pasado por el tamiz de los diferentes roles y hasta sus manos: desde el cliente, pasando por la toma de requisitos, análisis funcional y orgánico y cualquier otra fase que queramos meter en medio. Y es entonces cuando todo ese trabajo que no se ha realizado antes, todo lo que se ha olvidado, omitido conscientemente, tergiversado… cualquier decisión que no se ha tomado, se atasca en la implementación, que necesita convertir toda la documentación, en un producto funcional y mantenible en el tiempo, y debe hacerse sin errores, porque la implementación no perdona, y si no “cae” en el compilador, lo hará en tiempo de ejcución en el entorno de preproducción, o peor aún, en producción.

Parafraseando a Richard Feynman: "Para lograr un éxito tecnológico, la realidad debe estar por encima de las relaciones públicas, de los diseños, análisis y requisitos tomados, porque la problemática que resuelve el sistema, los usuarios que lo van a usar, el compilador, la base de datos y el entorno de producción no pueden ser engañados.".


La necesidad de hacer algo sólido, sin errores, ni omisiones, desde lo que es la documentación incompleta (como decíamos, por definición), obliga al desarrollador a mantener un modelo mental del sistema muy detallado, mucho más que en las etapas anteriores, y esto cuesta mucho más “cerebro” (atención, modelos mentales detallados, datos, simulaciones, peculiaridades del entorno…) que en el caso del análisis (que puede abstraerse del entorno como poco). Supongo que por eso cualquier cosa que robe “cerebro” o lo ralentice, como las interrupciones o el ruido, son tan perjudiciales en esta etapa de implementación. Y quizá por eso también los técnicos tienden (tendemos) a dejar de ver el bosque en muchas ocasiones, de tanto árbol que tiene, con las consiguientes quejas (con razón o sin ella) de usuarios y comerciales.

Y ojo, esto no es una crítica al indispensable trabajo de análisis y diseño (que me parece crítico para poder llevar a cabo el proyecto con éxito), ya que en mi caso hablo de mi propia experiencia en los diversos roles, sino una reflexión sobre la posible necesidad de mantener a los programadores en entornos más tranquilos y relajados que los de los analistas. Es una invitación a incentivar el uso de cascos (quizá proporcionándoles unos con reducción activa de ruido), quizá ropa cómoda, pero sobretodo a dejarlos en paz durante periodos largos del día, aislándolos de interrupciones y distracciones indeseadas. Y también es una invitación a establecer relaciones estrechas y de confianza (laboralmente al menos), entre los miembros de análisis y desarrollo, ya que su productividad como equipo debería mejorar con un lenguaje común, conocimiento de los talentos y limitaciones de cada uno, buenas costumbres y manías. Al fin y al cabo no son dos recursos intercambiables como les gusta pensar a demasiados responsables de proyectos y departamentos de RRHH, sino dos tipos de diseñadores creativos (o deberían serlo) que van a realizar una obra común de carácter muy técnico. Son dos creadores (ahora que está de moda la palabra con la Ley Sinde) que van a colaborar (en el sentido de Pixar), y es por ello que más vale que se entiendan bien y sepan donde ceder ambos el lápiz y el papel o la decisión para obtener algo coherente, porque de no ser así, el resultado puede ser catastrófico.

Vídeo relacionado: Jason Fried 2010 en TED o Youtube.

Foto de Wiki Commons.

NOTA: Este artículo empecé a escribirlo hace 10 meses, pero diversas circunstancias lo han mantenido en un cajón durante largo tiempo.

lunes, enero 03, 2011

Android: 2.1 Ecclair. Impresiones


Hace unos días  meses escribí la review de mi nuevo terminal Samsung Galaxy Spica (I5700 para los amigos), pero quería tomarme algo de tiempo para terminar de probar algo más el sistema operativo que lo gobierna, Android en su versión 2.1 codename Ecclair. Creo que ya es hora de comentar mis impresiones.

Debo reconocer que el Android de Google me ha sorprendido para bien (mucho) y para mal (está muy lejos de ser perfecto).
A mi, que me considero un usuario avanzado de tecnología y que he usado a lo largo de los años unos cuantos teléfonos, PDAs y algunas otras cosas bastante extrañas (Atari Portfolio, tablets pre-iPad, sistemas operativos de todos los colores y sabores), me ha costado más de lo que esperaba hacerme completamente con el terminal. Evidentemente las funciones “básicas” como llamar, poner música, fotos… son relativamente simples y vienen integradas, pero cuando quieres ir un poco más allá, empiezas a recorrer un camino más largo de lo deseable. Posiblemente el mayor problema viene de que el interfaz es muy flexible, y para saber qué puedes y qué no puedes hacer, tienes que probar todas las opciones: botones físicos, pulsación, doble pulsación, pulsación mantenida, arrastre… en resumen, demasiado trabajo solo para aprender cómo funciona lo que trae o cada aplicación adicional que instales.

Evidentemente, al ser un terminal de Google, la integración del teminal con los servicios de Google, va muy fina, principalmente el correo y los mapas, pero curiosamente no todo se integra integraba hasta hace poco de manera oficial. Por ejemplo, el lector de RSS más decente era una aplicación de terceros y la integración de Tareas que uso es una aplicación de terceros. Otra cosa llamativa, sobretodo viniendo yo de Palm, es el Calendario. El calendario de Android es simplemente inusable, y aun no he dado con una aplicación que permita usarlo decentemente, así que solo lo tengo para algunos recordatorios.
Por otro lado, las aplicaciones de terceros son variadas, muy variadas. Tanto como que algunas funcionan y otras no (a veces por bugs, otras por versión), pero no lo sabes hasta que las instalas (ligeramente molesto, pero indoloro). Facebook por ejemplo está muy logrado, pero los reproductores de video no se acercan ni en broma al TCPMP que reproducía prácticamente de todo y bastante bien en dispositivos en los que en principio nadie lo esperaría, y la aplicación para gestionar la conexión 3G, me obliga a reiniciar el terminal para recuperarlo. Afortunadamente parece que todo es muy robusto y el instalar y desinstalar cualquier cosa no provoca problemas de ningún tipo, quizá unos restos de carpetas en la tarjeta de memoria a lo sumo.

En cuanto a la gestión del sistema, llama mucho la atención que esté tan dispersa (ajustes, widgets, botones físicos…). Cosas como cambiar a modo de vuelo, ajustar el brillo o conectar a una red Wifi, se realizan desde lugares muy diferentes, sin una lógica clara que permita intuir donde encontrar la función deseada. Y de momento no he encontrado una manera de establecer y usar perfiles de sonido (reunión para silencio, volumen bajo para oficina, volumen alto para el coche…). Esto con Palm o Sony no pasaba, todo era fácil de encontrar y tenía sentido.

En general yo diría que se trata de un buen sistema, y desde luego está a la misma altura que el de Apple o muy, muy cerca (por delante o detrás según en que nos basemos). Sin embargo, aunque he ganado bastante funcionalidad y conectividad a multitud de servicios, queda claro que el sistema no está tan bien pensado como los de Palm. No parece que Android aspire a ser el mejor sistema operativo para dispositivos móviles, sino que su meta parece ser el convertirse en el nuevo Windows: poder hacer un poco de todo, pero nada bien, ser muy flexible y abierto hasta donde se desee.

Por último para aquellos recién desembarcados en este sistema operativo, recomendaré una página: El Androide Libre. Multitud de aplicaciones y buenos consejos, aunque en ocasiones tiende al fanátismo tipo fanboys de Apple.

NOTA: Este artículo estaba casi terminado en Agosto de 2010, pero las circunstancias me han impedido publicarlo hasta ahora.