Sugerencias para un Buen Desempeño como Desarrollador de Software Profesional

Todos empezamos sin saber muchas cosas cuando llegamos a nuestro primero empleo. De lo que sea. De niño solía trabajar en mis vacaciones del colegio. Fuera esto con mi papá como ayudante o donde un vecino que tenía una empresa de estampados.

Generalmente, siempre me explicaban cómo hacer las cosas que me encargaban y procuraba hacerlas siempre de la mejor manera. Cuando no sabía preguntaba y cuando tenía problemas los mencionaba.

Luego, cuando empecé a trabajar como programador se repetía un poco lo mismo. Se me pedía hacer algo, se daban instrucciones e indicaciones de por donde empezar y luego cuando me ponía manos a la obra procuraba informar, hacerlo bien, mencionar problemas, etc.

Es muy importante cuando se nos delega algo hacerlo bien. Si yo hago mi trabajo bien, a mi empleador le va bien y a mí me irá bien.

Cuando escribo este artículo tengo ya 8 años trabajando escribiendo software. Mi experiencia ha sido muy variada al comienzo y luego tuve la oportunidad de profundizar y especializarme.

He vivido altibajos. He sido exitoso y he ayudado a otros a ser exitoso. He fracasado e hice que otros perdieran confianza en mí. En todo caso, sea cual sea la experiencia, me sirvió para aprender y comprender aquellas cosas que considero que son importantes para tener un buen desempeño como desarrollador de software profesional.

A continuación las compartiré.

Comunicación

Es de las cosas más clave al trabajar como programador. En software hay mucha ambigüedad y hablar claro y conciso es una de las herramientas más fuertes que podemos tener a nuestro favor.

Por eso, es importante que practiquemos y hablemos de manera:

  • Clara
  • Concisa
  • Asertiva
  • Y sin temores

ante jefes, compañeros, clientes, colaboradores, quien esa. La comunicación debe ser sincera y sin temores.

Si algo no está para una fecha, hay que decirlo sin miedo. Si se me pregunta por algo, doy respuesta clara y es mejor si doy contexto para establecer un entorno común a esa respuesta.

En los proyectos que he tenido éxito, considero que la buena comunicación que he sido capaz de manejar ha sido clave.

Estimaciones

Tema escabroso pero al cual no se le debe temer.

Si bien hay muchos que abogan por que se deje de estimar y pedir estimaciones, la verdad es que estamos muy lejos de eso. Y como estamos muy lejos de eso, lo mejor es aprender a hacerlo o tratar de hacerlo mejor.

Para estimar mejor o dar mejores estimados suelo tener en cuenta:

  • Tiempo para pruebas manuales y/o automáticas
  • Tiempo para hacer el commit y pull request
  • Tiempo para despliegue
  • Tiempo de estudio e investigación
  • Tiempo para mantenimiento y mejoras
  • Si ya he hecho la tarea
  • Si no sé nada sobre la tarea
  • Usar puntos de esfuerzo en vez de horas (recomendación personal)
  • No dar estimaciones muy optimistas
  • Tener en cuenta que no siempre trabajarás 8 horas
  • Puede haber muchos imprevistos

Solemos equivocarnos en las estimaciones porque somos demasiados optimistas. Creemos que algo durará poco tiempo pero en realidad solo estamos cayendo ante una presión externa.

Si algo toma 1 día de trabajo, eso es lo que toma. Si se necesita para antes, entonces hay que reducir el alcance de la tarea o trabajar extra(entonces negociar un costo extra por trabajar más).

En todo caso nunca seremos expertos en estimar. La estimación nunca será precisa.

La estimación solo es una herramienta para dar una idea cuándo algo estará. Es una forma de disminuir la incertidumbre, no de eliminarla.

Mira estas notas que he tomado sobre estimación en software si quieres saber más.

Apropiación del Proyecto

Esto no es meterse donde no lo han llamado ni atribuirse responsabilidades que no corresponden sino aprovechar las oportunidades para jalonar el proyecto hacía un buen rumbo cuando nadie más lo hace.

Se da mucho más en equipos pequeños donde hay muchos roles que no los cubre nadie y en ocasiones una o más persona le toca o se anima a aventurarse en otras áreas.

Es en esas ocasiones donde uno puede aprovechar para “apropiarse del proyecto” y:

  • Animarse a liderar (si no hay un líder claro o nato)
  • Apropiarse de diferentes frentes como frontend o backend (si no hay la persona)
  • Brindar apoyo al gestor de proyecto o al dueño de producto con estimaciones, actualizaciones, definiciones
  • Tratar de guiar al cliente, siempre que se pueda, sobre el mejor camino a seguir
  • Tener confianza para tomar decisiones que puedan impactar de manera positiva o negativa. Hay que atreverse.

¿Por qué creo que esto es importante? Esto implica que de alguna forma vas a aprender mucho y que vas a demostrar a los demás que el proyecto te importa, que eres confiable, que puedes tomar decisiones, que puedes liderar, que puedes influenciar.

Todo eso se traduce en crecimiento personal y profesional que en el tiempo de va a convenir en tu hoja de vida para mejores puestos o merecer aumentos salariales.

Proponer en Todos los Aspectos

En equipos pequeño y grandes siempre habrá algo que falle o falte. Ahí es cuando también podemos proponer y liderar la bandera.

Cuando falten procesos o herramientas, sugerirlas a los líderes o colegas abrirá la discusión y puedes hacer que el proyecto coja un mejor rumbo de ahí en adelante.

¿Qué cosas proponer? Ejemplos:

  • Mejoras en código y refactorizaciones
  • Implementar code reviews
  • Implementar pair programming
  • Sugerir adecuar el proceso → Scrum, Kanban
  • Sugerir nuevas o mejores herramientas → Trello, Clubhouse, Twist
  • Mejorar el proceso de despliegue e integración continua (que sea más óptimo o rápido)
  • Promover compartir el conocimiento.

Promover compartir el conocimiento es que los aprendizajes de cuando pasen cosas malas o se resuelvan problemas complejos no queden como evidencia verbal sino que haya un documento donde esté escrito todo y se detalle cada evento.

¿Qué se gana con esto? Historia y experiencia que se puede revisar cuando ocurra o para tener ideas si algún problema o suceso similar acontece.

Esto lo puedes hacer inicialmente solo y luego ir viendo quien se anima a seguir la costumbre hasta que el equipo empiece a tomarlo en serio y también contribuir.

De una u otra forma, he tenido estos puntos muy en cuenta siempre que me aventuro en algo nuevo sea proyecto o empresa.

No son una bala de plata pero me han ayudado mucho cuando los factores y las condiciones han estado a mí favor.

Autor: cesc1989

Ingeniero de Sistemas que le gusta escribir y compartir sobre recursos que considera útiles, además que le gusta leer manga y ver anime.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .