Carlos Reig Matut

Freelance web Developer

Category: Uncategorized

Cómo hacer una buena oferta de trabajo

Como desarrolladores tenemos muchísima suerte de que, aun en crisis, las ofertas de trabajo sigan llegando. Aunque últimamente veo más cantidad de ofertas de lo normal por dos motivos.

El primero es que desde hace un año aproximadamente que organizo con Stephen el grupo local de Valencia de PHP. Desde entonces suelo recibir correos donde empresas que buscan desarrolladores de PHP pidiendo ayuda para difundir sus ofertas laborales. La verdad es que es algo que me gusta hacer. Normalmente suelo remitir las ofertas a la lista de correo de PHP Valencia, pero creo que las comunidades podemos hacer un papel muy útil poniendo en contacto a los talentos locales con empresas.

El segundo motivo por el cual ahora veo más ofertas de lo normal es que las empresas han encontrado en el canal de Slack de Valencia Devs un buen sitio donde ponerse en contacto con muchos desarrolladores de Valencia. Por lo que es normal que cada semana se publiquen una o dos ofertas en el canal de #jobs.

Todo esto sería genial sino fuera porque la calidad de las ofertas suele ser bastante baja. Me explico, no estoy valorando que las condiciones laborales de las ofertas sean mejores o peores. Lo que quiero decir es que la información que tienen es vaga, muy vaga, poco concreta o inexistente.

En general, después de varias discusiones con compañeros del sector, creo que una buena oferta de trabajo debe tener la siguiente información:

  1. El nombre de la empresa que realiza la oferta de trabajo: Links, perfiles en redes sociales, etc. Puede parecer mentira, pero llegan algunas ofertas en las que ni siquiera aparece. Este punto podría tener una excepción: que por cualquier motivo no quieras que el nombre de la empresa aparezca (igual no quieres que se sepa abiertamente que estás buscando gente). En este caso, simplemente con indicar que la empresa prefiere seguir en el anonimato, sería suficiente. Lo importante, como he dicho antes, es que las normas del juego estén claras.
  2. La responsabilidad que conlleva el cargo: Un factor común en casi todas las ofertas de trabajo es el listado, normalmente bastante largo, de tecnologías que el candidato debe conocer: PHP, MySQL, Symfony, Laravel, Thermomix, GamusinosJS etc. Como podrás imaginar, es importante que estén en la oferta de trabajo, pero no basta solo con informar a los candidatos de las tecnologías que se usan en el día a día. También hay que informar de las reponsabilidades asociadas al puesto: ¿Se trabaja en uno o con varios clientes y proyectos? ¿Se trabaja con más desarrollores o el candidato será el único?
  3. Metodología del trabajo: ¿Se trabaja con metodologías ágiles? ¿TDD, Pair programming? ¿Se utiliza git flow o alguna otra metodología de trabajo? ¿Cómo se hacen los deploys?
  4. El perfil laboral que se busca: ¿La oferta de trabajo está pensada para un freelance o para un asalariado? ¿Qué dedicación (en horas) requiere?
  5. El horario del trabajo: ¿Es jornada completa? ¿Hay horario flexible? ¿Hora de entrada? ¿Y de salida?
  6. Presencia física: ¿Es un trabajo en remoto o presencial?
  7. Remuneración del trabajo: Lo dejo el último punto porque es uno de los más importantes. Más de la mitad de ofertas fallan aquí. Y meto en el saco aquellas donde se especifica que el salario va según la valía/experiencia etc. No hace falta que ponga hasta el mínimo detalle del sueldo, pero sí que debería de estar por lo menos el rango en el que se mueve tu oferta. Tres cuartas partes de lo mismo si lo que quieres es remunerar con share ¿Cuánto ofreces?

Espero haberte ayudado a que tus ofertas de trabajo tengan más respuestas. Son 7 puntos bastante obvios y muy sencillos de cumplir, así que ¡no hay excusa para no hacerlas mejor!

Si quieres saber más sobre este tema puedes ver el vídeo de la charla que se hizo en la comunidad de Ruby de Valencia sobre Hiring ¡Que la disfrutes!

¡Un saludo!

Carlos

Cambio de trabajo

Esta semana he dejado la empresa en la que he trabajado los últimos 3 años y he empezado con uno nuevo completamente diferente. En este post me gustaría explicar de la forma más constructiva posible, qué situaciones se han producido en la empresa que estoy dejando para que haya decidido marcharme.

Mi marcha no ha sido una decisión basada en comparar las condiciones laborales. Aunque es verdad que las nuevas condiciones son bastante mejores que las antiguas, este no ha sido el principal motivo. Básicamente, lo más importante es que me he sentido profundamente desmotivado.

La desmotivación de un trabajador es algo que se va cociendo poco a poco. No aparece de un día para otro y normalmente viene fomentado tanto por la parte de dirección como por la parte del trabajador. Sintetizando mucho, los motivos más importantes han sido:

  • Sensación de estancamiento técnico: Desde que empecé hasta el día que me he marchado, hemos utlizado las mismas tecnologías y metodologías proyecto tras proyecto. Nada de TDD (¡no teníamos tests en nuestros proyectos!), ni pair programming, ni librerías estándares en casi todos los proyectos del mismo sector. ¡Ni siquiera conseguí que cambiáramos de svn a git!
  • Pocas perspectivas de futuro: Al tratarse de una empresa muy pequeña no había forma de promocionar ni económicamente (o eso te hacía entender la dirección) ni profesionalmente. La sensación que tenía yo es que si me quedaba allí nunca progresaría.
  • Negación al cambio: No solo había problemas para cambiar la forma de trabajar en la parte técnica. Siempre me choqué con una pared cuando planteé teletrabajar algún día a la semana, gestionar algún proyecto con SCRUM, meter tests en los proyectos, hacer una guía de estilos para todo el equipo, investigar con Oculus Rift, etc. Por no conseguir, no conseguí ni usáramos Trello como herramienta de comunicación de tareas.
  • Formación nula: Todos los eventos a los que he ido para intentar estar al día  han salido todo de mi bolsillo y de mis días de vacaciones. Cero facilidades.
  • Falta de reconocimiento: La he dejado para el final porque creo que es la más importante. En todo el periodo en el que he estado trabajando no he escuchado un “Gracias, buen trabajo” por parte de la dirección. Ni un “Gracias por quedarte a apagar el fuego” cuando te quedabas hasta que las problemas se resolvían. Cada día de esos me quedaba con una cara de panoli de cuidado. Sintiéndome un pringado.

Esa ha sido mi experiencia estos últimos años. Quiero compartirla para intentar mejorar la situación de muchos pequeños equipos en los que estoy seguro que se repiten estas situaciones. A los trabajadores os diría que hay mucha vida fuera de las empresas en las que estéis, aunque dé vértigo. Y a los equipos de dirección, que lo más importante para que los proyectos informáticos salgan bien, es tener a la gente que los construye motivada.

Lo que me llevo bueno de este tiempo es un muy buen recuerdo del equipo con el que he trabajado. Gente muy válida con la que estoy seguro me vuelva a encontrar en un futuro.

 

 

Presentación

Hola,

Este post tiene como objetivo presentarme. Me llamo Carlos Reig Matut. Estudié ingeniería informática superior e ingeniería técnica de telecomunicaciones en la Universidad de Valencia. En el momento que estoy escribiendo este post, tengo 25 años y vivo en Valencia.

¿De qué quiero que hable el blog? Como te podrás imaginar por mi perfil académico, en principio, quiero que esté dirigido a gente técnica.

Vale, y… ¿qué objetivo tengo? Básicamente quiero que sea una herramienta que me ayude a aprender más y mejor sobre mi campo. Y también para que ayude a otra gente a hacerlo. Aunque también me gustaría contar experiencias profesionales que no tengan que ver con la parte técnica, sino con la social.

En definitiva, lo que quiera que acabe siendo esto ya lo iremos construyendo juntos.

¡Un saludo!

© 2017 Carlos Reig Matut

Theme by Anders NorenUp ↑