viernes, 3 de diciembre de 2021

Lenguajes más utilizados según tecnologías

Extraídos de Slashdata y Developer Media, se facilitan a continuación los lenguajes de programación más utilizados y demandados según la tecnología, de mayor a menor uso.

  • Aplicaciones web: JavaScript, PHP.

  • Desarrollo en la nube: JavaScript, Java, PHP, Go, Ruby. 

  • Ciencia de datos / Machine learning: Python.

  • Internet de las Cosas: Python, C/C++, Ruby, Objective-C, Rust, Lua.

  • Aplicaciones móviles: Java, Kotlin, Swift.

  • Código embebido: C/C++, Objective-C.

  • Realidad Aumentada / Realidad Virtual: C#, Kotlin, Swift, Go, Objective-C, Rust, Lua.

  • Aplicaciones de escritorio: C#.
 Para lo que pueda servir.


martes, 26 de octubre de 2021

Tres aspectos a investigar antes de tu entrevista de trabajo

Antes de ir a una entrevista de trabajo, asegúrate que investigas tres aspectos de interés, tal y como recomienda Judith Humphrey en Fast Company.

En primer lugar el tipo de trabajo que buscan: ¿qué es "científico de datos"?, ¿qué diferencia hay con "analista de datos"?, ¿qué es full stack engineering? Por una parte, es necesario saber si el trabajo es de interés para ti; por otra, si posees la competencia adecuada como para llevarlo a cabo; finalmente, si de tu curriculum vítae puede extraerse dicha figura.

El segundo aspecto a estudiar es la cultura empresarial, con el foco en cómo espera que se comporten los empleados (por ejemplo, ¿hay teletrabajo?) o cómo trata la empresa a sus trabajadores. Redes sociales como Twitter, Facebook o LinkedIn de personas actualmente en su nómina pueden darnos una idea de la cultura de la empresa. Tal vez simplemente no te interese trabajar allí, porque tus condiciones laborales no se correspondan a las de la compañía.

Por último, debe estudiarse la información sobre la empresa. La capacidad de sostener una conversación sobre la empresa durante la entrevista no sólo muestra respeto e interés, sino la posibilidad de elevar la charla e intercambiar opiniones, permitiéndote dar tu punto de vista sobre enfoques en diferentes proyectos o áreas funcionales que, de otra forma, no saldrían a la luz.

Con esto no se garantiza el éxito de una entrevista, pero sí más oportunidades de enfocarse en lograr un trabajo acorde a tus preferencias.

sábado, 14 de agosto de 2021

Las bases de datos más utilizadas en 2021

Aquí un ranking de las bases de datos más empleadas en 2021, tal y como recoge Matt Asay en InfoWorld

  1. Oracle
  2. MySQL
  3. Microsoft SQL Server
  4. PostgreSQL
  5. MongoDB
  6. Redis
  7. IBM DB2
  8. Elasticsearch
  9. SQLite
  10. Microsoft Access
Dos añadidos de interés: el ranking apenas ha cambiado desde hace diez años, y sigue habiendo una mayor proporción de bases de datos relacionales, frente a las NoSQL.

viernes, 30 de julio de 2021

Publicados los nominados de Educa Abanca, 2021

Se han publicado hoy los nominados en la Quinta Edición de los premios Educa Abanca al mejor docente de España en 2021.

Enhorabuena a los nominados, y gracias a los nominadores y a la entidad organizadora, Mundo Educa. Se echan en falta más iniciativas como ésta que promocionen la calidad docente.

viernes, 23 de julio de 2021

20 preguntas que todo ingeniero de software debe hacer cuando se incorpora a un nuevo equipo de trabajo

Cada equipo de trabajo tiene sus propias particularidades, entornos y procedimientos de trabajo. En consecuencia, conviene tener claro las respuestas a una serie de cuestiones, tal y como refiere Thomas Stringer en su artículo 20 Questions a Software Engineer Should Ask When Joining a New Team, y que aconsejo leer para completar los detalles de esta relación.

Cuestiones técnicas

  1. ¿Cómo se compila localmente el software?
  2. ¿Cómo puedo probar localmente el software?
  3. ¿Cómo configuro mi entorno de desarrollo?
  4. ¿Dónde se encuentra el código fuente?
  5. ¿Dónde está el conducto CI/CD y cómo funciona?
  6. ¿Dónde está el product backlog?
  7. ¿Cómo se desarrollan las pruebas de preproducción y producción?
  8. ¿Cómo son las rotaciones y la asignación de tareas entre los desarrolladores?
  9. ¿Dónde está la documentación interna?  

