archivo

Archivos Mensuales: octubre 2011

La creatividad de los desarrolladores de software es una de sus grandes virtudes (tal vez la que más) y mal empleada, uno de los mayores defectos.

Hay veces donde hay que crear, otras donde el trabajo a realizar está restringido al ámbito de un proyecto y donde resultas más conveniente ser práctico que complicar un desarrollo por intentar saltarse sus propios límites o el propio contexto en el que se encuentra el proyecto.

Teniendo en cuenta que la creatividad produce resultados y puede marcar diferencias si se aplica en aquellos proyectos y ámbitos donde es necesaria, resulta de interés crear el contexto adecuado o caldo de cultivo donde la misma pueda ser expresada, sin olvidar de lo necesario que resulta educar a los desarrolladores sobre los momentos en que resulta más adecuado ceñirse al guión establecido.

Me gusta esta reflexión de Frederick Brooks porque ofrece una visión romántica de lo que es un programador (traducción libre): “El programador, como el poeta, solo funciona si se encuentra un poco retirado de lo estrictamente racional. Construye sus castillos en el aire, desde el aire, creando a través del esfuerzo de la imaginación. Pocos medios de creación, son tan flexibles, tan sencillos de pulir y reconstruir y tan fácilmente capaces de concebir grandes estructuras conceptuales”.

Anuncios

Hay una cita de Fred Brooks que expresa varias problemáticas en los proyectos de desarrollo de software y en la gestión de las carreras profesionales en las empresas que se dedican a este negocio: “La conclusión es simple: si un proyecto de 200 personas tiene 25 gestores que son los programadores más competentes y experimentados, despide a los 175 programadores y pon de nuevo a los gestores a programar”.

– Es mejor la calidad que la cantidad.
– En cada rol en un proyecto debe estar el personal más adecuado para el mismo.
– Muy pocas personas son excelentes en todos los perfiles del desarrollo de software.
– La gestión vertical de las carreras profesionales es una autolimitación nada razonable que se ponen a sí mismas las empresas.

Proyecto desarrollado en cascada, meses de desarrollo tras el análisis, cambia el responsable funcional, el nuevo llega a falta de poco para la entrega y empieza a sugerir cambios.

¿Os suena? Es lo de siempre, cambie o no el responsable funcional. Podía haber sido incluso peor y cambiar además el proceso que se informatiza por completo o de forma sensible, riesgo que crece proporcionalmente con el tiempo de construcción y todavía más para determinados tipos de clientes, como por ejemplo la Administración Pública.

Por eso esta forma de desarrollar el software no funciona, por mucho que sea la metodología más utilizada, por mucho que se lleven muchos años trabajando de esta manera. Es cierto que a veces proyectos desarrollados así salen bien pero también lo es que la mayoría tienen resultados discretos o pésimos, para el cliente, para el proveedor y generalmente para ambos.

El equipo de proyecto, el proceso para conformarlo, para seleccionar los roles adecuados, para orquestar la posible colaboración entre diferentes equipos. De esto trata este área de proceso del nivel 3 de CMMI.

En demasiadas ocasiones se le presta muy poco atención a la composición del equipo. A veces parece como si la selección de los integrantes se hubiera echado a suertes.

Esto es un error. El equipo debe ser el mejor posible, teniendo en cuenta el contexto de todos los stakeholders. ¿Por qué digo que debe ser el mejor posible y no que el mejor (a secas)? Pues porque no siempre van a estar disponibles para trabajar en el proyecto en el momento adecuado las personas que mejor se ajusten al alcance del mismo (estarán asignadas a otros proyectos, tareas o trabajos y no es posible o conveniente su participación en este, el presupuesto del proyecto no permite que determinados perfiles puedan participar en él, etc…), ahora bien, esto no debe ser un obstáculo para renunciar a conformar el mejor equipo que sea posible.

En este proceso de CMMI el equipo de proyecto no es solo el equipo de desarrollo, sino también está formado por personal de las distintas áreas involucradas cada uno de los cuales con el rol, dedicación y poder de decisión suficiente (en su ámbito de actuación).

El alcance de este proceso comienza desde la propia metodología para identificar las tareas que debe realizar el equipo de proyecto y los conocimientos y habilidades que se necesitan para su ejecución. Con esta información y el conocimiento del personal que puede estar a disposición del proyecto, se realizaría la selección de los integrantes.

