Tinselcity

Pensando En Equipo

Programar

Hace cosa de un año me decidí a escribir algunas ideas sobre la actividad de programar. Decidí centrarme en lo que significa programar en sí. Es decir, en la actividad de solucionar problemas escribiendo programas, como una actividad fundamentalmente individual, como la actividad del programador o programadora, de una persona que se enfrenta a un problema, lo estudia, comprende, busca una solución e implementa dicha solución escribiendo un programa.

El resultado fue Pensando en Programar. Un escrito algo flojo, simplemente una serie de ideas y sugerencias, basadas en mi propia experiencia, de cómo debemos enfrentarnos a esa actividad de programar. Como ya hay mucho escrito sobre temas que tratan directamente el código y los aspectos más técnicos de la programación, decidí centrarme en algo de lo que se encuentran menos explicaciones: la parte que implica “pensar”, resolver problemas.

Como decía, no creo que sea una obra de gran trascendencia. Ni siquiera creo que sea demasiado bueno lo que escribí allí. Sin embargo, sí creo que esa intención, esa idea de centrarnos más en el aspecto de pensar y resolver problemas de la programación, es algo que sigue necesitando que se escriba muchísimo más sobre ello.

En cualquier caso aquello se centraba en la actividad individual del programador. Existen muchos casos en que esto es todo lo que hace. Trabaja solo. Puede que elija o no el qué hacer, pero al trabajar sólo prácticamente siempre elegirá el cómo hacerlo a muchos niveles. Seguirá siendo una actividad principalmente individual, donde tome las decisiones dirigido únicamente por el objetivo del proyecto y sus necesidades/capacidades/preferencias personales.

Sin embargo, hoy en día, en el ámbito de la programación profesional, el desarrollo de software casi nunca es una actividad individual. Lo habitual es que el software se produzca en equipo. En uno o más equipos. Colaborando con equipos de otras empresas. O de la misma empresa. Con clientes. Con equipos de otras disciplinas, como negocio, comercial, administración, recursos humanos… Esto, trabajar con otras personas, es lo habitual.

Y en esto surgen toda una serie de problemas y preocupaciones que van más allá de lo que es la programación a un nivel técnico de “escribir código”, pero que siguen estando muy íntimamente relacionados con el aspecto más general de “resolver problemas”.

Pensando En Equipo

He tenido la suerte -aunque a veces no lo llamaría exactamente “suerte”- de trabajar con equipos muy distintos, en proyectos diferentes y circunstancias variadas, a lo largo de mi carrera. Seguramente hay quien lo haya hecho más que yo, y también menos que yo. No voy a pretender reclamar que he tenido una experiencia especial, ni mejor, ni más apropiada que la de otras personas. Simplemente es la que he tenido.

Lo que sí creo que tengo derecho a señalar es que yo, dentro de lo que he podido, me he tomado la molestia de fijarme en todas esas circunstancias, equipos, proyectos, situaciones, etc. Y no solo fijarme, sino que he intentado ir un poco más allá y preguntarme qué se puede aprender de todo ello, qué se puede extraer que vaya más allá de la anécdota de uno de esos proyectos o circunstancias. Esto no lo hace tanta gente. La mayoría se limita -como mucho- a analizar su propia y única perspectiva.

Es con esta idea de extraer algo que vaya más allá de un único proyecto, de una única circunstancia, que he decidido escribir ahora algunas ideas -porque no sé si esto llegará a nada más que unas pocas ideas con un pequeño hilo común- centradas en “esas otras preocupaciones de la programación” que surgen de la necesidad de pasar de lo individual a lo colectivo, del trabajo de una sola persona al de un equipo completo.

Nota: Escribo esto centrándome en un equipo de desarrollo de software. Con esto no quiero decir que todo lo que escriba será exclusivo de este tipo de equipos. Tampoco pretendo decir que nada de lo que escriba deba funcionar con cualquier equipo. Como decía antes, he trabajado con muchas personas y muchos equipos diferentes y en un número no despreciable de casos, la intervención de diferentes factores (sean estos actitudes personales, restricciones contractuales, restricciones técnicas, o cualquier otro tipo de factor) hacen muy difícil, por no decir imposible, que el proyecto pueda salir adelante correctamente. Escribiré también sobre esto, pero es algo que conviene tener siempre en mente porque a veces no hay soluciones fáciles.

También es importante señalar que la perspectiva no es la de gestionar un equipo. Mi intención es presentar algo que sirva para todos los miembros del equipo sea cual sea su papel dentro de este.

  Equipos de Desarrollo ¿Equipo? ¿Qué? ¿Por qué?  
  Infraestructura del Equipo Antes de formar un equipo...  
  equipo Formar un Equipo  
  xxx zzz  
  xxx zzz