Riskout International

Esta discusión comenzó en el Facebook. La primera parte está cargada debajo, volcada directamente de allí.

Siguiendo con el interesantísimo thread creado en facebook, acerca de estimaciones y planificación, agrego mi granito de arena por acá.

Me sumo a los que piensan que por un lado esta el proceso de calcular el esfuerzo, que (a mi entender) es una primer etapa (que yo denomino "estimación"), al proceso de planificación en sí mismo, que conjuga tres variables dependientes, el esfuerzo propiamente dicho (calculado en la etapa anterior), las asignaciones con sus porcentajes y la duración estimada de la tarea (que ojo, no es lo mismo que el esfuerzo). El resultado de la planificación (o quiza como lo llama Marcelo, "calendarizacion", muy buena palabra) que en sí mismo es un proceso bastante complejo, es el conjunto de tareas finales, concatenadas de cierta manera para representar de la forma más cercana a la realidad posible, de lo que va a ser la ejecución del proyecto propiamente dicho. Esta concatenación de tareas, obviamente no es algo estático, sino que va cambiando contínuamente para representar la realidad (lo hecho hasta el momento) y un forecast cada vez más preciso de lo que falta.

Volviendo al cálculo del esfuerzo, ademas, es una tarea por lo general (de acuerdo a mi experiencia), bastante reiterativa, que tiene diversos fines, desde el costeo inicial que permite quiza avanzar con sucesivas etapas de evaluación (proceso de preventa), hasta ser la "materia prima" para poder obtener una planificación detallada. Demás está decir de que en las etapas iniciales, es muy normal contar con poquísima información para tener una estimación de esfuerzos. Esto no debería impedir el hecho de poder tener un número con el cual negociar y avanzar. Obviamente vamos a contar con un riesgo importante, pero siempre es mejor que nada.

De todas maneras, por lo general no avanzamos a una "personalización" de la estimación ("horas marcelo"), hasta no necesitar dicho detalle, ya que sino transformaría al proceso en sí mismo en algo engorroso y costoso innecesariamente. Por lo general los recursos humanos no tienen una productividad constante y/o medible, sino que es algo sumamente dinámico, que cambia a medida que se ganan conocimientos, de que avanza el proyecto, y es muy subsceptible a variaciones diversas producidas por factores externos (problemas familiares, etapa del año, etc.). Además está el hecho de que quizá, es más importante aún cual es la performance que "debería" tener un recurso vs la performance "real", otro factor que suma complejidad. Esto hace de que solamente hay que contar con ese detalle cuando necesitamos un nivel de certidumbre elevado.

Otra cosa que me pareció muy interesante, es que creo que tampoco sirve invertir demasiado tiempo (dinero) en una estimación (o planificación/calendarización) tan detallada, cuando en la vida real los proyectos cambian, y mucho. Por lo general la reacción al cambio es "áspera" por decirlo de alguna manera, pero es siempre bueno poder adaptarse contínuamente, eso le da un valor agregado mucho mayor, al hecho de intentar contar con toda la información posible para tener una fecha super remota exacta al momento de comenzar el proyecto. Seguramente muchos clientes preferirían poder comenzar rápidamente a trabajar en base a un cono de incertidumbre más ancho, pero que pueda reaccionar rápidamente al cambio. Es por esto que las metodologías ágiles, que van de la mano del RERO, son mucho más atractivas. En mi experiencia e visto muchas veces que las grandes empresas toman muchas decisiones políticas, que afectan terriblemente a los proyectos, pero que, administrados de forma correcta, generan una muy buena impresión, debido a lo rápido que el proyecto puede adaptarse a los cambios y continuar su curso.

Estimación y planificación van de la mano, y más allá de la metodología que se utilice, estos procesos tienen la obligación de ser ágiles, simples, claros y contundentes.

Finalmente, aclaro que no soy lider de proyecto, pero, debido a mi puesto, participo activamente en tareas relacionadas a la confección de estimaciones y asistencia de traslado de esta información a planes utilizables, medibles y controlables.

Saludos!

Parte 1

