Hace dos meses, me uní a una empresa de desarrollo de software. Me acaban de asignar mi primera gran tarea que consiste en revisar todo el front-end de una de nuestras aplicaciones Rails. El proyecto aún está en el departamento de diseño, pero pronto comenzaré a trabajar en él.
El problema es que la gerencia me preguntó el típico "cuándo vas a terminar". La verdad es que no tengo ni idea. Escribir HTML y CSS no es realmente complicado, pero los controladores son un desastre y espero descubrir muchos problemas.
En estos dos meses, he visto a muchos compañeros durmiendo debajo del escritorio, esto es Japón, y esto es algo que obviamente no voy a aceptar, por lo que quiero dejar claros los riesgos incluso antes de comenzar.
Esto es lo que pensé que escribiré una vez que tenga el diseño definitivo:
Project: Redesign of X app.
Scope of the project:
- Write all the templates of the new design using HAML language: X lines of
code affected.
- Write all the new stylesheets using X framework: X lines of code
affected.
- Refactor controllers and correct possible inconsistencies: X lines of
code possibly affected.
Description of tasks:
- Page 1: x hours est.
- Page 2: x hours est.
- Page 3: x hours est.
- Component 1: x hours est.
...
Total estimation of project duration: XXX hours.
Risks:
- This is the first time that we replace all the front end of the
application. All the estimations have been done without having a
real example to compare, but when we added Page5 and Page6 in the
Issue #xxxx, took x hours work. This is the metric I am using to predict
the duration of the tasks.
- I have detected some issues in the controllers' code that will necessarily
have to be addressed while performing this project. Other unknown issues
are expected to arise.
For this reason, I predict _high probability of deviations_ on the original
estimation that I think should be taken into account.
Aparte de la gramática horrible (siéntase libre de editar), ¿hay algún otro punto que deba agregarse a este documento?
Además, este texto acaba de salir de mi cabeza, pero estoy seguro de que hay metodologías que ya se están utilizando en otras empresas. ¿Existe una forma estándar de comunicar las estimaciones?
Retrocedería unos pasos.
Se le pregunta cuándo se puede completar el proyecto. Es una pregunta válida, pero responder con horas específicas volverá a morderte. Da la vuelta a la pregunta. Hágales saber el alcance de lo que debe cambiar y pregúnteles cuánto tiempo tomó la última interfaz. Si es probable que no tengan una respuesta, pregunte qué métricas existen para que las aproveche: registros de tiempo dedicado, etc. Después de todo, no se trata de qué tan rápido puede escribir. Es lo rápido que puede obtener una comprensión clara, la cooperación con los materiales, etc. si no saben cómo y no pueden calcular cuánto tiempo llevó construir el último, ¿cómo puede saber cuánto tiempo tomará el próximo? ¡Una es especulación y la otra es un hecho!
El número real será mucho mayor que sus expectativas. Nadie quiere aquí "6 meses" por algo que se siente como 3 meses. Pero si tomó 6 la última vez y es descuidado, ¿por qué no debería tomar más tiempo esta vez?
Probablemente sabrán las fechas de inicio y finalización. Agregue 20-40% según su nivel de comodidad. Ahora las expectativas están puestas y sus derivaciones son claras. Supera esa expectativa si puedes.
En esta situación, delinearía el trabajo a realizar, pero no estimaría un plazo. Pediría un tiempo para tener una idea real de lo que se necesita antes de estimar. Porque en realidad no lo sabes todavía.
Si me presionan, iría con el mayor margen que razonablemente podría estimar y diría que debería estar hecho para entonces y que puede hacerse más rápido. No iría a buscar puntos medios todavía.
aroth
keshlam
nvoigt
Daniel
Lilienthal
Daniel
Mónica Celio
Daniel