Y colorin colorado este cuento se ha terminado en cuanto te dicen ó haces esto asi ó a la calle. Las bajadas de pantalones son epicas.

@@antonpirulero2836 Cuando uno se baja los pantalones como dices, al final más tarde o más temprano surgen los problemas. ¿Y quién crees que acaba tragando con la responsabilidad? ¿La empresa? ¿El manager? No. Todos los dedos acaban apuntando al programador. Y en esos casos las excusas tipo "es que me metieron prisa" no valen nada. Quien es capaz de plantarse para defender un trabajo bien hecho, al final se ahorra mayores problemas futuros, tanto para uno mismo como para el resto de la industria. Obligar a abandonar las buenas prácticas es un insulto a la profesionalidad. Y si lo que toca es cambiar de empresa, pues se hace. Por fortuna, no es un sector en el que haya escasez de demanda. El cambiar de empresa cada pocos años es algo que incluso se recomienda. No te vas a la calle, te vas a la competencia.

Gracias bro

No, lo que dices no sirve en la realidad y tiene muchas fallas. Si el manager te pide una fecha, es porque le has dado tres fechas seguramente muy separadas que demuestra demasiada incertidumbre por la falta de análisis previo. Ese análisis se realiza mediante 1) definición clara del alcance, 2) desglose de las pequeñas tareas individuales requeridas, 3) estimación del esfuerzo de esas tareas y repartición en el equipo existente, 4) unión de todas esas estimaciones de tareas, teniendo en cuenta el solapamiento por tareas hechas en paralelo por distintos miembros del equipo, y 5) obtención de la ruta crítica que da el tiempo estimado de la tarea. Luego de esa primera estimación base, se deben identificar los posibles riesgos, sus causas y consecuencias, estimar su probabilidad e impacto para obtener la exposición al riesgo y poder priorizarlos, y a los riesgos con mayor exposición obtener posibles medidas de mitigación (en base a las causas del riesgo) y PLANES DE CONTINGENCIA (en base a las consecuencias del riesgo). Cada uno de esos planes de contingencia tiene un trabajo asociado que se lo debe estimar de la misma manera que la de la estimación base. La estimación base es el "mejor escenario", y la estimación base más el tiempo de los planes de contingencia de los tres riesgos con mayor exposición es el "peor escenario". NOTA: Si aún así el manager en un p3ndejo y presiona para que le den una fecha concreta, que seguramente luego la santificará como el deadline inamovible, hay que darle la estimación del peor escenario MULTIPLICADO POR DOS

@@IngeGallito Estoy de acuerdo con el elaborado proceso que indicas, aunque me parece también muy teórico. De todos modos, a lo que me refería yo es que los managers odian la incertidumbre. Y es normal, puesto que a mayor incertidumbre, mayor dificultad tienen para hacer su trabajo: gestionar recursos. Por ello, es responsabilidad del desarrollador (o desarrolladores) intentar reducir y acotar la incertidumbre lo más posible, en base a la experiencia previa y al análisis que describes. Pero por mucho que se intente reducir, siempre habrá algo de incertidumbre. El problema surge cuando el manager de turno es o muy incompetente, o muy vago para lidiar con cualquier incertidumbre (cosa bastante frecuente por desgracia, hay muchísima gente en puestos de gestión que no tiene ni idea de gestionar). Y que, aprovechándose de su posición de poder, exige certeza absoluta (o interpreta lo que se le dice como si lo fuera, que para el caso es lo mismo). Gente que no comprende que las estimaciones son eso, estimaciones, y no compromisos. Pero, cuando surgen los problemas (retrasos, bugs por falta de tests completos, malos diseños que dificultan mantenimientos futuros...), los dedos acusadores siempre acaban apuntando al que desarrolla, mientras que el manager se lava las manos. Ojo, no siempre pasa esto. Hay por ahí managers altísimamente capaces que hacen muy bien su trabajo. Pero por desgracia, también existe el otro extremo. Edit: Releyendo tu comentario, he visto que he olvidado comentar una cosa: Si, es cierto que puede darse el caso de que los rangos de fechas no le valgan a un buen manager por ser demasiado amplios. Ahí entran la experiencia, el conocimiento y los recursos dedicados al análisis. Todo lo que he dicho aplica suponiendo que las estimaciones se han hecho correctamente, y que se ha reducido la incertidumbre lo más posible. Si la estimación se ha hecho como se debe y es lo más correcta que se puede, no hay que cambiarla porque otro no pueda/sepa gestionar.

Muchas gracias🙌🙌🙌🙌

y al cuadrado

Todo depende del endpoint 😂😂

Gracias por comentar!

Con mucho gusto!!

En mi caso he tenido varios clientes asi, he tomado desarrollo que ha estimado otro, trabajo en software factory , y siempre que me pasa esto... les digo lo mismo. Lo podemos hacer rapido mal, que aparentemente funcione... y lo podemos hacer lento bien... y que funcione , ahora de las dos opciones la primera te sale mas barata... pero los bug te van a salir claro... y la segunda te sale mas cara y los bugs mas baratos... Casi siempre eligen la primera.... y despues yo mismo despues de varios meses de desarrollo... de parches... etc.. Les digo.. se acuerdan que se los dije.. bueno ahora hay que hacer la opcion dos... Hay una estadistica que es que mas del 75% de los proyectos de software fracasan... y no salen a produccion. y es por esto mismo... pq kieren software rapido , escalable, robustos aahhh pero 3 meses... ,, siempre te ponen de ejemplo empresas como amazon, google, whatsapp... Pero Les digo kieren app como whatsapp facebook pero no kieren hacer las cosas que hacen whatsapp facebook. google para hacer esas aplicaciones robustas

@@johanhimelymendoza4880 esta respuesta siento que soy yo, toda mi vida. Es increible que aun tras los golpes, la gente insista en hacerlo mal y no confiar en los especialistas que los contratas justo para que eviten que te vaya mal. Pero no. Ni caso. Una 'startap' va de hacer todo corriendo y reir aunque todo sea una sh*t. :) Si dices algo, eres un amargado, o estás deprimido o 'no sabes trabajar en un ambiente startup', o mil cosas más que me han dicho XD

Yo de quimica no vi nada, pero de fisica si había una asignatura obligatoria y otra optativa (la optativa era para temas de programacion con qubits, cuantica etc)

@@BettaTech Muchas gracias! 😋

Este video trata de estimaciones de proyectos mas grandes, no esta enfocado al uso de agile (no siempre se usa agile). De hecho tengo otro video también de estimaciones enfocado a historias de usuario y puntos de esfuerzo!

@@BettaTech Gracias por tu respuesta.