Dijo Bill Gates: Para ser un buen profesional de ingeniería, siempre comience a estudiar tarde para los exámenes, porque esto le enseña cómo manejar el tiempo y lidiar con las emergencias

Daniel Sachi: Un excelente consejo, especialmente para los que lidiamos con los cambios todos los días...

Marcelo Zucchelli: avisale a bill q ya existen la ley de parkinson y el sindrome de estudiante...

Daniel Sachi: Che!! Esas no las conozco!!

Marcelo Zucchelli: son las q explican x q no tiene sentido dar mas tiempo a una persona para hacer una tarea: http /en.wikipedia.org/wiki/Parkinson's_law y http /en.wikipedia.org/wiki/Student_syndrome.

Daniel Sachi: Gracias Marce, sigo aprendiendo todos los días, jaja

Marcelo Zucchelli: es ponerle nombre a algo q ya sabias

Marcelo Zucchelli: y mi favorito para mis alumnos... la ley de Hofstadter: Siempre lleva más tiempo que el esperado, incluso si tienes en cuenta La Ley de Hofstadter. je.

Augusto Amaya: Si se me permite la opinión muchachos, no me asombra lo que piensa Bill, sobre todo con el nivel de fixes que se necesita para los productos que fabrica Microsoft. Tampoco estoy de acuerdo con que las cosas llevan más tiempo del pensado. Uno sabe perfectamente cuanto tiempo le va a tomar. Salvo que en el momento que uno lo estima, se engañe a uno mismo por factores externos. En niveles de empresas, dificilmente un líder de un proyecto ( que sea un líder propiamente dicho, no alguien que asignaron como líder que no es lo mismo ) le pifie a una estimación de tiempo. El problema y normalmente los desvios se incurren cuando justamente, factores externos inciden sobre la estimación. Es decir, que el tiempo real de un proyecto se vea afectado por los "deseables". Ahi es en donde empieza el ovillo de que se sabe cuando empieza, pero no se sabe cuando termina. El tiempo real de un proyecto es fácilmente estimable, al igual que los problemas y/o riesgos que puedan llegar a interferir con el mismo.

Augusto Amaya: Ojo que es una apreciación meramente personal, dista en mi romper ningún tipo de ley, ni cambiar ningún tipo de pensamiento.

Marcelo Zucchelli: disiento completamente

Augusto Amaya: jaajajjaajajajajajajaj... creeme que estoy abierto a escuchar opiniones distintas y me gustaría saber (si tenés tiempo) el motivo y/o los motivos por los cuales disentís.

Daniel Sachi: No sabés en qué te metiste Marce!! Augusto es un perro de presa!! Jaja

Marcelo Zucchelli: daba dos clases de 4h cada una sobre el tema (no es q sepa mucho, pasa q necesitaba 4 de discusion xq es un tema ASPERO), asi q no me dan los caracteres... en resumidas cuentas, empiricamente se cree q la exactitud (q no es lo mismo q precision) de una estimacion depende de 3 variables: experiencia en la actividad a estimar, informacion (alcance principalmente) sobre la tarea a realizar y tiempo para ejecutar la estimacion. y aun asi, el resultado obedece (la mayoria de las veces) a una funcion beta de probabilidad... juro q es mas claro con un pizarron

Marcelo Zucchelli: idealmente, entonces, la estimacion seria 100% precisa si las tres variables tendiesen a infinito. como eso no pasa, hay un % de error inducido. eso multiplicalo x CADA TAREA del plan.

Daniel Sachi: Por otro lado, el tiempo es relativo y la misma tarea puede llevarle mucho o poco a distinta gente. En cuanto a la estimación, dado que en los proyectos grandes, el cambio es permanente y las condiciones de borde son variables, los tiempos de la tarea posiblemente no cambien pero las prioridades y la atención prestada si, por lo tanto se generará un incumplimiento no volitivo de las mismas, ya que, aunque se cumpla con el tiempo, no se cumplirá con la duración. También agrego que muchas de las leyes nombradas son "bromas calificadas". Abrazo a ambos

