La diferencia entre un profesional y un aficionado

· Creado por: Mike Cohn

· traducido por: rick@oncedev.com

Un profesional hace todas las partes de un trabajo. Un aficionado hace solo las partes divertidas.

https://www.mountaingoatsoftware.com/blog/the-difference-between-a-professional-and-an-amateur

¿Eres un profesional o un aficionado?

Te voy a pedir que consideres ser un profesional. Pero, antes de que lo hagas y antes de que puedas responder la pregunta que formulé, debo asegurarme de que estés totalmente consciente de lo que quiero decir cuando hablo de ser un profesional.

Para mí, la diferencia es simple: un profesional siempre hace todo lo necesario para completar un trabajo. Un aficionado a veces elige solo las partes divertidas.

Un ejemplo de la diferencia

Un golfista aficionado, por ejemplo, puede emocionarse ante el intento de un "drive" de 300 yardas pero odiar hacer un "putt". Y así, un aficionado puede elegir con frecuencia recoger la pelota una vez que esté "lo suficientemente cerca" del hoyo.

Un golfista profesional nunca podría hacer esto. Es posible que el profesional aún prefiera usar los discos largos en lugar de hacer putts complicados. Pero el profesional sabe que necesita hacer ambas partes del trabajo.

Profesionales y aficionados en el desarrollo de software.

La diferencia entre los profesionales y los aficionados aparece en los equipos en los miembros que solo hacen las partes del trabajo que les gusta.

Esto puede suceder en cualquier rol en un proyecto. Podría ser el Tester al que no le gusta hablar con los clientes ("Son los analistas que hacen eso"). O podría ser el Product Owner que solo quiere pensar en características nuevas y estratégicas, en lugar de ir al meollo de la implementación.

En cualquier trabajo hay partes buenas y partes malas. Los profesionales hacen el trabajo completo, no solo las partes divertidas.

El programador aficionado

Uno de los aficionados más comunes con los que me he encontrado últimamente son los programadores que solo codificarán exactamente lo que se les dice. "Te di precisamente lo que pediste", dirán. Y no hay nada malo con esa respuesta en algunos casos. Pero no es apropiado todo el tiempo.

El programador profesional aporta todo su cerebro, experiencia y creatividad al trabajo. Cuando se le pide que desarrolle una característica, el profesional va a pensar: ¿hay lagunas en lo que se pidió? ¿Hay alternativas y mejores soluciones? ¿Llevará a problemas posteriores? Y luego, la profesional conversa con el Product Owner basándose en las respuestas a estas preguntas para determinar exactamente cómo se verá la característica cuando se implemente.

En contraste, el aficionado dice: "Está bien, te daré exactamente lo que pediste". Eso es lo más fácil. El programador aficionado no tiene que pensar en el trabajo más allá de las especificaciones. Solo codifica lo que se pidió.

De manera similar, un programador aficionado dice: “Simplemente escribo código; no pruebo ". Seguramente, ese programador probablemente hará un poco de pruebas en su propio código. Pero cuando el equipo se acerca al final de un Sprint y podría usar un poco de ayuda para las pruebas un día, es probable que un programador aficionado simplemente programe las siguientes funciones con anticipación en lugar de hacer el trabajo más útil, pero para algunos, menos deseable, de ayudar a hacer pruebas.

No hacer el trabajo completo es un lujo

No hacer todas las partes de un trabajo es un lujo que solo se ofrece a los aficionados. Un aficionado puede golpear el glamuroso y poderoso "drive" de 300 yardas y luego recoger la pelota en el "green" sin hacer el "putt". El aficionado puede escribir código y no preocuparse de que ningún usuario se beneficie de ese código hasta que un Tester se ponga al día y lo pruebe semanas después.

Los profesionales no hacen eso.

Un profesional sabe que, en última instancia, su trabajo es hacer lo que sea necesario para ayudar al equipo. A menudo, eso significa tomarse el tiempo para conversar acerca de las tareas en cuestión o abordar algunas de las partes menos deseables del trabajo.

Un equipo de aficionados hace difícil el desarrollo de software

Es difícil ser Agile con un equipo compuesto en gran parte por aficionados. Los aficionados tienden a adoptar la actitud claramente no Agile de "ese no es mi trabajo" y "yo solo hago este tipo de trabajo".

Es más probable que los aficionados sean altamente especializados y se sientan con derecho a trabajar únicamente dentro de su especialización. Si bien esto puede hacer que las personas en ese rol se sientan más eficientes, reducirá el rendimiento general del equipo. (Es decir, la velocidad general del equipo sufrirá incluso si un rol puede sentirse más eficiente).

Por muchas razones, un equipo de aficionados dificulta el desarrollo del software.

¿Qué piensas?

Por favor comparte tus pensamientos en los comentarios abajo.

¿Eres un aficionado o un profesional? ¿Cómo te mantienes motivado para hacer siempre las partes menos glamorosas de tu trabajo? ¿Cómo has convencido a los aficionados para que se conviertan en profesionales?