A lo largo de mi vida como programador he vivido momentos difíciles en el trabajo diario. A veces sólo puedes apretar y apretar, sea cual sea la razón. Esto pasará, sin duda, y cuando pase tienes que hacer el esfuerzo. El trabajo tiene que salir.
Pero, sea como sea, pase lo que pase, intenta evitar estas 3 cosas.
1. Establecer fechas límite poco realistas
Todos hemos tenido deadlines, y sabemos que tenemos que atenernos a ellas. Pero cuando hablamos de programación, estas fechas tienen que ser realistas. La mejor manera de tener fechas realistas es consultando con el equipo de desarrollo. Sabrán trocear el proyecto en tareas más pequeñas y estimar la fecha de finalización con bastante exactitud. Y si el equipo usa Scrum lo harán todavía mejor.
Establecer deadlines poco realistas te retornará de varias formas:
- Equipo estresado. «Tensión» está bien, pero el estrés no.
- Baja calidad del código. Tendrán que correr para cumplir con el deadline, sin importar demasiado si las decisiones de implementación son correctas o no.
- Deuda técnica. Habiendo leído el punto anterior, ¿pensabas que me iba a dejar la deuda técnica?
¿Estás dispuesto a pagar este precio?
2. Permitir deuda técnica
La programación implica deuda técnica. No tener deuda técnica es casi imposible y, con toda seguridad, demasiado caro. Así las cosas, lo que tenemos que conseguir es minimizar su impacto.
Profundizando en esto de la deuda técnica, ya hace algún tiempo, encontré un artículo muy interesante que además incluía un «Cuadrante de la Deuda Técnica» (de Martin Fowler). Te recomiendo encarecidamente la lectura de este artículo.
https://deviq.com/technical-debt/
Me encanta la definición de la primera frase del artículo:
Technical debt is a metaphor for all of the shortcuts, hacks, and poor design choices made for a given software system that compromised its quality, usually in an attempt to meet a deadline.
«La deuda técnica es una metáfora de todos los atajos, trucos y malas elecciones de diseño hechas para un sistema de software dado, que comprometió su calidad, generalmente en un intento de cumplir con una fecha límite.»
Como Jefe de Desarrollo, una de tus prioridades es entregar software, y entregarlo con buena calidad (minimizando, como decíamos antes, su deuda técnica). Por otro lado tenemos las fechas límite. Esto es siempre lo mismo: atenerte a las fechas límite y entregar buen software. ¿Todo? ¿¡Cómo!?
La mejor manera de «intentar» llegar a este objetivo es usando metodologías ágiles. Probablemente sabes que me encanta Scrum. Bueno, eso es porque te da a ti y al equipo de desarrollo una visión muy amplia de lo que se está desarrollando.
Y, por supuesto, las metodologías ágiles son el siguiente punto.
3. Evitar el uso de metodologías ágiles
Cuando tienes o formas parte de un equipo de desarrollo estable, deberías/deberían usar metodologías ágiles. Y a mi me encanta Scrum (¡Ah, que eso ya lo dije!). 🙂
Así que, si tienes un equipo de desarrollo, no asignes ‘n’ proyectos a ‘n’ individuos en un intento de paralelizar su trabajo. ¡Eso es un error terrible! Si haces eso, un proyecto pertenecerá a un programador, los demás no tendrán conocimiento sobre ese proyecto, y por ello el mantenimiento se verá seriamente afectado.
Usar Scrum le otorga al equipo algunas ventajas muy interesantes:
- Todos participarán en la definición de la solución (sprint planning).
- Todos hablarán cada mañana sobre sus logros y problemas del día anterior (daily meeting).
- Todos sabrán qué se está haciendo.
- Todos hablarán al final de cada sprint sobre lo que han aprendido en él (sprint retrospective).
- Y mi favorita: aprenderán más y más sobre ellos mismos y serán capaces de estimar la duración de las tareas con mucha más exactitud.
Esta vez no he dicho nada sobre la calidad de código, pero estaba implícito en los tres puntos. 😉