The Gervais Principle

Para aquellos a los que les gusta (o no pueden para de mirar) The Office y se ríen (o lloran) con Dilbert y están dispuestos a leer largo duro y parejo, y a pelearse con un inglés un poquito más difícil que la media:

The Gervais Principle, Or The Office According to “The Office”

Para tentarlos y de paso tenerlos a mano para cuando se necesite, dos botones de muestra:

Ojo que es más serio que lo que parece. Lo encontré leyendo el blog de Erik Dietrich, también recomendable para agregar al feed.

PD para cuando lean un poco de eso: yo me considero claramente un looser, y -creo- es fácil distinguir a los sociopaths (antes de que alcancen el nivel al que sólo ellos pueden llegar, si no pierde la gracia)... lo divertido es ponerse a discutir quiénes son los clueless. Tengan en cuenta que no todos son tan "puros" como Michael.

La queja.

Soy quejoso por naturaleza. Siempre le encuentro el pelo al huevo y, a falta de errores o problemas más graves, hago de un charquito una inundación…

A veces exagero un poco. Cuando mis compañeros de trabajo están –razonablemente- ya un poco hartos de mis cancioncitas plañideras les recuerdo, como para equilibrar un poco la balanza, que si bien me quejo

a) estoy en general encargándome activamente o lidiando con el problema, así que eso me da cierto derecho a una breve descarga emocional –a veces no es tan breve como debería-, y

b) estoy constantemente pensando y tratando de proponer soluciones –a veces peores que el problema, pero bueno… prueba y error, y sin error no hay prueba- y que

c) soy el primero en ponerle el hombro a cualquier intento de mejora, incluso cuando no crea que vaya a funcionar –probemos, con un poco de suerte me equivoque-.

Sí, a veces exagero y soy demasiado duro con algún temita en una solución que, en general, funciona bien. Pero bueno, es parte mi forma de motivar –correcta o no, efectiva o no, ésa es- y de motivarme a concentrarse no en lo que salió bien sino en lo que salió mal, que es lo que merece más atención.

Lo que es seguro es que es menos probable –a veces se requiere de más de un golpe- que me vuelva a dar con la misma piedra… aunque luego encuentre otra con la que impactar.

Por otro lado, hay personas en las que la queja es sólo eso, una queja. Una enumeración interminable de problemas, errores y malas decisiones que no las mueve a la acción o al cambio en lo más mínimo.

Estas personas piensan en el pelo antes de hacer el huevo. Como el “pelo a futuro” desmotiva, se quedan en la inacción y la queja se vuelve constante –porque sin acción nada cambia-, autosuficiente e inmortal.

Si es la queja la que lleva a la inacción o si es la excusa para la inacción, es imposible de saber. Pero es en todo caso indiferente, si el resultado es el mismo y es la nada.

Pero ojo, porque el quejoso no es mentiroso y no necesariamente tiene malas intenciones. Normalmente los problemas sobre los que la queja se asienta son reales, la práctica de la observación pasiva lo ha vuelto experto en su detección.

Así que –para mí- tampoco es prudente hacer oídos sordos a su cantinela. Lo que debemos evitar –a veces harto difícil- es quedar atrapados girando en la órbita de su parálisis.

Una solución imperfecta es siempre mejor que nada. Incluso una solución equivocada es mejor que nada, es una posibilidad menos en el camino de la prueba y error. Hacemos sistemas, no estructuras de concreto, y siempre podemos volver atrás y buscar otra salida. El tiempo insumido, al que usualmente calificamos de “perdido”, no será tal hasta que nos demos por vencidos.

Reuniones técnicas…

…en las cuales el arquitecto explica a la audiencia la estructura del sistema en el que luego deben meter los dedos:

(gracias a Nicolás por apuntarlo)

20 sitios web muy mal diseñados.

La gente de Manolith ha recopilado estos sitios en su entrada 20 of the Worst Designed Websites In the World.

Si bien hay algunos que -en mi opinión- no acumulan suficiente mérito como para ser incluidos en semejante “lista de la vergüenza”, el resultado final del recorrido es un fuerte mareo y dolor de cabeza.

Lo malo no es ser incapaz de crear un buen diseño –yo soy incapaz de ello- sino el mal gusto liso y llano –y la falta de un poco de sentido común- que impide al creador del sitio (la frase “diseñador del sitio” está fuera de lugar, queda claro que no todo el que diseña es diseñador) reconocer que algo no está del todo bien.

Un par de ejemplos:

A ver si alguno de los incluidos en esta lista se decide a pedir ayuda profesional, o por lo menos a robar inspirarse en algún sitio un poco más sobrio y bien diseñado.

Encontrarán la lista completa y los links a los sitios (si es que se quedaron con ganas) en el artículo original.

Visto en Menéame.

10 Principios para el diseño de la interfaz del usuario.

“A modern paradox is that it’s simpler to create complex interfaces because it’s so complex to simplify them.” – Pär Almqvist

1. Conoce a tus usuarios.
2. Presta atención a los patrones.
3. Mantente consistente.
4. Jerarquiza visualmente.
5. Da feedback en cada acción.
6. Soporta los errores del usuario.
7. Da el control al usuario.
8. Habla su lenguaje.
9. Mantenlo simple.
10. Avanza, actualiza, no te estanques.

Desarrollados en el artículo original (en inglés): 10 User Interface Design Fundamentals (vía @DeliciousHot).

Trabajo remoto.

Las herramientas de comunicación han avanzado muchísimo, qué duda cabe. Es posible sentarse en el escritorio de la oficina desde casa de una forma razonablemente transparente utilizando una VPN, conversar con los demás miembros del equipo por chat, por voz o video a través de servicios que prácticamente todo el mundo utiliza de forma muy natural y cotidiana. Si pensamos en cómo este conjunto de tecnologías –de comunicación- ha impactado en la economía y las relaciones laborales veremos gran dificultad en imaginar en qué las transformará de aquí a 20 o 30 años.

En el rubro del desarrollo de software -integrado necesariamente por personas y empresas acostumbradas y abiertas a la tecnología- todos, en mayor o menor medida, utilizamos algunas herramientas de trabajo remoto. Aquellos con más experiencia recordarán con extrañeza los no tan lejanos tiempos en los que instalar, configurar, verificar un problema o arreglar una emergencia, eran todas tareas que implicaban moverse e ir a visitar al cliente.

De un tiempo a esta parte -apenas un par de años-, la “presencia virtual” se está extendiendo hacia dentro del equipo de desarrollo, al que siempre imaginamos como un montón de personas trabajando juntas en el mismo lugar. Si bien la imagen anterior sigue representando la norma, opciones de trabajo remoto comienzan a analizarse seriamente como una posibilidad por cada vez más organizaciones, y comienzan a configurarse otro tipo de equipos, a los que usualmente se nombra como equipos distribuidos.

