Estoy trabajando como gerente de entrega de proyectos de una empresa de desarrollo de software. A menudo, antes del inicio del proyecto, un cliente leal y de mucho tiempo se pone en contacto conmigo directamente para solicitar un "estimado" de algunos trabajos que se realizarán en su sistema.
A menudo, estas solicitudes vienen con descripciones de muy alto nivel. Cabe destacar que aún no están solicitando Cotizaciones en ese momento. Ellos (la persona, a menudo mi contraparte en la empresa del cliente o un miembro de su equipo) virtualmente me piden que haga su tarea para producir estimaciones de alto nivel para sus informes o reuniones.
Para dar una imagen más completa, mi empresa ha estado sirviendo al cliente durante algún tiempo. Más tiempo que algunos de los gerentes e ingenieros del cliente han estado trabajando allí. No tenemos un contrato general que cubra solicitudes fuera de contrato como esta. Por lo tanto, sobre una base estrictamente contractual, no estamos obligados a considerar tales solicitudes. Sin embargo, el propietario de mi empresa me aconseja que considere tales solicitudes porque fomenta una buena relación con el cliente y al menos nos pone a la vanguardia cuando el proyecto entre en licitación abierta. Y francamente, estoy de acuerdo con ella.
El problema aquí es que cuando emito estimaciones en números como el costo en dólares, los requisitos de días-hombre o los plazos. El número a menudo surge en alguna reunión de presupuesto o en alguna carta de proyecto. Las personas dentro se comprometen en base a ello. Y cuando llega el momento de presentar cotizaciones formales, mi empresa a menudo se compara con esos números. A menudo, el alcance del trabajo ha crecido un poco.
Mi pregunta es la siguiente: cuál es la mejor manera de comunicar a los clientes que el presupuesto no es vinculante. Es una cosa de 'discusión en curso'. Cualquier número que surja de allí, ya sea que los costos en dólares o los plazos no sean un compromiso mío o de mi empresa.
Desafío de marco leve: considere proporcionar sus estimaciones como el extremo ancho de un cono de incertidumbre en lugar de un número discreto.
"Necesito una [cosa vaga], ¿cuánto tiempo tomaría?"
"Está bien, lo discutí con mi equipo y creemos que tomará entre 2 y 7 semanas".
"Necesito una estimación exacta".
"Entonces necesitaremos los detalles exactos. Nuestra estimación de los detalles que ha proporcionado es de 2 a 7 semanas".
"Está bien, ¿qué pasa con [algo menos vago]?"
"Oh, eso sería de 3 a 5 semanas".
Proporcionar sus estimaciones como un rango integra su incertidumbre en la estimación en sí , de modo que no hay necesidad de un paso separado "pero no nos comprometemos completamente con esta estimación".
Para agregar a la respuesta correcta de nvogel .
Además de proporcionar entregas detalladas, debe agregar las funciones estándar que se olvidan, se pasan por alto pero son necesarias y consumen mucho tiempo y recursos, por lo tanto, afectan tanto la línea de tiempo como el presupuesto.
Funciones como diseño, especificaciones funcionales, diseño gráfico y aprobación, integración (corrección de errores como resultado de la integración; se debe dar un nombre para ocultar los "errores"), control de calidad (con algunas rondas para la corrección de errores), pruebas beta/fuera de línea, procedimientos de puesta en marcha, para proporcionar algunos ejemplos.
Puede dar esto por sentado, pero, como dijo, su "borrador" se convierte en un documento de trabajo y, por lo tanto, desea evitar la fijación de precios erróneos (y la posible falla del análisis competitivo) en función de un plan de proyecto parcial.
Adjunte cada estimación a una entrega detallada en lugar de un alcance de trabajo designado, de esa manera hay menos lugar a dudas sobre lo que se estimó. Utilice la estimación relativa (puntos) a nivel de artículo y luego agregue los valores de puntos y conviértalos en tiempo y costo absolutos según sea necesario. Las mejores estimaciones generalmente las crea y las posee el equipo de desarrollo, no un gerente de entrega.
Su problema requiere dos cosas que son 100% propiedad de SU empresa, y solo estas dos cosas: 1) Debe insertar un lenguaje de tipo legal que acompañe a su estimación de que se trata de una estimación aproximada de orden de magnitud de alto nivel basada en lo que se sabía en ese momento que está sujeto a cambios cuando los requisitos se vuelven más conocidos y firmes; y 2) SU empresa necesita mantenerse firme y retroceder si experimenta presión para apegarse a esa ROM. El número 2 es crítico porque, sin eso, el número 1 no tiene sentido.
Basta con mirar a otras industrias como la construcción. Si se acercó a un contratista para que le construyera una casa con algunos deseos rudos y de alto nivel, y luego tratara de mantenerlos en ese valor, si es que lo proporcionan, se reirán mientras se alejan de usted.
Para aquellos de nosotros en SW u otro trabajo de conocimiento, parece que tenemos dificultades para hacer precisamente eso. Pero realmente no se requiere ninguna otra intervención excepto decir, "¡No!" Los vendedores de SW y otros trabajos de conocimiento tienen un asiento igualitario en la mesa.
La comunicación debe ser lo más clara posible si desea evitar malas interpretaciones, eso no es descortés sino simplemente profesional. ¿Qué pasa con una nota destacada?
This is a rough estimate based on incomplete requirements.
It is intended to support your decision process, but it's not binding
and should not be used in budget or schedule planning.
en su correo electrónico de respuesta? CC a su jefe para que haya un rastro claro de que no se comprometió con un rango de tiempo o presupuesto definitivo.
Una forma de responder a la pregunta es centrarse en los riesgos inherentes al trabajo posterior. En total, para un proyecto muy arriesgado, nunca daría ninguna estimación, sino que sugeriría un estudio previo.
Los factores de riesgo típicos para evaluar y podrían resaltarse en la respuesta podrían ser. A cada una de las declaraciones se le podría dar un número, digamos entre 1 y 5, donde 5 sería de alto riesgo -- suma demasiado alta -> sugiere un estudio previo.
chris h
Mazura