Mejorando cuando se trabaja en proyectos

Esta es la realidad: la mayoría de los desarrolladores y gestores trabajamos en proyectos para un cliente específico final. Es decir, hay un cliente que genera unas especificaciones y un equipo que las desarrolla (en el mejor caso esos requisitos están claros al principio aunque lo habitual es que no lo estén).

¿Pero es que puede haber otra cosa? Claro que sí, no tiene absolutamente nada que ver la dinámica de trabajo en un proyecto que la dinámica de desarrollo de un producto software.

Ya he hablado en alguna ocasión sobre esta cuestión, pero ahora quiero enfatizar qué aspectos en el desarrollo de proyectos se deben cuidar mucho para evitar que tanto los equipos de trabajo como la misma compañía caigan abrumados bajo el peso de multitud de proyectos mal gestionados y mal cotizados.

El desarrollo de un proyecto está lleno de detalles y todos cuentan: el resultado final es un conjunto de aspectos que se han ido haciendo suficientemente bien, como en cualquier otra actividad profesional. Si descuidamos algunos, se notará en el resultado final. Sencillo de entender, ¿no?

Recientemente he visitado una empresa en la que he visto que se dan algunas de estas circunstancias: gente con ganas de hacer las cosas mejor pero agotadas de las guerras del día a día en que no hay tiempo de pararse un momento y ver qué no funciona o qué se puede mejorar. No hay que ser muy listo para evidenciar qué se está haciendo mal o qué impide que las cosas avancen mejor, el problema es que tú puedes pensar algo pero tiene que ser el gestor del equipo, sus jefes o el responsable de la compañía el que ponga los medios para que la gente trabaje correctamente y decida también cambiar cómo se hacen las cosas. Esto también es algo típico: la incapacidad de ver que los resultados dependen de eso...

Y no sólo se trata de disponer de la infraestructura mínima necesaria, también de mantener una disciplina metodológica en la forma en que se decidan hacer las cosas. Yo creo que no hay más, lo difícil realmente es seguir esa disciplina y los procedimientos establecidos.

He creado esta pequeña encuesta sobre los puntos que vamos a ver a continuación.

Si te sientes identificado con algo de lo siguiente, enhorabuena, perteneces a una cultura de trabajo muy extendida en nuestro sector (con poca productividad y resultados pobres que se pueden mejorar). Todo lo que indico a continuación es demasiado obvio y a muchos les sonará a principios básicos, no obstante, ¿se cumplen en la mayoría de compañias de software?

#1 Un proyecto bien estimado en tiempo nos permite trabajar mejor

Cosa obvia aunque lo habitual es que los proyectos se consigan reduciendo los tiempos al máximo y cotizando las horas por lo bajo..., ¿resultado?, proyectos que tienen que salir sí o sí con poco tiempo y, por tanto, en su desarrollo deberemos ir abandonando las buenas prácticas de trabajo (las conozcamos o no, que esa es otra).

Básicamente, los proyectos se cotizan por horas y éstas por los perfiles de la gente que va a participar en ellos (dentro de la misma compañía suele haber perfiles más caros que otros).

Por tanto, si ese trabajo de estimación de horas no se hace bien, habrá dos posibles consecuencias: o vamos a reventar al equipo con mucha presión (cosa no mala sino malísima) o bien la compañía va a perder dinero (que tampoco es nada bueno, vaya).

¿La solución? La estimación se debe hacer por lo alto y contando con la opinión de las personas más relevantes que van a participar en el proyecto, añadiendo también alguna desviación. Esto es fácil de decir y difícil de llevar a la práctica, de ahí que las habilidades comerciales permitan conseguir esto. Seguramente de este modo va a salir un precio mayor que el cliente va a intentar regatear, que ese es otro tema, no menos importante.

Comercialmente no se puede disparar a todo lo que se mueve sin darnos cuenta de que igual que hay compañías que trabajan mal, también hay clientes que conviene no tener. Difícil decisión en épocas de crisis, claro.

#2 La especificación tiene que ser lo más completa posible

Este es el gran caballo de batalla de nuestra profesión en la que lo normal es que los clientes no tengan claro al 100% lo que realmente quieren o necesitan. No obstante, un buen comercial debe ser capaz de ayudar al cliente y extraer de él lo que quiere.

Lo importante de esto es que se debe adquirir el compromiso de que una vez establecida la especificación, ésta no debe cambiar (al menos demasiado) a lo largo de la ejecución del proyecto, y, si cambia, si nos obligan a cambiarla, entonces tenemos que repercutir en el cliente los excesos de tiempo que supongan. Claro, esto tampoco será sencillo, pero el cliente debe entender que no trabajamos por amor al arte y si los números no salen, pues no salen.

Para ello es necesario un trabajo comercial que sea capaz de llevar al cliente al terreno que nos interesa.

#3 Evitar la dispersión de tecnologías

A menos que la compañía cuente con muchísimas personas con perfiles muy distintos, lo normal es que sólo se dominen algunas tecnologías y se sepa algo de otras.

Al cotizar un proyecto hay que tener en cuenta el grado de conocimiento que tiene el equipo en las tecnologías que se van a usar. Si el equipo no conoce bien, por poner un ejemplo, JSF, entonces estamos obviando la curva de aprendizaje (igual a tiempo) en que se va a incurrir durante la ejecución del proyecto. Es, digamos, un coste oculto que hay que tener en cuenta.

No nos engañemos: si bien hay gente que en sus horas no laborales pasan gran parte del tiempo empapándose de manuales o haciendo proyectos por su cuenta, mucha gente no toca esos temas fuera de la oficina.

