Cuando el tiempo juega en tu contra
Es fin de año y pensando en que aprendizajes me llevo conmigo, me ha venido a la mente uno en concreto: ser consciente de cómo afrontar un proyecto en el que no hay tiempo.
Y este es un tema que da para hablar mucho más, de lo que yo voy a dedicarle aquí. Se habla mucho en tech de buenas prácticas, de cómo conseguir un código limpio y de calidad. Pero no he visto tanto contenido preparándote para otra realidad, ¿Qué hago si tengo una entrega obligada tan cercana que no me da tiempo a implementar esas prácticas?
Supongo que muchas personas estaréis pensando, muy fácil, se habla con la empresa cliente y se negocia atrasar esa entrega. Sí, eso sería lo idóneo, pero no siempre es así. Muchas veces se niega, o necesita una determinada funcionalidad para el día X que es indispensable para su negocio.
Aquí es cuando suelen llegar las frustraciones, porque si en tu proyecto no te queda otra que asumir esta situación ¿Cómo la gestionas?
¿Cómo lo hago yo?
- - Analizar que decisiones que van a afectar al desarrollo general son indispensables. Por ejemplo, la internacionalización. Es algo que sino se implementa al inicio de un desarrollo, luego acarrea mucho trabajo. De la misma forma crear unos componentes mínimos comunes, como por ejemplo los diálogos de confirmación o error.
- Del código limpio, algo con lo que siempre me quedo es con hacer métodos de pocas líneas y con los nombres de variables y métodos descriptivos. Esto me va a facilitar la refactorización, porque lo que es claro, es que va a haber que refactorizar cuando desarrollas con prisas.
- Llegará un punto en que sea necesario decidir funcionalidad, o dedicar tiempo al diseño o la apariencia. Aquí, voy a cubrir funcionalidad y tratar de tener una apariencia que favorezca la navegación y la interacción pero que sea muy simple. Nada de animaciones, efectos o incluso estilos muy bonitos. Colores básicos y componentes sencillos.
- Lo mejor sería tener el diseño mobile first, de lo contrario se pierde mucho tiempo. Si no lo tienes y no te da tiempo a llegar a cumplir con el diseño responsive, igual lo mejor es pensar en tener contenedores que se puedan ver dispuestos horizontalmente o verticalmente dependiendo del dispositivo. Flex y Css Grid son tus amigos.
- Si hacer algo de forma general lleva mucho tiempo y no lo hay, para una primera fase se puede obviar. Pero siempre, hay que dejar un TODO visible. Para mí los TODOS son indispensables, porque una vez salvado el primer apurón, lo lógico es ponerse a revisarlos y mejorarlos. Además si de la que implementas algo ya sabes como debería ser, pues déjalo escrito o incluso anotada la información de como llevarlo a cabo.
- Los test son necesarios para asegurar que algo funciona como es debido, en eso estoy totalmente de acuerdo. Pero, me he visto en muchas ocasiones en el punto de que no tengo ni los minutos necesarios para crear la infraestructura básica: clases de test, mocks… para implementarlos. Es por eso que siempre se acaban dejando de lado, cuando hay mucho apurón. Desde mi punto de vista, igual sería una buena idea crear al menos la estructura básica al inicio, para después de ese primer apurón que simplemente sea añadir test unitarios. Y marcarlos como una prioridad antes de continuar.
- Asegúrate de que tu código sea muy legible, si hay ese apuro, puede que se necesite meter más gente para conseguir sacarlo. Y esas personas sufrirán una curva de entrada muy apurada, así que facilítales la vida para que puedan ser efectivas pronto.
- Márcate un horario máximo realista. Este es un punto polémico, no deberíamos tener que hacer ni un minuto de trabajo extra, pero si ves que puedes y quieres hacerlo, al menos márcate un horario máximo. Cuanto más rápido hagas algo y con menos descanso, peor va a salir. Vas a necesitar tener la mente despejada o el burnout va a ser épico.
- Trata de pensar que aunque haya muchas cosas que no están como a tí te gustaría hacerlas, vas a refactorizar. Trata de hacer una retrospectiva al terminar y compártela con el equipo y la persona responsable del proyecto. Para que entiendan que cosas no se pueden seguir manteniendo tal como están y requieren esa refactorización urgente tras pasar el deadline.
- Respira, y trata de no agobiarte por sentirte un o una mala profesional. A veces no queda más remedio que hacer cosas de forma rápida y no precisamente buena. Pero lo importante, es tratar de hacerlas lo menos malas posibles y con una base que facilite el mejorarlas después.
Y sólo desear que este tipo de situaciones se vuelvan cada vez más inusuales y pueda llegar el día en que nadie tenga que vivirlas. Para eso nos hace falta llegar a transmitir el tiempo real y el esfuerzo que cualquier cambio conlleva y que las empresas clientes, sean cada vez mas conscientes de ello. Poco a poco, se conseguirá.
