« HOME

7 razones para escuchar a tu desarrollador, aunque no te guste lo que diga

By Victoria Quirante on 21 February 2015

El escenario sobre el que escribo en este artículo es el mismo que introducía en el artículo anterior, y se puede resumir así:

Lo que aquí escribo va dirigido a la persona del primer punto. Mi esperanza de que alguien con esas características lea estos siete motivos y le sirvan de algo (le ayuden a ahorrarse alguno de los posibles disgustos relacionados con el emprendimiento en esas circunstancias) se acerca bastante a cero. ¡Pero no es cero! Así que ahí va, estas son las siete razones por las que debes poner todos tus sentidos en atender y tratar de comprender a esa persona técnica que quieres que convierta tu sueño en realidad.

1. Estás haciendo de diseñador técnico de un producto técnico complejo, sin tener conocimientos técnicos. Lo quieras o no, en el momento en que decides embarcarte en esto, tu situación es esa. Solo tú sabes lo que quieres, y eres tú el que pone el dinero, así que al final eres tú el que decide. Pero tú no tienes ningún conocimiento que te permita elegir bien. Solo tienes tu intuición, y la intuición dista bastante de ser suficiente en este asunto. Si estuvieras haciendo de diseñador de un Fórmula 1 estarías acojonado, y tendrías todos los sentidos puestos en qué dicen los ingenieros alrededor. No hay motivo para tener otra actitud a la hora de ponerse a diseñar un proyecto web, por mucho que no veas las ruedas. El desarrollador está ahí para ayudarte, y será el arquitecto técnico del proyecto… si le escuchas.

2. Una misma funcionalidad se puede implementar de mil formas distintas. Y las diferencias en coste de unas formas a otras son a veces abismales. Cuando un desarrollador te dice que algo es “mucho más costoso” o “mucho peor” implementarlo de una forma que de otra, es fácil fallar a lo hora de imaginarse qué significa ese “mucho peor”. Ese “mucho peor” puede no ser de una magnitud… normal. Aunque suene igual, lo que te está diciendo el desarrollador puede no parecerse en nada a frases como “este restaurante es mucho peor que aquel”, o “esta gasolinera es mucho más cara que esa”. Dicho de otro modo, es posible que cuando el desarrollador te dice algo así no esté hablando de la diferencia que hay entre, digamos, un perro un caballo, sino de la que hay entre un perro y el Sol. En las conversaciones normales no suele haber problemas derivados de estar hablando de órdenes de magnitud distintos. En una conversación técnica sí puede haberlos. Y no es lo mismo que una decisión incremente el coste o el tiempo de desarrollo de una funcionalidad por dos, a que lo incremente por mil. Generalmente, cuando un desarrollador dice que algo es “mucho peor” hacerlo de un cierto modo, ese “mucho peor” está más cercano al mil que al dos.

3. Hay funcionalidades que no vale la pena implementar. Por lo explicado en el punto anterior, hay funcionalidades que no vale la pena implementar. Bien porque lo que cuesta implementarlas no sale a cuenta, bien porque lo que costaría mantenerlas no saldría a cuenta… Tu desarrollador no gana nada al oponerse a implementar una funcionalidad, de modo que si te dice que no es buena idea implementar algo, es muy probable que sea cierto.

4. Hay cosas que es fundamental hacer, que desconoces. Si estuvieses diseñando un F1, verías claro que, más allá de tus deseos, hay un montón de asuntos que los técnicos saben que hay que cuidar si se quiere que ese F1 consiga, no ya arrancar, sino seguir funcionando un tiempo más tarde. El software web no es distinto en este sentido, y hay montones de cosas que no se ven, que es necesario hacer si quieres algo sólido que se pueda mantener y mejorar fácilmente. Si no escuchas mucho, y te empeñas en que solo lo que tú quieres hacer es lo que hay que hacer, te vas a saltar esta parte.

5. El desarrollador prefiere trabajar en algo que funcione. Por raro que pueda parecer, tu desarrollador lo normal es que te aconseje siempre lo que considera que es mejor para el proyecto. Lo que él haría si el proyecto fuese suyo, lo que opina, lo que le parece que es mejor desde su experiencia. No por amor al arte, simplemente porque prefiere trabajar en un proyecto que vaya a ver la luz a trabajar en uno que no. Aunque cobre sus horas tanto si las dedica a mejorar el proyecto como si las dedicase a empeorarlo, la mayoría de gente prefiere hacer lo primero. Es por eso que, si tu desarrollador se toma el tiempo de discutirte una funcionalidad, o de explicarte algo, lo más probable es que te esté dando el mejor consejo posible, desde su experiencia.

6. Pero no tiene paciencia infinita. A pesar de lo anterior, el desarrollador es posible que no te diga las cosas dos veces. Y casi seguro que no te las dirá tres veces. Aunque a él le repercute positivamente que el proyecto tome una dirección correcta, a quien le va a repercutir más positivamente es a ti, si las cosas van bien. Tú estás asumiendo el riesgo y tú obtendrás los beneficios si llegan. Por tanto, si por casualidad estás ante un desarrollador con experiencia que te está dando los consejos correctos en el momento correcto, y tu respuesta es no prestar atención, o considerar que el desarrollador simplemente tiene que limitarse a hacer lo que tú digas y como tú lo digas, lo más fácil es que tu desarrollador pase a actuar como pides.

7. La parte técnica no es una commodity, la parte técnica es todo. En definitiva, el motivo por el que deberías escuchar a tu desarrollador con toda la atención posible, es que tu desarrollador es tu proyecto. Lo bueno que sea tu desarrollador va a estar directamente relacionado con las opciones de éxito del proyecto. Así que, por un lado, es fundamental buscar un desarrollador bueno, o muy bueno. Y por otro, es muy importante escucharle. Muy a menudo es más cómodo no escucharle, porque dice cosas desagradables como “esto es demasiado complejo” o “no se hace así, fíjate que nadie lo hace así”… pero que tu idea se convierta o no en proyecto depende en gran parte de hacer lo posible por escucharle.

Entiendo que esto de “escucha a tu desarrollador sobre todas las cosas” puede suscitar muchas preguntas del tipo: ¿pero y si el desarrollador es malo?, ¿y si quiere engañarme?, ¿y si se equivoca?… La respuesta corta es: si tu desarrollador no es bueno el proyecto está condenado, le escuches o no escuches. Si tu desarrollador es bueno, y le escuchas, no lo tienes todo hecho, pero tienes opciones.

Written by @vicqr

blog comments powered by Disqus

» ALL POSTS