Marcelo Zucchelli: asi es... en resumidas cuentas, lo q bill nos dice es q ejecutar tardiamente lleva a minimizar la ley de parkinson, q es el principio fundamental de timeboxing q a su vez es la entrada para el desarrollo x iteraciones de duracion fija q tanto gusta a los agiles.

Daniel Sachi: Habiendo certificado varias metodologías ágiles y creado la propia (ROI Agile), no tengo menos que aprobar lo dicho, jaja

Augusto Amaya: Marce, a pesar de haberlo reducido a pocos caracteres entiendo perfectamente lo que querés explicar. Lo cierto es lo siguiente, es un error incurrir tareas que corresponden a un período anterior dentro del período de estimación. Hay un paso previo antes de la estimación, que resulta de la evaluación. Y si bien las variables no tienden a infinito, el proceso si lo hace. Vos vas a usar tanto tiempo de evaluación como así necesites para poder realizar una estimación. Pero lo curioso ( y lo rico de todo esto ) es que la evaluación en si misma, también se estima en tiempo. A donde lleva a lo que yo digo: Los tiempos de los proyectos se pueden estimar de manera muy certera y precisa. El problema se sucita cuando aparecen los deseables en el medio.

Augusto Amaya: Daniel. Parte del proceso de evaluación y estimación del proyecto incurre en el análisis de los recursos a utilizar. Y entre los recursos, figura la gente y sus capacidades.

Daniel Sachi: Lo sé, pero justamente, es algo dificil de afirmar en el momento del armado del proyecto, ya que uno estima con metricas y presenta las primeras estimaciones mucho antes de saber el equipo con el que va a contar. Por supuesto que lo que decís es válido para proyectos en ambientes cerrados, con equipo único y conocido, cosa que no pasa con el 90% de los proyectos de las empresas...

Augusto Amaya: Entiendo Daniel. Pero ahi entra lo que dice Marcelo ( que impacta sobre los tiempos ) que es el hecho de contar con la información.

Augusto Amaya: Si no conocés al equipo, te falta información. Y sin información, dificilmente puedas evaluar y estimar de forma precisa un proyecto.

Daniel Sachi: El PMI dice por norma que en la primera estimación el margen de error es de -25% +75%, bajando a un -10% +20% al fin de la planificación, y a un -5% +10% al comienzo de la ejecución (post revisión final). En Prince2, norma inglesa, es todavía menos optimista. Y si, lo que planteas de la información es así, pero es lo que ocurre en la vida real. Tengo 3 certificaciones internacionales en distintas normas, y más de 30 años en proyectos, sin embargo y lamentablemente, los proyectos que terminan en tiempo y forma que he visto o sobre los que he leído son la escasa minoría. Por supuesto, y como te decía, en condiciones ideales, uno puede estimar con exactitud, pero esas condiciones se dan raramente en los ámbitos de proyectos.

Augusto Amaya: Ojito ojazo, que la vision que yo estoy dando es la de líder de proyecto, y o coordinador de proyectos ( líder de líderes ), quizás uds estén parados en capas superiores. Y tienen otra visión. Pero lo cierto es que si los líderes hicieran su trabajo como lo tienen que hacer, la diferencia de visión no debería de ser tan dsitinta.

Augusto Amaya: Daniel. Te pusiste a pensar que el problema quizás es la falta de información dado a que existe un error en la selección de por ejemplo, los recursos a utilizar? Yo lo veo constantemente en varias empresas, ponen líderes de proyectos que no son líderes. O los ponen por antiguedad, o por méritos técnicos. Cuando un líder de proyecto no cumple correctamente con su rol asignado, pasa lo que vos decís, gaps en los tiempos. Y voy a decir algo que quizás me terminen odiando, pero viví varios cursos de " coaching ".... Los cursos de coaching no sirven. No se estudia en ningún lado como ser un líder. Ya que ( dadas las variantes que indican y se que existen ) no existe un standard de como lider proyectos.

Parte 2

