Los plazos en sí mismos no son algo malo, incluso diría, en algún lugar bueno. Personalmente, mi trabajo resulta ser más productivo si me concentro mentalmente en algún marco de tiempo, y cuando un proyecto no tiene ningún marco de tiempo, en última instancia puede perjudicarlo. Lo principal aquí es pensar de manera realista y mantener el equilibrio.
El plazo debe estar justificado. “Porque porque” no es justificación. Esta es una mala práctica de establecimiento de tiempos que afecta tanto a las empresas como a los desarrolladores. Tuve la suerte de que la mayoría de las empresas para las que trabajaba no tenían la costumbre de elegir fechas límite. Pero ha habido excepciones. Quiero hablar de una situación de este tipo como ejemplo en este artículo.
En ese entonces trabajaba en una startup; Nuestro equipo de front-end estaba formado por tres personas y también había un equipo de back-end del mismo tamaño. Estábamos trabajando en una versión actualizada de la aplicación móvil y teníamos que cumplir con el lanzamiento antes de un día claramente marcado. Un problema: este día fue elegido arbitrariamente por un simple director o por un técnico sin ningún motivo para tal decisión.
Bueno, es decir, no del todo sin justificación: al elegir un día, se tuvo en cuenta la duración aproximada del trabajo declarado por los desarrolladores. Si trabaja con código o con las personas que lo escriben, probablemente ya comprenda cuál es el problema. Las fechas aproximadas son siempre aproximadas, es decir, son muy distintas de lo que realmente sale. Y no se trata de la incompetencia de los desarrolladores, es increíblemente difícil estimar la cantidad de trabajo en un proyecto completo. Hay muchas cosas que pueden cambiar los plazos y que son imposibles de predecir.
De una forma u otra, nuestra estimación aproximada fue el resultado de reuniones de dos días: primero, una descripción general de las nuevas funciones, luego un análisis detallado de cada una por separado, luego un análisis aún más detallado ... Finalmente, para cada etapa del trabajo , estimamos la cantidad de horas, volvimos a verificar, correlacionamos con el diseño de UX y UI, juntaron todo, pusieron algunas horas en la parte superior, y esa fue la fecha límite para el trabajo.
Probablemente ahora esté pensando: bueno, dado que sus diseños de UX y UI ya están listos, y aún más horas están reservadas, entonces, probablemente, ¿todo debería ir bien? En la mayoría de los casos, las condiciones son peores al establecer las fechas. Bueno, en general, no. Nada salió bien.
La duración del trabajo se fijó en tres o cuatro semanas, no demasiado tiempo si hablamos del lanzamiento de un nuevo producto con un equipo pequeño. Por supuesto, después de las dos primeras semanas, ya estábamos retrasados. No porque trabajaron despacio o dedicaron pocas horas al proyecto, sino porque todo siempre sale mal.
El backend estaba estudiando detenidamente la implementación de la API para la aplicación, cuando de repente resultó que el sistema no podía interactuar normalmente con un simple complemento, lo que significa que era necesario reescribir el fragmento de API ya preparado tomando esta circunstancia en cuenta. Se necesitaron dos días no programados para finalizar el punto final.
Debido a este pequeño cambio, la API comenzó a funcionar de manera un poco diferente de lo que se pretendía en la etapa de discusión, lo que llevó a la necesidad de reescribir partes individuales de la aplicación, un trabajo de varias horas. Reescribir como esta es común en aplicaciones móviles de todos los tamaños y no debería sorprender a nadie. Pero tenemos una fecha límite ajustada. Y ahora no podemos encajar.
¿Entonces que puedes hacer? Al día siguiente, nos dijeron que teníamos que trabajar cuatro horas más para volver a salir adelante. Cuatro horas además de una jornada laboral típica de ocho horas. Bueno, sí, nos alimentaron, por supuesto, pero no hay nada útil para el cerebro en turnos de doce horas y no puede serlo. Sin embargo, logramos ponernos al día y mantenernos al día con el calendario.
Una semana después, se lanzó la aplicación. Nos alegramos, alguien trajo unos cupcakes para celebrar, y cinco minutos después ya todos estaban sentados en los monitores y fingiendo que no había pasado nada.
No había nada tan importante en la actualización que motivara la necesidad de un lanzamiento en esta fecha en particular y no un día después. Ninguno de los usuarios sabía que se estaba preparando una nueva versión, nadie (ni clientes ni inversores) hizo planes en base a una fecha. Sí, las funciones son útiles, pero ¿alguien se sentiría peor si se lanzaran un día después? ¿Afectaría a alguien en absoluto?
Pero los desarrolladores afectados. Aquí y allá, la gente se contagiaba su disgusto; la relación entre el equipo y la dirección estaba claramente estropeada. Y este no es un caso aislado, esto sucedió a menudo mientras trabajaba allí, con una frecuencia de aproximadamente una vez cada varios meses.
¿Y cuál es la conclusión de todo esto? ¿Renunciar por completo en cualquier momento? Bueno, por supuesto que no. Como se mencionó al principio del artículo, los plazos son realmente útiles y yo mismo encuentro más fácil trabajar con ellos. Pero deben tomarse como directrices, no como compromisos rígidos. Si el producto sale un par de días después, no debería considerarse el fin del mundo. ¿Cuál es el punto de presionar innecesariamente a los desarrolladores? ¿O cree que la calidad del código no se ve afectada por tales marchas?
Cuando entrenamos horas adicionales después de un día de trabajo a última hora de la noche bajo el lema de fuerza mayor, el estado de ánimo general era: "Entonces, tenemos que terminarlo lo antes posible". A menudo, se introdujeron todo tipo de soluciones de muleta que funcionarían durante un tiempo y luego requerirían refactorización. En algunos casos, la refactorización correspondiente se programó de inmediato, en otros se olvidó de manera segura. Y sucedió que los propios desarrolladores no se dieron cuenta realmente de que estaban haciendo algo de muleta, porque estaban cansados y querían irse a casa.
Cuando se trata de refactorización (de dónde vino), probablemente sea más un recurso que la fuerza mayor en sí. Los errores comenzaron a aparecer en fragmentos de código escritos a toda prisa. Dado que la aplicación ya había sido lanzada, puso de los nervios a todos especialmente.
Según mis estimaciones (no recopilé estadísticas, por lo que no puedo responder), este procesamiento fue útil solo a corto plazo. Bueno, sí, lanzamos la aplicación a tiempo. Y el próximo lanzamiento ya tuvo que retrasarse, porque se estaba reescribiendo mucho. Los desarrolladores no estaban contentos (y, lo adivinaste, estaban renunciando activamente), la atmósfera en el equipo se volvió tensa. Y todavía no tenemos en cuenta las consecuencias de los errores que los usuarios encontraron después del lanzamiento.
¿Cómo lo necesitas?
Si desea que todo se haga de manera eficiente, no entre en fiebre, escuche a los desarrolladores y asegúrese de realizar un seguimiento del progreso. Si el equipo no encaja y no hay motivo de urgencia, ¡mueva el plazo! No de forma arbitraria, pero por el momento eso no es suficiente en la etapa actual. Anime a los desarrolladores a comunicar las posibles causas de retrasos y riesgos. Si alguien ve algo que claramente no encaja en el horario general, vale la pena llamar la atención de la persona que está planeando, para que tenga la oportunidad de corregir las fechas estimadas.
¿Hiciste todo antes de tiempo? Bueno, en tal situación, todo el mundo solo gana. Y las pruebas se pueden realizar correctamente y brindar a los desarrolladores la oportunidad de mejorar algo en la base de código. Si usted es un desarrollador o se comunica con desarrolladores para trabajar, entonces usted mismo lo sabe: siempre hay lugares en el código que le gustaría ajustar. A veces, solo toma una hora y, a veces, varios días. Es mejor no perder el tiempo haciendo el código mejor y más preciso; como todos podemos confirmar, hay suficientes deficiencias en las aplicaciones que ninguno de los usuarios apreciará.