¿Te conviene trabajar desde casa?

Dilbert-Teletrabajo Los Millenials, esa raza aparte de la que hablaremos otro día, lo valoran. Estamos hablando del trabajar desde casa. Y el trabajar desde casa ha sido objeto de un artículo muy interesante en LinkedIn.

Pero analicemos un poco el artículo, ya que ponen al hecho de trabajar desde casa como un lastre en la carrera profesional. Claro, desde casa es sencillo realizar el 99% de las tareas. Pero por ejemplo, ya no es tan sencillo liderar. Y no hablo de dirigir a un equipo, sino dar ejemplo, y ser el líder que todos desean ver hacer y que guía al equipo.

¿Significa esto que no se puede ser jefe trabajando desde casa? No, pero en el artículo se plantea que a la hora prosperar en la carrera profesional, es más sencillo hacerlo de forma personal en la oficina, o codo a codo con el equipo en el cliente (o donde sea). Es en ese día a día en la oficina, haciéndose ver, donde  se genera la confianza para que los responsables te tengan en cuenta a la hora de promocionarte profesionalmente.

Aquí es donde viene la pregunta: ¿te conviene trabajar desde casa?

Pues tal como lo plantea el artículo, pues no, si lo que quieres es progresar profesionalmente a puestos de dirección.

Por supuesto, si entre tus objetivos están el no progresar rápidamente, sino realizar un trabajo a gusto, y con un adecuado balance entre la vida personal y la profesional, el teletrabajo es un punto a valorar.

El artículo está muy cargado de valores profesionales, y está muy bien dirigido. Sin embargo, no tiene en cuenta que está estableciendo una premisa: si quieres prosperar profesionalmente, debes dejarte ver. Que te vean trabajar, y que te vean haciendo cosas bien.

De nuevo, aquí extraemos algunas tristes conclusiones, dos de las cuales dejo a la reflexión de mis lectores:

  • ¿Y si mi visibilidad se reduce no por trabajar desde casa sino porque me mandan a un cliente? En ese caso no es porque queramos, sino que se nos saca fuera “visualmente”, impidiendo y coartando nuestra carrera profesional de forma ajena a nuestra voluntad.
  • Si se trata de dar visibilidad a nuestro buen hacer, ¿no estaremos fomentando que la gente oculte descaradamente sus errores o su “no tan buen hacer”? O lo que es peor, que se busquen culpables de cualquier situación, en lugar de afrontarlas y solucionarlas (tal y como se esperaría de un líder)

Así que tras darle muchas vueltas…vuelve a mi cabeza la pregunta:

¿Te interesa trabajar desde casa?

 

 

 

Anuncios

Sobre iniciativas y proactividad

Dilbert-iniciativa.pngHoy hablaremos sobre las iniciativas y la proactividad. ¿A qué nos referimos con iniciativa? Pues una iniciativa se define como “proposición o idea para iniciar alguna cosa”. Hay otros significados, pero hoy hablaré de este. Es el primer paso de un proyecto, o el punto de partida de alguna acción.

¿Qué problema hay con las iniciativas? Que son muy bonitas, son útiles, pero promover iniciativas es una trampa. Y es una trampa, porque pensemos en el caso de que la persona que propone las iniciativas es la misma persona que debe ejecutarlas y llevarlas a cabo. Pues en ese caso las iniciativas son como pegarse un tiro en el pie: cuantas más ideas propone esa persona, y/o mayores son, más trabajo debe asumir.

Y al contrario, es muy bonito soltar ideas e iniciativas, cuando han de ser otros los que las terminen y lleven a buen término. Después de todo, alguien  lo llevará a cabo. No importa lo ambicioso o complejo de la iniciativa, o incluso no importa si las iniciativas son plausibles o no.

¿Y qué ocurre con la proactividad? Veamos. La proactividad se define como “toma de iniciativa en el desarrollo de acciones creativas y audaces para generar mejoras”. Muy bien, vemos que la proactividad es una medida de las iniciativas que llevamos a cabo.  Por desgracia, la proactividad, se verá bloqueada por el razonamiento anterior de las iniciativas:

Es fácil ser proactivo cuando otros han de llevar a cabo las iniciativas, o cuando éstas son sencillas. Es fácil tener iniciativa. Lo complejo es poder asumir su ejecución.

En un entorno empresarial, se suele premiar la iniciativa o más concretamente, la proactividad de las personas. Sin embargo, no es un buen indicador, ya que las personas que prevean que van a tener que asumir la ejecución de las iniciativas, se van a ver animadas precisamente a no presentar iniciativas.

Por tanto, podemos obtener este interesante corolario:

El tamaño y complejidad de una iniciativa, suele ser inversamente proporcional a nuestra implicación en la realización directa de las mismas.

Claro, a no ser que compenses la desmesurada magnitud de tus iniciativas, con pasión y amor por tu trabajo. Así que si eres de los que pecan de lo primero, asegúrate antes de ir sobrado de lo segundo.