Cuestiones sobre colaboración

  1. ¿Cuál es la labor de cada integrante del equipo?
  2. ¿Cómo se establecen temporalmente los objetivos?
  3. ¿Con quién debo contactar para mis primeras preguntas?
  4. ¿Quién o qué determina las nuevas características?
  5. ¿Cómo se comunica el equipo? 

Cuestiones externas

  1.  ¿Cómo se obtiene el feedback del cliente?
  2.  ¿Cuáles son los acuerdos de servicio para el cliente?
  3. ¿Dónde se encuentra la documentación pública y/o para el cliente?

Cuestiones sobre el enfoque al producto

  1. ¿Cuáles son los puntos débiles que tiene el software actual?
  2. ¿Cuál es el enfoque de los participantes?
  3. ¿Cuál es el ciclo de despliegue del software?

viernes, 9 de julio de 2021

c# 10 y la comprobación de parámetro nulo

Ya hemos visto en entradas previas la importancia de las aserciones, precondiciones y postcondiciones. Entre las precondiciones, es muy común la comprobación de que un parámetro de entrada sea no nulo. Por ejemplo,

 private void process(MyObject myObject) {
 
   if (myObject == null)
      throw new ArgumentNullException("myObject can't be null.");
 
   [...]
}

Este mecanismo supone copiar y pegar código muy similar, que lo que puede ser tedioso fundamentalmente en métodos que emplean varios parámetros de entrada. Para paliar esta situación, c# 10 facilita la expresión doble admiración (!!) para la declaración de un parámetro. De esta forma, incluyendo dicha expresión al final de la declaración del parámetro, el compilador genera el código necesario para la comprobación de su valor nulo, no siendo necesario código explícito.

 private void process(MyObject myObject!!) {

   [...]
}

jueves, 10 de junio de 2021

Principios del escaparatismo aplicados al diseño de diapositivas

El escaparatismo es el proceso en el que se decoran, organizar y diseñan los escaparates de tal modo que capten la atención de los usuarios.

Esta disciplina se estudia en ámbitos como la sociología, psicología, publicidad, estilismo, pedagogía y diseño gráfico, entre otros, siendo su finalidad:

  • atraer
  • motivar
  • reflexionar
  • sensibilizar
  • desear
  • recordar
  • relacionar

Dado que estos fines coinciden con los fines pedagógicos que deberían perseguirse durante una clase magistral, los principios del escaparatismo son aplicables a las diapositivas de una presentación. En consecuencia y aunque no todas las técnicas son extrapolables (por ejemplo, los escaparates se miran de abajo a arriba), existen estrategias compatibles y que aumentan la eficacia de las presentaciones. A continuación se refieren algunas.

Estilo propio, creatividad y originalidad

Cada diapositiva debe tener su propio estilo. Esto no significa que no pueda existir una estética general, pero cada diapositiva debe diferenciarse visualmente de las otras, no únicamente cambiar el texto o las imágenes.

Simplicidad

Las diapositivas han de ser simples visual y estructuralmente. En un primer vistazo debe quedar claro dónde está el elemento principal y cuáles son los detalles secundarios.

Espaciado

Los elementos demasiado juntos dificultan la percepción individual de cada uno de ellos. Un elemento aislado, más grande y/o de color cálido produce mayor peso en la atención.

Unidad

Debe buscarse armonía mediante compatibilidad en tamaño, forma, luminosidad, orientación u oposición. Por ejemplo, Los triángulos son más efectivos; los círculos son más agradables; los rectángulos, más estables. Los rectángulos horizontales son más equilibrados, mientras que los verticales resultan más elegantes, pero generan mayor tensión. En todo caso, las líneas ayudan a dirigir la mirada.

Detención visual

Los elementos más atractivos hacen sostener la mirada en ellos un 50% más que en otros elementos. Esto hace igualmente que haya que tener especial cuidadado con los textos, que la audiencia tiende a leer, perdiendo, durante la lectura, atención en la persona que expone.

Especificidad

Cada zona de la diapositiva debe centrarse en un concepto o aspecto fundamental. Cuanto menor número de conceptos o aspectos fundamentales, mayor intensidad y nivel de importancia tendrán los conceptos o aspectos fundamentales presentados. El resto de los elementos no fundamentales de la diapositiva, en caso de que tengan que aparecer, deberán hacerlo en impacto visual menor que los conceptos o aspectos fundamentales.

jueves, 20 de mayo de 2021

Uso de viñetas numeradas en las diapositivas