¿La solución? Intentar contratar proyectos en cuya ejecución se utilicen las tecnologías que mejor se conocen: esto es garantía de productividad (y rentabilidad).

En mi opinión nada peor que un equipo que le da a muchos palos (para mis lectores latinos, "darle a muchos palos" = hacer cosas muy distintas). Sólo podemos ser expertos en pocas cosas y, por tanto, la rentabilidad y productividad va a venir de la mano de esas tecnologías que conocemos mejor. Estamos hablando de hacer un proyecto rentable, no de querer jugar con MongoDB porque mola y voy a forzar a usarlo en el proyecto X sencillamente porque me gusta, no porque realmente encaje en él.

#4 Hay que usar algún tipo de gestión de la configuración

El día a día en el trabajo está lleno de pequeños momentos y detalles que podemos hacer bien, ejecutar en segundos o hacerlos rematadamente mal. Todo detalle cuenta, de modo que la falta de fluidez en el trabajo se debe a ejecutar mal parte o todos esos detalles del día a día.

No hay nada que afecte más a la productividad de un desarrollador que una mala gestión de la configuración: aunque sea simple, se debe establecer. 

¿Cuánto tiempo hemos perdido a veces porque se ha roto la compilación o porque hemos querido volver atrás en el código y esto ha sido imposible?

No es sólo usar un repositorio de código (me da vergüenza hasta escribir esto, pero es que hay quien trabaja sin usar ninguno), también establecer unos mínimos procedimientos sobre cómo usarlo para un equipo de varias personas.

En cuanto a la gestión de la configuración está todo inventado, no hay que innovar, sólo céntrate en las buenas prácticas buceando mínimamente en Internet.

#5 Hay que crear cierta documentación

Vale, sí, esto es obvio pero ¿hay alguien en la organización que exija que se cierre el proyecto con una mínima documentación? No estoy hablando sólo de la guía de usuario para el cliente final (si es que este la exige), sino de todo aquello que debamos documentar mínimamente para poder retomar el proyecto de manera rápida en el futuro. 

Yo siempre insisto en hacer una guía de diseño con todos aquellos aspectos sobre el diseño y la arquitectura que se deban explicar y que no sean evidentes; también una guía de despliegue exhaustiva que nos garantice que podemos instalar y hacer funcionar el proyecto en un nuevo entorno. Esto es tremendamente productivo y generalmente consume sólo unas pocas horas (muy pocas en comparación con cualquier proyecto). Ese tiempo meses más tarde, a la hora de asumir el proyecto de nuevo, pueden ahorrar mucho más y la frustración de hacer ingeniería inversa para ver cómo se han hecho las cosas.

No se puede dar por cerrado un proyecto si no se crea la documentación exigida; es más, se debe ver si ésta se puede realizar a lo largo de la ejecución del proyecto.

Al cotizar el proyecto se deben incluir unas horas dedicadas a la documentación. No es exagerado incluir un 5% de tiempo dedicado a este trabajo.

#6 En lo posible, hay que practicar el enfoque ágil en los proyectos

En la mayoría de proyectos podemos poner en práctica todas aquellas características del desarrollo ágil que nos permite avanzar con productividad. Puesto que un proyecto será rentable si está bien cotizado y si se realiza en tiempo, entonces hay que cuidar mucho todo aquello que suponga ahorrar horas de trabajo.

En especial, el mostrarle periódicamente al cliente los avances (entregas tempranas), tiene un efecto multiplicador en la productividad y rentabilidad de los proyectos, ya que el cliente va a corregir y encauzar todo aquello que no se haya entendido bien o aquellos requisitos que no se hayan tomado de manera muy exhaustiva.

Corregir durante es mucho más efectivo que corregir al final del proyecto, cuando seguramente la bola ya es demasiado grande y costosa de cambiar.

Nada nuevo bajo el sol, sólo seguir las buenas prácticas.

#7 Un proyecto por persona

Eso es esencial y me consta que es muy difícil conseguir en las empresas. Es una mala práctica tener a la gente trabajando en varias cosas a la vez. Un desarrollador necesita de cierta calma mental para hacer bien su trabajo.

En cualquier actividad o tipo de trabajo, cambiar de contexto conlleva un coste en tiempo y esfuerzo. Es decir, que si tenemos tres proyectos en marcha y cada uno cuesta hacerlos X horas cada uno, si los ejecutamos a la vez, no se va a tardar tres por X, sino bastante más que si se hicieran secuencialmente.

Como digo, esto es muy complicado de conseguir en la empresa, pero debemos intentar ir en esa dirección.

#8 Debemos tener los medios adecuados para ejecutar los proyectos

Que sí, que ya lo sé, que esto es obvio pero ¿realmente podemos decir que todas las compañías procuran que los desarrolladores tengan los medios adecuados?

El drama es que no se ve el impacto que tiene el no disponer de una buena estación de trabajo en el resultado final del proyecto. Tener un buen PC, disponer del hardware adecuado, de las licencias adecuadas, un entorno cómodo y sin ruido, etc. hace que al final se hagan las cosas en menor tiempo (= rentabilidad, que de eso se trata al ejecutar los proyectos).

Existen muchas más consideraciones a tener en cuenta para conseguir un ambiente y un entorno donde se puedan ejecutar los proyectos con calidad y en tiempo. Hay que ser también pragmáticos, de modo que si no podemos conseguir completamente todos esos puntos que he descrito del uno al ocho, al menos sí tenerlos en cuenta y hacer que la organización se acerque a ellos todo lo posible.

A los desarrolladores: ¿no se trabajaría así mucho mejor?, a los gestores: ¿no serían los proyectos más rentables?