Al trabajar en desarrollo web, me enfrento a una situación común cuando los clientes quieren usar software de terceros como punto de partida del proyecto. Eso podría ser un CMS, un sitio de comercio electrónico o algo más. La motivación suele estar impulsada por el presupuesto; al cliente le parece que tener un sitio web creado sobre algún producto listo para usar reducirá los costos. No siempre es cierto. Por ejemplo:
Eso lleva a preguntas que me gustaría hacer:
Realmente no está haciendo una pregunta sobre gestión de riesgos. En el fondo, la pregunta es realmente sobre cómo estimar proyectos en los que no tiene valores de referencia. Una solución común es utilizar un proyecto piloto para generar valores de planificación como entradas para un proyecto a gran escala.
La capacidad de su proyecto para estimar con precisión (o en absoluto) depende en gran medida de la experiencia del equipo con un dominio de conocimiento específico. Si no tiene experiencia con una determinada tecnología o proyecto, entonces el cronograma de su proyecto es una caja negra; no hay forma de estimarlo más que conjeturas.
Incluso suponiendo algún conocimiento, todos los proyectos tienen un cono de incertidumbre . Por lo general, trazará un cronograma preliminar basado en algunos valores de planificación, a menudo ajustados por un factor de error que representa la cantidad de incertidumbre que tiene el equipo sobre el proyecto. Por ejemplo, los equipos sin experiencia pueden multiplicar sus valores iniciales de productividad (por ejemplo, la velocidad) por 0,6, o aumentar su programación multiplicando las estimaciones de tiempo por 1,4.
El valor real del factor de fudge es menos importante que el conocimiento claro de que es un ajuste a los valores de planificación. Recuerde: una estimación es una opinión informada , no una garantía absoluta.
Si su proyecto involucra habilidades fuera del área de especialización actual del equipo, o si es necesario realizar algunas tareas para calibrar el cronograma de un proyecto más grande, entonces necesita un proyecto piloto .
Por ejemplo, en lugar de tratar de estimar un sitio web de 100 páginas con una cadena de herramientas con la que nadie tiene experiencia, podría planificar un proyecto piloto para un sitio web de 5 páginas. Los entregables importantes de un proyecto piloto como este no son en realidad las páginas web; los entregables reales son la experiencia con la solución propuesta y mejores valores de entrada para el proyecto más grande.
Por ejemplo, puede hacer su estudio de 5 páginas en dos semanas, pero descubre que la solución no escalará de la manera que lo necesita. O bien, es posible que descubra que la configuración inicial lleva una semana y que los desarrolladores pueden promediar una página al día siguiente.
Cualesquiera que sean los resultados, utiliza los datos del proyecto piloto junto con un nuevo conjunto de factores fudge más informados para generar el cronograma o la estimación para el proyecto más grande. Esto puede o no ser lineal: un proyecto web de 100 páginas no es necesariamente 20 veces más complejo que un proyecto de 5 páginas. Sin embargo, su cono de incertidumbre debería ser más pequeño después de un estudio piloto, y es mucho más probable que sus estimaciones caigan dentro de los límites de la varianza aceptable.
Pregunta #1: este es un caso de negocios. Para convencer a un cliente de cualquier cosa, debe construir un argumento. Desarrolle un caso que muestre varias alternativas entre las que el cliente puede elegir, los beneficios/costos/riesgos de cada alternativa y su recomendación. Su recomendación debe estar respaldada y fundamentada con los estándares de la industria y los hechos que encuentre en su investigación, no solo su opinión probablemente sesgada por su búsqueda de ganancias. Toda su presentación debe estar respaldada por la relación que ha desarrollado con su cliente. No sería solo un vendedor que ofrece sus productos, sino un asesor de confianza.
Pregunta #2: Esta es una pregunta de gestión de riesgos. Y aplicaría técnicas normales de gestión de riesgos. Hay pocos proyectos por ahí que no dependan de algo externo que podría tener un impacto adverso o favorable en su cronograma y presupuesto. Así que esto es normal; bienvenido a gestión de proyectos 101.
Investigue lo que pueda sobre la dependencia externa, por ejemplo, reputación en el mercado, historial de retrasos o puntualidad, referencias, etc. Lo que no puede aprender, necesita redactar una suposición adecuada (una fuente de riesgo). Carga su programación con los hitos externos basados en esa suposición para que pueda comunicar claramente cómo se vería afectado su rendimiento si esas suposiciones no dan resultado. Puede cargar reservas de programación para acomodar algo que llega tarde y, sobre todo, le comunica claramente a su cliente dónde tiene dependencias, los riesgos que usted y su cliente deben aceptar y cualquier actualización de lo que está observando.
Solo puedes controlar lo que puedes controlar. La mayoría de las variables muy aleatorias que afectan nuestro desempeño, tanto favorable como desfavorablemente, están fuera de nuestro control, lo cual es muy contrario a la intuición de todos los proyectos de gestión de negocios tipo A, pero así es la vida. Todo lo que puede hacer es observarlos, planificar para ellos (gestión de riesgos), comunicar lo que está observando de manera oportuna y aceptar el hecho de que todo esto es muy normal.
Para responder a su segunda pregunta, aplicaría técnicas de gestión de riesgos. Hay mucho material en Internet sobre todo el proceso. Hay un buen ejemplo elaborado de gestión de riesgos en un proyecto de software en la Guía del usuario de Risk Register .
Todd A. Jacobs
rodion bikov