Project Planning PictureEsta 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.

Surver Monkey Logo

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

A lo largo de esta web así como de El Libro Negro del Programador, se insiste mucho acerca de la necesidad de que una solución software sea mantenible. Es más, si no es mantenible fácilmente, el proyecto puede ser todo un fracaso y traerá consigo un cliente muy cabreado y enojado (que seguramente nunca volverá a confiar en ti) o una compañía que tiene un agujero económico que cubrir.

No se hace software para que funcione ahora, sino para que pueda ser evolucionado y matenido fácilmente con el tiempo. Esto para mí es un mantra que repito y un principio irrenunciable.

Mantener un proyecto software en producción es en definitiva conocer cómo se comporta, tener identificadas claramente las actividades de mantenimiento, poder detectar con sencillez dónde ocurren los problemas pero, sobre todo, tener la capacidad de hacer todo eso de manera eficiente y en poco tiempo.

Administrar, por su parte, está relacionado con lo anterior y es igualmente importante: si la administración de cualquier producto software es ineficiente, estaremos poniendo en peligro su viabilidad en producción.

Por muy bien que funcione aparentemente nuestro proyecto, si este no se puede ni mantener ni administrar correcta y eficientemente, habremos realizado en realidad un proyecto más bien pobre. Para que un software sea mantenible y administrable tiene que desarrollarse desde el principio pensando en su sencillez de mantenimiento y administración.

Realizando recientemente algunas actividades de mantenimiento de la web de la compañía en la que dirijo proyectos software, volví a tener presente este carácter intrínseco tan importante del desarrollo. La web está montada en Drupal y se tenían que actualizar algunos módulos desde hacía algún tiempo. A los que me conocen no les extraña en absoluto que dirija la realización de proyectos software al mismo tiempo que me meto de lleno es aspectos de desarrollo de bajo nivel, ¿acaso se puede dirigir algo sin conocerlo suficientemente?

Idea Concetp Development ProductDurante mis primeros años como desarrollador de software tuve la enorme suerte de participar en un equipo que estaba dedicado íntegramente al desarrollo de un producto. Incluso teníamos quienes se dedicaban exclusivamente a escribir pruebas (lo que era un auténtico lujo). Hace tiempo de eso y aunque usábamos tecnologías ahora obsoletas o de menos uso (Visual C++, ActiveX, COM, DCOM, etc), la dinámica para la creación de un producto software no ha cambiado en absoluto, aunque desde entonces he abrazado el desarrollo ágil como mejor forma de realizar software.

Estos dos últimos años, sin ir más lejos, me he dedicado íntegramente a dirigir un equipo de desarrollo para la creación de un producto software muy específico para compañías del sector eléctrico. Han sido dos años muy duros en los que hemos escrito muchísimo código, hemos sacado unas cuatro versiones comerciales del producto con éxito (con clientes consolidados) y hemos tenido siempre presente la necesidad de refactorizar, de esforzarnos por mejorar y ampliar las pruebas, de escribir una documentación de despliegue correcta y mantener una gestión de la configuración eficiente. Nada es perfecto, pero el resultado, en mi opinión, me indica que hemos hecho las cosas aceptablemente bien.

Programar algo que funcione es relativamente fácil, crear un proyecto muy particular para un cliente requiere de algunas habilidades más, hacer un proyecto similar pero de mayor tamaño con un equipo de varias personas añade un nuevo nivel de dificultad pero, sobre todo, realizar un producto software que sea válido no para uno sino para cientos de clientes distintos, es otro nivel completamente distinto que requiere de una dinámica muy diferente a la del trabajo en un proyecto particular.

Hay muchas diferencias técnicas y de gestión entre uno y otro escenario y no siempre se distinguen claramente.

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...