En resumidas cuentas, mi gerente me tiene trabajando en un proyecto que tiene la escala de tiempo más limitada que jamás haya visto. El cronograma fue dado por el cliente, no determinado por el proyecto.
Quiere una aplicación de nivel empresarial completa en menos de 3 meses que pueda albergar a más de 10 000 usuarios. Soy el único desarrollador que trabaja en ello y, aunque me acerqué a mi gerente para pedirle ayuda, no se mostró receptivo. Le he dicho varias veces que no creo que pueda cumplir con la fecha límite y su respuesta a esto ha sido cortar todos los rincones posibles que pueda. He escrito 0 pruebas y gran parte, si no la mayoría, de las entradas de los usuarios no se someten a ninguna validación. Sinceramente, estoy escribiendo código tan rápido que tampoco tengo mucho tiempo para pensar en la arquitectura.
Ha declarado que la empresa para la que estamos construyendo el programa tiene una demostración programada con su junta directiva y que la fecha límite no puede extenderse en absoluto y debe cumplirse. Estoy increíblemente nervioso porque estoy escribiendo un código que está introduciendo errores a largo plazo que serán difíciles de rastrear y corregir. Decir esto es poner mucha preocupación en mi lugar en la empresa es subestimarlo.
He leído muchas preguntas sobre cómo el incumplimiento de los plazos es muy común en la industria del software y me preguntaba cómo hacen otros desarrolladores para preparar a alguien superior a ellos para esas noticias sin ser despedidos, especialmente si esa persona no es una persona técnica. ?
Haga que la preocupación sea de su gerente, no suya.
"El cronograma fue dado por el cliente, no determinado por el proyecto" es una tontería total. Tú (o, más exactamente, la empresa para la que trabajas) aceptaste esa fecha límite, así que asegúrate de que no seas tú personalmente quien se haga cargo de un requisito tan ridículo.
Cúbrase el trasero, hágalo por escrito y ciertamente no acepte "simplemente corte todas las esquinas que pueda" como una base razonable para trabajar. Por el momento, líneas como esta:
Ha declarado que la empresa para la que estamos construyendo el programa tiene una demostración programada con su junta directiva y que la fecha límite no puede extenderse en absoluto y debe cumplirse.
... están haciendo del problema su problema. Impúlselo, pero diga específicamente lo que puede y no puede hacer (en lugar de simplemente decir "No puedo hacerlo, es demasiado trabajo"). En su lugar, diga algo como:
Dibujé una línea de tiempo y creo que puedo cubrir
xla funcionalidad en la cantidad de horas que tenemos disponibles; pero ciertamente no se probará a fondo y no se escalará a más de un puñado de usuarios. Alternativamente, puedo cubrir (subconjunto dex) y tenerlo mucho más probado y listo para la producción. ¿Cual te gustaria?
Si su jefe todavía dice "Me temo que necesitamos que todo esté listo", simplemente diga algo como:
Me temo que simplemente no puedo hacer eso dada la escala de tiempo. Estaría feliz de trabajar con más desarrolladores / evaluadores para lograr un mejor progreso, o tomaría en cuenta cualquier consejo en términos de eliminar funcionalidades adicionales.
Si sigue así, prepárese para compartir cualquier cronograma o desglose de las estimaciones que haya realizado y solicite específicamente un cronograma revisado. Continúe con la cadena de correo electrónico hasta que sienta que tiene suficiente rastro de papel detrás de usted para que, si todo explota, pueda CYA de manera directa y sólida.
La clave aquí es el intercambio constante de información y actualizaciones de progreso constantes para el administrador; si es necesario, actualizaciones todos los días sobre el progreso actual y también actualizaciones cada vez que termina una tarea y comienza otra.
¿Tiene un probador dedicado? Si no, pídale que haga las pruebas; dígale que la mejor práctica es que el desarrollador no pruebe su propio trabajo. Como mínimo, esto lo mantendrá al tanto del progreso actual y verá con sus propios ojos lo que funciona y lo que no. Si es necesario, puede decirle que le permite familiarizarse con todas las facetas de la aplicación antes de que se la demuestre al cliente.
Cuando llegan solicitudes de nuevas funciones, debe sentarse con él y analizar lo que puede hacer. Dígale cuánto tiempo llevará y pregúntele qué prioridad tiene cada característica y qué características deben retrasarse para lograr el cambio.
Si trabaja en este campo el tiempo suficiente, se encontrará con estas situaciones. Un libro que habla de esto es "Death March" de Edward Youdan. Está disponible en Amazon.
Documente todo por escrito. Si su gerente le dice algo verbalmente, responda con un correo electrónico que refleje la aclaración.
Debe tener una discusión con su gerente sobre lo que significa 'éxito' en este proyecto. Si el objetivo es tener un prototipo para la reunión de la junta, eso es lo que ofrece. Si se trata de un sistema terminado completo, debe especificar el uso de la matriz de tiempo, costo, rendimiento y pedirle que elija dos (en su caso, suena como tiempo y costo).
Cygnus oscuro