Un muy buen fin de semana a todos.

 

¿Eres un job-hopper?

job-hopperYa llevo unos días oyendo el término de Job-Hopper. La última vez ha sido leyendo un artículo de Forbes.

Después de todo, es un concepto antiguo en nuestra profesión. Pero antes de ir más allá con ello, vamos a ver su definición:

 

Un “job-hopper” es una persona que cambia de empleo con cierta asiduidad. No hay un límite definido, pero al menos 1 vez al año o cada dos años. También se les conoce con otros términos como “salta-empleos”.

Supongo que me estaréis diciendo. “Vale, ¿y qué?”. Pues que tenemos que tener cuidado con estos individuos. Me explicaré.

Estas personas suelen necesitar periódicamente nuevos estímulos, aprender cosas nuevas. Efectivamente, odian el estancarse y el hacer cosas similares todo el tiempo. Necesitan variación, adrenalina, novedad y enriquecer su intelecto con cosas diferentes. Hasta aquí suena bien, ¿no?

Los job hoppers suelen estar vinculados con cualidades negativas como la falta de responsabilidad, compromiso e inmadurez.También se cree que los job hoppers son individuos que carecen de seguridad laboral. Una persona que cambia frecuentemente de trabajo, podríamos pensar que tiene menos posibilidades de convertirse en gerente, ya que este tipo de posiciones exige una conducta de trabajo duro y constante en los empleados. Una desventaja que padecen aquellos que cambian frecuentemente de puestos de trabajo es que no consiguen tener el tiempo suficiente para especializarse en algunos temas.

Sin embargo, en un entorno laboral plagado de Millenials en el que ya no se valora la experiencia…¿a quién le importa? ¿Qué más da si has estado en 1 trabajo durante los últimos 10 años…o 10 trabajos durante los últimos 5 años?

Por desgracia, es más fácil prosperar profesionalmente y ganar cada vez más saltando de empleo en empleo, sin llegar a demostrar nada y dejando atrás los errores para que los arreglen los demás. No se valora el esfuerzo, el pensar a largo plazo y ya no hablemos de la deuda técnica, calidad del código y las buenas prácticas.

Sin embargo, he visto artículos en la red donde a estas personas se les valora positivamente el hecho de haber cambiado de empleo constantemente. De hecho, en entornos profesionales donde se trabaja por proyectos, es donde estas personas encuentran su hábitat natural. De hecho, hay empresas donde conforme se acaba un proyecto de un año…los profesionales empiezan a preguntarse por su futuro laboral, y es aquí donde los job-hoppers encuentran su lugar favorito, ya que no les tiembla al pulso al buscar empleo constantemente, pero especialmente conforme se acerca el final de dichos proyectos.

¿Y tú, eres uno de ellos, o conoces a alguno? ¿Te gustaría trabajar con un job-hopper?

PD: Gracias, Angel Granero por la idea de este post.

La línea de Base y los cambios en producción

branch-per-taskMuchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva “foto”, y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y “jugárnosla”, hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

Eat your own dog food

dogfoodingHoy vamos a hablar de un término (dos en realidad), que están relacionados con prácticas de testing interno.

No te despistes al escuchar la frase ‘eat your own dog food’. En el mundo del desarrollo del software, nos referimos a una empresa que usa sus propios productos en el día a día, de forma interna, incluso mucho antes de salir al mercado. ¿Qué mejor demostración de confianza en tus productos y mejor forma de entregar un producto software pulido y plenamente operativo que usarlo tú mismo, de forma interna?.

Esta práctica, que también podremos oir como “dogfooding” (este es el segundo término), puede tener varios orígenes:

  • Queremos dar una imagen de confianza en nuestros productos. Es una manera de decir al público: “eh, fijaos si nos fiamos de nuestro software, que lo usamos día a día internamente”.
  • Qué mejor beta-testing que precisamente usar el producto de forma interna. Tendremos la garantía de que todos los defectos encontrados van a ser reportados, y resueltos de forma inmediata.
Hay muchas compañías que aplican este concepto. Apple usa internamente sus productos, Microsoft es otro habitual en el uso de esta práctica: usa sus lenguajes y entornos de desarrollo para crear sus…lenguajes y entornos de desarrollo, sistemas y aplicaciones. Incluso Microsoft usó Windows Server 2012 todavía sin terminar como plataforma para dar servicio a Bing a nivel mundial.  De hecho, Microsoft lleva toda su historia ligada al concepto de dogfooding con sus productos.
Pero son muchos los desarrolladores que lo hacen. Esto era muy típico por ejemplo hace algunos años con las típicas soluciones sectoriales de pequeñas compañías que desarrollaban software interno para su gestión (facturación, contabilidad, nóminas y gestión de…presupuestos, clientes, proveedores, etc.) y con el tiempo acababan vendiendo el software a empresas de su sector, o incluso a otros sectores.
¿Y tú? ¿Te atreverías a usar internamente en tu empresa el propio software que produces y confiar en él hasta el punto de dejar tus procesos de negocio críticos en sus manos?

