La pregunta que debe hacerse es cómo sabe el vendedor que la función le costará a x días de trabajo. Dado que incluso los buenos gerentes de proyectos con años de experiencia profesional no pueden decirlo con frecuencia, tales datos provenientes de un vendedor parecen extremadamente ... especulativos .
Según mi experiencia, los vendedores generalmente no hacen estimaciones, pero adivina cuánto es demasiado para la administración o para el cliente: si la administración está lista para pagar 50 semanas de trabajo, pero rechazará absolutamente 75 semanas hombre, digamos que la función tomará 70 semanas hombre mientras esté listo para renegociar (algo que está fuera de discusión para una estimación real) hasta 55 semanas hombre.
-
Por un lado, tienes estimaciones hechas por expertos de TI que dicen algo como:
Según esta auditoría específica, estamos desperdiciando $ 8 000 por día usando una tecnología obsoleta en comparación con proyectos similares de tamaño similar que utilizan tecnologías más nuevas. También parece que tomará de 50 a 80 semanas-hombre para migrar todo el código base; Durante este tiempo, no habría nuevas características lanzadas. También existe un riesgo del 10% de que la migración de un componente específico resulte en 20-30 semanas de trabajo adicionales.
-
Por otra parte, tiene suposiciones hechas por vendedores, en función de su influencia al negociar con la persona que necesitan para convencer.
Se trata de cuán influyente eres en tu empresa. La comunicación es clave aquí, y aquí es donde los vendedores generalmente se ganan a los profesionales de TI cuando se trata de explicar los beneficios de una característica a la administración (o un cliente).
Tenga en cuenta que si en el pasado sus estimaciones fueron bastante precisas, ganará reputación e influencia. Si sus estimaciones fueran siempre erróneas, la administración probablemente ignoraría sus propuestas.
En cuanto a las estimaciones, es extremadamente difícil hacer una valiosa aquí, ya que hay una gran cantidad de parámetros a tener en cuenta. Entre otros:
-
¿Sabe realmente cuán hábil es su equipo en C # en comparación con VB6? ¿Se basa en mediciones reales o solo en suposiciones?
-
¿Este equipo ha desarrollado grandes proyectos en C #? ¿Conocen las herramientas que deben usar (IDE, depuradores, perfiladores, etc.)? ¿Necesita licencias adicionales (que, en el mundo de Microsoft, significan miles de dólares por máquina)?
-
¿El proyecto actual es totalmente claro y puede garantizar que no habrá sorpresas al migrar? ¿Es sencillo reescribir todo , cada característica, o habrá sorpresas?
-
¿Tiene la infraestructura que admite C #? ¿Qué pasa con la integración continua? ¿Qué pasa con su servidor de compilación? ¿Guías de estilo? ¿Damas estáticas?
-
En producción, ¿los servidores (si se trata de una aplicación web) o las PC de los clientes (si se trata de una aplicación de escritorio) pueden ejecutar la versión de .NET Framework que esperan usar?
Pero lo más importante es saber por qué , ¿quieres reescribir todo? ¿Cuál es el problema que está tratando de resolver a través de una reescritura? ¿Una pérdida de productividad? ¿Como lo mides? ¿Cómo muestra esta pérdida de productividad a la gerencia?
Una vez que haya demostrado que está desperdiciando, digamos, $ 8 000 por día debido al VB6 (lo que significa que ahorrará $ 8 000 por día una vez que migre a C #), ¿cómo explica el beneficio de tener cada nuevo? ¿Desarrollo de características y enfoque en una reescritura completa? ¿Cuál es el beneficio en comparación con la reescritura progresiva en la que migra sus componentes en trozos pequeños uno por uno, mientras envía nuevas funciones?