Por otro lado, desde lo ágil siempre se ha dicho –y yo comparto- que la coordinación y comunicación es a la vez demasiado importante y demasiado compleja en el desarrollo de un producto de software, por lo que deberíamos optar, siempre que sea posible, por la forma más eficaz de coordinar y comunicar: cara a cara.

Debemos ser conscientes de que al utilizar estas nuevas tecnologías estamos, en mayor o menor medida, sub-optimizando la comunicación. Es una opción racional si -y sólo si- los beneficios superan el costo de esa sub-optimización. Es decir que si para una consultora argentina tener un cliente español no representa ninguna dificultad operativa seria, no por ello tiene sentido hacer una videoconferencia con otro cliente cuyas oficinas están a escasos 200 metros. Una software factory que alquile oficinas con espacio e infraestructura suficiente para todos sus empleados no se beneficiará de las posibilidades del trabajo remoto en tanto no reduzca el costo del alquiler o capitalice una mayor velocidad de respuesta como nuevos clientes o precios más altos en cada contrato, o en un aumento medible de la productividad.

Yendo un poco a lo personal, para los miembros de un equipo tener la posibilidad de trabajar remotamente implica libertad de horarios y –sobre todo- el aprovechamiento de esos momentos de inspiración o entusiasmo, esquivando la saturación. Si a uno se le ocurre una gran idea un domingo a la mañana y tiene ganas y tiempo de probarla lo antes posible, ¿por qué no? Si se nos hace cuesta arriba un lunes a la mañana o un viernes a la tarde y las fechas límite lo permiten, ¿no sería más productivo entrar tarde o irse temprano, descansar, distraerse, en vez de luchar por terminar algo que en otro momento de mayor motivación nos llevaría la mitad de tiempo?

Suena bien, pero tiene un límite. Recordemos los costos de los que hablábamos al principio: de poco servirá todo ese trabajo adelantado si la funcionalidad había cambiado (la cambió el analista trabajando tarde a la noche desde su casa) y el desarrollador no se enteró por no chequear el correo.

Sobrepasamos un límite cuando, más seguido que esporádicamente, unos quedan a la espera de poder comunicarse con otros y los horarios no coinciden y comienzan a aumentar los tiempos muertos. Desde lo personal, ese costo de la libertad puede pagarse en forma de constantes llamadas y comunicaciones disruptivas por temas laborales que impiden una desconexión completa.

Para complicar las cosas las personas son extremadamente diferentes en este sentido. Algunas preferirían trabajar todo el tiempo en forma remota y sin horarios y otros ir a la oficina con un horario fijo, salir y no ser molestados para nada hasta el día siguiente. ¿Entonces? Dependerá de cada equipo encontrar el punto justo en el que todos se sientan cómodos, lejos de los extremos del control estricto o de la amalgama entre vida personal y laboral.

Personalmente creo que las herramientas de trabajo virtual deberían estar disponibles para todos, sobre todo teniendo en cuenta que en general las empresas ya cuentan con el software necesario (o hay opciones gratuitas o de muy bajo costo) y que no deberían demandar mucha infraestructura adicional a la que una empresa suele tener sólo por estar en el rubro de sistemas. Pero que al mismo tiempo deben establecerse ciertas reglas. Un horario en el que todos deberían estar en el mismo lugar, ciertas reuniones a las que sea obligatorio asistir en persona, cierta flexibilidad diaria (2 o 3 horas en una jornada de 8), una cuota de horas a cumplir por mes, ese tipo de cosas.

Debemos, en definitiva, tratar estas herramientas como a todas las demás: por más casos de éxito que escuchemos, por más buzz que se haya generado alrededor de ella, tiene que ser adecuada para nosotros.

La ¿evolución? de la discusión.

Llegué a este diagrama obra de Paula Scher saltando desde un artículo de Coding Horror.

Lleva a tus monitos de paseo.

La semana pasada escribía sobre el paradigma que rodea cualquier actividad, sobre lo importante que resulta el conocimiento y la comprensión de éste para desarrollar con éxito un software alineado con el negocio, y lo difícil de su transmisión al equipo de desarrollo.

Rara vez es explicitado en manera alguna –decía- y cuando lo es –cuando pretende serlo- se materializa en forma de frases de compromiso que rara vez tienen que ver con la cosa real que dicen reflejar. Es un poco como la visión a la que tanta importancia le dan las normas de calidad: pocos saben qué es y de poco sirve saberlo -salvo para certificarse en algo- pero no se puede tener éxito sin ella. Análogamente, los negocios exitosos no son los que saben qué es un paradigma sino los que tienen un paradigma exitoso. Siempre es bueno racionalizar, poder poner en palabras, explicitar, pero lo indispensable es tener qué explicitar.

El problema es, volviendo al primer párrafo, que el equipo de desarrollo necesita conocer el paradigma real que subyace al modelo de negocio para derivar de él lineamientos concretos con los que diseñar un software. Imaginemos por un segundo que creamos un sistema de gestión para una empresa de la industria farmacéutica partiendo de que, tal cual rezan sus documentos sobre políticas internas, “la base de nuestro negocio es proveer los medicamentos para curar todos los males de la humanidad”… Imaginemos ahora la cara de los directivos cuando mostremos nuestros reportes y panel de control de gestión conformados por indicadores tales como tasa de mortandad, calidad de vida, reducción de casos de tal y tal enfermedad… cuando midamos el éxito de un producto de acuerdo a la cantidad de pacientes que se han curado gracias a él… “¡Hey! ¿Dónde está el estado financiero? ¿Y la cotización en bolsa? ¿Dónde se muestra el ROI?”.

Entonces, para conocerlo y comprenderlo cabalmente se requiere estar ahí. Es tarea propia de analistas funcionales, representantes comerciales y demás. Pero, normalmente, los programadores no pueden estar ahí y la solución propuesta por metodologías ágiles como XP –tener al usuario dentro del equipo- no siempre rara vez es posible. Surge entonces, como siempre en el desarrollo de software, el problema de la comunicación.

Pero… ¿No pueden estar ahí? ¿Nunca? ¿Ninguno? ¿Ni de visita? ¿Ni por un rato? Difícil de creer. A pocos se les da la oportunidad de conocer a los usuarios en su entorno real de trabajo. Incluso cuando esto es posible, incluso cuando es sencillo encontrar la oportunidad. Más raro aún es que esta actividad sea establecida formalmente entre las tareas de un programador durante el proceso de desarrollo.

Para los que han tenido esta experiencia -como parte de una visita formal o no- ha sido casi reveladora. Día a día, inevitablemente y de forma intuitiva, encerrados tras una muralla de código, los programadores derivan, imaginan, se forman una imagen del negocio para el cual programan. Lo hacen a partir de los requerimientos, del diseño propuesto para las pantallas, de las funcionalidades. Pero es muy difícil que esta imagen, condicionada por su experiencia y sus propios paradigmas, coincida con la realidad.

