Trabajo para una agencia de desarrollo web y recientemente asumimos un proyecto heredado para un nuevo cliente que desea implementar cambios en su sitio. El conjunto actual de cambios en los que estoy trabajando es bastante grande y el marco es uno en el que ni yo ni ninguno de mis colegas tenemos experiencia previa. El código está terriblemente mal administrado y el marco es difícil en el mejor de los casos.
Estoy en un nivel medio y trabajo en un equipo de mantenimiento, aunque la naturaleza de estos cambios es significativamente diferente a cualquier cosa anterior. La gerencia me pidió hace unas semanas que estimara estos cambios y dijo que los necesitaban rápidamente y que tenían poco o ningún tiempo para analizar el código base. Miré a través de los diseños y estimé las obras en la cara de ellos. Tras un examen más detenido, resultó que el trabajo y el proyecto en general son mucho más complejos. Estos trabajos no solo llevarán más tiempo, ni siquiera estoy seguro de poder completarlos en un tiempo razonable en este momento.
Aquí está el pateador. Después de mis estimaciones originales, la gerencia me pidió que redujera la grasa y redujera aún más el tiempo de desarrollo, con poco tiempo para analizar la base de código del proyecto. Comencé a trabajar esta semana y me di cuenta de que es probable que sea imposible dentro de los plazos actuales, sin embargo, me han dicho que cumpla con los plazos acordados.
Generalmente disfruto de mi trabajo y los proyectos en los que trabajo, sin embargo, este vino directamente de la alta gerencia sin casi ninguna consultoría de desarrolladores antes de mí, y aunque es raro, es una situación en la que me he encontrado antes. ¿Cómo puedo manejar esta situación?
Como ya proporcionó una estimación, en el futuro, triplique sus estimaciones. Mi regla general cuando brindo estimaciones sobre software en el que nunca he trabajado antes, ni estoy familiarizado con las tecnologías utilizadas, es tomar cualquier corazonada inicial y triplicarla. Esto me ha salvado el pellejo muchas veces a lo largo de los años, y ahora es una buena práctica por la que vivo.
Dicho esto, dado que ya proporcionó un número, su primer trabajo es restablecer las expectativas ahora que ha profundizado un poco más. Está bien volver a los jefes y decirles que va a llevar mucho más tiempo, no les va a gustar dado que ya ha proporcionado un número, así que prepárese para montar una defensa sólida.
También debe trabajar con los jefes y ver si puede subdividir el trabajo en fases, y obtener su Producto Mínimo Viable (MVP) inicialmente, luego trabajar en funciones adicionales después 1 . Una vez tuve un proyecto muy grande que era abrumador, y una vez que el proyecto se dividió en 3 fases distintas, se volvió mucho más fácil de administrar.
Además, si no está familiarizado con las tecnologías utilizadas, haría bien en ver si puede encontrar un consultor experto y luego obtener algunas horas de ellos para comenzar bien, al menos diciéndole las piezas móviles. y conectar algunos puntos para usted. Puede pasar días investigando/aprendiendo, o pasar algunas horas de tiempo para obtener una manguera contra incendios de información que le permitirá comenzar a trabajar.
Lo más importante para lidiar con situaciones como esta es la comunicación , no entre en una caja y salga a tomar aire una semana antes de la fecha límite y luego diga que necesita dos meses más. Eso solo se reflejará mal en ti . Debe proporcionar actualizaciones a la empresa/su gerente con regularidad, incluso hasta el punto de presentarles el trabajo y preguntarles si esto cumple con sus expectativas, luego tomar sus comentarios e implementarlos nuevamente en el producto para la próxima ronda de desarrollo. Este es el plan básico de desarrollo iterativo utilizando el desarrollo de software Agile. La clave en este proceso es que constantemente muestra cuál es el progreso, por lo que cuando se acerca la fecha límite, nadie puede sorprenderse si falta mucho en el producto.
1: Un Producto Mínimo Viable es el subconjunto de funciones que se requiere mínimamente para que los usuarios finales puedan usar la aplicación para lograr sus objetivos básicos. Un ejemplo podría ser el transporte: podrías comenzar con una patineta como tu primer MVP, ya que te llevará a donde vas. Luego, lo convertirá en un scooter para que sea más fácil de manejar. Luego agrega funciones hasta que tiene una bicicleta que lo ayuda a aplicar más potencia. Luego, agrega funciones para hacer una motocicleta y, finalmente, trabaja para convertir el producto en un automóvil. Dependiendo de los requisitos exactos, puede ser que el scooter sea en realidad el MVP, pero en cualquier caso, hay algún subconjunto de la lista total de características que será suficiente para poner el producto en manos de los usuarios finales, para comenzar a recopilar retroalimentación para el resto del desarrollo.
Habiendo trabajado para una agencia de desarrollo web, sé exactamente lo que quiere decir y tuve que aprender rápidamente después de tener exactamente el mismo problema. Los gerentes de cuentas les piden presupuestos y luego los regatean.
En la situación en la que te encuentras ahora mismo, diría que cuanto antes plantees esto, mejor. Explíqueles sus inquietudes, lo que ha aprendido y por qué sucedió. Si resalta el problema en lugar de señalar con el dedo, esto lo pondrá a usted y al equipo en un buen camino para evitar que esto vuelva a suceder. Cuanto antes mencione algo, mejor será para usted y el equipo involucrado.
Intente obtener algo de tiempo para investigar y aprender sobre las tecnologías o tal vez buscar a alguien que lo sepa como referencia o para ayudar a trabajar en él.
Aquí hay algunas cosas que aprendí al dar estimaciones en un entorno similar al que estás describiendo:
Eres de nivel medio, por lo que es probable que tu opinión sea respetada y tenga algo de seriedad detrás. Por lo tanto, cuando se le pida un presupuesto rápidamente, simplemente exprese que necesita tiempo para evaluar el trabajo para dar un presupuesto más preciso. Incluso si lo presionan, advierta que es probable que sea inexacto si lo apuran. Esto luego les pone la responsabilidad a ellos, ya que les diste una advertencia si algo sale mal.
Las advertencias son el rey. Siempre tenga cuidado si no está seguro. Por ejemplo, "tomará 2 días si 'X', 'Y' y 'Z' se proporcionan y se documentan claramente" o especifica que es una base de código heredada y viene con sus complejidades, etc. "2 días siempre que conozcamos las tecnologías, si no tardará más" cosas así. Esto hace que la persona que pregunta se dé cuenta de que depende de que no haya complejidades que no haya tenido la oportunidad de considerar mientras lo apuran.
Sobreestimado, 5 por lo menos 20% de espacio para respirar como mínimo (más si no sabe en qué se está metiendo) de esa manera, si algo sale mal, tiene algo de relleno por si acaso. También tienes algo de tiempo para devolver en caso de que te pidan que lo quites y puedas permitírtelo.
Comunicar. Exprese sus inquietudes, reservas y vacilaciones. No querrán ir al cliente y decirle que va a costar más o que llevará más tiempo. Dígales constantemente a ellos y al cliente lo que está haciendo y cualquier problema que haya, con suerte ya lo está haciendo en una reunión diaria de todos modos.
Si los plazos no son alcanzables y su estimación no fue correcta, debe comunicarlo lo antes posible. Puede haber otras formas de mitigar esto de las que no eres consciente y dejar que se reduzca hasta el último minuto ciertamente no es una buena idea.
Sobre querer dejar de fumar: nunca dejes de fumar al primer impulso, pon un cronómetro y observa si al cabo de 30/60/90 días persisten las mismas circunstancias que te hicieron querer dejar de fumar. Especialmente dada esta situación, la forma en que la empresa lo maneje será una muy buena señal de si es un lugar en el que desea continuar trabajando o no.
Y para el futuro, practique #noestimateso mejore mucho en la estimación, el descubrimiento de riesgos, la venta de compensaciones y la instalación de amortiguadores dentro de sus estimaciones para evitar que algo así vuelva a suceder. Algo de eso se puede aprender de los libros, pero mucho se reduce a la experiencia (como este).
erik
Lilienthal