Ya van varias veces que veo esto ocurrir en diferentes proyectos y diferentes compañías, así que asumo que es algo relativamente común.
La historia casi siempre es la misma: se vende un proyecto grande a un cliente, quizá algo ajustado de tiempo, pero suficiente para hacerlo. Se hace el análisis y se bosqueja el diseño rápidamente. Se reparte la chamba y todos en el equipo se ponen a jalar: "Tú aviéntate este módulo, tú este y yo este otro".
Ves a uno de los desarrolladores involucrados en el proyecto todos los días en su esquinita, tecleando como hormiga. Sabes que está chambeando (o al menos crees saber que está chambeando). Cuando le preguntan:
—¿Qué rollo? ¿Cómo vas con eso?
—Bien—contesta sencillamente. No se queja, no da detalles. Así que asumes que todo va bien, ¿verdad?
Pasa una semana, quizá un mes o dos... tres meses, y de pronto esa persona comienza a enfermarse o a faltar misteriosamente y de buenas a primeras decide renunciar. Para entonces ya estás a una semana de entregar el sistema que prometiste, y cuando comienzas revisar el código que el cuate hizo, te das cuenta que: 1) lo que hizo no funciona o 2) lo que hizo hace algo pero no era lo que se supone que tenía que hacer. En otras palabras estás jodido en aprietos.
Entonces el proyecto entra en pánico. Se oprime el botón rojo y comienzan a sonar alarmas. Llamadas desesperadas. Baja de unas cuerdas del techo un equipo S.W.A.T. de desarrolladores externos (o si no tienes pues con los mismos de tu equipo) y se junta a la raza en el war room para ver cómo canijos se puede hacer en una semana lo que un chango no hizo en 3 o 4 meses. Todo mundo entra en overdrive codificando día, noche y fines de semana casi sin dormir.
Si tienes suerte, y gente MUY talentosa, igual y logras la meta. Pero muchas veces no es suficiente.
¿Qué fue lo que pasó? Acabas de ser víctima del SDC, o Síndrome del Desarrollador Callado.
Una de las cosas que a menudo hacemos al desarrollar software es que cuando el schedule anda apretado, lo primero que se hace es mandar a la goma las revisiones de código, las pruebas unitarias, etcétera. Es decir, lo primero en sacrificarse en aras del calendario, normalmente son las buenas prácticas de desarrollo de software, que irónicamente son tu más valiosa herramienta para terminar a tiempo y con calidad.
Lo que acaba ocurriendo es que si las sacrificas y tienes uno de esos desarrolladores con SDC, lo más probable es que esa persona no esté entendiendo los requerimientos y/o no tenga las habilidades para pasarlos a código y tiene demasiado temor de que se sepa. Así que no pide ayuda, no se queja, no hace preguntas. Simplemente se va a su esquinita y hace el intento. Cuando va pasando el tiempo y se acerca el deadline (por algo trae dead la palabra) esa persona comienza a sentir la presión que a menudo se manifiesta en enfermedad/desaparición.
No me malinterpreten, conozco dos o tres desarrolladores excelentes, algo anti-sociales, que chambean en su cubículo/esquina, calladitos, enclaustrados una semana o dos y cuando emergen salen con una fregonería de código. Pero son dos o tres de un montononal que conozco.
Lo peor es que la solución al SDC casi siempre es bien simple: hacer revisiones frecuentes del avance, no solo a lo que se ve (es decir, las pantallas, páginas, o lo que sea visible del sistema), sino a nivel código. Cada semana (cuando MUCHO) juntar a otro desarrollador, y a un tester o persona que conozca los requerimientos: —A ver, vamos a ver cómo va esa pantalla.
No se trata de traer a la raza a latigazos, y tampoco se trata de hacer que la raza no le busque por su cuenta. Se trata de no esperarse para descubrir las broncas cuando es demasiado tarde para hacer algo al respecto. Sobre todo de que no se atasque el proyecto por cosas sencillas. Yo, personalmente, si me atoro con algo (ya googulié, y ya lo intenté de dos o tres formas distintas) más de 3 o 4 horas y no puedo salir de ahí, inmediatamente agarro uno de mis compañeros y comienzo a explicarle el problema. A veces con solo explicarlo se me viene una idea que resuelve el atorón, y cuando no, ellos me pueden dar ideas nuevas o enfoques que a mí no se me habían ocurrido. Por muy chicho que creas ser, nunca faltan los días—o meses jejeje—en los que puedes caer en un lapsus brutus.
Así que si son uno de esos desarrolladores con SDC, por amor de Diosito, levanten la mano cuando se les atore la carreta. No se esperen a que sea demasiado tarde. Les prometo que nadie los va a morder.