Creo que es una práctica fácil, barata y muy productiva el llevar a los programadores “de paseo” al entorno del cliente en cualquier oportunidad que se presente (oportunidad para tomarles fotos vestidos decentemente… ¡o hasta de saco y corbata!). ¿Para qué? Para que conozca a los usuarios, su nivel, su entorno, su trabajo. Por ejemplo…

¿Son usuarios avanzados en el uso de una computadora en general? Hace ya mucho tiempo (no creo que esto pueda suceder ahora) me di cuenta de que el significado de los íconos más básicos y estándar –guardar, abrir- de la barra de tareas del sistema eran completamente oscuros para el usuario de nuestro sistema, que utilizaba sólo el menú porque allí decía “Abrir”, “Guardar”, haciendo todo de una manera muy incómoda. El detalle cool (para mí) de poner íconos grandes y sin texto hacía que la barra fuese completamente inútil. El gesto –tan natural para mí- de poner el cursor encima de un ícono para ver una descripción de su funcionalidad era imposible en esta persona.

¿Son jóvenes, personas mayores? ¿Necesitan algún tipo de accesibilidad para utilizar el sistema? Allá lejos y hace tiempo tuve un compañero de trabajo, un contador –creo- que era tan corto de vista que tenía que usar la lupa… y les aseguro que el sistema se veía MUY diferente de esa manera.

¿Su trabajo les exige interacción constante con el sistemao es más bien esporádica? ¿Tienen otros sistemas abiertos? ¿Tienen que consultarlos alternativamente? ¿Llevan a cabo varias tareas al mismo tiempo? Esa transacción, que nosotros imaginamos como una rápida carga de datos y un enter final tal vez requiere de varios minutos entre ingreso e ingreso para conseguirlos. Otra de las cosas impensadas que vi fue un usuario que primero copiaba todos los datos necesarios a un archivo de texto. Lo hacía desde diferentes planillas, sistemas, desde el navegador y luego abría el sistema de presupuestos y los pegaba desde allí. ¿Por qué? Era obvio, porque temía perderlos y el sistema no le dejaba grabar el registro –aunque sea localmente o en un repositorio temporal- si no tenía los datos completos. Esta era una funcionalidad que yo había discutido tercamente por demasiado problemática en relación al beneficio –según mi propio punto de vista- que representaba para el usuario. Cuando lo vi no discutí más.

¿Están cómodos? No es lo mismo utilizar el sistema localmente que hacerlo a través de un escritorio remoto, o sentado cómodamente en un escritorio que de parado frente a un rack de servidores.

Siempre hay, en definitiva, alguna cosa rara. Se me dirá que es cuestión de hacer lo que los analistas o diseñadores nos piden y listo, que al fin y al cabo ellos han estado allí –o ha leído un documento redactado por alguien que ha hablado con alguien que estuvo allí-, pero eso nos limita a lo que ellos consideran fácil o posible.

Esto último me hizo acordar algo que había escrito en La “respuesta” a “¿Cuál es el error?”, la ambigüedad, su resolución y, finalmente, la realidad:

[…] ya lo dijimos, vivimos en un mundo imperfecto. Muchas veces (en todo proyecto real esta situación es más que frecuente) el cliente no está disponible […] o no entiende la pregunta. ¿Entonces?

[…] hay veces que hay que adivinar y seguir adelante, rellenar los huecos en las especificaciones apelando al sentido común […]

Cultivar el “sentido común” -al que apelan los programadores cuando tienen que inventar algo para tapar algún hueco- mostrándoles “la vida real” del proyecto para el cual trabajan ahorraría innumerables idas y vueltas entre desarrollo y producción y seguramente haría que surjan ideas y mejores posibilidades para el sistema.

Typing is not the bottleneck.

…es una frase que resume bastante bien mi visión del desarrollo de software. La encontré en Sebastian Hermida's Blog, quien se sintió inspirado por ella y creó unos stickers -que ofrece a quienquiera pasar el mensaje- con la imagen que ilustra este post.

Si siguen hacia la entrada original descubrirán de dónde viene y un par de links interesantes.

Paradigmas.

Los desarrolladores somos –¿hipótesis?- ante todo humanos, luego usuarios, luego desarrolladores.

Como humanos –entre otras cosas-, tendemos a sobrevalorar la propia experiencia. Por ejemplo, si el sistema que desarrollamos nos es fácil de utilizar solemos atribuirle esta característica obviando el hecho de que hemos aprendido a utilizarlo “desde atrás” (es decir, desde el código, el diseño o los requerimientos) y no “desde adelante” (desde la pantalla, los manuales o la capacitación). Para cuando nos enfrentamos a la pantalla de inicio ya sabemos casi de memoria todo lo que sigue. Abstraerse de este conocimiento es –por más que me juren y recontrajuren- imposible, y es por eso que nuestras pruebas y experiencias personales son bastante objetables como medida de lo que sucederá en el mundo real. Esto se aplica, con variaciones, tanto a desarrolladores como a analistas, testers, líderes de proyecto y a cualquiera implicado en el desarrollo de software (excepto, claro está, al cliente y al usuario).

Además de humanos –si es que damos por válida la hipótesis-, somos usuarios de sistemas de un determinado negocio: entornos de desarrollo, clientes de bases de datos, herramientas de diseño y documentación de requisitos, entre muchos otros, conforman el software de soporte al negocio del desarrollo de software. Negocio en el que estamos inmersos y que, como todos, tiene su paradigma establecido y materializado en la forma de determinados estándares: flujos de trabajo, herramientas visuales, disposición física de los objetos en una oficina… todo lo que nos rodea se deriva de éste en alguna medida.

La importancia de estos elementos –paradigma y estándares- que sobre el papel parecen un conjunto arbitrario de caprichos funcionales -¿por qué Ctrl+U y Ctrl+Shift+U? ¿Por qué un árbol y no una serie de listas encadenadas?- radica en que condicionan toda nuestra visión de la realidad (¡vaya si estamos condicionados por los paradigmas de nuestro negocio!). Los sistemas -si pretenden ser exitosos- deberán respetar –o revolucionar, pero esto es más difícil-, sobre todo en la interacción con sus usuarios, los paradigmas del negocio para el que fueron diseñados.

Como desarrolladores que somos –de eso sí estamos seguros- nos sería imposible, si estuviésemos librados a nuestro criterio, no aplicar el paradigma y los estándares propios del negocio al que pertenecemos –el desarrollo de software- a los sistemas que desarrollamos.

El problema es que, como establecimos más arriba, otros negocios o actividades tienen estándares y paradigmas diferentes. Internalizarlos es prácticamente imposible (deberíamos ser, por ejemplo, tan usuarios de distintos sistemas de gestión como lo somos de distintos entornos de desarrollo, tanto como lo es un empleado administrativo que ha transitado por diferentes empresas y puestos). Sólo podemos pretender, a lo más, conocerlos. Y para ello se requiere de una experiencia… “presencial”. Es la experiencia que trata de transmitir el analista funcional, el área comercial o quienquiera que tenga contacto directo con el cliente.

Pero un modelo mental es algo realmente difícil de describir, los estándares que se deriven de éste serán en su gran mayoría reglas y prácticas comunes y no estarán explicitadas en ningún lado. Es, en definitiva, difícil de transmitir. Por todo esto, cuantos más intermediarios haya entre aquellos que conocen a los clientes y usuarios y los desarrolladores, más probabilidades habrá de que nos apartemos del paradigma y los estándares a los que ellos están acostumbrados.

Sobre la importancia del interlocutor.

Creo que la propia experiencia nos condiciona más fuertemente que cualquier otro factor y que, si bien eso tiene su razón de ser, puede llevar fácilmente al dogmatismo.  Veo algo de esto reflejado en cada discusión en torno de alguna de las dualidades de moda: Windows vs. Linux, Software Libre vs. Software Privativo, Código Abierto vs. Código Cerrado, Java vs. .Net, Oracle vs. MS-SQL y ambos vs. MySql y PostgreSQL… uf, podría rellenar varios párrafos más (se ve que nos gusta hacer polémica). Si rascamos un poco en busca de la experiencia profesional de los polemistas veremos que abunda de un lado de la frontera y escasea (o ha sido traumática) del otro.

Un pequeño ejemplo: ASP 3.0 me produce urticaria (sobre todo si lo mezclamos con una buena dosis de xml). Pero reconozco que mucho tiene que ver el hecho de que la primera y única aplicación más o menos compleja que hice terminó como la imagen de aquí a la izquierda (extraída de este viejo post). Si hubiese tenido una segunda oportunidad desde cero podría haberme amigado con el lenguaje y hoy estaría defendiéndolo acaloradamente contra PHP (ya no sucederá, ha muerto en manos de él, y merecido se lo tiene). Pero me han comentado casos en los que mediante diversas técnicas se ha podido mantener el orden y construir aplicaciones realmente complejas sin perder la cordura en el intento.

Pero volvamos al hilo. Decía que el peso de la experiencia tiene su razón de ser, y pensaba en lo siguiente: un joven padawan está deseoso de adiestrarse en el manejo de nuevas armas, mientras que Yoda se preocupa más por eliminar al oponente (aunque no de cualquier manera, siempre mantiene las formas y sobre todo la estética). Si el padawan es criterioso no se pondrá a innovar antes de (o en medio de) una batalla… bueno, hasta aquí llego, supongo que se entiende la idea.

Volviendo ahora al desarrollo de software (del que no debería haberme apartado), repasando mi propia experiencia, veo que he cometido errores empujando la balanza hacia uno u otro lado: algunas veces he utilizado herramientas más allá de lo razonable porque las conocía (y mi experticia en ellas me permitía forzarlas) y porque los tiempos apuraban (y un largo etcétera que podemos resumir como “aversión al riesgo”). Por el otro he elegido algunos malos momentos para experimentar.

Por suerte fui aprendiendo y hoy por hoy puedo decir que acerté más de lo que pifié (por lo menos hasta ahora)… ¿por suerte? Un factor común en los errores fue que (llevado por el apuro o el entusiasmo) no tenía y no busqué un referente con alguna experiencia (por más mínima que fuese) en la “herramienta nueva”. Estoy casi seguro de que éste factor explica tanto los fracasos como los éxitos, ya que siempre que la decisión que tomé terminó mostrándose acertada sí lo tenía.

Por supuesto que no tiene por qué ser alguien del equipo (tal vez hasta sea mejor que no lo sea). Puede ser un amigo, un conocido, un allegado. O ni siquiera una persona. Podría ser un caso de éxito (o fracaso) bien documentado, un foro o comunidad en la que se tenga alguna confianza y participación activa. Tampoco es tan importante que sea un experto en la herramienta o un relato de fuente confiable. Basta que nos cuestione o nos apruebe de alguna manera, y que nos fuerce a plantear las preguntas correctas, ésas especialmente incómodas y sin respuesta precisa, en las que encontramos puntos a favor y en contra de cada posible solución, en las que prima la opinión sobre el dato y en cuya respuesta podemos incluso discernir con respecto a ese referente.

Como me señalaba hace apenas un par de días Cerebrado, cualquier programador con un par de logros y moretones encima valorará enormemente tener con quién o en dónde discutir, polemizar o pelear. Lo valora porque (sobre todo si tiene moretones) desconfía de las decisiones en solitario o tomadas por una sola persona a puertas cerradas y sin una discusión previa, así sean las propias.

Al discutir, polemizar o pelear, puede que no se llegue a un acuerdo sobre la posible superación de determinados problemas, pero por lo menos se habrán planteado y tenido en cuenta o descartados conscientemente.

Recalco: no critico el hecho de que decida una sola persona (que al fin y al cabo un equipo no es una democracia… en la que de todas maneras tampoco se decide por unanimidad) sino la falta de un intercambio de ideas previo.

Hace no mucho tiempo (aunque usted no lo crea) programábamos sin internet. En ese tiempo la experiencia era difícil de encontrar y un interlocutor válido mucho más todavía. Hoy no hay excusas, no existe ningún lenguaje o herramienta o sistema o librería o framework del que no podamos encontrar opiniones a favor o en contra. No prestar atención a esas discusiones u opiniones antes de tomar una decisión es… suicida.

Un viejo conocido: Comunicado del Jefe.

¿Se acuerdan de esto? Seguro que lo han visto alguna vez dando vueltas por su casilla de correo. Debe ser una de las primeras cadenas que recibí por mail… ¡y ahora vuelve para perseguirlos en forma de post!

De : PRESIDENTE
Para : GERENTE GENERAL
El lunes próximo a eso de las siete de la tarde el cometa Halley se hará
Visible. Es un acontecimiento que ocurre cada 78 años. Reúna a todo el
personal en el patio de la fábrica -todos usando casco de seguridad- que
allí les explicaremos el fenómeno. Si llueve, este raro espectáculo no podrá ser visto a ojo desnudo, en ese caso entraremos al comedor donde será exhibido un documental sobre ese mismo tema.

De : GERENTE GENERAL
Para : JEFE DE PRODUCCIÓN
Por orden del presidente el lunes a las siete aparecerá sobre la fábrica el
cometa Halley. Si llueve reúna a los empleados con cascos de seguridad y
llévelos al comedor, donde tendrá lugar un raro espectáculo, que sucede
cada 78 años a ojo desnudo.