Nos referimos a "viñeta" como el símbolo que aparecen delante de cada elemento una lista. Los dos tipos de viñeta son la no-numerada y la numerada, y ambas pueden encontrarse en distintas presentaciones a criterio arbitrario de la persona que diseña.

Existe no obstante un criterio claro para emplear una u otra. Dicho criterio está basado en que los individuos interpretamos los números como criterio de orden; es decir, el 1 es el primero; el 2 es el segundo; y así sucesivamente. Dicho criterio de orden no ha de contextualizarse en el orden en la lista (lo cual es evidente; no hace falta reincidir en que el elemento que está en primer lugar es el primero en la lista), sino que debe contextualizarse en el contexto del contendo presentado.

Así, el uso de las listas numeradas debe estar justificado por el contexto de la información y, en consecuencia, sólo debe numerarse aquello que tiene un orden específico en su propio contexto. Por ejemplo, una lista en la que se enumera la clasificación de una liga de fútbol por orden de puntuación debe tener una lista numerada, dado que, en su contexto los elementos están ordenados (primero, segundo, tercer clasificado...). De igual modo, un proceso que requiera un orden concreto también justificaría una lista numerada, dado que cada paso del proceso tiene una posición estricta.

Por el contrario, no es conveniente usar una lista numerada si se desea indicar un lista de productos a comprar, de ingredientes para una receta, o de características de un sistema. No se puede evitar que tengan un orden en la lista presentada, dado que cada uno requiere una posición (cuyo criterio debería ser por imporancia del elemento), pero, al no tener un orden establecido más allá del contexto de la diapositiva, el tipo de viñeta a utilizar en estos casos sería la no-numerada.

martes, 11 de mayo de 2021

Mejora tus diapositivas con PowerPoint #4 (reboot) - Los sistemas biométricos dejan huella

Cuarta entrega de la serie pensada para mejorar diapositivas en PowerPoint. En este caso, la diapositiva trata de algunos sistemas biométricos. Como en la entrega anterior, se propondrá un análisis de los problemas de la diapositiva original, y se construirá una nueva versión teniendo en cuenta aspectos estéticos y pedagógicas.





jueves, 6 de mayo de 2021

Mejora tus diapositivas con PowerPoint #3 (reboot) - Seguridad en la empresa y unos monstruos

Tercer vídeo de la serie propuesta para mejorar diapositivas en PowerPoint. En este caso, la diapositiva trata de los efectos positivos y negativos de la seguridad en la empresa, y viene acompañada de unos personajes que conoceréis. Como en la entrega anterior, se propondrá un análisis de los problemas de la diapositiva original, y se construirá una nueva versión teniendo en cuenta aspectos estéticos y pedagógicas.



miércoles, 5 de mayo de 2021

Mejora tus diapositivas con PowerPoint #2 (reboot) - Muestra estadística y señor mayor

Nueva entrega de la serie de vídeos en la que se propone mejorar diapositivas en PowerPoint. En este caso, la diapositiva trata de las características básicas de una muestra estadística. Como en la primera entrega, se propondrá un análisis de los problemas de la diapositiva original, y se construirá una nueva versión teniendo en cuenta aspectos estéticos y pedagógicas.


lunes, 3 de mayo de 2021

Mejora tus diapositivas con PowerPoint #1 (reboot) - Cassandra

Como en todas las entregas de esta serie de vídeos, se propone la mejora de una diapositiva, en este caso relativa a Cassandra, no el personaje de la mitología griega, sino un gestor de bases de datos no relaciones. Para ello, se propondrá un análisis de los problemas de la diapositiva original, y se construirá una nueva versión teniendo en cuenta aspectos estéticos y pedagógicas.



jueves, 29 de abril de 2021

Utiliza un sistema de gestión de incidencias

Un sistema de gestión de incidencias es algo tan simple como una aplicación que permite indicar errores o necesidades, asociarles una prioridad, indicar el proyecto relacionado y, en su caso, asignarlo a un responsable. A pesar de esta sencillez, es uno de los mejores aliados de un equipo de trabajo. Si además genera informes, la dirección del departamento tiene una herramienta extraordinaria.

Un caso sencillo es Bugtracker.NET, que nos dio excelentes resultados. El procedimiento era el siguiente: si la incidencia llegaba por teléfono, el primer nivel de atención al usuario daba de alta una incidencia en el sistema, asignando el tipo y el responsable (normalmente acertaba); el sistema enviaba un correo al responsable, quien evaluaba su urgencia y, de ser imperioso, se ponía a trabajar en ella y lo indicaba en el sistema; en otro caso, quedaba a discreción del responsable la prioridad y cuándo acometer la tarea; y una vez el trabajo estaba hecho, se actualizaba la incidencia.

 Por supuesto, también se añadían al gestor las actividades relacionadas con el desarrollo de los proyectos conforme se avanzaba el mismo.