Una vez conformado el equipo lo siguiente es definir las actividades que permiten fomentar una visión compartida de los objetivos a conseguir y del método para conseguirlo (comunicación, trabajo en equipo, etc…), dar a conocer a cada componente su rol y responsabilidades, establecer los procesos necesarios para coordinar el funcionamiento del equipo y por último definir los procedimientos para poder establecer relaciones de colaboración con otros equipos de trabajo (para ello además de existir determinados procesos horizontales, requiere tener un conocimiento de las tareas y proyectos que se están realizando en la organización o en los que colaboran algunos de los interesados).

El nivel 3 de CMMI extiende el área de proceso del nivel 2 denominada Gestión de acuerdos con proveedores.

En el anterior nivel el objetivo principalmente era gestionar esos acuerdos, sin olvidarnos del proceso que permite llevarnos a los mismos, de la adquisición de esos productos o servicios y de la aceptación de los mismos.

En este nivel los objetivos son los mismos aunque con un enfoque más formal, más estratégico y con una visión más allá del alcance de un proyecto (o de un conjunto de ellos).

Este área de proceso se ocupa desde el método para la analizar proveedores potenciales de productos o servicios, evaluarlos y seleccionarlo hasta la verificación del cumplimiento de los compromisos fijados con los mismos y la posibilidad de revisar, si fuera necesario, los acuerdos adoptados con determinados proveedores.

Estamos ante una de las causas de la crisis del software. El exceso de optimismo. Pensar que todo es más fácil de lo que parece. ¿Cuántas veces no es hemos arrepentido de decir que esto es fácil, esto es trivial o esto está hecho en una semana? Muchas. Y lo peor de todo es que nos seguiremos arrepintiendo de ello porque tarde o temprano volveremos a caer.

Somos así, es nuestra manera de ser. Es cierto que, como somos una profesión de extremos, también pasamos por períodos en los que todo es imposible o en lo que todo requiere un esfuerzo dos, tres o cuatro veces el real, pero nuestra falta de término medio nos lleva a eso, a comprometernos a plazos, dedicación, calidad, etc… que después por el motivo que sea (propio o ajeno) no podemos cumplir. A veces no tendrá repercusión, otras le costará mucho dinero al proyecto.

Mejor optimismo que pesimismo (es mi forma de entender el desarrollo de software, respeto quien piense y con razón que una actitud conservadora origina menos disgustos), pero también es mejor pensar que precipitarse.

No soy el único, pensaba que era una más de mis rarezas.

Hay bastante más gente que coincide conmigo en que una de las cosas que más pereza les da es recoger el lavavajillas, ¿por qué? al rato deja de estar vacío y antes de que te des cuenta lo tienes de nuevo lleno.

Un bucle sin fin.

Esta sensación creada por una rutina sin fin puede alcanzarnos en nuestro trabajo. A mi me ha pasado y en diferentes momentos. Te das cuenta de que cada día es más de lo mismo, tal vez actores diferentes pero un argumento parecido.

La rutina tiene sus ventajas y sus inconvenientes. Sientes que controlas, te conviertes prácticamente en un autómata, te llevas menos trabajo en la cabeza, etc…, pero también limita tus posibilidades y te puede llevar por un camino equivocado y es que la rutina se torne en aburrimiento y el aburrimiento en pereza.

¿Es productiva la rutina? No hace mucho tuve una conversación con un amigo al respecto y no terminamos de ponernos de acuerdo. Tal vez los dos teníamos la razón, tal vez los dos nos equivocábamos o tal vez nos encontrábamos cada uno en una escala del gris.

Mi amigo defendía el hecho de que el dominio de una especialidad permite ser más productivo en la misma, creas automatismos, te equivocas menos, etc…, pero, ¿acaso es necesaria la rutina para llegar a ser un experto en una materia?, y si te sacan de tu zona de control, ¿qué es lo que pasa?.

Aprendiz de todo, maestro de nada, el que mucho abarca, poco aprieta dice el refranero. Creo que no se trata de dirigirnos a los extremos y que desarrollando un ámbito concreto de una profesión se puede llegar a tener un cierto dominio de la misma sin caer en la rutina.