Augusto Amaya: Curiosamente el último curso de Coaching que viví lo daba una persona que en teoría era un "grosso" en la matería. Cuando le pregunté cual era su experiencia me indicaba las universidades ( nacionales y del exterior ) en las cuales había instruido. Cuando le volví a preguntar cual era su experiencia ( buscando que me diga sus casos de éxito, por ejemplo, lograr que un grupo que trabajaba de manera desprolija, trabaje de manera prolija, algo sencillo ) me seguía contestando lo mismo, las universidades donde había instruido. Ahi me di cuenta que de grosso no tenía nada. Porque como bien indicaron uds, las variantes existen. Y es meramente imposible estudiarlas todas. No se puede establecer un standard.

Augusto Amaya: Y quien establece un standard, termina generando el mismo nivel de calidad de producto que establece Microsoft.. la reducción a la mínima expresión para lograr un punto de inflexión que unifique los criterios en el liderazgo de proyectos. Básicamente, lo que hace Microsoft con sus sistemas operativos.

Augusto Amaya: Sorry muchachos si mi opinión quizás les resulte humilde. Vuelvo a decir, es una visión desde mi humilde posición. Lógicamente uds en base a la experiencia , el estudio y la posición que tienen seguramente tienen otra visión distinta. La cual para mi es un gusto escuchar.

Marcelo Zucchelli: mmm... lo q comente de estimacion esta apuntado a quienes estiman actividades, q creo q es tu caso. no me qda claro lo q es la "fase de evaluacion" vs "la estimacion propiamente dicha".

Daniel Sachi: No creas Augusto, nosotros preparamos gente en proyectos en 3 metodologías diferentes, y hemos tenido PMs exitosos. El problema de ser exitoso o no, no está en la definición exacta al inicio, sino en el manejo de los cambios y las variables, y por sobre todo, la comunicación. Por eso vemos a las metodologías ágiles como una muy buena elección cuando uno no tiene toda la información al inicio y necesita comenzar el proyecto. Y no estoy hablando de un módulo de soft, sino de re-configuraciones de plantas químicas, reorganizaciones de empresas, certificaciones de calidad, etc., es decir, ámbitos mucho más heterogéneos, con muchas ramificaciones y especializaciones incluidas dentro de los recursos necesarios. Y si, existen estándares para manejar proyectos, incluso existen estándares de la performance que debieran tener los miembros de los equipos y ciertas tareas. Nosotros (ROI) somos parte del GAPPS que es la Global Alliance for Project Performance Standards, un paraguas que tiene más de 30 metodologías de proyectos diferentes cubiertas y la información existente es extremadamente rica (http /www.globalpmstandards.org/)

Augusto Amaya: Marcelo: La fase de evaluación es un paso previo a la estimación, uno evalua factibilidad, recursos, alcances, etc. El alcance no se determina en la estimación, en la estimación se determinan los tiempos y tareas que resultan de la evaluación. El tema es contar con el tiempo necesario para una correcta evaluación. Y ahi entran lo que yo llamo "deseables".

Augusto Amaya: Daniel: Vos lo acabaste de decir: Metodologías ágiles para cuando tenés la necesidad de iniciar el proyecto y uno no tiene toda la información al inicio. Cuando vos hablás de "tener la necesidad" estás haciendo referencia a lo que yo determino como "deseable". Y ahi ingresamos a lo que yo dije: Los tiempos de los proyectos reales se ven afectados por los deseables. Pero eso no significa que no se pueda estimar de manera efectiva y precisa los tiempos.

Augusto Amaya: Ojo Dani eh !! Ni por ASOMO pienses que yo me estoy poniendo al nivel de uds.!

Marcelo Zucchelli: mmm... oka, entonces estamos hablando de cosas distintas. una cosa es estimar esfuerzo (q es a lo q apuntaba), y dsps en base al resto de la informacion, eso se lleva al tiempo q depende de muchas otras variables q no son "lo que hay q hacer", tales como quien lo hace, cuantas hs trabaja, riesgo de q se enferme, q le caiga un meteorito, eficiencia de la empresa, eficiencia del recurso, interrupciones promedio en la empresa, epoca del año (en navidad no esperes q se trabaje igual q en mayo), etc, etc, etc... dsps esta si te comes tareas, si cambian su alcance, su prioridad, el equipo y demases q daniel y su metodologia apuntan a minimizar para maximizar el retorno.