De : JEFE DE PRODUCCIÓN
Para : SUPERVISOR
A pedido de nuestro gerente general, el científico Halley de 78 años
aparecerá desnudo en el comedor de la fábrica usando casco, porque va a ser presentado un documental sobre el problema de la seguridad en días de lluvia.

De : SUPERVISOR
Para : ASISTENTE
Todo el mundo desnudo -sin excepción- deberá estar en el patio el lunes a las siete, donde el famoso músico Halley mostrará el vídeo “Bailando bajo la lluvia”. El show se presenta cada 78 años.

De : ASISTENTE
Para : PERSONAL DE PLANTA
El jefe cumple 78 años el lunes y habrá una fiesta en el patio y el comedor con el famoso conjunto Bill Halley y sus cometas. Todo el que quiera puede ir en pelotas pero usando casco, porque se va a armar un flor de webeo aunque llueva.

Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

• el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

• el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

• el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

• el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

• La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.

El origen de la comunicación.

La comunicación dentro del desarrollo de software es un tema recurrente en este blog (artículos sobre comunicación). La principal razón de ello es, simplemente, que desarrollar software es comunicar (Del desarrollo de software como sistema de comunicación...).

Trabajamos en un mar de mensajes orales, escritos, gestuales. En castellano o inglés, expresados en diagramas y gráficos o como lenguajes de programación, y de diferentes fuentes (humanas, mecánicas, informáticas). Las acciones y decisiones que tomamos y percibimos son también mensajes.

Participar de la comunicación hace a cada integrante del equipo. No puede calificarse como tal quien no logre entender los objetivos. No se integra un equipo con estar ahí físicamente, hay que decodificar los estímulos que se reciben en ese ambiente en un sentido similar al de los otros integrantes.

Para un líder la comunicación es todo. Donde la coerción física es bastante infrecuente (digo bastante...) la comunicación hace al líder. No lo será el más fuerte ni el más capaz ni el más viejo ni el más sabio. Será aquél que transmita mensajes que lleven a los demás a seguirlo.

Usualmente vemos un gráfico parecido a éste:

Tomemos un elemento: el mensaje es “el conjunto de señales, signos o símbolos que son objeto de una comunicación”. Pero en la vida real, ¿quién dice qué estímulos son señales, signos o símbolos, y cuándo conforman un mensaje?

A la derecha del escritorio de X está el cubículo del líder de proyecto, al que puede ver ya que está definido por una separación transparente. Está visiblemente molesto mientras conversa con el líder técnico, y cada tanto levanta la vista en dirección a X. En un momento señala directamente a X, quien entiende que están hablando de él, a cerca de un grave incidente del fue responsable, y espera lo peor.

Se ha cerrado un circuito de comunicación: el líder de proyecto envía mensajes gestuales que X interpreta. ¿No?

El líder de proyecto está molesto porque han recortado casi un cuarto de su presupuesto. Descarga su furia conversando con el líder técnico, un viejo amigo. De vez en cuando levanta la vista y queda mirando al vacío al recrear los detalles de la reunión. El recuerdo lo enfurece. Apuntando hacia donde -en su recuerdo- se encuentra el gerente general, dice: “Es un verdadero imbécil”.

¿Esta última aclaración invalida la comunicación anterior? ¿El mensaje recibido por X no fue real? ¿Cómo puede X saber eso? ¿Y si no fue real, qué fue?

La decodificación de un mensaje y su interpretación es un fenómeno que hace al receptor, lo define. Somos receptores si -y sólo si- recibimos mensajes y lo somos sólo fugazmente durante el momento en que lo hacemos.

Pero por otro lado es el receptor quien decide qué es un mensaje y qué no. También decide si va dirigido a él y cómo se decodifica. En nuestro ejemplo X decidió que el gesto del líder iba dirigido hacia él, y decidió también su sentido al decodificarlo.

Así que nos convertimos en receptores a voluntad, incluso con independencia de la existencia real de un emisor con intención de dirigirse a nosotros. Basta con tomar cualquier estímulo e interpretarlo (¿o incluso el estímulo es innecesario?).

Pero este proceso de creación del mensaje que hace de una persona un receptor no es, habitualmente, aleatorio. Si así fuese la coordinación -si no la vida misma- sería imposible. Si no interpreto la luz roja del semáforo como un mensaje dirigido a mí que indica que no cruce la calle, probablemente no dure mucho en una ciudad moderna.

A través de un proceso (de aprendizaje, enseñanza, prueba y error) que comienza con nuestro nacimiento, filtramos estímulos y creamos mensajes cada vez más ajustados a la forma en la que necesitamos reaccionar para sobrevivir. Este proceso se vuelve tan automático que ni nos percatamos de ello.

Es decir, hemos aprendido a interpretar lo que nos rodea no de acuerdo a una realidad objetiva (si es que tal cosa existe), sino de acuerdo a nuestras necesidades de supervivencia (¡esto es duro de tragar!). 

Para sobrevivir necesitamos reaccionar especialmente a lo que un emisor intenta transmitirnos deliberadamente, y por ello somos muy buenos en detectar eso.

Pero de vez en cuando se produce un equívoco. El efecto de encontrarse con un malentendido (por ejemplo cuando X se entere de que no estaban hablando de él) es parecido al que nos provocan las ilusiones ópticas: nos revelan que nos movemos en un entorno que nosotros mismos estamos creando a partir de los estímulos que recibimos, y que nos podemos equivocar.

Pero volvamos a lo laboral. Lo anterior supone un problema, y uno grande. Desde el punto de vista de un líder, por ejemplo, es imprescindible asegurarse de que lo que dice se interprete en determinado sentido.

El lenguaje, los estudios y la experiencia compartida ayudan pero no aseguran. Si hay que transmitir la definición de un sistema administrativo un cursograma aportará un lenguaje preciso… dependiendo del grado de conocimiento de éste que tenga el receptor.

La única forma es el feedback (lo que puede pasar en su ausencia: Pedrito (el líder de proyecto) y el lobo: la importancia del feedback): el receptor devuelve el mensaje al emisor y éste lo confirma.

A mayor experiencia (más tiempo, conocimientos y vivencias compartidas) menor necesidad habrá de este tipo de “feedback de confirmación”.

Notemos que esto no soluciona nuestro ejemplo. ¿Cómo confirmar un mensaje que no se ha enviado? Si el emisor (el líder de proyecto) no es consciente de la interpretación de la que han sido objeto sus señales (por parte de X) no tiene forma de corregirla.

Este último caso es insalvable. Y todos lo sabemos. X tiene “cola de paja”. En la oficina está el paranoico que cree que lo van a echar. Y el que no sabe que está en la cuerda floja. Y el que se siente galán de la oficina. Y el jefe que se cree respetado y obedecido. Y el que cree que son todos haraganes. Todos “nos creemos” porque, finalmente, hemos construido nuestro mundo interpretando a nuestro antojo los estímulos que… ¿recibimos?

