¿Cómo debo proceder si sospecho que un proyecto está muy sobreestimado? [cerrado]

Prácticamente todo lo relacionado con el núcleo comercial de la empresa para la que trabajo se basa en la generación secuencial de algunos números de artículos. Desafortunadamente, hace mucho tiempo estos números de artículos se definieron como un punto fijo sin decimales y se están quedando sin números posibles.

Por supuesto, algunos departamentos fueron lo suficientemente inteligentes como para definirlos como números enteros de al menos 32 bits y pueden adaptarse fácilmente al aumento.

Actualmente estoy trabajando para varias aplicaciones satelitales de almacenamiento de datos y sé que el almacenamiento de datos en sí debe adaptarse al cambio. Se pidió a los desarrolladores de almacenes de datos que estimaran el cambio y proporcionaron un gran esfuerzo (alrededor de 800 días-persona). Esta información se proporciona dentro de una plataforma interna junto con las estimaciones para todas las unidades de negocio involucradas.

Después de haber trabajado en una aplicación para proporcionar pruebas automáticas para el almacenamiento de datos, sé lo que deben cambiar (por ejemplo, descartar índices, estadísticas, alterar la columna, recrear índices, recrear estadísticas, actualizar algunos metadatos propietarios para todas las tablas involucradas, verificar y cambiar la precisión de las tablas temporales) en algunos scripts, probar que todo sigue funcionando, etc.) y creo que su estimación de esfuerzo es muy grande.

Para responder algunos problemas en comentarios/respuestas existentes: puedo respaldar esto con datos como la cantidad de tablas afectadas, la cantidad de archivos de metadatos afectados, ya que soy consciente de que sin esto no tiene sentido discutir este problema.

Además, había un correo electrónico que explicaba el motivo del esfuerzo, ya que uno de los propietarios del producto también se preguntaba al respecto. El esfuerzo es principalmente proporcional al número de objetos afectados (tablas e informes) y no contiene ninguna referencia a componentes oscuros o una gran reserva para lo "desconocido".

¿Por qué eso importa?

Dado que pertenecemos a la misma unidad de negocio y su presupuesto es limitado, si se aprueba este esfuerzo, nuestro equipo recibirá un pequeño presupuesto para el próximo ejercicio. Esto es importante ya que estamos luchando por tener un miembro adicional para cubrir la carga de trabajo.

Solo dos personas con las que puedo hablar vienen a mi mente:

  • gerente de personas: muy poco conectado con las personas del almacén de datos y también muy ocupado
  • el propietario del producto de uno de los proyectos en los que estamos trabajando: tengo una muy buena relación con él, pero también es gerente de personas para algunas de las personas involucradas en la estimación, por lo que parece un "conflicto de intereses"

Pregunta: ¿Cómo debo proceder si sospecho que un proyecto está muy sobreestimado? (y esto me afecta a mí y a mi equipo)

solo para aclarar el bit de 800 días-persona: ¿dijeron que el cambio en el sistema requerirá que 3 personas trabajen a tiempo completo durante 3 años? tal vez fue un error tipográfico?
@Alex: sí, esta es generalmente una buena opción. Sin embargo, existe una colaboración deficiente entre nuestro equipo y los estimadores. Simplemente han ignorado todas nuestras preocupaciones pasadas y simplemente no están interesados ​​en discutir estos temas con nosotros. Un gran esfuerzo es muy conveniente para ellos ya que el tiempo/presupuesto puede usarse para justificar el retraso de otros proyectos.
@viorel: no, no hay error tipográfico, ya que el esfuerzo también va acompañado del costo estimado y pude verificarlo dos veces. Sí, es por eso que mencioné "groseramente estimado". Una parte del esfuerzo puede justificarse por la cantidad de objetos afectados, ya que los elementos son una dimensión utilizada por muchas tablas de hechos y por la falta de automatización de pruebas para los informes. Aun así, el esfuerzo es enorme.
¿Realmente ha trabajado con este código base específico o está evaluando en función de algún otro sistema? ¿Está al tanto de toda la deuda técnica que puede verse afectada por este cambio más allá del trabajo que describió? Tenga cuidado de no contradecir la estimación de otra persona si no tiene conocimientos específicos.
@cdkMoose: el código base no se ve afectado en este caso. Simplemente tienen que ampliar una columna de dimensión en muchas tablas e informes. Entonces, básicamente hay un DDL muy grande + cambiar algunos scripts que usan tablas temporales + actualizar algunos informes. El DDL se puede construir mediante programación ya que la columna tiene prácticamente el mismo nombre en todas partes. De hecho, existe una gran deuda técnica, pero los scripts que se modificarán también se pueden enumerar automáticamente (aunque su modificación debe hacerse manualmente).
no lo sabes Sospechas.
@paparazzo - sí, tienes razón. He arreglado la pregunta. Pienso como un ingeniero: si estoy seguro al 95% de algo, es lo suficientemente cercano a estar absolutamente seguro.
"¿Cómo debo proceder si sospecho que un proyecto está demasiado sobreestimado?" - con incredulidad. Todos los proyectos desde las pirámides se han subestimado enormemente
No es una respuesta a su pregunta, sino una lección muy importante para el futuro. Si su idioma lo permite, nunca, nunca, nunca use tipos de lenguaje estándar. Si actualmente tiene cientos (¿miles?) de uint8_t itemNumber;(espero que, al menos, no estén firmados), piense en lo fácil que sería cambiar el código si hubiera tenido typedef uint8_t indexNumber_t;. Estarías viendo un enorme cambio de una línea. Demasiado tarde, ahora, lo sé, pero si una sola persona que lee el suyo aprende una lección, entonces mi trabajo aquí está hecho (¿quién era ese hombre enmascarado?)
@Mawg: aquí estamos hablando de SQL, pero también admite tipos personalizados que se basan en los estándar. Lo que dice tiene mucho sentido, aunque algunas bases de datos tienen algunas limitaciones al respecto (tal vez el uso en algunas tablas temporales, el uso en índices, etc.). De todos modos, en nuestro caso, el diseño es realmente extraño: definieron un valor entero como numérico/decimal (x, 0), que es un número de punto fijo con un máximo de x dígitos y sin decimales.

Respuestas (3)

Un par de cosas a considerar, ¿realmente estás mirando el panorama general o solo el que conoces? Usted muy bien puede estar en una posición en la que no sabe lo que no sabe. Lo que significa que puede haber una serie de secuencias de comandos y/o aplicaciones que muy bien podrían necesitar ser reelaboradas. Algunos de estos podrían contener una gran cantidad de deuda tecnológica o simplemente ser "cajas negras", ya que los desarrolladores que lo escribieron ya no están en la empresa y nadie ha tenido que mirarlo antes. Puede ser que ni siquiera sepan lo que no saben y tengan que crear un entorno para probar todo e incluso entonces es posible que no sepan qué se verá afectado. Sin mencionar si hay alguna API orientada al cliente que deba ser versionada y tal vez no tengan una forma de versionar el sistema, por lo que

Podría ser una gran cantidad de cosas, que en este punto parece estar basando todo solo en lo que cree que sabe sobre ese lado del negocio, ¿realmente les ha preguntado por qué va a tomar tanto tiempo?

Sí, tienes un punto válido aquí. También se envió un correo electrónico para justificar el esfuerzo, agregaré la información en la pregunta.

y creo que su estimación de esfuerzo es muy grande.

¿Puede respaldar esto de alguna manera con hechos y datos?

¿Cómo debo proceder si sé que un proyecto está muy sobreestimado?

Si puede respaldar esto de manera objetiva, con datos, entonces lleve su reclamo a su gerente . Dependerá de ellos qué hacer con la información que proporcione. También puede considerar cuál podría ser su solución.

Asegúrese de que puede respaldar su reclamo .

Permítanme comenzar con que generalmente soy el tipo que proporciona las estimaciones para proyectos como estos a personas como usted, e incluso cuestiono la validez de una estimación de 800 horas, pero no voy tan lejos como para acusarlo de ser groseramente sobreestimado bastante todavía. Hay bastantes cosas que pueden hacer que un cambio aparentemente simple como este tome mucho más tiempo y sea mucho más complicado de lo que parece inicialmente (por ejemplo, el tamaño del conjunto de datos, las limitaciones/deficiencias del diseño actual, el conocimiento técnico, las limitaciones tecnológicas, etc.).

Pregunta: ¿Cómo debo proceder si sé que un proyecto está muy sobreestimado? (y esto me afecta a mí y a mi equipo)

Honestamente, creo que está absolutamente permitido pedir un desglose del trabajo. En realidad, puede encontrar otras tareas que necesita acomodar en su proyecto que aún no se habían pensado o planeado, y debe mencionar que esta es la razón por la que necesita más detalles. Las personas odian ser objetivos, pero les encanta contribuir a una solución y sentir que están ayudando.

En realidad son 800 días. 8-9 años de trabajo para una sola persona. Me encantaría ver el desglose de eso.
¡Decir ah! Supongo que ahora soy realmente sospechoso, pero tal vez la persona que proporciona el presupuesto se refiere a días calendario en lugar de días laborales. Sin embargo, mi enfoque es el mismo, ya que debería ayudar a todos a acercarse a un alcance y una estimación final más realistas.
¿Cómo debo proceder si sospecho que un proyecto está muy sobreestimado? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v