Así, en todo momento se reflejaba qué trabajos quedaban pendientes y cuánto tardaban en terminarse. Esto permitió que todos los meses pudiera enviarse un informe a la dirección general, que describía las incidencias resueltas por el departamento y el estado de los proyectos. Este hecho no es baladí: no siempre es fácil para un equipo de trabajo justificarse.

Y ya los sistemas de gestión de proyectos como Redmine, Jira o Trello tienen gestión de incidencias, así que no hay excusa para no implantarlo.

miércoles, 21 de abril de 2021

Limita las reuniones internas

En no pocas ocasiones, las reuniones internas pecan de tener una función social más que laboral, pero conllevan un coste mayor que quedar a ir a tomar una cerveza. Este coste sobre todo se percibe si tratamos de ser metódicos en la preparación de la misma, preparando y enviando el orden del día, nombrando a un secretario para que tome apuntes, controlando los tiempos por cada punto y solicitando o elaborando un informe al final de la misma.

Durante dos años y como regla impuesta por nuestro jefe, mi departamento tenía reuniones todos los viernes, y cada semana uno de nosotros hacía las veces de organizador y director de la misma. Las reuniones duraban un mínimo de tres horas, durante las cuales se exponía la situación actual de los proyectos, así como los problemas encontrados y previstos. Cada descripción se hacía con todo detalle técnico, para que los que tenían encomendados otros proyectos se enteraran. Lo que parecía una buena idea acabó significando una notable pérdida de tiempo: por una parte, cuando se trataba un proyecto, los que no se encontraban en él no tenía motivación para prestar atención a los detalles; por otro lado y en consecuencia, el tiempo dedicado a la reunión era tiempo no productivo

Tras ese largo período y una serie de cambios organizativos, se determinó que las reuniones debían ser a petición de la dirección y, posteriormente, se extendió también a la solicitud de los desarrolladores, acordando que al menos debía haber una reunión al comienzo y otra al final de un proyecto, y en cualquier caso una vez cada mes. Las reuniones, además, eran más flexibles, trataban sólo de los problemas y de las posibles soluciones, y en las de comienzo de proyectos se resumía también el trabajo a desarrollar. Finalmente nos dimos cuenta que con una reunión mensual de una hora solía bastar para todo. Así que, en pos de las relaciones sociales, habiendo aumentado la productividad y convertidas las reuniones internas en algo útil, los viernes, media hora antes de la salida oficial, nos íbamos a tomar una cerveza. 

Claro que cuando se usa Scrum, la cosa cambia :)

lunes, 5 de abril de 2021

Cuatro conversaciones entre trabajador y jefe

Se ilustran a continuación cuatro diálogos en sus correspondientes combinaciones entre trabajador, en sus variantes motivado y desmotivado, y jefe, en sus variantes entre bueno y malo.

Trabajador motivado y mal jefe (o cómo hacer que un trabajador competente empiece a desmotivarse)

12:45 p.m.

—¿Qué desea, jefa?
—Hay que terminar la fase de análisis. A ver cuándo puedes tener el documento de especificación.
—¿Para cuándo lo necesita?
—Para ayer.
—Ahora estoy pillado con un par de modificaciones de la aplicación anterior. En cuanto las termine me pongo con ello. Creo que antes del viernes lo tendré.
—No esperes. Deja lo que estás haciendo y ponte con los requisitos.
—Si quiere yo lo hago, jefa, pero los de Reinoso están esperando. Hasta que no les resuelva el fallo tienen el trabajo parado.
—Me da igual, Carlos. Acaba los requisitos y luego sigues con lo otro que sea. Si hace falta, echa hoy más horas.
—Pues hoy me viene fatal… ¿Por qué tanta prisa por los requisitos precisamente ahora?
—Porque acabo de encontrar todos estos papeles sobre la mesa y creo que ya llevamos mucho tiempo de retraso. Y porque me he propuesto terminarlo esta semana. ¿Tanto trabajo te cuesta hacer un simple documento de especificación de requisitos?
—No… Bueno, pues me pongo con eso. Ya me inventaré algo para explicarles a los de Reinoso.


Trabajador desmotivado y mal jefe (o cómo tener un equipo que perpetúe un sistema ineficiente)

13:12 p.m.

