¿Cómo saber quien es un buen desarrollador?
Planteaba José M. Aguilar la interesante cuestión que da título a este post. Es también una pregunta que recibo a menudo en los cursos de Gestión de Proyecto que imparto. Asi que voy a dar mi opinión. Opinión que esta basada simple y llanamente en lo que yo valoro cuando trabajo con un desarrollador codo con codo.
Todas las cuestiones que se han planteado en los comentarios al post de José son relevantes, desde luego, pero en mi opinión hay tres factores claves a la hora de distinguir a un buen desarrollador:
La calidad de los artefactos que generan (código, diagramas, diseños, planes de proyecto, burndown charts, etc... según el perfil), algo facil de comprobar simplemente viendolos. Ver el código de un desarrollador, pantallazos del trabajo de un diseñador, o pedirle a un arquitecto que te explique algunos diagrámas de sus arquitectura es algo que sin duda nos va a dar idea de la calidad de su trabajo. En el desarrollo de software la calidad no es opcional. Esto nos da un vistazo ràpido de las capacidades técnicas con cierta independencia de la tecnología que emplee. Si un desarrallador no nos puede enseñar nada del producto de su trabajo es seguro una mala señal y esto ocurre a menudo. Por otro lado, aquel que nos enseñe su trabajo y hable de él con pasión tiene bastantes números, en mi opinión, para ser un buen desarrollador.
La cantidad de proyectos completados, puestos en producción y con usuarios usándolos en los que han participado. Esto nos da una idea rápida de la experiencia real y de las capacidades no técnicas. Es fácil preguntar por este punto en una entrevista, además da oportunidad al desarrollador de explayarse sobre lo que aporto en esos proyectos, las dificultades que encontro etc... Pero sobre todo esto nos da una idea de si es alguien que termina lo que empieza. Conozco algunos desarrolladores técnicamente excelentes incapaces de completar nigún proyecto. Un proyecto es un camino duro, lleno de momento mejores y peores, de cosas divertidas y cosas menos divertidas. Muchos desarrolladores pierden la ilusión por el proyecto una vez esta hecho lo que ellos consideran el 'trabajo bonito'. Otros muchos carecen del pragmatismo necesario para completar los proyectos, y convierten los proyectos en los que participan en un continuo ejercicio de investigación. Hay que distinguir desarrollo de investigación. La cantidad de proyectos completados también es indicador de la capacidad para dominar tecnologías, en lugar de dejar que estas dominen el discurrir del proyecto. No quiero decir que las cuestiones técnicas no sean relevantes, pero si quiero decir que no son las más relevantes.
Las capacidades de comunicación tanto oral como escrita. Esto nos da idea de si podrá comunicarse con otros miembros del equipo. Las dificultades de comunicación es uno de los principales problemas que se encuntran los proyectos de software. Si los miembros del equipo no son capaces de transmitir información de manera fluida tendremos serios problema a la hora de conseguir que el equipo de desarrollo funcione como un autentico equipo. Además esta no es una cuestión relevante solo de puertas adentro del equipo. Los proyectos son un exito o un fracaso en función de lo que el cliente percibe. Un grupo de desarrolladores capaz de comunicarse con soltura con el cliente con seguridad va a obtener mejores resultados, resultados más alineados con las necesidades del cliente. Pero si este no fuese el caso y los resultados solo fuesen 'normalitos', las capacidades comunicativas siempre juegan a favor de que los resultados obtenidos, sean cuales sean, se 'vendan' mejor. Otro factor importante es que quien es un buen comunicador suele ser un gran lector, y para estar al día en esta industria hay que leer mucho... por mucho que a algunos no les gusten los libros. Y para terminar todo proyecto de software necesita generar algo de documentación por mucho que yo no sea muy amigo de la documentación por la documentación (1, 2 y 3), y es una tarea que los desarrolladores no disfrutamos por lo tanto cuanto mejores seamos escribiendo menos nos costará realizar la ardua labor.