Archive for March, 2009
Blogs dentro de 20 años
Posted by Leonel in Internet, Temas generales on 29 March 2009
Pensaba en lo que escribí en el artículo anterior sobre que ponía los precios de los ingredientes para poderlos revisar dentro de 20 años.
En realidad no se si dentro de 20 años este blog todavía existirá, pero supongamos que sí.
Si uno toma un libro impreso hoy y lo compara con un libro de hace 20 años se encuentra diferencias visibles: el material en que está impreso, los tipos de letra, las ilustraciones, los colores, la diagramación, el estilo de escritura, y otros detalles. Pero lo esencial se mantiene: el libro es para leerlo.
Yo creo que con los blogs pasará algo parecido. Dentro de 20 años habrá otros estilos de blogs con más imagenes, videos y otros contenidos multimedia, que demanden anchos de banda mayores a los que están disponibles hoy en día. Pero lo esencial se mantendrá, es decir, la gente querrá siempre comunicar sus experiencias e interactuar con sus lectores.
Por ejemplo, el blog de Nancy Arroyave, Historias Citadinas, tiene historias muy bonitas y nos gusta leerlo en familia. Actualmente tiene ya una cantidad considerable de artículos ya que ella es muy constante en escribir cada semana.
Hoy nos parece que es muy fácil leerlo y encontrarlo, pero dentro de 20 o 30 años las cosas pueden ser ligeramente diferentes. Digamos que para sus descendientes de ese entonces, descubrirlo entre la enorme cantidad de contenidos que estarán disponibles en el futuro, será como encontrar un viejo arcón del abuelo refundido en un cuarto de “chunches” como decimos en Guatemala y descubrir un mundo nuevo leyendo lo que el antepasado escribió por aquel entonces.
La primera página que tuvimos en Geocities. Un día de estos la tengo que actualizar. Ya ni siquiera vivimos en Huehuetenango.
Yo ya escuché en una conferencia en el congreso “LA-Web” del 2006 cómo los contenidos van envejeciendo y en ocasiones rescatarlos puede ser tan difícil como rescatar las estelas mayas que se han perdido.
Tenemos los motores de búsqueda y ayudan mucho, pero tarde o temprano tendremos que afrontar el hecho de que o la tecnología deje de ser capaz de manejar cantidades tan grandes de información o simplemente la cantidad de información disponible exceda nuestras capacidades intelectuales.
No es tan descabellado como parece. Basta con ver la cantidad de información que uno almacena en las computadoras personales. Es muy difícil decir que uno está perfectamente conciente de todo lo que tiene guardado, o de todos los correos que ha recibido y leído.
Conclusión: Yo espero que la emoción de encontrar el diario del tatarabuelo al revisar arcones viejos se traslade también a la Web, cuando descubramos el blog del tatarabuelo.
Muffins de fin de semana
Los ingredientes listos
Hemos ido experimentando diferentes formas de prepararlos y diferentes carnes y aderezos. Yo hago el experimento y mis hijos y mi esposa dan su veredicto.
Por este método de prueba y error, y ya con el tiempo que llevamos desde que decidimos que desayunar en casa era más económico y divertido, hemos llegado a un platillo que nos gusta bastante y que sabemos que se prepara bien y rápido, a un precio mucho mejor que el de los restaurantes comerciales.
Es ideal contar con un buen ayudante
Para que quede en el recuerdo voy a ir poniendo los precios aproximados junto con los ingredientes así cuando vea este artículo dentro de 20 años voy a poder suspirar por los precios de ahora.
| 1 bolsa de 6 panes muffin | Q.17.50 |
| 1 bandeja de lomo relleno de 10 rodajas | Q.17.50 |
| ½ libra de queso en rodajas | Q.19.50 |
| 1 salsita preparada | Q.3.00 |
| Margarina o mantequilla | Q.1.00 |
| 2 huevos | Q.6.00 |
| Total para 6 muffins | Q.64.50 |
Sobran rodajas de lomo relleno y de queso, así que el costo exacto es todavía menor.
Para prepararlos se pone a asar el lomo relleno ya sea en una sartén o en un horno tostador. Esto del horno tostador lo descubrimos en uno de los tantos experimentos que hemos realizado. Resulta que ponerlos en el horno tostador tiene muchas ventajas: se asan de forma uniforme, requieren mucho menos atención que al utilizar una sartén, se puede controlar bien el tiempo que se utilizará, ensucia menos, en fin, una maravilla. También se podría utilizar una parrilla o algún otro artilugio de cocina moderno, lo importante es no usar el lomo relleno “crudo”, ya que el sabor es completamente diferente.
Asar el lomo en el horno tostador es una buena idea
Si se utiliza el horno tostador se requiere como 15 minutos para asar las 6 rodajas. Hay que darles vuelta a la mitad de ese tiempo para que se asen bien de los dos lados.
Los panes se parten en dos rodajas, se untan con margarina o mantequilla y se tuestan. Al terminar de tostarlos se les pone una rodaja de queso y una de lomo relleno, un poco de salsita preparada y listo.
Se termina de preparar los muffins poniendoles queso y la carne entre tapa y tapa. El día que tomamos estas fotos también habíamos preparado hot-dogs.
A mis hijos no les gusta que sus muffins lleven huevo, pero a mi esposa y a mí sí nos gusta, así que los preparamos revueltos ya sea en omelet, revueltos o en el horno de microondas y se lo agregamos al muffin.
El microondas puede cocer huevos perfectos para muffins en 3 o 4 minutos, quedan muy bien con un poco de leche de soya, si es en polvo hay que disolverla antes de agregarle los huevos
Quedan deliciosos. Otro día les cuento de cómo hacemos los burritos, los hot-dogs, los omelet, etc.
¡A comer!
El ciclo de ingeniería
Posted by Leonel in Diseño, Ingeniería, Usabilidad on 22 March 2009
Las cuatro actividades principales del ciclo de ingeniería: analizar, diseñar, construir, evaluar.
En este artículo, “Usability Engineering Turns 10”, publicado en la revista especializada Interactions de la ACM, Butler explica en qué consiste la ingeniería de la usabilidad y por qué puede considerarse una rama de la ingeniería con todo derecho.
Su argumento básico es que sigue el ciclo de ingeniería. Hasta ese momento la usabilidad era para mi algo así como la aplicación de la teoría conocida sobre factores humanos, computadoras y usuarios para construir sistemas que fueran fáciles de usar y de entender, eficientes y satisfactorios. Pero no la entendía como una ingeniería.
Tampoco estoy seguro de que yo entendiera bien cuál es la esencia de la ingeniería, y eso a pesar de que para ese entonces llevaba ya más de 3 años de haberme graduado y más de 10 de haber cerrado ingeniería y estaba estudiando la maestría.
El ciclo de ingeniería consiste en una serie de actividades que se realizan iterativamente en cada proyecto. En mayor o menor medida el ingeniero las planifica y ejecuta una o varias veces si es necesario, de acuerdo a la naturaleza del proyecto.
Para algunos proyectos de ingeniería el ciclo se ejecuta una sola vez, pero en otros, especialmente en los de ingeniería de sistemas, el ciclo puede recorrerse varias veces hasta alcanzar la solución. Se construyen múltiples prototipos que pueden desecharse hasta llegar a la versión final.
En el diseño se plantea la solución a implementar. A pesar de que la solución puede ser de común aplicación en la industria o para el tipo de problema que se intenta resolver, la adaptación que se requiere para las circunstancias concretas puede implicar una innovación considerable. Si la solución es novedosa entonces resulta innovadora por sí misma. Así que todo diseño de ingeniería siempre implica innovación.
Luego inicia la construcción. Tanto el diseño como la construcción son etapas bien específicas para cada rama de la ingeniería, no se ejecutan igual si se trata de un proyecto de ingeniería química o de ingeniería mecánica y definitivamente no con las mismas perspectivas. Se puede decir que la construcción es la parte administrativa de un proyecto de ingeniería, ya que implica planeación, organización, dirección y control, que son las cuatro funciones administrativas comúnmente aceptadas. Dependiendo del proyecto la construcción puede resultar la etapa más larga.
En la evaluación se hace un examen de cómo se llevó a cabo el proyecto, si se resolvió el problema que se había planteado y si se hizo de una forma efectiva y eficiente. Puesto que no es conveniente dejar esta etapa exclusivamente para el final, ya que ayuda a identificar errores y efectos negativos que es importante resolver tan pronto como sea posible, es común que las evaluaciones se hagan con cada etapa parcial del proceso de construcción.
El ciclo se cierra cuando del resultado de la evaluación se desprenden nuevos problemas que requieren nuevamente de análisis, diseño, construcción y evaluación.
Algunos autores definen un ciclo de ingeniería con más actividades principales de las que se plantearon aquí. A mi me parece que estas cuatro especifican muy bien lo esencial de cualquier ciclo de ingeniería y que de hecho identifican lo que podríamos llamar el método de ingeniería, pero eso será tema de otro artículo.
Encabezado del artículo de Butler, publicado en 1996 en la revista Interactions de la ACM.
¿Por qué son tan aburridos los libros de programación?
Posted by Leonel in Ingeniería, Programación on 18 March 2009
El ciclo de programación son los pasos que se ejecutan iterativamente al programar.
Pero cuando se intenta hacer lo mismo con un libro de programación el resultado es muy diferente.
No creo que mi percepción que se deba a que la programación es una de mis grandes pasiones, ni tampoco a que en general se le considera un tópico “complicado”. Lo que creo es que los libros de programación están en general muy mal hechos.
Para empezar la programación es algo eminentemente práctico y por lo tanto no se aprende leyendo teoría sino programando. Usualmente se enseña algo de teoría, pero la relación es más o menos de 20% de teoría contra 80% de práctica. Siguiendo esta fórmula muchos libros de programación parecen una mezcla de 20% de libro de matemáticas y 80% de libro de instrucciones para armar muebles “hágalo Usted mismo”.
En el diseño se visualiza la estrategia a seguir para resolver el problema, usualmente con un algoritmo.
Como consecuencia cualquier libro de programación que uno tome del anaquel de una biblioteca probablemente está desactualizado en el lenguaje que utiliza aunque sus conceptos teóricos sigan vigentes la mayoría.
Tomar un libro de programación y pretender leerlo nada más significa que uno tendrá que negarse a poner en práctica inmediatamente los conceptos que están expuestos en él, lo cual no es sencillo porque los ejemplos abundan y no son como los de un libro de física, con el que basta tomar papel y lápiz para “practicar”, lo lógico con la programación es ir a la computadora y programar.
En la codificación se lleva el diseño a código en el lenguaje que se esté utilizando.
Por supuesto, para eso es más útil una referencia del lenguaje, con lo cual el libro de programación pierde buena parte de su razón de ser.
Hay que repensar la forma en que se estructuran los libros y los cursos de programación. Para empezar hay que abandonar completamente la idea de que se utilice exclusivamente un lenguaje concreto como herramienta de apoyo. Algunos lenguajes son mejores que otros para mostrar técnicas como recursión, estructuras de control, manejo de errores, tipos de datos, algoritmos básicos, manejo de números, construcción de interfaces de usuario, etc.
Las pruebas implican ejecutar el programa en variedad de escenarios.
Para evitar el problema de que el lector quiera probar cómo funciona el ejemplo hay que cambiar el enfoque y convertirlos en retos del tipo ¿qué hace este código? ¿Qué error tiene? ¿Dónde podría mejorarse? ¿Es eficiente al aumentar la cantidad de entradas? Este tipo de razonamiento inducido es más beneficioso que simplemente copiar el texto en la computadora y ejecutarlo.
Luego hay que centrarse en las competencias básicas de un programador: recorrer el ciclo de programación, diseñar un programa antes de codificarlo, utilizar patrones, leer y entender código que no ha sido escrito por él en un lenguaje que no es el que domina, encontrar errores y depurarlos, etc.
Por supuesto el enfoque no es el mismo si se trata de libros dirigidos a estudiantes de primaria, secundaria o universitarios; si la carrera está relacionada con Ciencias de la Computación o si la programación se toma como una materia auxiliar. Pero definitivamente creo que se puede hacer algo mejor que revisar tediosamente todas las posibles estructuras y comandos de un lenguaje particular, que es lo que hacen buena parte de los libros que conozco.
Corregir cada problema o mal funcionamiento encontrado y volver a empezar el ciclo.
Siempre he dicho que para cualquier ingeniero la habilidad de programar es tan básica como resolver ecuaciones o hacer un diagrama de fuerzas. La diferencia con los ingenieros de sistemas no es más que el enfoque y probablemente la intensidad. Así que tenemos una gran necesidad de buenos libros de programación, bien orientados y que puedan ser leídos con gusto aún 10 años después de haberse utilizado en un curso.
Algún día espero poder escribir un libro así.
Ya es tiempo de dejar el diskette
Posted by Leonel in Interfaz de Usuario, Usabilidad on 12 March 2009
El floppy de 3 1/2
Hace unos días, caminando por los pasillos entre cubículos de las oficinas donde trabajo, me di cuenta que en el escritorio de alguien habían unos diskettes (disquettes o floppies) y me pregunté inconcientemente que para qué querría alguien usar esos discos hoy en día.
Lo más extraño fue que al poco tiempo me di cuenta de que casi todos seguimos usando esos artefactos arcaicos, no en su forma física, sino como un pequeño dibujito, muy bien conocido, al que llamamos “ícono de guardar”.
Este bien podría ser uno de esos casos en los que algo se sigue usando no porque sea bueno sino porque la fuerza de la costumbre es tal que nos obliga a continuarla y a no considerar siquiera la posibilidad del cambio.
Office 2007 con diskette
Revisé cuidadosamente y aún las aplicaciones más recientes que tengo disponibles siguen usando ese ícono: Microsoft Office 2007, Adobe Reader 8.0, y otros. Nadie se atreve a cambiarlo porque los resultados para la usabilidad del producto podrían ser negativos.
Cuando los disquettes pasaron de ser de 8 pulgadas a 5 ¼ no hubo problema porque prácticamente nadie usaba GUIs – Graphical User Interface – y por tanto no habían íconos. El primer GUI de gran difusión fue el de la Mac, lanzada al mercado en 1984, hace 25 años, y cuando le siguió Windows de Microsoft, la transición del disco de 5 ¼ a disco de 3 ½ no fue problema, básicamente se cambió de color al ícono, de negro a azul o gris, sin que se avizorara inconveniente alguno para los usuarios finales.
Pero con la introducción masiva de las memorias USB la transición no fue tan simple. Hubo un tiempo, entre 1995 y el 2000, en que no estaba claro cuál sería el sucesor del diskette o siquiera si habría sucesor.
Para guardar un PDF en IE se hace clic en un diskette
Los discos compactos o CD-ROM, no fueron aceptados masivamente por lo complicado de su selección a la hora de comprarlos – había que elegir entre varias opciones y uno nunca estaba seguro de cual comprar, si la R o la RW o cualquier otra – y al momento de querer guardar en ellos había que recurrir a un programa especial que se tomaba su tiempo hasta para agregar un solo archivo.
Así que nunca vimos un ícono de guardar con forma de CD-ROM y si lo vimos no nos acordamos.
Las memorias USB solucionaron el problema de la facilidad de uso, eran fácilmente aceptadas por los sistemas operativos más modernos – salvo Windows 98 que requería instalar los drivers – y se integraban transparentemente al sistema de archivos.
Omnipresente diskette
Pero no hemos visto íconos con forma de memoria USB por un problema básico: ¿Qué forma tiene una memoria USB?
El ícono de guardar se debe asociar fácilmente con el dispositivo en que se guarda, para que el usuario intuya la operación que se realiza al presionarlo. Pero si la imagen no es identificable entonces se compromete la intuitividad. ¿Resultado? Nadie se atreve a poner un ícono de guardar con forma de memoria USB.
Lo mismo pasa con los discos duros. Como usualmente no se ven, tampoco se conoce qué forma tienen.
El floppy sigue saludable
Para mí, la solución sería no tener ícono de guardar, de hecho no tener siquiera el concepto de archivo. Los archivos son un concepto arcaico relacionado con cómo se guarda la información en la computadora y yo no soy el primero que opina que los usuarios finales no deberían tener que preocuparse por cómo guarda la computadora la información. Jeff Raskin ya lo decía y otros también.
Pero como nadie se atreve a cambiar algo a lo que se supone que todos ya estamos acostumbrados, seguimos teniendo diskettes, lo mismo que teclados QWERTY cuando desde hace mucho tiempo se sabe que el DVORAK sería mucho mejor, seguimos con teclas que ya no se usan como “Scroll Lock”, “Pause/Break”, “SysRq” y la mayoría de las “Fx” (F1 a F12).
Bueno, para ser honesto tengo que reconocer que Microsoft implementó un cambio radical en su interfaz de Office 2007 y lo hizo sin mirar atrás, o sea, sin incluir una opción para regresar al interfaz anterior. El diskette demostró su fortaleza y su ícono aparece con todo su esplendor. Si esto es bueno o malo no lo sabría decir.
Intentar hacer un ícono de guardar que se pueda asociar con memorias USB no es la mejor opción, pero como parece que tendremos ese ícono presente en nuestras computadoras por largo rato, ¿qué tal si ideamos uno mejor?
El diseño en ingeniería
Posted by Leonel in Diseño, Ingeniería on 9 March 2009
Feria de Ingeniería en la Universidad Rafael Landívar en Guatemala
Un diseño es la expresión de una idea que soluciona de forma innovadora un problema concreto y sirve de guía para llevarlo a la práctica, es decir, para construirlo y evaluarlo.
De todas las ramas de la ingeniería, los planos de construcción en las obras civiles son la expresión más popular de diseño. Con el tiempo han alcanzado un buen nivel de accesibilidad y muchísimas personas sin formación técnica pueden entenderlos sin mayor explicación.
No ocurre lo mismo en el resto de ramas de la ingeniería. En mayor o menor grado es posible pasar directamente del análisis a la construcción sin tener un diseño bien especificado.
Probablemente se deba a que el ingeniero es una persona práctica que se apasiona por solucionar un problema en cuanto termina de planteársele. Esta pasión, sin embargo, puede jugar en contra de la eficiencia en el proceso e incluso poner en riesgo todo el proyecto.
El caso más crítico es el de la ingeniería de sistemas informáticos, donde a menudo de hecho apenas se cubre algo del análisis y se pasa directamente a la codificación, que aquí equivale a la construcción.
Un profesor universitario lo resumía de esta forma “their design was the code” o “su diseño era el código”, como tratando de decir que simplemente habían empezado a codificar sin ningún diseño.
Las desventajas de trabajar sin diseño son muchas: falta de una orientación adecuada para el equipo, ya que cada miembro puede tener ideas diferentes sobre lo que se quiere construir; se puede adelantar mucho en la construcción y tener que desecharlo todo por falta de consistencia o porque simplemente se asumió algo que después resulta incorrecto; se le dedica demasiado tiempo a aspectos del problema y se descuida otros de igual o mayor importancia; no hay forma de evaluar si lo que se ha avanzado corresponde en tiempo y esfuerzo a lo que se habría esperado; y un largo etcétera.
Una vez más, hay fallos en la formación universitaria del ingeniero que promueven este vicio. Para empezar muchos profesores alientan a los alumnos a iniciar el trabajo sin exigir que primero se tenga un diseño. Simplemente asumen que no es necesario, que ya habrá otro curso en donde se les enseñe eso o que para el caso particular no aplica.
Los diseños pueden tomar muchas formas: prototipos, maquetas, esbozos en papel, diagramas, dibujos, storyboards (secuencias de dibujos que muestran cómo funcionará el artefacto terminado). En ingeniería de sistemas son muy populares los diagramas UML pero aunque son una excelente herramienta de ninguna forma se pueden considerar suficientes, sobre todo para sistemas interactivos que involucran usuarios. En estos es muy necesario acudir a los bosquejos, prototipos en papel, y otras formas de modelado, para dar oportunidad al usuario final de revisar si lo que espera del sistema es en realidad lo que se está construyendo.
Diseñar implica tomar decisiones. Se escoge una opción y se elimina el resto de posibilidades, para definir el diseño concreto. Estas decisiones implican criterio, compromiso y responsabilidad. Criterio porque no se pueden tomar simplemente por gusto o por conveniencia propia. Compromiso porque la decisión tomada debe acompañar todo el ciclo de ingeniería hasta la evaluación final, estando preparado para recibir cuestionamientos si hace falta. Responsabilidad porque las decisiones tomadas afectarán no solo a la obra construida sino a todos los involucrados, incluyendo a los usuarios finales.
En una conferencia del Dr. Fernando Cajas le escuché decir que más que matemáticas y física – materias tradicionalísimas en las escuelas de ingeniería – lo que había que enseñar era cómo diseñar.
Diseñar en ingeniería es idear un artefacto que resuelve un problema concreto – en oposición a un problema general, que estaría más relacionado con investigación. Enfocarse demasiado en las habilidades numéricas y los problemas abstractos que presentan las matemáticas y la física solo confina a los estudiantes a un ámbito muy restringido del universo de situaciones que enfrentan los ingenieros como profesionales. Lo peor que podría pasar es que ellos creyeran que de eso se trata la ingeniería.
Por supuesto que tiene muchísimo que ver con matemáticas y física, pero definitivamente va mucho más allá.
Viviendo en el centro histórico de Guatemala
Posted by Leonel in Centro Histórico Guatemala, Ciudad de Guatemala, Temas generales on 5 March 2009
Museo del Ferrocarril en la Plaza Barrios
Sin que casi nos diéramos cuenta llevamos ya más de dos años de vivir en el Centro Histórico de la Ciudad de Guatemala. Más bien, en su orilla sur, en la frontera con la zona 5, cerca del barrio Gerona y de la antigua estación del ferrocarril que ahora es un museo y de la hermosa Plaza Barrios, donde está la estación del Transmetro.
Todos los días voy a dejar a mi hijo varón al colegio, en bus, y luego tomo otro bus para ir a trabajar. De la oficina regreso a la casa usualmente caminando y no me toma más de 20 minutos. En vacaciones camino de ida y de regreso.
Paso por la 18 calle de vez en cuando, sobre todo cuando tengo que ir a Paiz de la 7ma avenida a comprar algo. Si no hay o está muy caro me paso a La Casita, que queda justo enfrente. No tiene tanta variedad pero los precios son un poco más bajos.
A veces vamos a comprar películas a las ventas que están entre la 5ta y la 7ma, siempre de la 18 calle, y si queremos poder escoger bien entre una ordenada selección por género o por autor, caminamos hasta el centro comercial Capitol donde hay vendedores verdaderamente apasionados por el orden y que tienen colecciones de películas dignas de un verdadero cinéfilo.
Muchas veces me he maravillado de la belleza de las calles del Centro Histórico. Ver esas viejas casas tan elegantes, manchadas de pintas, cubiertas de hollín de camioneta o escondidas tras verdaderas madejas de cables y alambres del tendido eléctrico, me hace pensar cómo debieron sentirse los Mayas cuando veían a los españoles quemando sus códices y sus ciudades.
Mucha gente se admira cuando les contamos que vivimos en el centro. Es por todo lo que se oye, del peligro, de los asaltos, de la inseguridad. Definitivamente no es lo mismo que vivir en una colonia donde tras un muro o cerca, con entrada controlada por garita, se siente cierta seguridad, pero tiene sus ventajas: estamos cerca de todo, ahorramos mucho en transporte (y en estrés de tráfico) y vivimos en el área del país donde hay mayor densidad de cultura, museos, teatros, arte, arquitectura, parques, etc.
Hay mucha miseria, eso sí, en cada esquina se puede encontrar un mendigo pidiendo limosna, y una moneda en la bolsa le puede crear a uno una enorme responsabilidad ¿a quién de todos se la doy? porque no hay juicio que pueda juzgar a ciencia cierta la necesidad humana, y para cualquiera de ellos, por muy pequeña que sea la moneda, le puede resultar una gran fortuna.
Con todo, el Centro Histórico está cambiando. Despacio pero visiblemente. Hace 20 años yo tomaba el bus cuando iba camino a San Felipe, Retalhuleu, a ver a mis papás en la 9na avenida y 18 calle, donde ahora está la estación del Transmetro. Pararse ahí ahora y pensar en cómo era en 1989 es como meterse a una cápsula del tiempo. Por supuesto que hay cosas que no han cambiado, pero eso también es positivo.
Definitivamente, ambas cosas me gustan.
Trabajo en equipo e ingeniería
Posted by Leonel in Ingeniería, Trabajo en equipo on 2 March 2009
Alumnos de un curso de electrónica preparándose para presentar su proyecto
La ingeniería hoy en día implica necesariamente el trabajo en equipo. Aunque algunas de las actividades de análisis y diseño se pueden realizar individualmente, sin consultar con nadie, valiéndose únicamente de la propia creatividad y experiencia, el resto del trabajo en el ciclo de ingeniería requiere en la gran mayoría de casos de otras personas que colaboren en la empresa.
Los ingenieros deberían ser personas acostumbradas a trabajar en equipo, pero lo extraño del asunto es que en general, en las escuelas de ingeniería, se le pone poca atención a enseñarle al futuro profesional cómo trabajar en equipo. De alguna forma se asume que el estudiante ya sabe cómo hacerlo, que lo aprenderá intuitivamente o que quizás no es que deba “aprenderse” sino más bien se trata de algo a lo que hay que “acostumbrarse”.
Hay que distinguir el “trabajo en equipo” del “trabajo en grupo”. El segundo es muy fácil de reconocer: una pequeña porción de los integrantes de verdad trabaja, o hace el esfuerzo por trabajar, y el resto funciona como asistentes o personal de apoyo y que cuando no tienen una tarea concreta asignada se dedican a cualquier cosa que se les antoja.
Los grupos de 5 personas para hacer una tarea en la universidad suelen estar organizados así: uno trabaja, otro prepara comida para todos, otro pone la casa, otro hace de chofer y el último no hace nada. Con ligeras variaciones esto es bastante estándar.
Y es una pena, porque la mayor parte del tiempo en la universidad o en los últimos años de colegio se la pasa uno haciendo trabajos en grupo y podría estar sacándole provecho a esa experiencia aprendiendo a trabajar en equipo.
Los verdaderos equipos se caracterizan por varios factores clave:
- Tienen una meta en común y es bien conocida por todos. Todos saben hacia dónde van, qué ruta están siguiendo – conocen no sólo el objetivo final sino las metas intermedias – y cuál es la situación actual. Las razones por las que desean alcanzar un objetivo determinado han sido discutidas y aceptadas por todos y una vez que eso ha ocurrido no se discuten más, aunque pueden ser revisadas si la situación lo amerita.
- Cada cual sabe qué papel desempeña y lo considera importante. En un verdadero equipo no hay tareas pequeñas o grandes, todas son importantes y valiosas.
- Todos respetan y valoran el aporte de los demás. Esto se deriva del punto anterior. Como no hay tareas grandes o pequeñas, el aporte de cada uno es apreciado como contribución para la consecución del objetivo que se busca. De este respeto se deriva la confianza en que cada miembro realizará sus tareas de la mejor forma posible y con responsabilidad.
- Se ejercita el liderazgo. El liderazgo se entiendo como la capacidad de guíar, conducir y motivar a un equipo. La base del liderazgo no es la autoridad impuesta por la fuerza o por el deber, sino el auténtico deseo de servir y ayudar al equipo a conseguir el objetivo. Por eso hay muchas formas de liderazgo, algunas se basan en el conocimiento, es el caso de las personas cuyo consejo y orientación se estima, en el carisma de quien ayuda al resto a adoptar una decisión difícil porque transmiten su propia seguridad, etc. El liderazgo en los verdaderos equipos no es estático, ya que puede cambiar en función de las circunstancias.
- Comunicación. La información es la base de la coordinación de esfuerzos. Los buenos equipos acostumbran a detener su trabajo para que cada miembro informe al resto de los progresos que ha alcanzado, de los problemas que enfrenta y de los soluciones a las que ha llegado. Esta comunicación permite el enriquecimiento de las tareas de los demás.
Esta lista no pretende ser exhaustiva, y de igual forma, este artículo no es un tratado completo del trabajo en equipo. Hay muchas cosas más qué decir sobre el trabajo en equipo. De momento baste este pensamiento: el trabajo en equipo es una poderosa fuerza que podemos explotar para conseguir grandes obras de ingeniería.
Comentarios recientes