—¿Qué pasa, que estoy liado?
—Hay que terminar la fase de análisis. A ver cuándo puedes tener el documento de especificación.
—Pues no sé. Todavía no están claras todas las cosas que vimos el otro día.
—Pues acláralas porque lo quiero para ayer.
—Además, tengo trabajo atrasado con los cambios de la aplicación de Reinoso, que no paran de dar por saco con los cambios.
—Olvídate de ellos y ponte con los requisitos.
—Es que ahora no puedo: con los cambios de Reinoso tengo el ordenador compilando todo el tiempo y se me bloquea cada dos por tres. ¿Cuándo me van traer el ordenador nuevo?
—Eso no es cosa mía. Habla con el sub-departamento de Compras.
—Ya se lo he dicho, jefe, pero dicen que tiene que solicitarlo usted expresamente.
—Aquí todo tiene que estar pedido por mí, autorizado por mí, corregirlo yo y todo yo… que parece que soy el único que trabaja, narices. El día que falte os vais a enterar todos.
—.Pues mientras yo siga tenga esa porquería de equipo no puedo trabajar bien... En fin, que a ver si puedo tenerlo para final de esta semana o como mucho mediados de la que viene. Igual me quedo un par de tardes y pido horas extras. ¿Vale?


Trabajador motivado y buen jefe (o cómo dar las gracias a los dioses por lo bien que están saliendo las cosas)

8:10 a.m.

—Dime, Marta.
—Carlos, ya sé que estás liado con los cambios de Reinoso, pero tenemos una desviación de una semana respecto a la fase de análisis y sólo faltan los requisitos funcionales. ¿Te queda mucho con Reinoso?
—Si no llaman más con algo importante, yo creo que entre hoy y mañana lo tengo liquidado. ¿Para cuándo te hace falta? Es que no quiero dejarles parados.
—En realidad no es urgente, pero no quiero salirme demasiado de la estimación.
—Vale, pues les resuelvo el problema de ahora y me pongo con los requisitos. Calculo que en un par de días los tienes.
—Gracias, Carlos. Da gusto trabajar contigo. No te molesto más.


Trabajador desmotivado y buen jefe (o cómo buscar razones para motivar a un trabajador con potencial)

9:10 a.m.

—Iba por un café a la máquina. Dime.
—Pues espera, Laura, que voy contigo y te cuento mientras. Necesito que aceleres lo más posible los cambios que te ha pedido Reinoso. ¿Cómo lo ves?
—Pues no lo sé, Juanjo. La verdad es que no paran de llamarme para que les haga cambios, y el ordenador no lo tengo muy bien.
—Lo del ordenador lo estuve pensando: ¿tú crees que se arreglaría con un formateo?
—Yo qué sé, Juanjo. La verdad es que ya me desespera.
—Pues te doy permiso para vengarte de él formateándolo sin piedad, a ver si lo metes en cintura. Es de los más modernos y el resto de los equipos han salido bien, así que no quiero que el sub-departamento de Compras adquiera otro sin darle al tuyo una última oportunidad. Espera, que invito yo al café.
—Gracias. ¿Formateo yo entonces el equipo?
—Como tú veas mejor, Laura. Si prefieres que el becario lo haga, se lo das a él, pero creo que nadie mejor que tú conoce las aplicaciones que utilizas habitualmente, así que igual es buena idea que dediques una mañana encargándote de instalarlas y configurarlas. Tú decides.
—Pero entonces, ¿qué hago con los cambios de Reinoso?
—¿Tienes alguno que sea urgente?
—Todos son urgentes. Ya les conoces
—¿Alguno super-super-urgente y que no puedan trabajar si no se arregla?
—De ésos hay un par; tres, como mucho.
—¿Crees que podrías tenerlos listos entre hoy y mañana?
—Supongo que sí.
—Pues liquídalos, reinstala el ordenador y ven a verme al despacho antes de seguir con los cambios de Reinoso, que vamos a hablar de los requisitos funcionales del nuevo proyecto y que se quedaron en el tintero. Te ruego, Laura, que no tardes mucho reinstalando, para no retrasar mucho el resto de las solicitudes de Reinoso. Cuento contigo para tenerlos contentos, ¿vale?
—¿Y si insisten mucho?
—Si puedes manejarlos, mejor. Si no, me lo dices y yo llamo personalmente al director de Contabilidad de Reinoso. Ahora me interesa más el tema de los requisitos funcionales.
—Jo. Yo creía que te habías olvidado de los dichosos requisitos.
—¡Anda, mujer! ¿Cómo me iba a olvidar de algo tan divertido?
—¡Uf! ¡Divertidísimo!
—Como todo en esta empresa, ¿no? Venga, al tajo y quítate de encima esos cambios urgentes de Reinoso para que te quedes más tranquila.

 