Habilidades vs títulos (episodio 2)

dilbert-certification

Si hace poco hablába de la titulitis en el artículo “Habilidades vs títulos” (que ahora deberé renombrar añadiéndole “episodio 1”), ahora va el jefe de Recursos Humanos de Google y suelta la frase: “el expediente académico no sirve para nada“.

Y es que nos pongamos a la defensiva o no, se está demostrando cada día más que la postura de “yo valgo porque mi título es tal o cual”, ha muerto, y debería considerarse una postura conformista y obsoleta.

Por desgracia, todo cambia, y debemos adaptarnos. Ya nunca más el tener un título va a suponer una ventaja absoluta, y debemos mirar con otros ojos (y con el debido respeto profesional), a los que han elegido otras vías de formación. Debemos valorar por capacidades, no por títulos.

Tal y como afirma el jefe de RRHH de Google, lo que se enseña en la universidad es muy distinto de lo que se necesita en el mundo laboral. La paradoja, tal y como desarrolla en el artículo, es que la universidad enseña…a superar la universidad. Del mismo modo que el hacer muchos Test Psicológicos entrena a superarlos (no necesariamente desarrolla el intelecto, aunque aparentemente los resultados de tus test sean exponencialmente mejores). De ahí se deduce que una persona que saca muy buena puntuación en un test…sólo significa eso y nada más. Para resolver problemas reales…hay que enfrentarse a problemas reales.

En el artículo, es curioso como una de las preguntas favoritas del jefe de RRHH de Google es “Dame un ejemplo de cómo resolviste un problema analítico difícil”. Aquí empieza a verse la luz valorando la experiencia, al mismo tiempo que una mente inteligente.

 

Habilidades vs títulos

Dilbert-graduate

Hace poco leía un titular de noticias que hablaba sobre la apuesta de Bill Gates por la contratación basada en habilidades y no en títulos. Y una frase saltó en mi cabeza “Por fin!”. Pero no es algo nuevo. Una búsqueda rápida en cualquier buscador con el término “habilidades vs titulación”, ofrecerá cientos de resultados con similar discrepancia.

Sin embargo, viendo los comentarios de la gente ante estas noticias, veo que existe una enorme preocupación. Frases del estilo “¿Dejarías que te operara alguien que no es médico titulado?”, son lapidarias, o pretenden serlo. Hay mucha gente con título universitario que pagó religiosamente por una garantía de empleo basada en el título, una garantía de estar “por encima de los demás” a la hora de ser seleccionado, y a la hora de percibir un sueldo. Una garantía de estar por encima basada puramente en el título, claro, no en el rendimiento profesional o en el valor aportado a la empresa.

Pero la realidad es otra. Las empresas no pagan por títulos. Pagan por gente resolutiva. Y los estudios demuestran que las empresas necesitan habilidades profesionales, no títulos. Eso no significa que el título sea despreciable.

Volviendo a la frase del médico: “¿Dejarías que te operara alguien que no es médico titulado?”, resulta paradójico que si analizamos dicha frase, nos lleva a un sinsentido: un médico no opera. Quien opera es un cirujano, que es un médico especialista que además de la titulación en medicina, debe cumplir una serie de requisitos adicionales, el principal de ellos, una experiencia profesional (el MIR) contrastada en la cirujía concreta de que se trate (ni siquiera todos los cirujanos son iguales). De hecho, en los hospitales encontramos gente trabajando que no es médico, ni siquiera titulados universitarios. Hay enfermeras, auxiliares, bedeles, secretarias, asistentes, etc, etc. Y todos son muy respetables. En una operación, no se presentan 10 personas tituladas superiores y expertas en cirujía.

Cambiando de tema con la ingeniería, en los talleres y las fábricas vemos constantemente cómo los ingenieros recién titulados tienen problemas para llevar a cabo las tareas porque les falta experiencia. Sólo los más veteranos, empleados de toda la vida (normalmente no ingenieros), conocen el negocio, las máquinas, y las soluciones a los problemas. Además, cuentan con conocimientos específicos (otras titulaciones no universitarias) que son de un gran valor para su profesión, y que les permite, con el apoyo de su experiencia, cubrir con soltura las casuísticas del trabajo.

Si revisamos las competencias profesionales más valoradas por las empresas, vemos que tienen poco o nada que ver con titulaciones universitarias: de hecho, la universidad y el expediente académico son los aspectos menos valorados. Y esta afirmación es constante en las empresas y departamentos de selección.

Me recuerda esto el caso de un compañero de trabajo que tuve. No fue a la universidad. No tenía estudios de postgrado. Pero tenía 30 años de experiencia en el sector y muchísimos cursos. Tampoco estudió inglés ni tenía certificado de ninguna escuela de idiomas, pero estoy seguro de que hubiera podido trabajar incluso como traductor si hubiera querido. Y no necesitaba título de inglés: era australiano.