Pedrito (el líder de proyecto) y el lobo: la importancia del feedback.

Todos conocen la historia de Pedro y el lobo. Por las dudas se las refresco:

<spoiler>

Pedro era un pastor que se divertía gritando que venía el lobo sólo para molestar a la gente del pueblo, que corría inútilmente a ayudarlo. Hasta que finalmente vino el lobo. Pedro gritó pero como lo había hecho tantas veces en broma nadie le creyó... Las versiones varían: en el cuento infantil se dice que el lobo se comió unas ovejas, yo digo que también atacó a Pedro y lo dejó inválido y deforme para toda la vida.

</spoiler>

A veces sucede algo por el estilo en el desarrollo de software: se establece una fecha difícil (mas no imposible) de cumplir, la presión se hace sentir, el equipo hace un esfuerzo extra, se trabaja a las apuradas, a deshoras, se llega a tiempo o no, y luego... nada.

¿Nada? Sí, nada. Ni para bien ni para mal. Nada si se ha cumplido o alguna suerte de reprimenda o discurso sobre la responsabilidad, la confianza y los compromisos asumidos, si es que no. La vida sigue, el desarrollo continúa, se agregan funcionalidades, se corrigen errores... la presión desaparece...

Supongamos que ésa es la situación percibida, ¿cuál es el origen? Si no tenemos más información hay que inventarla. Inventemos. Me imagino tres escenarios, que se pueden ir completando a placer:

1. La fecha límite fue artificialmente establecida para "meter presión" al equipo. La creencia subyacente puede ser que la gente se "relaja" cuando no tiene un límite de tiempo, se pierde en detalles o simplemente vaguea.

2. La fecha era real, pero poco importante. No hay un cliente comprometido ni socios desesperados. El líder apunta que (a ojo de buen cubero) no está tan lejos de "quedar bien" hacia arriba terminando justo a tiempo (o un poco antes) si presiona hacia abajo. O tal vez era un hito interno en su línea de tiempo, y exagerar la importancia de esas fechas es su manera de tener las riendas cortas.

   Así que presiona. Si llega mejor, y se olvida de bajar las felicitaciones (o no las hubo, porque esto puede suceder a cualquier nivel). Si no se llega aparece el discurso un tanto licuado y abstracto mencionado más arriba, porque al fin y al cabo no hay una gran mala noticia.

3. El límite existe, y sí era importante.

   Una posibilidad es que el líder haya utilizado su cintura para "zafar" de la situación y todo pasó de largo.

   Otra posibilidad es que, intentando "resguardar" al equipo de presiones excesivas, actuó como paraguas y no bajó el escarmiento.

En resumen: la fecha no existía, o sí pero no era importante, o sí pero el equipo no se enteró de las consecuencias.

Independientemente del origen o las causas subyacentes, si la comedia anterior se representa un par de veces los integrantes del equipo reaccionan como los habitantes del pueblo: simplemente se vuelven inmunes a las fechas límite y renuentes a hacer cualquier esfuerzo extra para cumplirlas.

Esta reacción es esperable, incluso la más lógica y, desde el punto de vista del equipo, la más sana. La experiencia les ha enseñado que esforzarse por alcanzar esas fechas no tiene ningún beneficio, ni su incumplimiento consecuencia alguna.

Es terríblemente difícil salir de esta situación sin un hito desagradable (como sería para Pedro aparecer sin un brazo o una pierna) o costoso (Pedro podría perder algunas ovejas), un golpe de efecto. Se necesitaría, por ejemplo, la pérdida de un cliente o la aparición de un bonus por cumplimiento de la fecha de entrega. Desagradable o costoso. Malo o menos malo (desde el punto de vista de la empresa), malo o bueno (desde el punto de vista del equipo).

Pensemos en cómo el feedback, en cualquier caso, modifica las cosas (cada punto es el correspondiente a la situación mencionada arriba):

1. Por más que la fecha establecida sea "artifical", proporcionar feedback demuestra preocupación por el estado del proyecto, conciencia de su estado, monitoreo constante. Es decir, demuestra la importancia que se le asigna, el interés que tiene para el líder. Sea este interés ficticio o no, motiva. O por lo menos no desmotiva, como sí lo hace una fecha que luego pasa prácticamente desapercibida.
2. Si la fecha es poco importante, se aplica el mismo razonamiento del punto anterior. Podemos además agregar que la fecha alguna importancia tiene. Si es importante para el líder puede ser importante para el equipo. Por ejemplo, quedar bien hacia arriba es un beneficio que se multiplica al ser extendido a cada uno. ¿Por qué no hacerlo?
3. Si la fecha era realmente importante, es tal vez el peor caso. Los motivos para el compromiso están, pero no son transmitidos. No es raro notar la falta de éste.

En todo caso, la ausencia de feedback sólo puede dar indicios negativos: poco interés en el proyecto o presión acumulada en "algún lado" o manipulación grosera y finalmente inútil (BTW: ¿"manipulación" es "motivación grosera" por definición?), un líder ausente o... no perfecto (para decirlo políticamente).

Un líder de proyecto tiene muchas tareas y atribuciones. Pero para un equipo de profesionales todas pueden resumirse en una: establecer un medio en donde la información fluya, ya sea comunicando o facilitando u obligando a los demás a comunicarse, en todas la direcciones.

Hay mucho que comunicar en un proyecto de software: los requerimientos, las restricciones, los recursos, los avances, las novedades, los cambios, todo. En un equipo de profesionales, un líder no impone sino comunica... bueh, esto dependerá también de qué tan profesional sea el líder ¿no?

El hecho es que siendo un sistema de comunicación (ver artículos relacionados), cualquier problema de comunicación en un integrante del equipo, y más en el lider, es muy problemático.

Sobre esto último, algunos relacionados:

La autopista del desarrollo.

Una clase sobre buenos modales.

Comunica... ¿QUÉ?

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

Comunicación: aprender a comunicar y aprender a escuchar.

No me canso de machacar con el tema de la comunicación, competencia fundamental como pocas.

En El inconformista este par de artículos conforman un muy buen punto de partida, ideal para programadores huraños inmersos en una burbuja de algoritmos:

• Cómo convertirse en un buen comunicador.
• Aprender a escuchar.

Que les aproveche.

Estimaciones y responsabilidad.

Me han quedado dando vueltas por el fin de semana las cuestiones que planteaba en el último artículo, Estimaciones y compromisos.

Por un lado lo he charlado un rato con los colegas del trabajo. También se lo he referido a Yuki en su blog De consultor a Director de TI. Pueden ver su respuesta en los comentarios de esta entrada.

