lunes, 16 de agosto de 2010

Herramientas, metodologías y personas

Hace un tiempo ya que estoy trabajando en un proyecto heredado.
Este proyecto, sencillo en realidad, empezó hace tiempo (no viene al caso cuanto) y por cuestiones que desconozco fracasó con el proveedor anterior.
Ahí es donde entramos nosotros (la empresa donde trabajo actualmente y desde hace ya un buen tiempo) para tratar de corregir los problemas y hacer que, finalmente, el sistema funcione.
Tecnológicamente no es ni siquiera actual, es un proyecto con tecnología vieja (java 1.4, ejb 2.1, Base de datos Oracle 9.2, etc) y la verdad, los primeros vistazos al sistema en general me dejaron preocupado, es la primera vez que me toca diagnosticar e intentar corregir los problemas de una aplicación así. No solo cuentan las tecnologías utilizadas sino que también los grupos de personas involucrados y el como ve el cliente al sistema, la importancia que tiene para el y la forma en la que lo llevó adelante ya que, seamos honestos, cuando un proyecto falla, tanto el cliente como el proveedor tienen la culpa. ¡Que no les mientan!
Ahora bien, una vez asumida la responsabilidad por este "viejo/nuevo" sistema me tocó buscar oportunidades de mejora, no solo a nivel diseño y codificación, sino que (aquí la parte que más me gusta) a nivel "proceso".
¿De que trata el tan famoso proceso de desarrollo?. Bueno existen tantas respuestas como personas piensen en ello y es por eso que voy a responder la pregunta con lo que es mi visión personal sobre el significado de proceso de desarrollo:
Puede llamarse proceso de desarrollo a TODAS las actividades involucradas con el día a día del programador. No es suficiente con adoptar una metodología de desarrollo (iterativa e incremental, pero carente de humanidad), sino que debe adoptarse un proceso completo, el cual ha de tener en cuenta todas las herramientas a utilizar.
Podemos decir que el proceso de desarrollo involucra:

Herramientas
Pocas veces, al menos en mi experiencia, se le da importancia a las herramientas mediante las cuales se pretende llevar un proyecto adelante. Total, y lo he escuchado, es solo cuestión de instalar. Epic Fail!!!
Podemos tener las mejores herramientas del mundo, que si no sabemos usarlas, las reduciremos a un notepad avanzado o poco más. Jamás debemos abstraer las herramientas de las capacidades del equipo con el que contamos.


Metodologías
Alguna vez me preguntaron en una entrevista ¿Sabés metodología de desarrollo scrum? mi respuesta fue, más o menos, ¿Sabés que estás preguntando?. Ojalá existiese una metodología que cuadre a todos los equipos de personas. Ojalá fuese tan simple como decir: Gente, aprendan esta metodología que es la que vamos a usar. Nada más alejado de la realidad. A las metodologías las hacemos las personas involucradas en su uso, maduración, corrección y mejoras. No hay una metología que nos garantice un resultado existoso. Solo existen un conjunto de lineamientos que nos pueden ayudar (o confundir) a la hora de tratar de armar los circuitos lógicos en la vida del proceso de desarrollo, pero solo eso.
¿Cual es mi preferencia? prefiero los métodos ágiles, pero ninguna metodología en particular.

Personas
El componente central en cualquier actividad llevada adelante por, precisamente, humanos. Aquí es donde todo confluye. Estamos signados por lo que somos como equipo de desarrollo. Por las virtudes y defectos del conjunto. Por lo conocimientos y falencias de todos. Nadie en el equipo de desarrollo debe ni puede quedar exento de culpa o responsabilidad a la hora de llevar adelante la tarea encomendad. Somos lo que somos porque somos una de las variables en la ecuasión del equipo. Tanto las metodologías como las herramientas quedan supeditadas a las capacidades del equipo en su conjunto y no podemos, ni debemos forzar esta realidad. No podemos pretender que el equipo se ajuste de forma natural a una nueva herramienta, a una nueva metodología porque no será así. Ese trabajo, el de ajuste, nos corresponde a nosotros, los que estamos encaragados de guiar al equipo, ya que es, indefectiblemente, la parte principal de nuestra tarea.


De mi experiencia personal, solo me queda decir un par de cosas, tratando de redondear el post:
1- Nunca debemos forzar a un equipo más allá de sus posibilidades. Los equipos de personas son predecibles, siempre y cuando estén en un ámbito que se ajuste a sus características. Si los forzamos más allá, puede salir bien, pero esa será la excepción.
2- Nunca tomar a la ligera las costumbres del equipo de trabajo. Es una realidad que cuando un equipo de trabajo está acostumbrado a una serie de tareas, una serie de herramientas y una metodología, será más productivo con ella. Podemos, sin embargo, introducir pequeñas variaciones haciendo incapié y demostrando que son mejoras, para que con el tiempo terminemos trabajando de mejor manera, incluso, con una metodología totalmente diferente de la inicial.
3- En cualquier proyecto, lo más importante son las personas. No hay forma de llevar adelante un proyecto si no tenemos en cuenta esto. Todo debemos ajustarlo al equipo que guiamos. Siempre habrá premisas, obvio, pero no son responsabilidad del equipo. Son responsabilidad de nosotros, los que guiamos al equipo y como todos sabemos: La responsabilidad no se delega, solo se delega la tarea.

Saludos

No hay comentarios:

Publicar un comentario