Augusto Amaya: Vuelvo a decir: Pido disculpas si mi opinión es humilde. Solo traspaso mi experiencia.

Augusto Amaya: Marcelo: Todo lo que vos indicás ( el análisis de riesgos ) es parte del proceso de evaluación. Y responsabilidad del ( en mi caso ) líder de proyectos. Esos factores los tiene que tener en cuenta.

Marcelo Zucchelli: mmm... no, eso no es analisis de riesgo exactamente, es calendarizacion.

Augusto Amaya: A manejarlos me refiero a tenerlos bien identificados, como así también la probabilidad y el plan a seguir en caso de que se suciten para poder mitigarlos.

Augusto Amaya: A que llamás calendarización?

Marcelo Zucchelli: a poner el esfuerzo en el tiempo. EEEJEMPLO, cuanto tiempo lleva una tarea estimada en 40 horas-hombre? hay infinitas respuestas, va a depender de varias cuestiones, como ser cuanta gente la ejecuta, su seniority, eficiencia, epoca del año, disponibilidad de otros recursos necesarios al momento de ejecutar (equipos, sw...), interrupciones... lo q nombraba arriba.

Augusto Amaya: Entiendo. Lo que es para vos la la calendarización para mi conforma parte de la estimación. Ahora bien, cuanto tiempo lleva una tarea no se puede determinar en horas hombre sin determinar el hombre que ejecuta dicha tarea. Estimar una tarea sin determinar quien la ejecuta indica que esa estimación de esa tarea fue ajustada al tiempo deseable del proyecto. Lo que incurre en los gap's que indica Daniel.

Augusto Amaya: Che, acabo de ver los mensajes, no me cabe la menor duda de que los métodos de Daniel ( y más habiendo trabajado para él ) funcionan y está en lo correcto. Reitero: Lo mio es una visión más humilde, y solo hablo del proceso de estimación ( y las falencias en este )

Daniel Sachi: Augusto, creo que acá no hay niveles, hay experiencias distintas. Vos sos bueno en lo que hacés, así como Marcelo lo es en lo suyo y yo creo que lo soy en lo que hago. Yo puedo contarte experiencias exitosas mías, pero son solo eso, experiencias. Y esto ayuda en los proyectos, pero no siempre es la clave porque siempre aparecen entornos y temáticas diferentes a las cuales todavía no tuviste un acercamiento, sponsors que no son lo mejor, equipos que son buenos pero que tienen bajones de performance (somos personas, no hay que olvidarlo) y te puedo asegurar, que en un proyecto con 100 personas involucradas como uno que me tocó dirigir y que por suerte salió muy bien, el mayor desafío es justamente lidiar con los problemas personales que afectan al rendimiento, por eso hablo de los proyectos cerraditos, casi asépticos, como aquellos en los que uno puede tener más certezas

Augusto Amaya: Creeme que me tocó lidiar con eso Daniel. Quizás no con proyectos que involucran a más de 100 personas, pero si tuve proyectos que incluian un grupo tremendamente hetereogeneo e individualista de 72 personas en donde al igual que vos, los problemas mayoritariamente eran del índole personal. También proyectos mal sponsoreados ( o peor aún, sin sponsor) Pero si lógicamente no tengo ( en cuestiones de cuantificación entre otras cosas ) la riqueza que vos tenés en el trato de distintas empresas. Ni tampoco el estudio que vos tenés sobre el tema. De ahi que simplemente transmito mi experiencia desde la humildad de decir "una más". Y mi experiencia me dice que ( dejando el equipo de lado ) son los deseables quienes afectan a la estimación de un proyecto.

Marcelo Zucchelli: una mala estimacion es un factor mas q t revientan un proyecto, o una mala calendarizacion, o un mal staffing, o la falta de sponsorship, o mil cosas mas. en tu experiencia una cosa pesa mas q otras, pero, si me lo permitis, eso es un tema de percepciones... y las percepciones son abstractas y muy personales segun lo q tenga cada uno en su mochila de la vida. lo q SI creo fuera de apreciaciones personales es q todas estas causas son del planning/administracion del proyecto y no otra cosa.

Augusto Amaya: Es que en realidad Marcelo en mi experiencia una cosa no pesa más que la otra, dentro de la evaluación todas esas cosas que indicaste a a mi criterio hay que tenerlas en cuenta. Estamos de acuerdo, la responsabilidad recae sobre el que hace el planeamiento y administra el proyecto.

Marcelo Zucchelli: ‎"El problema y normalmente los desvios se incurren cuando justamente, factores externos inciden sobre la estimación.". aca decis q "los factores externos" pesan mas, y de ahi toooodo este thread . a todo esto, no estoy de acuerdo en q no se puede estimar sin poner nombre, no existen horas-marcelo ni horas-daniel (aunque esas son mas caras ). se tiene q utilizar una unidad generica de esfuerzo xq si no los proyectos no son comparables, y tenes q reestimar esfuerzo si jose o pepe no pueden ejecutar la tarea. de la misma forma q la velocidad de un equipo no es comparable en dos instantes de tiempo, si ese equipo varia entre iteraciones.

Augusto Amaya: A lo que me refería es que básicamente un líder de proyectos que se digne como tal sabe cuanto tiempo le va a llevar el proyecto si tiene el tiempo necesario para poder evaluarlo. Como deseable me refería a que muchas veces en los proyectos, el tiempo de evaluación no es el necesario sino el otorgado. Y ahi es donde un factor externo impacta sobre la estimación. Te asombraría saber que rechacé proyectos grandes para mi ( de 6 cifras verdes) simplemente porque uno de los tres factores que ponderan cualquier proyecto ( en este caso el tiempo ) real del proyecto a mi criterio superaba al deseable. Simplemente, al no sentir la capacidad de lograr llevar adelante el proyecto en el tiempo deseado, o considerar que el tiempo real era mayor, determiné que no era el líder correcto para llevarlo a cabo. Parte de lo que es a mi criterio, el rol de la persona que planea y administra, es saber determinar sus propias capacidades, y conocer su límite.

Augusto Amaya: Otras de las llaves es que para mi si existen horas Marcelo y horas Daniel. Y es más, para mi existen las horas Marcelo trabajando con Daniel. Lo que no existe definitivamente son las horas "Hombre" porque ahi es donde la estimación falla para convertirse ( o ser influida ) por el deseable. Y aparecen los gaps.

Marcelo Zucchelli: es improbable q conozcas el equipo antes de costear, ademas q, repito, una unidad es necesaria para responder mejor a los cambios... ademas q veo q seguimos hablando de cosas distintas xq llamas estimar a lo q entiendo x calendarizar. ves x q son necesarias las 8h de clase?

Daniel Sachi: Esto está para compartir! Es muy jugoso todo lo que se dice y más visto desde tres perspectivas distintas. Sería bueno recomendarle la lectura a los conocidos, no solo por ls experiencias, sino por el nivel de la discusión, siempre con argumentos, nunca denostando. Gracias caballeros!!

Augusto Amaya: Marcelo. Ahi me diste una llave, si me pedís que estime un proyecto sin conocer al equipo, y no solo eso, sino que peor aún, me pedís una fecha en la cual va estar dicha estimación, ya estimaste el proyecto por mí, porque me estás pidiendo un producto, con fecha, y con poca poca información. Y ya el deseable afectó a la estimación del proyecto, impactando sobre las horas reales. Básicamente, a esto me refiero.

Augusto Amaya: Totalmente Daniel. Creeme que yo me nutro muchisimo con estas cosas y sobre todo con toda la documentación ( leyes y demases ) que pasaron para leer.

Marcelo Zucchelli: exacto, es x eso q estimar una duracion SI necesita de un equipo, mientras q estimar esfuerzo no. con el esfuerzo podes simplificar el costeo y conseguir una estimacion de duracion de baja confiabilidad (q en ciertas etapas tempranas no esta mal tener) y sirve como entrada para planificar el equipo necesario. una vez q tenes el equipo, puede tenerse un calendario mas confiable, avanzas en el cono de incertidumbre al estilo juego de la oca...

Martín Miguel López: Wow, que buen thread, apenas tenga tiempo voy a ver si puedo sumar algun granito de arena

Augusto Amaya: Te entiendo Marcelo. Solo que gran parte de lo que decis yo lo considero como una etapa previa de evaluación. En mi metodología no conforman parte de la estimación del proyecto. Pero si, básicamente es lo mismo, solo que yo manejo ( o mejor dicho lo etiqueto ) como una etapa previa. Quizás en lo único que no estoy de acuerdo es que el esfuerzo ( y sus respectivos cardinales en hs, presupuesto, y demás recursos ) ya queda volcado en la misma estimación. O sea, para mi la duración de un proyecto es una resultante de la estimación, no una determinante. No se determina la duración de un proyecto, se estima. Evidentemente tenemos metodologías distintas.

Daniel Sachi: Bienvenido Martín!!

Augusto Amaya: Cuando quieran, podríamos montar un foro de discusión ( no uno en Facebook sino un sitio en si mismo) dedicado a estos temas. Todo lo que sea Management a mi me gusta.

Daniel Sachi: Podemos usar los de ROI si quieren, que ya tiene temas cargados

Augusto Amaya: ¿link?

Daniel Sachi: http://www.riskout-intl.com/apps/forums/

Augusto Amaya: Listo. Ahi me registre usando mi ID de FB.

Martín Miguel López: Bueno, aporté mi granito de arena al foro, lo tiré en el sector de "Organización y Procesos"

Marcelo Zucchelli: entiendo la diferencia, pero recomiendo la division estimacion de tamaño/esfuerzo x un lado y calendarizacion x otro. las dos actividades tienen tecnicas muy distintas, se suele involucrar a gente diferente y el outcome de cada una sirve a procesos distintos. si bien esa diferenciacion tmb la hacen el PMI y el SEI, no es tanto x seguir las metodologias establecidas en el PMBoK y el SWEBoK sino xq en mi experiencia me dio mejor resu

Aporto mi pequeño granito de arena con un ejemplo: En noviembre del año pasado comenzamos un proyecto. Se hicieron los relevamientos de las distintas funcionalidades solicitadas descriptas en el SOW, lo cual derivó en una serie de docs de arquitectura, casos de uso, etc. A partir de esto tuvimos varias e interminables conferencias para pulir estos documentos. Los mismos fueron puestos a disposición del Cliente para que los apruebe. Se aprobó toda la documentación sin mayores comentarios (básicamente xq ya estabamos sobre el deadline)

A partir de alli se planificaron las distintas iteraciones y se estimaron las tareas involucradas. Las estimaciones se hicieron en base a la experiencia en proyectos anteriores, con un cierto colchón ya que el equipo del proyecto era junior en todo sentido (tecnologia e industria). Se comenzaron las tareas de desarrollo con un horizonte cercano para el primer prototipo entregable. Durante la primer iteracion se avanzo a pasos agigantados, todos super motivados, el cliente que no molestaba, etc. Se hizo la presentacion del primer prototipo y a partir de alli el cliente comenzó a enviar comentarios y modificaciones sobre flujos que ellos mismos habian confirmado, lo cual deriva en pedidos de cambio, replanificacion de tareas, retraso de las fechas de entrega y de piloto, etc.

A su vez, antes de comenzar cada iteración se planificaba o revisaba el plan, se analizaban performances de la it anterior y se detectaban puntos fuertes y puntos a corregir. Lo que me llamo mucho la atencion, es que a mitad de proyecto hubo un bajón anímico importante en el equipo tanto por temas inherentes al proyecto mas un mix de factores ambientales negativos de otros proyectos y temas propios de la empresa. Ese bajón afectó muchisimo la relacion rendimiento esperado/real. Una vez solucionados esos problemas el rendimiento volvio a sus niveles anteriores.

Con esto (no tan corto al final) quería simplemente aportar algo que todos vivimos cotidianamente. La única constante es el cambio, y nuestra cintura para adaptarnos y manejar esos cambios es uno de los factores mas decisivos para el éxito de los proyectos.