Cómo exigir a un desarrollador según Elon-Roig

En Squadmakers nos encontramos muy frecuentemente mentorizando clientes que no realizan una gestión adecuada del equipo de desarrollo, con un equipo desmoralizado, y un cliente que ya no sabe que hacer para saber cuanto le queda a su proyecto para terminar... acudiendo a videntes y horóscopos... por lo que vamos a resumir unas reglas muy sencillas ayudados de nuestro amigo Elon Musk.

No todo programador es un desarrollador.

Como dice Murphi "...lo que empieza mal acaba peor" por lo tanto, selecciona bien a los miembros del equipo,  y si no sabes deja que alguien experto los elija. Para que Squadmakers recomiende a un desarrollador primero ha de tener una cualidad básica como dice Elon Musk "Creo que es posible para la gente normal elegir ser extraordinaria" y ser extraordinario implica amar su profesión y tener el orgullo de poder decir que el código hecho es excelente, aunque siempre mejorable. Estos son los ideales, con la mezcla de excelencia técnica y humildad para reconocer lo que no sabe y la capacidad y gusto de aprender.. Según Elon "La mayoría de las personas pueden aprender mucho más de lo que piensan. Pero se creen incapaces sin intentarlo." Un buen desarrollador es de esos pocos seres capazes al menos de intentarlo.

Un buen desarrollador no solo es buen técnico, debe tener otras cualidades, que llamamos Principios, Valores que se enseñan en el hogar, en familia, y no son Competencias, son más intrínsecas a la persona. Esto es vital para formar un Squad Agile. Sin esos principios comunes sería imposible. Según Elon "Mi mayor error es, probablemente, fijarme mucho en el talento de la gente y no en la personalidad. Pienso que es importante que las personas tengan un buen corazón."

"La gente trabaja mejor cuando sabe cuál es la meta y por qué."

La frase completa es "La gente trabaja mejor cuando sabe cuál es la meta y por qué. Es importante que la gente sepa a dónde viene a trabajar cada mañana y que disfrute del trabajo." Para poder obtener un resultado excelente es necesario ofrecer al desarrollador una documentación semejante en calidad. Lamentablemente, lo popular es el caso contrario, muy evidente en la inteligencia artificial  "Si introduzco basura, genero basura". Pues al desarrollador lo mismo, si no tiene una documentación clara y concisa, que no genere malas interpretaciones, no debería empezar a trabajar.

Este es el primer paso, definir la meta, el objetivo a alcanzar de forma detallada contemplando los casos de uso principales, los datos a utilizar o las acciones que debería producir. Este suele ser uno de los principales errores del cliente. "ya tengo un desarrollador, ahora le cuento lo que quiero y el me lo hace". Pues no, esto no se hace así.

"Vamos a encontrar una manera, o crear una manera de llegar allí."

El desarrollador desarrolla... el plan no puede surgir de él, el plan es el roadmap de iteraciones, de evoluciones de producto desde algo sencillo mínimo a algo completo que produzca una satisfacción máxima a tu cliente. Es de una inocencia extrema pensar que el desarrollador va a ser capaz de producir un producto de 1 sola vez. Cada uno debe desempeñar el rol para el que está preparado. El desarrollador no es manager, no es investigador, no es customer experience, no es tester, no es un CTO, no es un Product Manager...es sólo un desarrollador.

En otra de sus frases famosas "A algunas personas no les gusta el cambio, pero necesitas abrazarlo si la alternativa es el desastre." Un proyecto nace de una manera y muere totalmente diferente, y esto es necesario. Tu modelo de evolución del proyecto debe prever que van a suceder "cosas" que harán que dejen de tener valor ciertos requisitos, por tanto el mayor desastre es tener que tirar todo el trabajo hecho a la basura y empezar de nuevo... para eso tanto el cliente como el desarrollador deben trabajar en un modelo agile que facilite que en esos casos la perdida sea ínfima.

"Siempre tengo optimismo, pero soy realista"

Ser optimista es otro de los errores del cliente, y del desarrollador, sobre todo cuando realizan estimaciones de tiempo. El desarrollador quiere satisfacer pero desconoce donde se mete hasta que tiene un 50% del trabajo hecho. Por eso normalmente la velocidad de desarrollo no se debe establecer hasta haber superado al menos 3 sprints en un entorno controlado y homogéneo. Elon dice que es realista aunque si le preguntamos a los monos sacrificados en neuralink... igual nos dicen los contrario. No existe realismo en una planificación, ya se demostró hace tiempo la falacia de la planificación.

"Presta atención al feedback negativo y solicítalo, particularmente de los amigos."

A esto añade Elon "La gente no suele hacer eso y es de mucha ayuda". Totalmente cierto, y más en un trabajo tan complejo como el desarrollo de software. Trabajar en solitario es un error, pero a veces es imposible de evitar. Por tanto, no tienes a un compañero con el que puedas desarrollar una estrategia de Code Review. Nosotros siempre recomendamos squads con número par en los perfiles a tiempo completo: frontend y backend. Esto permite el desarrollo de esta metodología de calidad. Tu par no tiene porque ser tu amigo, pero sí es un compañero de equipo con el que interactuas a diario y tu trabajo depende de que funcione como debe ser.. así que se le dedica tiempo para que mejore su calidad en el software, advirtiéndole de los errores o malas prácticas.. y si esto no es suficiente, tras haberlo intentado sin éxito, levantas la mano pidiendo ayuda al ScrumMaster.

"Dar, Pedir y por último Exigir"

(Juan Roig dixit)

Uno de nuestros empresarios de éxito Juan Roig,  dueño de Mercadona donde gestiona miles de empleados, lo tiene muy claro a la hora de gestionar personas: primero dar aquello que necesita para hacer bien su trabajo, después pedir un resultado que fue explicitado previamente acordado por ambas partes, y por ultimo exigirlo en caso de que no se cumpla ese resultado. Esto que parece tan obvio no se realiza en la mayoria de los pedidos a un desarrollador o a un Squad.

Elon Musk refuerza este aprendizaje "La gente trabaja mejor cuando sabe cuál es la meta y por qué. Es importante que la gente sepa a dónde viene a trabajar cada mañana y que disfrute del trabajo." Su mensaje representa el Dar aunque el Pedir y Exigir también lo cumple como demostró en X o en SpaceX.

"La única razón por la que pude lograr cosas es la gran gente dispuesta a trabajar conmigo..."

Podemos exigir profesionalidad, dedicación pero no entusiasmo o compromiso si no somos capaces de provocarlo. Lo ideal es que todo el equipo esté motivado, comprometido con el objetivo del proyecto, con la metodología seleccionada, con los controles de calidad, con los compañeros que nos han tocado... pero eso pocas veces se consigue.

¿De quien es la culpa? Del desarrollador no, siempre es del líder del proyecto, del cliente o en su defecto del responsable del proyecto. Elon añade "Una compañía es un grupo de personas organizadas para crear un producto o servicio, y este es tan bueno como la gente de la empresa y lo entusiasmados que están de crearlo. Quiero reconocer a un montón de gente supertalentosa. Sin ellos, habría logrado muy poco. Yo solo soy la cara de las empresas."

¿Y tu como gestionas a tu equipo? ¿Están comprometidos? ¿Prácticas el Dar, Pedir, Exigir? Cuéntanos tu experiencia.