Está en crisis la administración de proyectos a causa de las metodologías ágiles?
Por Norberto Figuerola [ Acerca del autor]
De acuerdo a observaciones realizadas por el autor de este artículo, debo admitir que la nueva certificación PMI® Agile Certified Practitioner (PMI-ACP®) despertó en mí, así como en muchos otros colegas algunas dudas. Esto me motivó a leer muchos encarnizados debates entre agilistas y tradicionalistas que confieso volvieron a despertar mis inquietudes sobre un replanteo en la profesión. El artículo publicado por Ken Schwaber en su propio blog y los comentarios recibidos me resultó impactante. Ya he visto además muchos informes que directa o indirectamente colocan en discusión o traen dudas sobre el objetivo que debe cumplir un gerente de proyecto. Tratando de colocarme en una posición totalmente imparcial, comento en este artículo ciertas
apreciaciones sobre cómo veo la evolución de esta disciplina.
Project Management y Agile
La aparición y adopción constante de métodos ágiles para manejar proyectos, a mi criterio ha puesto en jaque la función e incluso el alcance del rol del gerente de proyecto. “No necesitamos ningún director de proyecto”, es una frase común que se escucha a veces por parte de los desarrolladores de software (me refiero a los que utilizan métodos ágiles). Consideran que los jefes de proyecto interrumpen el camino y sólo sirven como “secretarios administrativos” que no agregan valor. Cuesta explicarles educándolos sobre las ventajas típicas de un buen director de proyecto, cuando se trata de proyectos tradicionales, sin duda, un eficaz gerente de proyecto añade un valor agregado fundamental en todo el proyecto, logrando una mejora de la
previsibilidad, la percepción y la probabilidad de éxito. Pero ¿francamente puede decirse lo mismo de proyectos ágiles o más pequeños y menos rigurosos? O ¿existe un conjunto diferente de habilidades y/o papeles necesarios para los mismos?
También se supone que el nivel de criticidad es relativamente bajo, por lo que hay una alta
tolerancia para la elaboración progresiva de los resultados. Por lo tanto para una organización y un equipo que están preparados para aceptar este planteamiento, puede ser muy eficiente el uso de estas metodologías ágiles. Teniendo en cuenta estos supuestos, parece que un director de proyecto experimentado y acostumbrado a la gestión de grandes iniciativas, estaría mal equipado para agregar valor a los proyectos ágiles. De hecho, sería como si un chef de un restaurante de altísima cocina fuera requerido para gestionar las actividades de un establecimiento de comida rápida. Probablemente el pobre chef agregue poco valor en esas circunstancias, lo que no quiere decir que un sistema de comida rápida no sea eficiente o no proporcione la satisfacción del cliente. En este tipo de proyectos las claves son:
Las líneas de base son irrelevantes: en un proyecto ágil, una línea de base no significa nada. El cronograma y el presupuesto se fija en cada iteración como “timeboxing”. Los requisitos de software van evolucionando a medida que el proyecto se desarrolla, por lo que no sería muy necesario el seguimiento del proyecto medido contra de la línea de base, ya que es un blanco móvil. En estos proyectos la comunicación y colaboración entre los desarrolladores de software y el cliente son los que garantizan el éxito.
Los requisitos formales no son de mucha aplicación: en los proyectos ágiles, los requisitos de alto nivel son capturados de forma anticipada, y los detalles se aclaran con cada iteración, justo antes del desarrollo de la funcionalidad. La idea es que se sabe mucho menos al comienzo por lo que sería una pérdida de tiempo formalizar requerimientos cuando todo va a cambiar. Además, las necesidades se recogen y se discuten en un marco de colaboración con todas las partes presentes para minimizar los errores de comunicación, lo que implica una participación muy activa del cliente.
Se requiere de más entendimiento técnico: en un proyecto grande y tradicional, el gerente del proyecto no necesariamente tiene que ser un experto en los detalles finos del proyecto, pero debe entender el objetivo, las necesidades, los problemas y los riesgos. Un proyecto ágil, por otra parte, exige que todos en el equipo entiendan los detalles e interconexiones técnicas involucradas. La experiencia sobre la industria es muy importante en este tipo de proyectos.
comunicación entre todos los miembros. Estamos hablando de equipos altamente calificados con experiencia previa y gran interacción con el cliente. En estos casos el riesgo tiende a ser menor y se convierte en un debate de colaboración, en lugar de ser una entidad independiente gestionada por un gerente del proyecto.
Si nos fijamos en Scrum (que es la metodología ágil más conocida y está aumentando en popularidad en los círculos de desarrollo de software), el “Scrum Master” y el “Product Owner” trabajan en conjunto para realizar la mayoría de las funciones que un gerente de proyecto habría hecho normalmente. El Scrum Master actúa como un facilitador para la eliminación de barreras y problemas del equipo, asegurando que utilicen productivamente la metodología Scrum y la comunicación constante con el Product Owner. Este último, a su vez, garantiza que las
características y requerimientos levantados durante el proyecto se prioricen y sean entendidos. La funcionalidad se define a través de “historias”, que identifican al usuario, la acción y su beneficio para la función. Juntos, estos roles y el resto del equipo trabajan para completar lo que ha sido establecido en forma fija por cada iteración, llamada “sprint”.
Teniendo en cuenta esto, no hay mucho que pueda añadir un director de proyecto en este esquema y que no haya sido realizada por los roles mencionados anteriormente. ¿Qué lugar ocuparía un líder de proyectos en estos ámbitos?, en realidad no mucho. En este tipo de proyectos un gerente de proyecto podría actuar por ejemplo como el Scrum Master, ayudar a coordinar actividades y facilitar la metodología. También en este tipo de ambientes podría resultar muy útil la participación de un gerente de proyecto como especialista o analista del negocio y como negociador entre el cliente y los desarrolladores. Pero con todo, la función que cumpliría no debe confundirse con la típica de un gerente de proyecto tradicional. La verdad es que en un enfoque ágil no se utilizan todas las prácticas de gestión de proyecto y las funciones se comparten entre varias personas.
proyectos, no es precisamente el gerente de proyecto o la metodología los factores causantes más importantes de dichos fracasos. Es cierto que hay gerentes de proyectos más capaces y con más experiencia que otros.
Del mismo modo, podríamos decir que existen metodologías o prácticas más maduras que otras, pero esto, debemos reconocerlo, no nos brinda hoy en día la confianza de que su utilización sea una certificación de éxito. Es por eso que está ganando en popularidad la difusión de nuevas metodologías, siendo las ágiles las que consiguen una adopción cada vez más progresiva. En mi opinión este tipo de metodologías traen resultados prácticos y exitosos en determinados procesos de desarrollo de software. Pero de ahí a generalizar como hacen algunos fanáticos ágiles, diciendo que cualquier tipo de proyecto (e incluyo en esto algunos proyectos de IT) deben ser gestionados bajo el amparo del Manifiesto Agile, creo que hay mucha diferencia. Sin embargo, de lo que si estoy seguro, es que vivimos en una era de cambios radicales, innovadores y de fuerte impacto. Por eso para los otros que siguen subidos al pedestal del Project Management tradicional, es necesario de una advertencia para que vean mejor la realidad.
¿Es suficiente el PMBOK®?
Nadie puede dar garantías de que cualquier tipo de proyecto, en cualquier industria, sea exitoso. En forma intuitiva podríamos afirmar que el éxito depende de varias circunstancias y factores, y en todos los casos como factor común está el talento y experiencia del gerente de proyecto, una buena planificación, el uso adecuado de una correcta metodología y tecnología, y el armado del grupo de trabajo ideal. Los procesos de gestión de proyectos de cualquier metodología deberían poder escalarse basados en el tamaño y complejidad del mismo. Si colocamos demasiados procesos de gestión en un proyecto pequeño estaríamos cometiendo el mismo error que si no aplicamos todos los adecuados y debidos procesos en los proyectos más complejos o grandes. El factor fundamental siempre pasa por el “valor” que como buenos gerentes de proyecto
deberíamos agregar al mismo, sabiendo cuando utilizar o no, determinados procesos.
Algunos suponen que un buen gerente de proyecto puede ser exitoso en cualquier proyecto, independientemente de si tiene experiencia práctica sobre el área o no. Otros consideran que no se puede manejar un proyecto si no se cuenta con la experiencia sobre el área adecuada. Novatos líderes de proyecto por ingenuidad y en su afán de lograr la más prestigiosa credencial del Project Management Institute (PMI®), que sigue figurando entre las 10 primeras certificaciones
PMBOK® es sólo una parte del cuerpo total de conocimientos de esta disciplina, y más que una metodología se trata de una colección de buenas prácticas.
La tercera edición (anterior) de esta Guía mostraba un gráfico sobre todo lo que comprendía un cuerpo de conocimientos sobre Project Management, e incluía: conocimiento sobre la “Guía PMBOK®”, “Las Habilidades Interpersonales”, “Las Habilidades y conocimientos generales de Management”, “Entendimiento del ambiente del proyecto” y “Comprensión del Área de
Aplicación, estándares y regulaciones (industria)”. En resumen, no se puede manejar un proyecto, o no se es un buen profesional si el practicante no cuenta con un entendimiento suficiente no sólo de “una metodología” como el PMBOK®, sino además cómo aportar valor en las otras cuatro áreas de competencias mencionadas, y las mismas no pueden ni son explicadas en los cursos generales de Project Management o incluso no son evaluadas en los exámenes de certificación.
Cómo se fue transformando el Project Management
En las últimas décadas las organizaciones han tratado de modificar sus estructuras
tradicionalmente funcionales en algo más efectivo para adaptarse a los acelerados cambios tecnológicos y sociales, tratando de ser más eficientes para cumplir las demandas del mercado. La consecuencia de esto fue la evolución de una organización funcional en lo que se denomina una organización matricial, que tratando de mantener su estructura funcional permita la formación temporaria de equipos de proyectos cross-funcionales, organizados y controlados por la figura de un gerente de proyecto. Sin embargo y dado que las soluciones “a medida” se transformaron en la norma, incluso las organizaciones matriciales pasaron de moda. Algunos autores señalan la evolución de las organizaciones en “adaptativas”, aquellas que van transformándose de acuerdo a las exigentes complejidades y cambios del mercado y exhiben comportamientos de
auto-organización en sus equipos de trabajo. Esta misma evolución se plasmó en los estilos de liderazgo, pasando de un tradicional jerárquico o “top down” a estilos más participativos,
democráticos e inclusive a estilos “facilitadores” en donde el rol del líder es simplemente eliminar los obstáculos a un grupo de trabajo auto-disciplinado, auto-organizado y competente.
Podríamos también simplificar diciendo que dicha evolución se manifiesta en el Project
no particularmente interesantes. La única manera de conseguir que la gente consiga hacer su trabajo bien, es incentivarla adecuadamente y controlarlos muy de cerca”.
El Management fue evolucionando a la par de los avances tecnológicos, sociológicos y de comunicación fortalecidos por las interacciones sociales a través de internet. Ya no sólo es
importante el Management para la gestión, sino que lo es mucho más el Liderazgo, el concepto de Equipo. El proyecto no es otra cosa que manejar gente. Es todo acerca de la gente que hace el trabajo en equipo y cómo se interactúa con ellos, esto podría verse como una segunda fase de evolución del Project Management. Si se fijan, todos los libros de Project Management cambiaron el foco de las habilidades “duras” hacia cómo deberíamos ser expertos en las denominadas “habilidades blandas”. Cualquier organización, asociación, grupo de interés o foro sobre Project Management comenzó a escribir artículos sobre las distintas habilidades interpersonales, dado que no había mucho más que agregar a temas como Diagramas de Gantt, Camino Critico, Curva S, etc.
La tercera fase evolutiva surgiría del hecho de reconocer que aún poniendo las más adecuadas herramientas y técnicas y sumarle un liderazgo democrático con profundas interrelaciones humanas pareciera que no es suficiente para el éxito de algunos proyectos. A principios del 2001 el Manifiesto Ágil sentó las bases para otro tipo de gestión de proyectos orientado al desarrollo de software que prometía bajar la tasa de fracasos. De hecho en cierta forma lo logró y esto puso en jaque a los planteos tradicionales, dado que “la metodología ágil” no trajo conceptos o procesos más complicados, sino todo lo contrario. Pero deberíamos ser concretos sobre cómo y dónde tuvo y tiene éxito este tipo de aproximación. El concepto de liderazgo en estos métodos coincide con el ya visto de “facilitador” y surgen nuevas expresiones como el “servant leader” donde la figura de un gerente de proyecto está totalmente diluída. El desarrollo ágil fue producto de las compañías que desarrollaban software, principalmente en internet. Su éxito fue contundente y el intento de replicar estos métodos de empresas de software en corporaciones mayores no significa que se vaya a repetir. El modelo de trabajo que proponen estos métodos requiere de un trabajo muy estrecho entre cliente (gerente de producto) y equipo de trabajo y conseguir este tipo de
involucración en determinado tipo de empresas es imposible. Es muy importante hacer énfasis en la diferencia que existe entre “Product Management” y “Project Management”.
Product Management vs Project Management
Internet o Casas de Software tengan gerentes de producto. ¿Cuál es la diferencia entre este rol y el de gerente de proyecto? En realidad es un poco semejante a la diferencia que existe entre un rol estratégico y un rol de ejecución. Los conceptos pueden resultar similares, los dos son gerentes que tratan de asegurar el buen cumplimiento de un proyecto, probablemente con conocimientos y habilidades similares, sin embargo existen grandes diferencias entre un product manager y un project manager, y confundirlos puede traer problemas. El gerente de proyecto es responsable por el éxito en la “entrega” de un proyecto (emprendimiento único con principio y fin) conforme al tiempo, presupuesto, metas, alcance y otras restricciones. Coordina recursos, lidera y controla, gestiona problemas y riesgos y coordina todos los elementos necesarios para cumplir con el proyecto, sus objetivos y la satisfacción del cliente. El product manager se refiere a la coordinación de todos los aspectos de la creación y gestión de un producto. El proyecto puede encararse para construír un producto, agregar más funcionalidad a uno existente, o crear nuevas versiones del mismo, pero cuando el proyecto está completo, el gerente de proyecto terminó su labor y por lo general se ocupará de otro proyecto y probablemente también de otro producto. En cambio, el gerente de producto no se transfiere, permanece como responsable de dicho producto durante todo su ciclo de vida.
El ciclo de vida de un gerente de proyecto, es el proyecto mismo, el ciclo de vida de un gerente de producto es el ciclo de vida total del producto hasta su muerte o reemplazo. Ambos roles pueden trabajar en conjunto, pero mientras el gerente de producto querrá agregar más funcionalidades y desarrollará estrategias para modificaciones y mejoras constantes, el gerente de proyecto tratará de mantener el alcance acotado para que el proyecto pueda cumplirse conforme al plazo y presupuesto. De existir ambos roles y ser ambos expertos, sabrán convivir y crear un balance adecuado de dicho conflicto. Un buen gerente de proyecto sabe que el éxito no es solo el
cumplimiento del proyecto en tiempo y presupuesto, sino además lograr los objetivos del mismo. Del mismo modo un buen gerente de producto sabe que los cambios pueden llegar a ser infinitos en búsqueda de la perfección y que demorar la entrega o salida al mercado tiene un precio.
Este tipo de roles como vimos es muy común en empresas de software. Las metodologías ágiles nacidas en estos ambientes se basan más en la función de un gerente de producto que la de un gerente de proyecto. No interesa tanto el control del alcance sino la funcionalidad del producto. Existen diferentes tipos de aproximación de metodologías ágiles, pero en casi todos los casos el alcance de la gestión ágil es más bien a nivel técnico, en el desarrollo de software, no existe una clara definición del rol de gerente de proyecto, más bien cuando se llega al nivel del product manager, se hace recaer sobre el mismo algunas tareas de un project leader.
efectuamos cambios, adaptaciones o inclusive si combinamos distintas aproximaciones entonces dejaría de ser ágil. De todas formas siempre que trabajemos con estas metodologías el rol del gerente de proyecto cambia, se hacen mucho más importantes conceptos más técnicos y otra forma de trabajo y gestión, donde ya un cuerpo de conocimiento como la Guía PMBOK® pierde algo de sentido. Igualmente y tal como se mencionó anteriormente, el cuerpo de conocimientos sobre Project Management no sólo lo conforma un BOK, sino además el conocimiento sobre la industria, estándares y avances, y en este sentido en el ámbito de IT, es sin duda cierto que para algunos proyectos el uso de dichas metodologías ágiles es ideal. Mi duda es ¿por qué el PMI® se ocupa recién ahora en hablar de ello e incluso hasta dedicarle una nueva certificación?. ¿El manejo de proyectos en construcción, farmacéuticos u otras industrias pueden seguir aproximaciones ágiles? Si admitimos que no, ¿por qué no sería razonable además que el PMI® dedique alguna certificación para dichas industrias? Personalmente creo que la respuesta a esto es moda….y dinero.
Buenas Prácticas en Project Management
Hoy en día podemos generalizar que los proyectos han crecido en complejidad y que es muy común que los gerentes de proyecto se encuentren en dificultades para llevar en forma eficiente su trabajo. Reconociendo estos desafíos, dificultades, cambios y avances tecnológicos, los gerentes de proyecto tratan de utilizar los estándares que mejor puedan cumplir con los objetivos de éxito y entrega de los mismos. A esto deberíamos sumarle el hecho de que actualmente el trabajo en equipo y el trabajo en sí mismo son diferentes que hace 50 años antes. Como se mencionó en el artículo “El Dinero no es un factor motivador”, el trabajo hoy en día es más bien de tipo
“heurístico”, creativo, se aplica más conocimiento e innovación, los equipos requieren de más autonomía para ello. Teniendo en cuenta la evolución marcada en párrafos anteriores sobre Liderazgo y Project Management, la pregunta sería ¿cuáles son los mejores estándares hoy en día? Francamente no existe una respuesta directa dada la gran variedad de proyectos y ambientes. La Guía PMBOK® sin duda alguna, sigue siendo uno de los más reconocidos mundialmente. Otro ampliamente usado es el de la OGC PRINCE2®, y a estos dos podríamos agregarle el del International Project Management Association (IPMA). Algunos autores sugieren que para la profesión una combinación del énfasis en las habilidades interpersonales que tiene el IPMA, sumado al énfasis de los procesos del PMI® podrían dar una buena sinergía a la disciplina del Project Management. De un relevamiento general el uso de una metodología está mucho más repartido y además de estos tres clásicos métodos, las organizaciones hoy en día utilizan otras aproximaciones como ser :
Agile Project Management
Critical Chain Project Management
Una combinación de diferentes metodologías
Lean Thinking / Kanban process Project Management
En mucha literatura referida a aproximaciones de gestión de proyecto adaptativas y ágiles se hace también mención al pensamiento Lean y a Kanban asociándolos con métodos ágiles. El
pensamiento Lean y Kanban son filosofías anteriores al movimiento ágil que sin embargo demuestran que pueden convivir y nutrirse perfectamente. Muchos conceptos sobre el
pensamiento Lean (value stream mapping, wip limit, cycle time, etc) han sido incluídos en la nueva certificación del PMI-ACP®. Actualmente para el que no está informado ya existe el LSSC siglas del Lean Software and Systems Consortium que cuenta no sólo con su propio BOK sino además sería la tercera certificación oficial que existe en “métodos ágiles” luego de Scrum y DSDM. Por otro lado Kanban está ganando popularidad en los círculos de project management, fundamentalmente en lo relacionado con la visualización de workflow, mejores reportes, limitación del work in progress y balance del trabajo.
La mejor práctica sigue siendo la que le brinde a una empresa particular los mejores resultados, más allá de las certificaciones profesionales. Y esto depende mucho del tipo de industria, sector de negocio, región geográfica, complejidad y tamaño del proyecto, etc. Podriamos decir que existen dos tipos de conocimiento: explícito e implícito. El conocimiento explícito es aquel capturado, escrito y documentado que se puede encontrar en libros, manuales, políticas, procedimientos y BOK’s. El conocimiento tácito o implícito es el que existe en la mente de las personas y se transfiere mediante entrenamiento, trabajo, mentoring, coaching, conversaciones, discusiones y experiencias de gente experimentada y entrenada. Este conocimiento tácito que involucra ricas experiencias de distintas áreas de negocio, geográficas e industrias, es el que debería alimentar e ir transformando la Guía PMBOK®, para que no quede como un conjunto de procesos “ideales” de gestión de proyectos y bajarlos más a la realidad.
Conclusión
era la luz al final del túnel, hoy en día sería la luz al comienzo del mismo. Un profesional debe estar continuamente enriqueciéndose de los nuevos conceptos de gestión, management y calidad, tal como me esfuerzo en explicarlo permanentemente en mis cursos.
De hecho como fue referido por algunos autores, el Project Management es una profesión “accidental”, porque no existió una carrera en el pasado para su preparación. Personalmente como otros de mi generación y pertenecientes a distintas profesiones (marketing, ingeniería, finanzas, etc.) fueron inmersos en la gestión de proyectos (“task force” se llamaba antes en IBM cuando comencé a trabajar). Como no había o existía muy poco entrenamiento formal, las propias empresas preparaban a sus “gerentes”. Después de trabajar en algunos proyectos, se comenzaba a aprender cada vez más basado en la experiencia sobre la profesión.
El PMBOK® no es “todo” lo que hay que saber para ser gerente de proyecto, sino que es una excelente y muy completa Guía a utilizar como punto de partida para la carrera profesional. Representa un sub-conjunto de mejores prácticas del mercado que debe ser complementado y enriquecido con nuevas ideas, nuevos conceptos, nuevos métodos y técnicas y nuevas habilidades que debe manejar un gerente de proyecto. Con todo, la evolución y los cambios continúan y asi como la irrupción de los nuevos métodos ágiles han cambiado radicalmente el rol de un gerente de proyecto, nadie sabe cómo seguirá transformándose esta profesión, que asi como nació casi accidentalmente, pueda también ser transformada accidentalmente en algo muy diferente a lo que comúnmente estamos acostumbrados a conocer.
Esta página ha sido calificada como: Califica esta página:
+
Comparte
Ruben dijo el 16 Agosto de 2011:
comparto todos los comentarios y felicito por este polémico artículo.
Los debates que propone son varios: Agile y PM, Project Mgmt y Product Mgmt, Mejores prácticas en PM, etc.
En mi opinión la "crisis" solamente podría darse en proyectos de IT, no veo que Agile tenga cabida en otro tipo de proyectos (industrias). Coincido con Norberto sobre el tema que busca el PMI con la certificación. La formación tradicional de PM no serviría para proyectos agiles, y no creo que tampoco sea necesario una certificación para los mismos.
Saludos,
Miguel Acevedo dijo el 15 Agosto de 2011:
es un articulo bastante bueno que en pocas paginas abre la menta a nuevas iniciativas y a la necesidad de combinar estrategias ya definas con un poco de invencion a fin de encontrar la mejor forma de hacer exitoso un proyectos para diferentes empresas
Sebastian Montero dijo el 14 Agosto de 2011:
Excelente artículo. Soy PMP y tuve la oportunidad de trabajar en un proyecto de desarrollo ágil usando Scrum. Realmente la forma de trabajo es distinta a la de un método tradicional y es cierto que no existe un rol de Project Manager. Es un cambio de paradigma. Saludos.
Ezequiel Altamirano dijo el 10 Agosto de 2011:
Que buen documento !!! Coincido con la opinión y los comentarios. Por lo que yo leo veo que la función del PM en proyectos ágiles esta desdibujada.
Gracias por estos articulos...
Alex dijo el 07 Agosto de 2011:
ágil del PMI que será todo un hitazo de seguro, es obviamente para hacer dinero, sin menospreciar que sea buena y que de seguro harán un estándar ágil
Veronica Papandrea dijo el 05 Agosto de 2011:
Muy interesante el artìculo. Actualmente trabajo como PM en una Consultora de Software con Mètodos Agiles y me sentì completamente identificada con el artìculo. Creo que en estos entornos se resta importancia a la planificación, liderazgo y gestiòn del camino crìtico, que en mi opinion resultan necesarias en proyectos "llave en mano".
Norberto Figuerola dijo el 04 Agosto de 2011:
Fernando: disculpas por la redacción, mi intención fué volcar el resultado de la encuesta y donde dice "nuestra propia metodología" es la de cada corporación (ej: IBM).
Andrés: efectivamente, yo también estoy trabajando con proyectos en donde el core es tradicional pero se agregan matices de ágil (por supuesto es de IT)
Nora: gracias por tus comentarios
Mario: muchas gracias también por tus comentarios y efectivamente estamos en un mundo de cambios que se suceden exponencialmente, por lo que es muy importante estar al tanto de diversos temas.
Queda mi mail para cualquier información adicional que necesiten y pueden visitar además mi Blog Site.
Saludos cordiales.
Fernando Larrea Leoro dijo el 04 Agosto de 2011:
Excelente documento ! Sólo una aclaración, cuando se comenta sobre las metodologías utilizadas, el párrafo "Nuestra propia metodología" hace referencia a alguna que proponen ustedes ?
Muchas gracias.
Un articulo muy interesante, que sin ir mas allá y entrar en tecnicismo te da muy buenas sensaciones. Yo ahora estoy en un proyecto de Telecom y aunque se maneja la metodología tradicional tienes ciertos matices de metodologías ágiles. Muy buen aporte, gracias.
Nora dijo el 04 Agosto de 2011:
Muy interesantes comentarios. Muchas gracias por el aporte!!!
Mario Morales dijo el 03 Agosto de 2011:
