Archivo de la categoría: Gerencia de Proyectos

Estimación de proyectos de software: cálculo usando el método PROBE (PROxy Based Estimation)

La estimación de proyectos software es una tarea muy compleja, pero de vital importancia en toda la etapa de desarrollo del software.

Algunos de los principios a tener en cuenta para la realización de una estimación de software:

  • Retrasar la estimación lo máximo posible. Cuanto más se retrase, más precisa será.
  • Hacer estimación por analogía. Utilizar el costo de proyectos similares.
  • Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.
  • Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en el proyecto.
  • Existen técnicas de descomposición. Estimas el costo descomponiendo el producto y/o el proceso.
  • Existen modelos empíricos. Modelos de regresión que relacionan esfuerzo con tamaño o funcionalidad.

Factores importantes a considerar:

  • Complejidad del proyecto.
  • Tamaño del proyecto.
  • Estabilidad de los requerimientos.
  • Facilidad de identificar funciones.
  • Estructura de la información.
  • Disponibilidad de información histórica.

El método PROBE

Este método está descrito en el libro PSP A Self-Improvement Process for Software Engineers, aunque es un poco complicado de seguir, por eso que mejor hacer un trabajo más práctico para tratar de enfocar el aprendizaje haciendo, más que diciendo.

Un proxy es una unidad de software que se puede identificar en un proyecto. Ejemplos de ello son las pantallas (User Interfaces), archivos, objetos, entidades lógicas, funciones (Stores Procedures) y puntos de función. La representación se pueden visualizar fácilmente a partir de las especificaciones del proyecto tales como documentos de requisitos. A continuación, se pueden traducir en líneas de código en función de los tamaños de los proxies históricos similares en proyectos de desarrollo anteriores. La líneas de código junto con cifras de productividad se pueden utilizar para predecir los recursos necesarios para un proyecto.

El método completo está organizado en una planilla Excel de construcción propia:

2016-11-09_16-40-40

Proxy’s

En esta Hoja de Trabajo se establecen las estimaciones por Proxy, y a partir de la estimación de los tiempos de construcción se estiman los de las otras fases del desarrollo. Si estas estimaciones porcentuales no aplican para el caso específico, pueden reemplazarse por valores históricos (en caso de contar con ellos).

La distribución de los porcentajes de referencia va a depender de la metodología o del criterio utilizado por los evaluadores del proyecto.

¿Cómo determinar la cantidad de días de construcción?

Este es el dato que mejor se puede estimar por los expertos o por consenso. A partir de este valor se calculan los otros de acuerdo a los porcentajes de referencia.  Son los desarrolladores (expertos) los que mejor saben cuánto se demorar en construir un proxy.  De todas formas existen tablas de complejidad de referencia por lenguaje de programación que pueden utilizarse, aunque en la práctica es mucho mejor el juicio experto.

2016-11-09_17-01-40

Estimación

En esta hoja, se desglosan las funcionalidades en los proxys definidos en la etapa anterior. Las columnas en azul son el resultado de la ponderación de la cantidad de Proxys requeridos por su tiempo definido en la hoja ‘Proxy’.

Para cada funcionalidad del sistema se especifican la cantidad de proxy’s a desarrollar, por ejemplo en el caso de la funcionalidad “Login”, se requiere 1 página web sencilla, 1 mediana, 1 procedimiento almacenado (en BBDD), 1 clase mediana y 1 tabla.  Lo anterior solo para efectos del ejemplo.

Sobre esta base la planilla va calculando la cantidad de días de análisis, construcción, integración y pruebas (para efectos del ejemplo) que se requieren en este proyecto.  Las etapas por supuesto pueden ser personalizadas por el evaluador.

Aplicaciones para otras áreas que no sean de construcción de piezas de software

Cualquiera donde sea factible definir y estructurar vía proxys.  Solo basta usar un poco la imaginación.

Link a planilla de ejemplo:

https://drive.google.com/file/d/0B3-y5EFvrO7ec3drWlJhZmhfaUk/view

Referencia:

http://www.sei.cmu.edu/reports/06tn017.pdf

Método y proceso implementado con éxito en una empresa de desarrollo de software de Santiago de Chile.  https://drive.google.com/file/d/0B3-y5EFvrO7eeEdJVzlTWEdkczQ/view

Anuncios

Deja un comentario

Archivado bajo Gerencia de Proyectos, Ingeniería de Software

Lo que PMP no te enseña de la gestión de proyectos

Seré sincero: he estado a punto de titular este post “La gestión de proyectos según el Dr. House”, pero resultaría pretencioso. Así que dejémoslo como está; todo lo que escribiré aquí es puro zumo de realidad, tras 14 años de experiencias muy diferentes en el mundo TIC y de haber cometido todos y cada uno de los errores que resumo en este decálogo. Espero que os sirva de algo a los recién certificados, Jefes de Proyecto Junior y demás neófitos en esto del Project Management.

I. Conoce a los verdaderos interesados antes de iniciar el trabajo.

Tomar requisitos no es una tarea rápida ni objetiva. Normalmente, en las sesiones de toma de requisitos hay mucha gente con grandes requisitos de nombre bonitos (escalabilidad, robusto, calidad total, ISO), y que presume de haber leído “El arte de la guerra”. Pero todos se suelen obviar al usuario final del aplicativo o servicio, normalmente un administrador muy abajo en el organigrama corporativo. Lo paradójico es que es esa persona o grupo de usuarios quienes normalmente van a validar gran parte de las funcionalidades. Encuéntralo y no lo sueltes hasta conseguir los requisitos ocultos.

II. Controla los riesgos obvios que siempre se infravaloran.

Si tu chárter no ha sido firmado o nadie ha asumido el rol de sponsor, éste es el primer riesgo a tener en cuenta. Sin sponsor, no hay proyecto ¿Quién va a escucharte cuando levantes la bandera roja? ¿A quién vas a recurrir para cuando tengas problemas con la factura de la Fase N? ¿Cómo vas a discriminar las funcionalidades core de la carta a los RRMM?

El contrato y el Acuerdo de Nivel de Servicio (SLA) son la biblia. Si desconoces alguno de ellos, ese es el segundo riesgo evidente a tener en cuenta.

III. Usa una metodología adecuada para cada proyecto.

No intentes encajar tu proyecto en los marcos de trabajo que conoces, hazlo al revés. PMI no es tu cliente, ITIL no suele ser el marco más representativo de la organización de tu cliente, CobIT está en otro planeta, scrum es considerado en muchas organizaciones “una fricada”. Mantén el orden interno, pero sé práctico. Parafraseando a Bruce Lee: “si pones agua en una tetera, el agua se transforma en la tetera”… Be water, my friend!

IV. Empieza a definir el alcance del proyecto por los informes.

Ahí es donde encontrarás los detalles que definen la capa de acceso a datos, además de gran parte de la propia lógica de negocio. Entiende los informes que necesita el Departamento de Contabilidad y entenderás el negocio mejor que el propio Jefe de Producto.

Es muy común dejar los informes para el final, para la última fase del proyecto, y suele ser ese el momento en que te das cuenta de que alguno o varios de los informes no encajan con tu modelo de datos. Así que, no cierres el alcance del proyecto hasta que consigas que el cliente haya definido los informes de salida y estés seguro de haberlos comprendido completamente.

V. Define el core del proyecto y cíñete al plan.

Es típico en los proyectos TIC que las funcionalidades no estén cerradas incluso tras lanzar el proyecto y que haya que hacer modificaciones al vuelo. Bien, no hay problema, siempre que hayas definido las funcionalidades para alcanzar un mínimo producto viable. Si lo has hecho, pero aún así hay que modificar la funcionalidad del core,que sea solo a la baja ¡Por algo es el core! El resto faséalo y admite modificaciones sólo tras el cierre de la primera entrega o verás como los cambios sobrevenidos hacen tambalearse toda la arquitectura.

VI. Piensa bien qué hitos son fáciles de conseguir y espácialos adecuadamente durante las fases.

Si algo hemos aprendido de toda la literatura sobre gestión del cambio es que una mala gestión de expectativas puede hundirte el proyecto. No hay misterios: la agenda (política) del cliente marcará los entregables, tengas o no algo que entregar, por lo que deberías reservar algunos cartuchos. Y cuando llegue el momento, permite que sea tu cliente quien difunda los éxitos internamente.

VII. Cometerás errores; asúmelos lo antes posible y trata de solucionarlos sin buscar excusas.

Te han contratado para solucionar problemas o al menos mitigarlos, no para crearlos. Una forma muy común de generar problemas es ocultar los errores propios, porque los problemas que no se arreglan inmediatamente tienen muy mal envejecer: siempre, siempre, siempre empeoran.

VIII. Sé duro con tu cliente.

No has venido aquí para hacer amigos. Con suerte, puede ser que lideres un proyecto en una compañía que se esfuerza en ser un “human workplace”, favorece el after-work y trata de ofrecer un ambiente “friendly”… pero eso es para el equipo en casa del cliente, no para tí. En ningún caso te hagas amigo de tu cliente (para eso ya está el Director Comercial) porque llegado el momento de negociar un cambio de alcance o el cierre del proyecto… Bueno ¿Quién no ha salido perdiendo en una negociación con un amigo?

IX. Prepárate para que sean duros contigo.

Es lo mejor que te puede pasar. Si esto último no ocurre desde el principio, ten por seguro que los problemas vendrán al final del proyecto, cuando ya no haya tiempo de reacción.

Como corolario, sólo cuando las cosas pinten realmente mal será cuando aprendas a hacer las cosas bien de una vez.

X. Y aún así… Muchos de tus proyectos fallarán.

Las estadísticas dicen que la mayor parte de los proyectos no llegan a ver la luz porque no cumplen la funcionalidad esperada o porque el usuario no ha asumido el cambio (y vuelta al capítulo 4 de PMBOK, o al primer capítulo de este decálogo).

Esto es lo que ocurre en la vida real: por muy bueno o senior que seas, la mayoría de tus proyectos fallarán: anticípate. ¿Cómo? Valora los riesgos en su medida real, sigue el proceso, comunica retrasos y cambios de la línea base al sponsor y todos los interesados… Pero no te confíes: que el sponsor asuma los riesgos no implica que asuma las consecuencias de su materialización. Si constatas que la probabilidad aumenta pero no ves a nadie preocupado, quizá no sea mala idea ir buscando un nuevo proyecto.

Anexo 1 (por cortesía del Dr House): Recuerda que todos mienten.

Perdonad que al final haya sucumbido al encanto del Dr. House, pero es totalmente cierto. Hay que decir en favor del cliente que la mayor parte de las veces no se da cuenta de que miente. Si recibes una documentación con un wsdl de hace dos años, comprueba por ti mismo que los métodos aún existen ¡Sorpresa, ni siquiera responde! ¿Te ha mentido? No, simplemente “no tiene tiempo de pensar en eso ahora”. Así que no remolonees, piensa por ti mismo y trabaja duro para descubrir la verdad.

Autor: 

https://www.linkedin.com/pulse/20140703220301-22118661-lo-que-pmp-no-te-ense%C3%B1a-de-la-gesti%C3%B3n-de-proyectos

Deja un comentario

Archivado bajo Gerencia de Proyectos

El Arte de La Guerra Aplicado a la Gerencia de Proyectos

2016-07-28_19-36-06La Gerencia de Proyectos es un tema que debe ser bien abordado por quienes están a cargo, para ello deben ser estrategas y no hay libro que sea mejor que el libro de Sun Tzu “El Arte de la Guerra”, el cual ha sido reconocido como el mejor libro de estrategia de todos los tiempos, ya que no solo aplica para el ámbito militar, sino que es aplicable en los negocios.

Si has leído el libro, te estarás preguntando cómo es posible que sea aplicable al área de negocios, y acá en CertCampus te mostramos que es posible.

Sun Tzu y el Arte de los Negocios

Es sabido que en el libro “El Arte de la Guerra” la filosofía del escritor es obtener el éxito sin combatir y a continuación mostraremos el punto de vista aplicable al sector de negocios.

Obtén la victoria sin luchar

“La guerra es un asunto de vital importancia para el Estado; es la jurisdicción de la vida o la muerte, el camino que lleva a la supervivencia o a la ruina. Es indispensable estudiarla concienzudamente”.

En la época de Sun Tzu gobernaba quien tenía los medios para llegar a tener poder y establecerse entre él, no quien dominaba el comercio.

Lo que fue un motivo tremendo de irritación fue la guerra fría, la cual provocó una competencia comercial entre países, es por ello que los negocios son una parte vital del Estado hoy en día.

