Para tener éxito como desarrollador, no sólo hay que saber desarrollar, también hay que saber comunicarse.

Todos conocemos el anti-patrón Golden Hammer: Para un martillo de oro todo son clavos.

Hoy tenía una conversación con algunos compañeros de @autentia que creo que merece la pena comentar.

Imagina que estás arrancando un nuevo proyecto con un cliente y tienes un perfil altamente técnico. Lo primero que te va a pasar, casi seguro, es que como vas a sentir que no controlas totalmente la tecnología del cliente, te vas a tirar como un loco a montar el entorno y a probar cuatro conocimientos que quieres afianzar para sentirte con control. Posiblemente, FAULT.

Eso está bien mientras otra persona haga la labor de interlocución pero ¿y si eres quien lleva el proyecto?

Yo creo en las dinámicas artesanas en las que una persona primero es aprendiz, luego oficial y luego maestro.

Los matices están en la definición de qué es cada cosa. Voy a poneros una captura a https://es.wikipedia.org/wiki/Gremio y proponer una definición:

Aprendiz es una persona que lleve uno o veinte años trabajando cumple con estas características (se me está ocurriendo hacer una tabla de esto, ya para otro): 
- No conoce bien las técnicas a utilizar (para mi): Lenguajes, XP, TDD, BDD, Frameworks estándar, BBDD, motores de búsqueda, Agilismo, herramientas de medida de rendimiento, etc.
- Sólo puede trabajar en un proyecto/tarea a la vez (se estresa mucho con el cambio de contexto).
- Se preocupa más por lo que hace él (y aprende) que por el proyecto en el que trabaja.
- Tiene poca vinculación emocional con sus compañeros y con las necesidades de la empresa que le paga.
- Antepone en la solución sus preferencias técnicas al impacto que puede tener en el cliente (a nivel de operación).
- No tiene capacidad de definir un proyecto y negociar el alcance con el cliente.
- Tiene problemas de ego o comunicación. 
- Quiere hacerlo y saberlo todo solo.
- No sabe decir no.

Oficial:
- Conoce las técnicas de trabajo (amplias y profundas por los años trabajando).
- Aporta nuevas técnicas a otros oficiales (en un mundo tan cambiante, comparte conocimiento).
- Es capaz de hacer más de una cosa al mismo tiempo (como por ejemplo dar un curso, ayudar en más de un proyecto, hacer una oferta)
- Asume gente a su cargo a la que formar.
- Se preocupa por el proyecto, la calidad y la relación con el cliente y no solo por sus intereses de aprendizaje.
- Mide bien el impacto de la innovación en el proyecto y el cliente.
- Es capaz de definir y negociar el alcance de los proyectos/colaboraciones.
- Controla su temperamento y es capaz de ceder algunas veces y otras sacar los dientes.
- Se apoya en el conocimiento de otros compañeros.
- Sabe decir no.

Maestro:
- Conoce las técnicas de trabajo y es buen oficial.
- Empatiza con el cliente y sus necesidades.
- Decide voluntariamente no ser el mejor ejecutor pero que éstos de desarrollen en su taller.
- Realiza algunas labores técnicas especializadas o aporta criterio ante conflictos.
- Conoce y realiza las labores comerciales/preventa y de marketing (sociales), por lo que podría abrir un taller propio.
- Se relaciona activamente con la comunidad y busca el bien para el gremio, no solo para su taller.

Supongo que estos puntos son discutibles (a ver las aportaciones interesantes que hacéis).

Aprendices, oficiales y maestros

Volviendo al principio, si un técnico que se puede considerar “senior”, si se tira demasiado pronto con la tecnología es como si intenta sorprender a un/a chica/o, pavoneándose sabiéndolo todo, nada más presentarsedemasiado pronto (parecer presumid@). Es como si se va corriendo, de repente, a prepararse por si tienen un encuentro íntimo, sin molestarse en conocer a la persona, demasiado pronto. Hay que construir una relación y esto lleva un tiempo.

Supongo que antes de tirarse al código hay que preocuparse por otro conjunto de cosas para que los proyectos salgan bien:

- Entender la visión de la relación. Compartir esa visión (una hoja) con los objetivos de la colaboración.
- Dedicar tiempo a la conversación y relación personal. No ver a los interlocutores como solamente una fuente de resolución de dudas. Todos tenemos poco tiempo y elegimos a qué lo dedicamos. Si creas una relación algo más cercana te dedicarán tiempo. Para el que piense que no tiene tiempo le propongo que piense que si ahora le llama su madre/pareja/hijo diciendo que se ha caído de una escalera si no deja todo lo que está haciendo y desapareces durante un día o dos (y no pasa absolutamente nada). Elegimos a qué dedicamos el tiempo y tu cliente debe decidir dedicártelo a ti. Difícil si solo eres un recurso.
- Centrarse en la definición del trabajo a corto plazo. Si trabajamos con metodologías ágiles, trabajar bien la definición de Ready y de Done de las historias inminentes. Si no construimos un modelo de trabajo satisfactorio para las partes y con feedback temprano de nuestro trabajo, la relación puede ser irreparable. No hay una segunda oportunidad para una primera impresión.
- Comunicar el plan de trabajo y qué se va a hacer al principio de la relación. En Sprint cero o desde que se firma un acuerdo hasta que se ve algo tiene que estar claro que se está haciendo. Una conversación diaria y/o un panel compartido (como Trello) parece una buena idea.
- Aprender a celebrar los éxitos. Aportar tangibles a modo de herramientas (capturas, diagramas, presentaciones) para que los clientes puedan vender internamente los avances, y si es gráficamente mejor.

Obviamente hay que dominar la técnica pero no solo la técnica de construcción sino en su amplio espectro, incluyendo las técnicas de comunicación y relación. Todo tiene técnica ;-)