Quisiera desarrollar el tema de la responsabilidad, que surge de la transformación de la estimación en un compromiso, situación comentada en La masa, el ladrillo, la bota, el bocadillo... de la siguiente manera:

Generalmente cuando recibimos estimaciones es porque nos encontramos en una situación de autoridad dentro del proyecto y nunca debemos olvidar que la autoridad conlleva responsabilidad. Somos responsables de cómo tratamos estas estimaciones. Y la máxima es clara: No conviertas las estimaciones que recibes en compromisos.

Desarrollando esa idea, desde el punto de vista de los desarrolladores que elaboran esas estimaciones, había escrito:

¿Somos responsables del error? Del error de asumir el compromiso en ciertos términos, quiero decir. No digo del error de estimación, ya que no considero que la estimación sea errónea (¿lo es?). Por más desviada que esté, ese desvío refleja nuestro desconocimiento al momento de hacerla. Creo que no es lo mismo que un error (que sí sería uno de cálculo por ejemplo).

El hecho de si una estimación fallida es un "error" o no es una cuestión casi teórico-filosófica. El hecho es que el proyecto se encuentra desviado respecto de ella, y punto.

En las causas del desvío pueden converger un sinfín de factores. Tiendo a pensar ahora que el de más peso es la falta de experiencia. Estamos estimando, y obviamente no tenemos información completa. De todas maneras, toda información está referida al pasado, a un contexto diferente y en situaciones que no tienen garantía de repetirse. Pretender lo contrario sería requerir una bola de cristal.

Estimamos entonces utilizando nuestra experiencia. Y ponemos en juego nuestra habilidad para extrapolar esas situaciones al futuro, reconociendo similitudes y diferencias y tratando de asignarles un valor en horas.

¿Y si no tenemos experiencia? Bueno, por algún lado se empieza. Prueba y error, y probablemente al principio sean todos errores.

Ahora, el tema de la responsabilidad. En un proyecto cerrado hay que comprometer una fecha con el cliente. Esto es inevitable y razonable, son las reglas del juego. Es un compromiso que no puede eludirse.

Entonces, ante las preguntas que había planteado:

¿Nos hacemos cargo del compromiso asumido, dado que no hemos sido nosotros quienes lo hemos hecho? ¿Cómo? ¿Trabajamos más horas? ¿Aceptamos hacerlo gratis? ¿Hasta qué punto?

Creo que la primera respuesta es sí. Nos hacemos cargo del compromiso, porque no podemos pretender que ignorábamos las reglas del juego al momento de estimar. El tema es cómo.

Tenemos la responsabilidad de llegar a determinada fecha. Y de ser imposible, tenemos la responsabilidad de avisar apenas seamos conscientes de este hecho. Responsabilidad no implica hacer lo imposible, sino hacer todo lo posible.

¿Y qué es "todo lo posible"? Ahí está el punto. Sólo cada uno de nosotros sabe qué es lo que está dispuesto a dar. "Todo lo posible" es, en lo material, muy diferente para un joven recién egresado (digamos que vive solo y sin muchos compromisos familiares) y para una persona casada y con hijos (sobre todo) que siente una responsabilidad "de estar presente" mucho mayor para con ellos. Es, en todo caso, un tema personal.

Lo que no es personal es el compromiso para con el equipo. Que se traduce en dejar en claro de qué manera y bajo qué condiciones estamos disponibles. Se trata de volvernos previsibles, de dar predictibilidad al proyecto, de dar toda la información (incluso aquélla que nos deja en una situación incierta) que tenemos disponible para que los responsables formales puedan tomar una decisión.

Se trata, en definitiva, de ayudar a tomar una decisión con respecto al camino a seguir de forma que podamos estar de acuerdo con ella y apoyarla. Y si no podemos estar de acuerdo y acompañar, se trata de explicitarlo y asumir las consecuencias.

Es, por otro lado, no ceder ante la presión aceptando de palabra una situación que luego, en los hechos, no toleraríamos. Hacerlo sería mentir, engañar. Me imagino, por ejemplo, el clásico lugar común en el que un integrante del equipo "dice que sí a todo" y mientras se busca otro trabajo (pura imaginación, aclaro, es sólo un ejemplo). Esto último sí me parece moralmente reprochable. Es planear "con premeditación y alevosía" bajarse del proyecto mientras se lo envía con rumbo desconocido.

En resumen, ¿cuál es nuestra responsabilidad ante un desvío, error o como se llame en la estimación? Avisar y ser abiertos y sinceros al momento de buscar los caminos de acción posibles, dar información confiable. Creo que es un compromiso más razonable que el aceptar trabajar 15 horas al día sólo para decir, cuando todo se vaya al diablo, "yo hice todo lo posible".

Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

A veces me pongo extremista y veo al desarrollo de software solamente como un sistema de comunicación. Si lo vemos como una caja negra, se trata de de transmitir y traducir los requerimientos en una serie de instrucciones que un hardware pueda ejecutar, llevando a cabo la tarea que estos requerimientos representan. Por lo menos idealmente.

Si abrimos esa caja negra, encontraremos varios "puntos de retransmisión y traducción", que más o menos se corresponden con las etapas de relevamiento, análisis, diseño y codificación. Cada etapa nos acerca más desde el lenguaje del emisor (el cliente) al lenguaje del receptor (ese equipo de hardware).

En resumen, los requerimientos son el mensaje, el cliente es el emisor y el hardware que finalmente debe ejecutar la secuencia de instrucciones acorde es el receptor. En el camino tenemos varios retransmisores, algunos humanos y otros no: analistas de negocio, analistas funcionales, programadores, entornos de desarrollo, compiladores, personal de soporte al cliente (al instalar), sistemas instaladores. El mensaje se transmite a través de varias formas y a través de varios medios: oralmente, por escrito, electrónicamente.

Bajo esta óptica, somos retransmisores al tiempo que traductores.

Como en todo sistema de comunicación, hay ruido de fondo y ruido generado por el propio sistema. Ambos tipos de ruido deforman inevitablemente el mensaje. La comunicación perfecta no existe, por tanto tampoco existe el software perfecto.

Siguiendo por este camino, en el que suelo entretenerme inventando y perfeccionando analogías, llego usualmente a la siguiente conclusión (bombos y platillos):

La calidad del software depende de es la fidelidad con la que el equipo transmite un mensaje, por ello todos los participantes de un equipo de desarrollo de software deben ser excelentes transmisores de información.

De nada sirve ser un experto programador, analista o visionario del negocio si no se puede transmitir fielmente esa información a través del proceso de desarrollo.

Transmitir implica básicamente dos tareas: recibir y enviar. Incluso un programador independiente que trabaja absolutamente solo debe ser un experto escuchando o leyendo al cliente (recibiendo) y programando (enviando).

Recibir es usualmente escuchar, leer. Transmitir es usualmente hablar, escribir.

