Llevo un tiempo leyendo algunos libros y artículos sobre metodologías además de estar dentro de un proceso de adaptación a CMM2. La gestión de proyectos es compleja, por lo menos desde mi visión actual con más bien escasa experiencia, y aún no tengo muy claras las cosas.
Resulta que el objetivo del desarrollo es tener algo tangible, algo que se pueda usar, que sea útil y en el que cuanta menos burocracia haya mejor. Esto es aplicable no solo al desarrollo de software, si no a cualquier proyecto, pero yo no sé que pasa que en todos los proyectos/negocios que veo al final se consume más tiempo en burocracia que en desarrollo.
Si tienes una empresa de 100 empleados parece lógico que la burocracia aumente, sobretodo porque con 100 empleados tienes mucha probabilidad de que tengas a mucha gente no muy buena en su trabajo, poco motivada, etc. Es normal que se tengan que marcar unas reglas estrictas de funcionamiento.
Me planteo si de verdad usar metodologías muy severas aporta algo a proyectos dinámicos, los cuales se adaptan de forma rápida a las necesidades o si estoy confundido y es necesario un control muy cerrado para llevar un proyecto a cabo con una calidad profesional.
Al final creo que el camino se hace al andar, que las metodologías describen los procesos que se han ido mejorando a lo largo del tiempo y que de verdad han demostrado que funcionan después de probar variantes, ver el resultado y sobretodo cargarla. Al final si el equipo es bueno y estila buenas prácticas la metodología aparece sola.
Me recuerda a una frase que leía en una bodega de un familiar: "una buen vino puede arreglar una mala comida y uno malo estropear una buena"
2 comentarios:
Es como todo. La metodología es una herramienta, y debería escogerse aquella que mejor se adapta al proyecto. Dependiendo de la naturaleza del proyecto, a veces quizá no merezca la pena abarcar todas las prácticas recomendadas de una metodología y sea suficiente usar un conjunto reducido de plantillas.
Usar una metodología siempre es bueno, aunque sea una propia, o una versión aligerada de otras.
Por último, hay que tener cuidado con no confundir tres cosas: metodologías generales de gestión de proyectos (PMI, PRINCE 2…), metodologías de desarrollo de proyectos software(CMM2, Métrica 3…), y modelos de proceso de desarrollo software (cascada, RUP, desarrollo ágil o combinación de varias…).
La verdad es que, según el autor, a veces los modelos de proceso y las metodologías parecen fundirse… pero son cosas distintas y complementarias.
Es muy fácil equivocarse en la elección, o creer que la misma metodología software y modelo de proceso sirve para todos los proyectos. Error. Incluso tratándose de un producto final similar (juego para móvil), dependiendo de las características y circustancias puede convenir usar una u otra. Por ejemplo: si se trata de sacar un juego basado en otro anterior, con un nuevo branding y poco más, interesa ir a toda leche, ya que los riesgos son mínimos. Si resulta que estáis trabajando en un juego de cierta complejidad técnica, con una mecánica innovadora o qué se yo(algo "nuevo" en definitiva), hará falta una metodología algo más pesada para gestionar el cambio, los riesgos,etc… así como usar un modelo de proceso que contemple fases de prototipado o iteraciones.
Probablemente en ambos casos se podría aplicar las mismas metodologías de proyecto (generales y software), aunque con diferentes grados de exhaustividad o "burocracia" ;)
En definitiva, la gestión de proyectos no es un tema sencillo =) . Tan malo es trabajar al tuntún como bajo un nivel burocracia exagerada.
Otra cosa: La implantación de nuevas metodologías en la empresa tampoco es una tarea trivial. La resistencia al cambio suele ser fuerte (a veces con cierta razón). Lo ideal es un cambio gradual, y convencer a los miembros del equipo de que realmente el cambio es para bien.
Y si para eso hace falta un seminario de un par de días, se hace. Y escuchar a la gente, hacerla partícipe de algún modo, ya que son los que van a sufrir más durante la transición.
Publicar un comentario