martes, 2 de marzo de 2021

Condiciones para la felicidad laboral

La felicidad laboral (y, en general, cualquier felicidad) se basa en tres sencillos y comprensibles criterios: objetivos y límites claros y explicados, respeto y confianza, y recompensas justas.
  1. Objetivos y límites claros: todo el mundo debería saber qué se espera de ellos, cuánto se les exige y cómo de acotados están para conseguirlo. Si utilizamos como símil a un niño de cinco años, generalmente curioso y ávido por aprender (y, por tanto, motivado), podríamos decirle algo como: "necesito que me ayudes (qué se espera) a poner hoy la mesa para el almuerzo (cuánto se le exige), pero no lleves cuchillos y transporta los vasos de uno en uno (cuáles son los límites)". De forma natural, es muy probable que el niño pregunte el porqué de los cuchillos y los vasos, lo que nos da opción a dos respuestas: "porque yo lo digo" (típica del liderazgo cohercitivo) o "porque creo que ahora mismo es peligroso y no estás preparado, aunque no me cabe duda de que si sigues practicando pronto lo estarás" (contestación característica de un líder afiliativo que apoya y motiva). Lo reconozcamos o no, los adultos también necesitamos estos objetivos y límites claros y explicados; podemos vivir sin ellos pero, al igual que el niño, nos encontraremos emocionalmente en una situación de incertidumbre. Un ejemplo de solicitud para un trabajador es: "creo deberíamos tener ya terminada la fase de análisis previo (qué se espera) y sólo nos falta que le des el toque final al documento de análisis de requisitos (cuánto se le exige). Lo necesitaríamos esta semana (cuáles son los límites). ¿Cuándo podrías tenerlo? (confianza; lo veremos en el punto siguiente)". Es imprescindible que los objetivos sean asequibles, pero que constituyan un pequeño desafío, de manera que el trabajador consiga mejorar con cada tarea y no se estanque en la realización de labores monótonas. Los límites, por su parte, deben ser claros y firmes.

  2. Respeto y confianza: si como exigimos respeto, debemos igualmente respetar. Esta ley es de aplicación para directores, líderes, profesores, padres, tutores, políticos y cualquier trabajador independientemente del escalafón en el que se encuentre respecto de su interlocutor. Un profesor no es más que sus alumnos, un médico no es más que sus pacientes y un padre no es más que sus hijos, ni viceversa: simplemente tienen otras responsabilidades y diferentes maneras de interiorizarlas. Eso en ningún caso significa que un profesor deba aceptar la falta de respeto de sus alumnos, sino que ambas partes deben respetarse mutuamente, lo cual debe formar parte de la responsabilidad de ambos: del alumno, porque ha de saber que su papel es el de aprendiz tanto de conocimientos como de comportamientos; del profesor, porque no puede ignorar que tratar a un alumno con desprecio puede ser la base de que dicho alumno haga lo mismo con otros cuando se encuentre en una situación de poder. Jefes que no saludan al entrar, que no miran a sus empleados cuando éstos van a verlos al despacho, que critican en público y que no reconocen ni en privado pueden resultar más dañinos para su empresa que el más ineficiente de sus trabajadores. En cuanto a la confianza, una vez establecido objetivos y límites, si el trabajador tiene experiencia es él mismo quien debe decidir sobre los detalles de su trabajo y los tiempos dentro de los límites indicados [1]. Por volver al símil del niño y la mesa, una vez que le dimos las instrucciones necesarias debemos darle libertad para que él gestione su propio trabajo: si estamos detrás de él diciendo "ahora esta cuchara… y ahora esta otra… y luego este vaso… " no aprenderá nunca de los aciertos de sus decisiones ni de sus errores.

  3. Recompensas justas: las que se puedan y se consideren oportunas, ya sean positivas o, si no hay más remedio, negativas, no impidiendo el agravio comparativo (puede ser un elemento motivador) pero tratando de que las divergencias sean mínimas (grandes diferencias prolongadas en el tiempo acabarán desmotivando al que menos percibe). Podemos considerar aquí tres tipos de reconocimiento: objetivo cumplido, esfuerzo y objetivo no cumplido. Los dos primeros deben ser reconocidos positivamente: el objetivo cumplido, por motivos obvios; el esfuerzo, porque, aunque el resultado no haya sido eficiente probablemente se haya debido a problemas de experiencia, tecnología o incluso planificación. El objetivo no cumplido se considera cuando el trabajador es capaz de cumplirlo y no lo consigue; aunque de forma constructiva, debe penalizarse por acción u omisión (no hay que confundir respeto con firmeza). Un último consejo: no han de hacerse promesas que sin la seguridad de poder cumplirlas; pocas cosas desmotivan más que esperar durante un año un ascenso que se prometió en un plazo de tres meses.


    [1] "¡Es que el trabajador puede intentar darme coba!", protesta la voz del jefe que todos llevamos dentro. Vale. Es verdad. Pero la empresa también puede decidir que yo no puedo disfrutar de mis vacaciones un mes antes de pedírmelas. La confianza debe ser bidireccional. No hay nada más satisfactorio que conseguir que tu equipo lo formen personas en las que puedes confiar.