“Tu meta debe ser tomar intacto todo lo que hay bajo el cielo. De este modo tus tropas no se agotarán y tu victoria será total. Éste es el arte de la estrategia ofensiva”.

Este párrafo nos plantea una idea aplicable a los negocios: Capturar el mercado de una manera limpia, asegurando así una resistencia y bonanza. Una forma muy práctica es hacer una definición de los mercados y hacer un compromiso de obtener el dominio de ellos, de una manera relativa, sin poner en peligro la rentabilidad de la empresa. Se deben tomar en cuenta todos los factores, prever respuestas y resultados.

Se debe evitar la fortaleza, la debilidad debe ser atacada.

 “Pues un ejército puede compararse con una corriente de agua, porque así como el caudal que fluye evita las alturas y corre presuroso hacia las tierras bajas, así un ejército evita la fortaleza y ataca los objetivos más débiles”.

Aunque esto no es un secreto, otra de las tácticas principales para sobrellevar los negocios es atacar los puntos débiles, cuando menos se lo esperen. Esta táctica requiere menos recursos que atacar fortalezas, por lo tanto nuestro equipo no quedará exhausto y creará un camino corto hacia el éxito; al mismo tiempo se obtendrá una victoria con aún más valor, pues los recursos invertidos fueron menores y las utilidades serán mayores.

Para ser un buen estratega es bueno saber ver las debilidades del oponente, pero es necesario tener la fortaleza para evitar atacar cuando no es necesario o cuando una situación “prevista” cambia.

Actuar velozmente y con preparación

“La velocidad es la esencia misma de la guerra. Aprovecha la falta de preparación del enemigo; viaja por rutas inesperadas y atácalo donde no esté prevenido”.

La guerra –en este caso- no es diferente de los negocios, la velocidad es un factor esencial para obtener la victoria. El ritmo de los negocios acelera continuamente, y actuar lentamente podría no ser la mejor táctica. Para poder sobrevivir en el mundo de los negocios es necesario que la empresa sea presta para actuar y al mismo tiempo esa agilidad sea inquebrantable. Se debe estar apto para beneficiarse de las oportunidades creadas.

La velocidad es importante y no solamente para aprovechar las oportunidades, sino que es el factor sorpresa determinante para tomar desprevenida a la competencia. Luego de un primer ataque sorpresa se pierde el equilibrio, luego de eso, lanzar más ataques seguidos descontrola aún más y provocará incapacidad de responder.

Buen liderazgo, aún en tiempos malos

“Y por esto el general que no busca la gloria personal cuando avanza, ni se preocupa por evitar el castigo cuando retrocede, sino que su único propósito es proteger a la población y promover las mejores causas de su soberano, es la joya preciosa del Estado… pocos se encuentran de este temple”.

Muchos podrían ser buenos líderes en tiempos buenos, pero no cualquiera es ejerce un buen liderazgo en tiempos turbulentos, es difícil de encontrar un líder de este calibre.

Este tipo de líder es excepcional y deseable pues tienden a anteponer la necesidad de los demás a la de ellos mismos.

Para ejercer un buen liderazgo es necesario:

  • Temple de carácter, además de formarse una imagen.

  • Ser el ejemplo, reflejar lo que se dice.

  • Compartir los problemas del equipo, no solo las victorias.

  • Motivación emocional, además de la material.

  • Ser claro al momento de encomendar misiones, evitar confusiones.

  • Lograr que la estrategia planeada sea de beneficio a la organización, no lo contrario.

Si los recursos son pocos es bueno tener a la mano teorías o ideas nuevas para hacer una planificación correcta y aplicar todo eso de manera correcta en la organización.

El libro “El Arte de la Guerra” resulta bastante útil para las empresas, ya que nos encontramos en un mundo globalizado, y si se aplican todos los principios del libro las posibilidades de obtener una victoria incrementan.

BIBLIOGRAFÍA:

http://repository.udem.edu.co/bitstream/handle/11407/415/El%20arte%20de%20la%20guerra%20aplicado%20a%20la%20administraci%C3%B3n.pdf?sequence=1&isAllowed=y

http://www.degerencia.com/articulos.php?artid=937

Artículo visto en: http://www.certcampus.com/

Deja un comentario

Archivado bajo Gerencia de Proyectos