Recién comencé a hacer algunos contratos pequeños por primera vez, y estoy trabajando en un proyecto con una persona responsable de tratar con el cliente y analizar los requisitos.
En este caso, uno de los requisitos del proyecto estaba ligeramente incompleto y este pequeño cambio supone un gran cambio en el tiempo que se necesitará para implementar los requisitos (quizás duplicando o triplicando la carga de trabajo).
¿Quién tiene la culpa? ¿Es el cliente por no especificar el requisito, el analista de requisitos por no ser explícito o el programador por no hurgar en él?
Más importante aún, ¿quién es el responsable aquí? ¿Tendremos que implementar el nuevo requisito sin pedir una compensación adicional?
(Si cambia algo, no se ha firmado nada, solo hay un acuerdo verbal).
Primero, considérese afortunado de no haber firmado aún el acuerdo formal. Es mucho más fácil traer malas noticias a un cliente desde el principio que al final, cuando el cliente está listo para recibir la entrega.
En una etapa tan temprana, no debería necesitar simplemente comer el costo. En este punto el cliente no ha perdido nada. Si quieren que el proyecto se haga más barato, pueden optar por ir con otro proveedor.
Sin embargo, incluso si hubiera firmado el acuerdo y estuviera al 25%, 50%, 75% del camino hacia lo que creía que era la finalización del proyecto, aún es mejor informar inmediatamente al cliente sobre la situación para que puedan informar a sus partes interesadas. la situación y adaptar sus planes.
No se concentre en quién tiene la culpa, concéntrese en comunicar el problema al cliente y estar en la misma página. Centrarse en las soluciones.
Sin embargo, dado que su pregunta es sobre quién tiene la culpa, es de todos. El cliente es tan responsable como usted de asegurarse de que los detalles estén bien definidos. Están pagando por el proyecto, y si hay detalles que se omitieron, son parcialmente responsables. Después de todo, es su dinero, por lo que deben asegurarse de que se gaste de manera inteligente y que el valor que reciban sea justo.
Eso no quiere decir que no seas responsable tampoco. Se le paga por el trabajo, y es su responsabilidad, y la responsabilidad de su colega, asegurarse de que reciba una compensación justa y pueda cumplir con los requisitos.
Los requisitos faltantes o incompletos son una de aproximadamente 1,000,000,000 de variables aleatorias que lo afectarán durante el curso de un proyecto complejo, afectando tanto favorable como desfavorablemente sus costos y estimaciones de cronograma. Muchas de estas variables ni siquiera las verá y, por lo tanto, no tendrá la oportunidad de preguntar quién tiene la culpa en este intercambio.
Esto es gestión de proyectos.
Es por esto que existen herramientas y técnicas para hacer frente a las variaciones estocásticas en nuestro trabajo. En primer lugar, esta es exactamente la razón por la que no debe proporcionar estimaciones deterministas de un solo punto. Proporcione en su lugar su mejor caso, su peor caso y la distribución probabilística que se encuentra en la parte superior de ese rango. En segundo lugar, analice su proyecto con todas esas distribuciones probabilísticas mediante simulación. En tercer lugar, realice un análisis de gestión de riesgos para que pueda programar sus elementos de mitigación y contingencia, y sus costos, para las incógnitas conocidas.
Apuntamos y cotizamos un solo punto cuando se lo pasamos al cliente, pero usted sabrá dónde está ese único punto en su distribución y tendrá los recursos para hacer frente si las cosas no salen como esperaba.
¿Quién tiene la culpa? ¡Ninguno! Ninguno de nosotros puede predecir con algún grado de precisión el futuro. Siempre hay variabilidad en nuestro desempeño. Y siempre hay incertidumbre en nuestros planes.
Por lo tanto, centrarse en esta liendre es una pérdida de tiempo. Parece que tiene temas más interesantes en los que trabajar con sus procesos y técnicas de estimación, planificación y gestión de riesgos.
Según mi experiencia, los mejores documentos de requisitos especifican todos los requisitos (excepto los que no se especifican). Otros especifican los requisitos importantes y dejan el resto sin especificar. En cualquier caso, por lo general son los requisitos no especificados los que aumentan el costo (como sea que se mida). El proceso de diseño debe complementarse para permitir una cantidad razonable de requisitos no especificados.
El desplazamiento del alcance es otra forma en que se agregan requisitos a un proyecto existente. Después de todo, no costará mucho agregar la nueva característica ahora, pero costará mucho más adelante. He visto a un desarrollador trabajar un mes completo programando una pantalla para que el botón de reinicio se deshabilite si la pantalla se editó de nuevo a su contenido original.
Los requisitos inestables también aumentan los costos. El peor caso que vi fue cuando se agregó la misma función los lunes, miércoles y viernes. (Los martes y jueves se eliminó la función). Esto ocurrió 18 meses después de un proyecto de 6 meses.
Una cuarta área de cambio de requisitos es cuando los requisitos originales eran incorrectos. Esto debe tratarse rápidamente para garantizar que el proyecto vuelva a encarrilarse con un mínimo de reelaboración.
En todos los casos se trata de cambios en los requisitos. Como han señalado otros, esto debe gestionarse y comunicarse al cliente lo antes posible.
Estoy de acuerdo con JMort en que deberías considerarte afortunado de haberte dado cuenta de esto tan pronto. En este caso, todavía tiene la capacidad de volver atrás y renegociar sin que sea contencioso.
En cuanto a quién tiene la culpa, la culpa recae tanto en usted (su empresa) como en el cliente. En algún momento del proceso, las partes de ambos lados se reunieron y negociaron esto. Y en algún momento el cliente dijo “te lo contamos todo y explicamos completamente nuestros requerimientos”, y alguien de tu lado dijo “gracias, lo entendemos completamente y no tenemos más preguntas”.
Esta es la razón por la que es TAN crítico que al iniciar un proyecto tenga un acuerdo por escrito y un documento de alcance detallado, de modo que más adelante, cuando surjan estos problemas (observe que dije 'cuándo', no 'si') tenga algo a lo que recurrir .
Como con otros, estoy de acuerdo en que no es culpa de nadie. La culpa podría extenderse fácilmente como una buena capa de mantequilla de maní.
Y como con otros, estoy de acuerdo en que averiguar quién tiene la culpa es un enfoque equivocado. Descubrir quién dejó abierta la puerta del establo no hará que el ganado regrese al establo. Levántate y sal de allí para reunirlos a todos. Concéntrate en la solución.
A esto quiero añadir dos cosas:
1- ¿Qué harás diferente la próxima vez?: Una de las marcas de un gran líder de gestión de proyectos es que miran hacia adelante a la próxima vez. Preguntan "¿cómo nos aseguramos de que esto no vuelva a suceder?". Todos conocemos el viejo dicho "si me engañas una vez, te avergüenzo. Si me engañas dos veces, te avergüenzo". ¡El fracaso está BIEN! Lo que no es no es aprender de ello.
2- Como PM es culpa nuestra: No, no digo que debas tirarte a la espada. Pero en el " Gorila de la autoridad responsable " hablo de cómo los PM debemos dar un paso al frente y asumir la responsabilidad. Incluso cuando no estamos "a cargo", tenemos la responsabilidad de liderar y hacer que el proyecto tenga éxito. Entonces, cuando hay un fracaso, debemos mirarnos detenidamente y descubrir cómo podemos asegurarnos de no pasar por alto este fracaso en el futuro.
Cuando nos enfrentamos a cualquier tipo de problema, siempre hay una trampa: encontrar un responsable. La naturaleza humana convierte a menudo a esa persona en el chivo expiatorio que paga solo por un malentendido o error colectivo. Así que evitaría tratar de encontrar un responsable de inmediato. Me concentraría ahora en encontrar una solución. Hablaría lo antes posible con la persona que está a cargo de contactar a su cliente o incluso llamar al cliente yo mismo. Entender claramente los requerimientos de un cliente parece fácil, pero a veces crees que sabes lo que piensa la otra persona. O estás de acuerdo en algo que se percibe de manera muy diferente desde ambos lados. Así que no tengas miedo de insistir y hacer tantas preguntas como quieras. Haz que tu cliente entienda que quieres hacerlo bien al principio. Tener un buen comienzo en su proyecto es la clave de su éxito. Prefiero tener prisa al principio que al final. Es una pesadilla encontrar demasiado tarde que necesitas algo que no planeaste al principio.