miércoles, 24 de febrero de 2021

Jefe que manda vs. líder que asiste

Para mandar sólo hay que tener una posición de fuerza. Desde una posición de fuerza basta con decir qué se quiere dentro de tu campo de actuación y tus trabajadores lo harán. Desde una posición de fuerza podemos contradecir a nuestros empleados, sin importar que ellos tengan más experiencia o sepan más que nosotros, o que sistemáticamente y a veces de forma inconsciente convirtamos su trabajo en una rutina insoportable. Desde una posición de fuerza, en definitiva, podemos mandar.

Pero esa posición también nos permite "dirigir", que no es exactamente lo mismo. Es cierto que una de las acepciones de "dirigir" es "gobernar", pero ésa es sólo una de entre las diez definiciones que le otorga la Real Academia de la Lengua. Las otras nueve se basan casi todas en un modo de guía o consejo para conseguir un objetivo.

Incluso una posición de fuerza también nos da mejor opción que los demás a ser "líder", a estar atento a los problemas laborales individuales y de equipo con objeto de encaminarlos hacia los resultados de deseados, a motivarlos para que se impliquen en la tarea y acometan nuevos proyectos con empeño. En otras palabras, la función de un líder está relacionada con servir al equipo; esto es, estar para solucionar los problemas de los equipos, no para crearlos. A este respecto y en la medida de lo posible, debe fomentar la felicidad de los trabajadores.

Para los que quieren buscar un beneficio práctico en esta conducta, la felicidad de los trabajadores no hay que perseguirla necesariamente por utopías ni normas morales, sino como contraposición a la infelicidad. Un trabajador infeliz está escasamente motivado. Para un trabajador a disgusto, la empresa representa en exclusiva las horas en las que deja de hacer otras cosas. Este sentimiento es, en el mejor de los casos, neutro, y eventualmente hostil.

¿Merece la pena invertir en la felicidad de los trabajadores? Indudablemente sí. Ya sólo por el hecho de tener el poder de conseguir que las personas que trabajan satisfactoriamente vuelvan más contentos a su casa merece la pena plantearlo. En cuanto a los intereses empresariales, a la larga se pierden más recursos en lograr que los trabajadores desmotivados respondan bien que lo que se invertiría tratando de aportar un ambiente laboral que potencie la felicidad. Entre otros motivos, esto es debido a que las acciones correctivas tomadas para conseguir que quienes no quieren trabajar trabajen suelen derivar en recorte de condiciones tanto para pecadores como para justos. El resultado es que quienes no trabajaban antes siguen sin trabajar y los que trabajaban antes sienten que se les castiga sin motivo. La degradación de la motivación de los trabajadores sigue una progresión geométrica.

En contra de lo que puede parecer, un ambiente feliz no requiere de futbolines o salas de masajes. Tampoco de subidas de sueldo ni de más días de vacaciones. Esos beneficios se aprecian los primeros meses, pero a continuación se convierten en un derecho adquirido: si mi jefe, mi empresa o mi entorno me hacen sentir mal sistemáticamente, me sentiré mal cobre lo que cobre, porque el dinero no puede suplir todo el tiempo una mala emoción; es como mezclar peras con manzanas.

jueves, 18 de febrero de 2021

No confundas al cliente con el usuario

Existen dos diferencias fundamentales entre el cliente y el usuario: la primera, de índole técnica, reside en que el cliente no va a enfrentarse con el sistema una vez implantado (a menos que también sea usuario); la segunda, derivada de la primera, es que mientras que el cliente suele desear que el proyecto sea un éxito, esto no siempre sucede con los usuarios.

