La composición musical de un equipo de desarrollo de Software
El otro día tuve la oportunidad de acudir a un concierto de música clásica, un concierto de primavera para más señas.
El auditorio de forma circular, permitía envolver a la orquesta.
Tuve la mala o buena suerte de estar justo en la parte posterior de la orquesta.
Acústicamente el lugar no era el más idóneo, posiblemente a causa de algún fallo de diseño del auditorio, ya que el auditorio debería estar diseñado para que la acústica fuera envolvente y excelente desde cualquier punto del propio auditorio, sin embargo, desde el punto de vista del trabajo en equipo de la orquesta, el lugar en el que estaba era privilegiado.
Desde allí, pude observar al director de la orquesta gesticular, expresarse y mover con énfasis y pasión a los integrantes de la orquesta.
Después de 30 minutos observando y escuchando las piezas que tocaban no pude evitar hacer honor a mi deformación profesional, así que no pude dejar de acordarme y comparar a la orquesta y su director a la cabeza con lo que es un equipo de desarrollo de software.
Por expresarnos de un modo correcto, «Orquesta» es una palabra que procede del griego y cuyo significado es «lugar para danzar».
Desde el punto de vista de la RAE, significa «Grupo de músicos que interpretan obras musicales con diversos instrumentos».
Si buscamos en la RAE la palabra «desarrollador» veremos que no existe en el diccionario pese a que se usa erróneamente con frecuencia.
Sí existe sin embargo, «equipo», «software» y «desarrollo».
Así, en la RAE, desarrollo es entre otras definiciones la «acción y efecto de desarrollar o desarrollarse», y equipo, significa «grupo de personas organizado para una investigación o servicio determinado». Software evidentemente lo conocemos todos, y su significado es «conjunto de programas, instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora».
Por lo tanto y de acuerdo a nuestro caso, lo correcto sería expresarnos como «equipo de desarrollo», o «equipo de desarrollo de software» para ser más concretos sobre el cuál se realiza la acción de desarrollar (sobre el software).
Comentado esto, la simbología entre una orquesta musical y un equipo de desarrollo de software es bastante próxima bajo mi punto de vista. Pero eso ocurre con prácticamente todas las cosas que nos rodea ya que el desarrollo de software no es nada excepcional, aunque tampoco nada despreciable. La diferencia está en los detalles, aspectos estos que pasan desapercibidos en muchas ocasiones.
¿Alguien piensa en un equipo de remeros sin una persona que marque el ritmo de palada para evitar que la barca de vueltas sobre sí misma sin rumbo ni concierto?.
¿Alguien piensa en un equipo de albañiles que deben trabajar en una obra sin que nadie revise, supervise y exija cómo deben hacerse las cosas y en qué lugar deben ir?.
¿Alquien piensa en una orquesta musical sin un director de orquesta que dirija a las personas que forman parte de la orquesta para que leyendo un guión establecido (partitura) lleven un movimiento armónico sabiendo qué debe hacer cada integrante y en qué momento, generando esa composición global de trabajo en equipo (la pieza)?.
¿Alguien piensa que en un equipo de desarrollo de software no exista la figura de jefe de proyecto y del resto de los miembros del equipo bien diferenciados, organizados y con tareas y acciones concretas que permitan la ejecución armónica de los procesos?.
La similitud es enorme como nuestra lógica manda. Pero hay detalles que a veces dejamos aparcados por desconocimiento, por despiste o por otra causa, como si no fueran tan importantes.
En algunos casos de trabajo en equipo, la metodología se hace quizás más necesaria que en otros tipos de trabajos. En el desarrollo del software, tener una metodología es crucial bajo mi punto de vista.
En otros casos, las pruebas también son importantes. No me imagino por ejemplo a un albañil haciendo un muro de 10 metros de largo por 2 de ancho para ver que tal queda y empujándolo para ver si está firmemente asentado al suelo y su horizontal. Pero si el proceso de seguimiento de realización del muro se hace de acuerdo a unos patrones ya preestablecidos, estaremos asegurando un muro dentro de unas condiciones de calidad mínimas exigidas (usando una plomada por ejemplo, utilizando unos materiales con unas especificaciones determinadas, etc).
En otras ocasiones, el movimiento armónico de los integrantes es primordial y todos deben moverse según unos planes preestablecidos para lograr los objetivos marcados. Imaginaros una carrera de remeros en la que dos remeros del lado derecho dejan de remar o que dan la palada cada uno según le parece. Es fácil entender que pasaría. ¿Os imaginais las consecuencias?.
En el caso de la orquesta que comento, me resultó curioso observar varios aspectos.
Por un lado, no pude evitar pensar en la cantidad de horas de ensayos y pruebas que debieron llevar a cabo para que el día de su «puesta en producción» no fallara nada.
Aún y así, falló algo.
El violonchelista principal (uno de los integrantes de la orquesta más destacados) tuvo un problema aproximadamente en los tres cuartos de la primera pieza.
No es que yo sea muy listo (ojalá lo fuera), pero me dí cuenta de que algo «raro» pasaba. El caso es que como toda la orquesta continuó la pieza sin problemas y sin pestañear, tampoco le dí más importancia pensando en que era más fácil que yo estuviera errado que otra cosa. Nada más acabar la pieza, el violonchelista abandonó la orquesta con instrumento en mano y apareció a los 4 ó 5 minutos probando su instrumento. Estaba claro, se le había roto una de las cuerdas del violonchelo. Sin embargo, el equipo (la orquesta) siguió trabajando como si el impedimento no hubiera existido nunca y realmente llegué a pensar en que lo que había detectado como «raro» no era percepción errónea, pero aún y así, el problema se resolvió de una forma muy elegante.
Otro aspecto de éxisto destacable de la orquesta fue el hecho de que cada integrante supiera perfectamente que tenía que hacer, cómo tenía que hacer sus tareas, y cuando tenía que hacerlas.
Me pareció también muy cuiroso como una vez acabadas las piezas musicales, el director de la orquesta ante los aplausos de los asistentes, no hacía nada más que darse la vuelta alrededor suyo y extender la palma de la mano sobre todos los integrantes de la orquesta obligándoles con sus gestos a levantarse y haciéndolos merecedores de los aplusos.
Diréis que estoy un poco tonto, pero pensé… ¡eso sí es un equipo!.
Tan importante es en un equipo el «jefe» del propio equipo, como la última de las personas que forman parte de él, algunas de las cuales incluso, se han involucrado en el proceso en algún momento, pero que no tienen porqué dar la cara como en el caso de la orquesta.
Incluso hubo músicos que sólo aparecieron 1 vez en las 7 piezas que tocó la orquesta.
Seguramente hubo músicos que habiendo aparecido en las 7 piezas, tuvieron menos protagonismo que el mismo músico que solo apareció en 1 de las piezas, pero todos, absolutamente TODOS, formaron parte de la orquesta en algún momento de la representación del concierto, y el objetivo, no era hacer sonar 1 pieza sino las 7 piezas y con éxito.
En el desarrollo de software ocurre muchas veces lo mismo.
De forma un poco desorganizada, tan importante es el jefe de proyecto, analistas y programadores, como las pruebas unitarias y de funcionalidad que deben ejecutarse, como la preparación de los equipos hardware de producción, pre-producción y desarrollo, la designación de una metodología de trabajo, la descripción de la funcionalidad o funcionalidades a cubrir, la asignación de tareas y la complicidad de todos los integrantes para que ante una eventualidad como en el caso del violonchelista principal, todos los integrantes del equipo se comprometan a sacar el barco hacia adelante.
Pero para llegar a este punto, tendremos que hacer muchas muchas pruebas. Los músicos de la orquesta han tenido que hacer un extenso curso de solfeo, coral, etc., y dedicar muchas muchas muchas horas de práctica. El desarrollo de software no es diferente. Cualquiera puede desarrollar (sí, he dicho cualquiera, que nadie se sienta un ser especial por saber programar), pero el objetivo no es programar, sino ser el mejor programador posible. Para desarrollar en las mejores condiciones y con una base sólida, sólo hay un camino. La práctica, cometer errores, caerse y volverse a levantar, y sobre todo, intentar mejorar y ser capaz de aceptar los retos que se nos proponen y llevarlos a cabo de la mejor manera posible.
La persona que programa siempre estará aprendiendo, y dentro de un equipo de desarrollo de software cada integrante del mismo está día a día adquiriendo conocimientos. Compartirlos nos ayudará además a ser mejores y más preparados. Creo que casi todo el mundo tiene claro que la consecución de los objetivos se logra en equipo, y se avanza mucho más juntos que por separado, y con ello se puede llegar a un alto grado de excelencia y motivación.
Referencias:
Enlace Web: RAE.
4 Responsesso far
Jorge, ¿tu sabes cuál es la diferencia entre una orquesta y un equipo de desarrolladores? Pues que si la orquesta va mal es culpa de todos, si el proyecto va mal es que la informática es así. 😛
¿Y en qué se parecen indebidamente? En que ambos pagan canon sin tenerlo que hacer. 😛
En el artículo, donde debería decir «Otro aspecto de éxito destacable ..» dice
«Otro aspecto de éxisto destacable …»
Atte.,
Alvarez Arigós Roberto Miguel
rmaa77@yahoo.com.ar
Bueno, mi pequeña reflexión, hay algunas diferencias, la orquesta interpreta generalmente una pieza, que alguien ya a compuesto (El Arquitecto, en plan Matrix), el director de orquesta por supuesto dirige el cotarro, pero como la obra sea mala por mucha orquesta y mucho director, sonará como el culo.
t7r678uhgyf