El problema de escuchar y hablar es que, como se dice coloquialmente, a las palabras (y muchas veces a las personas que las pronuncian) se las lleva el viento.

¡Cuidado! Ahí vienen los pseudo-ágiles: que el exceso de documentación, que la comunicación informal, que los cambios continuos y un largo etcétera.

¿Cuál es la diferencia entre pseudo-agilidad y verdadera agilidad?

En el desarrollo pseudo-ágil no se preserva nada. Llegamos al punto de encuentro con el cliente y estamos solos. ¿Qué pasó? No tenemos idea.

En el desarrollo ágil se preserva solamente lo indispensable: el mensaje, los requerimientos. Es absolutamente minimalista: hay que preservar sólo el mensaje, pero hay que hacerlo como si fuera la vida misma, y verificar continuamente que no haya sido malinterpretado por nadie. Como recalqué muchas veces: tal es así que en XP las historias del usuario las escribe el mismo usuario, y éste es parte del equipo. Creo que solamente por una cuestión legal las cadenas para retenerlo cerca del equipo (que seguramente figuraban en los primeros bocetos) fueron finalmente suprimidas.

Aclarado que tenemos que preservar al menos el mensaje original, los requerimientos, el tema es cómo.

Me agarra el viejazo cuando me vuelvo tradicionalista, pero todavía nadie me convence de lo contrario: el texto es el rey. Es la herramienta más sencilla para el conjunto de actividades que se realizan alrededor de los requerimientos: recibirlos, discutirlos, modificarlos, transmitirlos, catalogarlos, archivarlos, buscarlos.

Pensemos en otros soportes posibles. Omito los puntos "catalogar" y "archivar" ya que con las herramientas disponibles serán sencillos para cualquier soporte.

Los gráficos son más difíciles de producir y modificar, aunque usualmente mejores para discutir y transmitir. La búsqueda no es sencilla, justamente porque contienen poco texto.

En cuanto a imagen y sonido, grabar la descripción de los requerimientos parece una buena idea, pero no me parece un soporte fácil para recibir o discutir, mucho menos de modificar. No me imagino en una reunión diciendo "poné de vuelta esa parte... no... un poco antes... ahí, ¿no debería decir...?" La transmisión es más complicada y la búsqueda sólo puede realizarse bajando el contenido a texto.

Recordemos que hablamos de requerimientos que cambiarán continuamente. A mayor complejidad mayor resistencia al cambio. Y cambio en los requerimientos es moneda corriente.

Así que si me preguntan a mí, texto.

Resumen: habilidades a valorar en un integrante de un equipo de desarrollo (¿o mejor dicho, de un equipo, a secas?): leer y escribir (porque si no a las palabras -o al integrante- se las lleva el viento). ¿Alguna vez los evaluaron en eso en una entrevista de trabajo?

BTW: Menudo título, ya sé, pero estoy cansado de aparecer en cualquier lado por hacer bromitas con los títulos de los post. No lo hagan.

Comunica... ¿QUÉ?

En varios posts (por ejemplo aquí y tangencialmente en muchos otros) hablé sobre la importancia de la comunicación en el equipo de desarrollo. De hecho, el trabajo en equipo es básicamente comunicación, y realmente poco más que eso.

El desarrollo de un sistema de software es muy sensible a los problemas de comunicación, a los malentendidos y confusiones en todo nivel: desde los requerimientos hasta el mantenimiento. Tal vez esta sensibilidad tenga que ver con que es la traducción de un proceso de negocio a varios lenguajes, desde los menos estructurados (relación con el cliente, análisis funcional, gestión del proyecto) hasta los más estructurados (lenguajes de programación, de consulta a la base de datos, de diseño de interfaz con el usuario).

Usualmente, para cada uno de esos lenguajes tenemos uno o varios profesionales en el equipo, y de alguna manera tienen que encontrar una base para entenderse. Pensemos por un segundo en qué diferente es el sistema visto desde el usuario, desde el líder de proyecto, el experto en base de datos, los programadores, los diseñadores, y nos parecerá casi un milagro que todas esas miradas logren coordinarse de alguna manera (cuando lo hacen).

En resumen, ya bastante difícil es la coordinación entre profesionales de una misma área (dentro del equipo de programadores, digamos), y se complica muchísimo más entre profesionales de distintas áreas.

Entonces, veamos el mismo problema desde dos puntos de vista diferentes. Es intersante ver que hay que pensar un rato para darse cuenta de que es el mismo problema.

Tomemos entonces "El éxito depende de tres cosas: comunicación, comunicación, comunicación" de Mejores Proyectos (un blog justamente orientado a líderes de proyecto).

Y por otro un aporte de Cerebrado, que creo que resume bastante bien cómo son caracterizados -a veces- esos "otros niveles" de un equipo de desarrollo.

ACTO I.

• Líder (L): El reporte tiene que tener mas o menos éstos campos.
• Programador (P): ¿Tiene o no tiene que tener el campo “X”?
• L: Y... si hay lugar ponélo.

ACTO II. Dos meses después.

• L: ¿Gente, por qué no está el campo “X” en el reporte?
• B: porque no había espacio para ponerlo.
• L: Pero... se suponía que tenía que estar.
• B: ¿En qué charco está escrito que tenía que estar?

... continúan líder y programador en un sinfín de si-no.

ACTO III.

• L: Listo, en ésta semana terminamos el módulo prometido.
• Jefe máximo que paga los sueldos de todos (DIOS): la semana pasada me dijiste lo mismo
• L: (Y la semana que viene le diré lo mismo, me parece) Sí, pero ésta vez ya está terminado.
• DIOS: (Ya no te creo nada.) Bueno. ¿Le comunico al cliente que estamos instalando el viernes?
• L: (El viernes me quiero ir temprano...) Mejor el lunes, por cualquier cosa.

ACTO IV. Ese viernes a las 18.00.

• L: Muchachos, el lunes instalamos.
• P: ¿Cómo? ¿Qué? ¿Cuándo? ¿Por qué? ¿Quién?
• L: Sí, el jefe máximo dio directivas claras, pero no se preocupen, en mi planilla figura que estamos en término.
• P: ¿Y cuando vimos nosotros esa planilla?
• L: Ni hace falta que la vean, para eso estoy yo.
• P: (¿Para qué era exactamente que estabas vos?)...

P llama a A (amigo) y le pregunta si el lugar donde labura está bueno. Como A es nuevo en ese trabajo le dice que sí. B manda el CV.

(TELÓN)

Mientras acomodaba todo esto pensaba "los programadores deberíamos leer más blogs de líderes de proyectos, analistas y emprendedores que de otros programadores", para acortar la brecha, para entender un poco más la mirada del otro lado (en la que somos los programadores los que quedamos siempre mal parados).

¿Alguien conoce?