¿Por qué? El origen pasa por un problema interno de la empresa, en general de comunicación y motivación. Comunicación porque tal vez no se les explica a los trabajadores el interés de la empresa por cambiar el sistema actual o instalar uno nuevo. Y motivación porque exista un problema de personal previo a la decisión, se excluya al usuario final de la planificación y/o el usuario piense que el cambio no servirá para nada, perjudicará su trabajo diario e incluso pondrá en peligro su estabilidad laboral.

Independientemente de cuáles sean las peculiaridades de la empresa y la actitud inicial de los usuarios, ganárselos es tan importante como conseguir mantener la implicación del cliente. Muchos proyectos finalizados, entregados, probados y perfectamente funcionales ni siquiera han empezado a utilizarse por la negativa de los usuarios y la desidia de la dirección ante esta actitud. La muerte por inanición de los programas es un peligro real, y más habitual de lo que sería deseable.

Así pues, no hay que escatimar recursos para estar cerca de los usuarios, conocer sus problemas con los sistemas actuales y qué esperan de la solución que se está desarrollando. Busca a la persona con más carisma de tu equipo de trabajo y acércalo a quienes en última instancia y en el mejor de los casos tratarán directamente con la aplicación, que les muestre los prototipos tal y como se les envían al cliente, y que comunique y tenga en cuenta cualquier sugerencia que escuchada.

viernes, 12 de febrero de 2021

Gestión de mensajes

La gestión eficiente de mensajes merece una atención especial en el campo de la construcción de software por dos razones: reutilización y, opcionalmente, internacionalización. La reutilización es común a todas las aplicaciones; resulta tedioso tener que escribir un mensaje de error varias veces a lo largo de un programa. Respecto a la internacionalización, la escritura de dicho texto directamente en el código fuente hace inviable que el sistema pueda traducirse a otros idiomas.

Existen dos formas de optimizar la gestión de mensajes: una, dependiente del entorno de desarrollo, consiste en utilizar archivos de recursos específicos de aquél en los cuales pueden definirse diferentes mensajes en varios idiomas; la otra, independiente, utiliza archivos propios o tablas en la base de datos para la gestión de mensajes. Me centraré en la segunda, al ser más general, teniendo en cuenta que no todos los entornos facilitan el trabajo con archivos de recursos.

La solución es tan sencilla como definir una serie de tablas como las siguientes: 

Tabla

Campo

Tipo

Error

Id

int32

Id_Language

int32

Code

int32

Message

varchar(512)

 

 

 

Tabla

Campo

Tipo

Language

Id

int32

Name

varchar(32)   

donde a continuación se muestran valores de ejemplo:

Id

Id_Language

Code

Message

1

1

1

El valor {0} de la variable/parámetro '{1}' debe estar en el rango {2}.

2

1

2

La variable/parámetro '{0}' no puede ser nulo o vacío.

3

2

2

Variable/parameter '{0}' can't be null or empty.

[...]

[...]

[...]

[...]

Id

Name

1

Spanish

2

English

[...]

[...]

De igual modo, se crea una clase Error con un código similar al propuesto (en este caso, en C#):


public static class Error
{
  // Deben corresponderse a los identificadores equivalentes
  // de la tabla Error

  public enum EError { InvalidRange = 1, EmptyOrNull = 2, […] }
  public enum EErrorType { Error, Fatal }

  public void PrintError(EError eError, params Object[] aoValue) {
    Print(EErrorType.Error, eError, aoValue);
  }

  public void PrintFatal(EError eError, params Object[] aoValue) {
    Print(EErrorType.Fatal, eError, aoValue);
  }

  private void Print(EErrorType eErrorType, EError eError,
    params Object[] aoValue) {
    MessageBox.Show(Messaje(eError, aoValue), ErrorType(eErrorType));
  }

  prívate string ErrorType(EErrorType eErrorType) {
    return eErrorType == EErrorType.Error ? "Error" : "Fatal";
  }

  private string Message(EErrorType eErrorType, EError eError,
    params Object[] aoValue) {
    return String.Format(MesssagePattern(eError), oValue);
  }

   private string MessagePattern(EError eError) {
    return (Database.MessajeError((int)eError,
      (int)Config.CurrentLanguage).ToString();
  }
}

Donde Database y Global son clases estáticas para acceso a información de la base de datos (en este caso, el mensaje del error) y para almacenar la información de configuración de la aplicación, respectivamente.


Con este código y el correspondiente cuidado al cargar la tabla en la base de datos, pueden gestionarse fácilmente los mensajes de error. Asimismo, la modificación del texto de los mensajes de error y la inclusión de nuevos idiomas no necesita la parada del sistema.