Pláticas casuales, conexiones reales

Las pláticas casuales son esas conversaciones que tienes con una persona a la que no conoces tanto y, por eso mismo, no tienes mucha confianza como para hablar de cualquier cosa. Estas suelen ocurrir, por ejemplo, cuando recién te presentan a alguien; pero donde más me toca que pasen es poco antes de iniciar una junta, mientras estamos esperando que lleguen todas las personas requeridas.

Lo que se habla son cosas sin importancia, cosas que quizás son obvias (como que está haciendo frío). Hace tiempo no me gustaba tener estas conversaciones. De hecho, aún no sé si me gustan porque a veces no sé qué decir y no me agrada mucho decir lo obvio o hablar de un tema cliché. Sin embargo, a través de los años me he dado cuenta de que esas conversaciones tienen su valor. No es por el tema en sí, sino porque ayudan al equipo a tener una relación, a romper el hielo e incluso a formar, poco a poco, una amistad con el resto del equipo.

He notado que muchas personas que se dedican a la tecnología como yo evitan estas conversaciones; incluso, algunos me han llegado a decir que las odian. A veces prefieren llegar tarde a las reuniones para saltarse esa platiquita y entrar directamente en el tema de la reunión. Confieso que yo también he hecho esto en varias ocasiones.

También he sido testigo de personas que evitan completamente estas charlas y pueden hasta llegar a ser groseras evitándolas, pensando quizás que son temas tontos. No se dan cuenta de que el tema es lo de menos. El propósito de la plática no es realmente saber cómo estás ni es crucial para el trabajo saber qué hiciste el fin de semana. En realidad, el propósito de la conversación es prestar atención a la otra persona, demostrar interés y construir una conexión que puede mejorar la dinámica del equipo.

Aunque estas pláticas casuales pueden parecer triviales, tienen un propósito importante en el trabajo en equipo. Facilitan la creación de relaciones personales y he visto que pueden mejorar el ambiente de trabajo y la relación entre los miembros del equipo. Así que la próxima vez que te encuentres esperando a que comience una reunión, considera que unos minutos de conversación ligera pueden tener un impacto positivo en tu equipo.

Tú, no eres tu código

Escribir código puede sentirse muy personal, sobre todo si pasas mucho tiempo pensando en él, diseñando, escribiendo, editando y quizás reconstruyendo módulos para lograr que se vea mejor. Puedes sentir orgullo por el código que escribes y por lo tanto, llegar a pensar que es parte de ti; pero la verdad es que: el código, no es parte de ti, es solamente algo más que hiciste.

Tú, no eres tu código. El código representa el nivel que tenías cuando lo escribiste; pero no te representa a ti como persona. Eso significa que está bien hablar de tu código con confianza, ver las fallas y oportunidades de mejora sin sentir que estamos hablando de las fallas de la persona que lo escribió. Una cosa es hablar de las fallas del código y una muy distinta hablar de las fallas de la persona.

Lo mismo aplica a las ideas acerca de la arquitectura y los procesos que debemos seguir para crear un producto de software. Alguien puede sugerir que se use algo diferente o usar algo de manera distinta. Esa persona puede sugerir cosas que quizás ya son obsoletas para ti. El sentir que sus ideas son viejas u obsoletas no significa que pienses que esa persona es vieja u obsoleta. Puede pasar que seas tú esa persona que sugiere cosas que para alguien más ya no se usan. Debes de no tomarlo personal para que así puedas evaluar las alternativas que te están sugiriendo. Si lo tomas como un ataque a tu persona será difícil poner atención a las ideas que proponen, se complicará ver las fallas de tu idea y poder aprender de eso.

Cada que veas código viejo escrito por ti, puedes sentir orgullo, eso está bien; pero también deberías de sentir un poco de "vergüenza", porque ahora puedes ver muchas mejoras que le puedes hacer, esos detalles que no viste porque fue ya hace tiempo y no tenías la experiencia que ahora tienes. Si ves tu código viejo y no sientes algo de pena, entonces quizás no estás mejorando tus habilidades para programar. Para ayudar con eso, debes dejar que otros comenten lo que opinan de tu código, sin tomarlo personal e incluso si no estás de acuerdo. También intenta leer cómo otras personas resuelven esos mismos problemas con nuevos estilos, busca cómo innovar.

Primero la pregunta y después el contexto

A veces cuando alguien quiere hacerme una pregunta, empieza por darme contexto sobre el tema del que va a preguntar. Me empiezan a explicar cómo fue que llegaron a la pregunta que tienen en mente. Algunos comienzan por explicarme lo que han intentado para resolver el problema que enfrentan, me explican el porqué de esos intentos. Ha habido, incluso, ocaciones en que me explican las respuestas que han encontrado en internet; pero todo esto sin haberme hecho la pregunta todavía.

Comprendo que me dan el contexto para ayudarme a encontrar la mejor respuesta, también lo hacen para que no crea que no han intentado encontrar la respuesta por su cuenta; o quizás para que no piense que me consultan sin tener una buena razón. Entonces empiezan por justificar el porqué de la pregunta sin siquiera haberme hecho la pregunta todavía. 

El contexto de la pregunta es importante, sirve para saber de qué estamos hablando en realidad, lo cual es bueno para dar una respuesta correcta. Entender el porqué sin saber el qué es más complicado. El contexto o el saber qué se intentó, sí me ayuda; pero una vez que conozco la pregunta, cuando sé que problema es el que se necesita resolver. A veces ni siquiera necesito saber porqué se necesita resolver el problema, con la sola pregunta puedo dar una respuesta rápida o puedo darme cuenta que no voy a poder contestarla sin importar el contexto, en esas ocaciones iniciar con la pregunta nos ahorra a todos algo de tiempo.

Yo también hago esto, empiezo por explicar la razón de alguna pregunta en lugar de solo iniciar con la pregunta y partir de ahí. Si se necesita contexto, es bueno darlo; pero no antes de la pregunta. Intentemos iniciar con la duda y después podemos explicar lo que hemos intentado para resolverlo, lo que queremos lograr con esa respuesta o el porqué de la pregunta; pero solo después de haber hecho la pregunta. No iniciemos por el contexto, primero hagamos la pregunta.

Fighting Frustration

Some days things don't go the way I expected, sometimes people don't agree with my opinion or with what I feel is "obviously" more important to do. It's easy to start thinking that some people just don't care, if only they leave me alone and allow me to do my work, I can change the company. I can blame others when things go bad and start thinking that is their fault because they have a different opinion than mine.

But the true is that if something goes wrong, with the project I'm working, it's my fault. I should be responsible to finish the project, in time and budget, and because of that, I have to deal with all the bureaucracy that needs to be dealt with. I have to realize that I need to do that as part of my job. Besides, is not that people don't care is just that they have a different (and valid) approach than mine.

How do I deal with the frustration? Well... first I need to stop complaining, because if I start to focus in the bad and let the negativity enter my mind, all the required work will be harder. I need to stop focusing in the bad and see the challenges as an opportunity to grow my skills. If I want others to follow my lead or my ideas what I need is to show them how I can get results and being known by my results instead of being known as a complainer.

Frustration is a feeling that I need to choose not to feel, if things don't go the way I expected then I take a step back, see what it didn't worked, what alternatives do I have and then try again using another approach, all this without complains. The solution is not that others change their opinions, the goal should be for me, to understand their reasons and give them a solution that address their concerns and allow me to complete the project on time.

So... to fight frustration I will stop complaining and start doing.

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto problemas similares y conoce los problemas comunes con cada posible solución. Si no ha resulto algo similar entonces es capaz de investigar, realizando búsquedas más concretas que le dan una mejor respuesta para el problema en particular que se quiere resolver. Para una persona con más experiencia los bloqueos son cuando está esperando información de alguien más. Puede ser alguna respuesta del cliente, la definición por parte de otro equipo sobre que herramienta en particular se va a usar.

La principal diferencia es que la persona sin experiencia puede sentir que está bloqueada aunque el problema no involucre a otras personas. La persona sin experiencia acepta la idea de que está bloqueada porque no tiene idea de como resolverlo. Por otro lado, una persona con experiencia sabe que si no ha resuelto el problema por si misma aun, entonces no hay un bloqueo solo hay un retraso, debe de intentar otras formas, debe de investigar, debe de preguntar a otros miembros del equipo o personas externas incluso. Es decir tiene cosas que hacer para resolver el problema, no está bloqueada a que alguien más venga a resolverle el problema. La persona con experiencia no acepta la idea de tener un bloqueo si el resolverlo depende de sí misma.

¿Qué pasa con los bloqueos que tiene la persona con experiencia, esos bloqueos que son porque está esperando que el cliente le conteste o que alguien más termine otra parte del sistema? En esos bloqueos la persona encargada del sistema puede buscar en qué otra cosa se puede trabajar mientras se da algo de tiempo a quien debe de dar la información. Se agrega como tarea dar seguimiento a las respuestas que se están esperando. Se busca la forma de obtener esa información lo antes posible o de trabajar alrededor de eso para que en cuanto llegue la información se pueda incluir de manera rápida.

El patrón que se observa en estos ejemplos es que lo que para unos es un bloqueo para otros son tareas a realizar para poder avanzar en el proyecto. Eso significa que un bloqueo que puedes usar como excusa para no trabajar puede convertirse en una tarea, en trabajo que puedes realizar para poder progresar en el proyecto. El llamarlo bloqueo depende de lo que aceptes que puede ser un bloqueo para ti. Puede variar según tu nivel de experiencia; pero debes de tender a tener cada vez menos bloqueos hasta que puedas trabajar sin bloqueos. Debemos aspirar a ser profesionales que encuentran una solución a todos los problemas a los que nos enfrentamos para completar los proyectos.

Robert C. Martin comentó en una de sus presentaciones que: "...lo peor que podemos hacer como profesionales es nada", cuando hablaba del tema de no estar bloqueado.

Comentar lo bueno

La intensión de que alguien más revise mi trabajo es poder encontrar posibles errores o revisar que haya tomado en cuenta detalles importantes. Se puede aprender cuando alguien más revisa lo que haces.

Los code reviews es un ejemplo de eso, se revisa el código y se ve qué es lo que se puede mejorar, se critica el estilo y la manera en la que se implementó la solución en el código. Los comentarios en la revisión del código ayudan a darme cuenta de lo que hice mal o de lo que pude haber hecho mejor y me hace crecer porque la siguiente vez que implemente algo similar sabré a que (otras) cosas debo poner atención, en base a esos comentarios.

También revisar el código de alguien más, con la intención de encontrar oportunidades de mejora, me ayuda a mí. No solamente le ayuda a quien escribió el código, también me ayuda a mí porque soy consciente de esos detalles que quizás no los hubiera visto si no hubiera revisado el código con la única intención de buscar mejoras. Después, cuando programe algo similar, puedo recordar esos comentarios que hice al código de alguien más y mejorar el código que yo mismo escribo, tomando en cuenta eso que comenté en la revisión.

Pero no solo es importante comentar las oportunidades de mejora, también es bueno comentar lo bueno de lo que se está revisando. Los comentarios buenos, que no recomiendan una mejora, sino que simplemente resaltan lo se hizo bien, ayudan a motivarme para hacer un buen trabajo. No solo busco que mi código se vea bien para que no me comenten como mejorarlo, ahora también me motivo a dar un extra porque sé que el equipo lo va a apreciar. Van a notar esos detalles extras, ese plus.

A veces puedo enfocarme en revisar que todo esté bien, comentar esas posibles mejoras y sentir que ya terminé la revisión; pero me doy cuenta que así como busco lo que se puede mejorar debo también buscar lo que quedó bien y también comentarlo. Cuando encuentre lo bueno y lo malo entonces ya puedo decir que terminé mi revisión. Claro que no se trata de siempre comentar, solo cuando se amerite. Si todos los comentarios son buenos, se pueden volver irrelevantes. La idea aquí es que, al revisar, debo poner atención a lo bueno también, así como lo hago con los posibles errores u oportunidades de mejora.

Trabajando remoto. ¿Desde casa u oficina?

Casi toda mi carrera de programador o ingeniero de software la he realizado de manera remota, aunque ha habido temporadas en las que sí estuve trabajando desde una oficina como parte de un equipo; pero la mayoría del tiempo lo he trabajado desde casa.

Actualmente a veces voy a la oficina y trabajo un turno completo desde allí, otras veces lo hago desde casa; pero siempre de manera remota, el resto de las personas trabajando en los proyectos están en otra parte. No es lo mismo trabajar de manera remota o a distancia que trabajar desde casa.

Una diferencia es el tiempo que estás disponible para trabajar, cuando voy a la oficina y allá dejo el equipo (la laptop y cuaderno con notas) no puedo seguir trabajando cuando ya llegué a la casa, lo mismo pasa a la mañana siguiente. Ha pasado que me piden algunos cambios rápidos y debo esperar a llegar a la oficina para atenderlos. Esta es la principal diferencia, cuando estoy desde casa siento que tengo todo el día para terminar mis tareas y me la llevo tranquilo haciendo que pase más tiempo en el trabajo. Cuando estoy en la oficina trato de trabajar más rápido, casi sin darme cuenta lo hago. Me imagino que es porque sé que no tengo todo el día y que en unas horas debo irme a casa.

Otra diferencia son las interrupciones, aunque en la oficina también pasan, son distintas; como el resto de las personas en la oficina conmigo no están trabajando en el mismo proyecto, se puede llegar a sentir un poco como distracciones, más que las que ocurren en casa. Puede ser por lo mismo de que en la oficina siento el tiempo más limitado.

El traslado es otra característica, aun estando remoto hay traslado si voy a una oficina a "remotear". Como que aquí no tiene mucho sentido ser remoto si de todos modos me estoy trasladando a una oficina. Algunas veces me gusta porque aprovecho para escuchar música o algún podcast, disfruto manejar (si trabajo muchos días desde casa, casi no manejo). Por otro lado es agradable la semana que me quedo en casa y veo que no gasté en gasolina esa semana.

Me gusta la sensación de ir a la oficina y terminar todo a tiempo para poder irme a casa y ya no pensar en el trabajo; pero también extraño estar en casa todo el día, estar con la familia desde temprano aunque esté trabajando incluso hasta un poco más tarde.

La idea de la oficina fue tener un equipo y trabajar juntos; pero al equipo también le gusta trabajar remoto y a veces es más fácil revisar código viendo la pantalla de la otra persona compartiéndola y hablando con un headset usando herrarmientas como Slack, Zoom, Skype, etc. la otra persona y yo estamos viendo la pantalla de frente, cuando estamos en persona hay más distracciones y alguien ve la pantalla de lado.

Empiezo a dudar si es buena idea tener una oficina para equipos de desarrollo de software.

Editor de texto obscuro y editor de texto claro

Estos últimos meses he regresado a programar tiempo completo, además de realizar tareas administrativas y administración de proyectos. Esto ha hecho que tenga que programar un rato en la mañana, luego atender unas juntas, después programar otro rato por la tarde y en las noches. No siempre estoy en el mismo lugar, por lo general durante el día voy a una oficina donde trabajo en un monitor externo y en la noches trabajo desde la laptop en mi casa.

He notado que cuando estoy en el monitor externo y la luz de la oficina está detrás de mi, no es tan intensa en la pantalla, usar el fondo de pantalla obscuro ayuda a sentir la vista cómoda mientras programo. Uso macOS y Windows, afortunadamente ambos sistemas operativos tienen un Dark Mode para esas ocasiones que prefiero usar el editor de texto con un tema obscuro.

Cuando estoy en la casa desde la laptop, ya sea una PC o la Macbook Pro, tiendo a usar el fondo claro. También ha pasado si estoy con un monitor externo que está justo debajo de un foco, el fondo obscuro en estas ocasiones no se siente cómodo. Esto es, en parte, porque me reflejo en la pantalla y siento que leo mejor si tengo el fondo claro y es más fácil navegar entre aplicaciones que tienen el fondo claro siempre, ya que hay algunas que no soportan el fondo obscuro, como Slack (también hay las que no soportan un tema claro, como Spotify).

A veces siento que debo elegir un tema, usar ese y acostumbrarme; pero no logro decidirme si solamente usar fondo claro u obscuro y en cierto modo me gusta usar los dos, de ese modo el fondo del editor no es excusa para no ponerme a programar. Algo similar me pasa con los teclados, me gusta poder usar cualquier layout sin estar quejándome como he visto a otros o como lo llegué a hacer yo mismo.

Trabajando bajo presión

No es raro encontrar ofertas de empleo donde como parte de las habilidades requeridas se pide trabajar bajo presión. Esto generalmente es una bandera roja. Puede ser un lugar en el que no hay un proceso definido para realizar las cosas o que los tiempos estimados son muy optimistas y por lo tanto se necesita sacar el trabajo para "ayer".

En las empresas chicas es común que haya presión por sacar el trabajo rápido. En una empresa grande es fácil pasar semanas sin trabajar y que apenas se note; pero en empresas chicas, donde el dinero y el personal es menor, es más notorio cuando el trabajo no se termina a tiempo.

Aún cuando se haya planeado todo a detalle siempre hay cosas que se salen del plan, por ejemplo: puede ser que un cliente no entrego la información a tiempo, que el trabajo era más complicado de lo esperado, el resultado que el cliente esperaba era otro y ahora necesita que se haga de otra manera lo antes posible y esto nos va afectar la fecha de entrega final, etcétera. No se puede asegurar que las cosas van a salir bien siempre y eso es parte del trabajo, no te enojes, míralo como parte del proceso. Puede ser fácil apuntar a la persona culpable de que las cosas no hayan salido bien y concentrarse en eso; pero si te concentras en eso puedes sentir frustración por pensar que tienes que pagar (con tu trabajo y tiempo) los errores de alguien más. Piensa que es un trabajo en equipo, si algo salió mal es parte del trabajo, no es algo personal.

Puedes llegar a sentir que todo urge; sentir una presión por terminar todo a la carrera, que debes apurarte para entregar. Ante estos escenarios es necesario que haya tranquilidad con la presión. Con esto no me refiero a tener un actitud desdeñosa; sino a tener una actitud calmada.

Para sentirte cómodamente con la presión debes despegarte del problema. Ve la situación como si fuera un problema que le pasa a alguien más. En ocaciones es más fácil ver la solución de los problemas de los demás. A veces es obvio como resolver el problema; pero estamos tan metidos en el problema y presionados por resolverlo que puede ser que no vemos las soluciones que están frente a nosotros. Si ves el problema desde una perspectiva despegada entonces puedes ver el problema con una actitud tranquila (como si no fuera tu problema). No siempre es fácil despegarse del problema, es cuestión de seguir practicando.

Es importante conocer las causas del problema para poder encontrar una solución. Es necesario, al buscar estas causas no concentrarnos en culpables. No se trata de ver qué persona tuvo la culpa del problema donde nos encontramos. La idea de buscar causas es entender el problema, la idea no es apuntar dedos ni estarse quejando, las quejas no ayudan, solo harán que te sientas peor. Una vez que entiendes el problema, con una buena actitud, puedes concentrate en la solución.

Debes verte como la solución al problema y hacer el trabajo necesario para arreglarlo, un paso a la vez porque no siempre se puede arreglar todo al mismo tiempo, procura que tu solución no sea trabajar toda la noche. Atendiendo el problema con calma; pero progresando en la solución es lo que puedes hacer. Siempre manteniendo la calma.

Sentirse a gusto con la presión es una habilidad de valor, si tomas esto en cuenta, esa oferta de empleo que pide que sepas trabajar bajo presión puede no ser tan mala, siempre y cuando la remuneración sea la adecuada. Trabajar bajo presión no tiene que ser estresante para ti. Si los clientes o jefes están presionados es problema de ellos. No se trata de que no te importe o que seas indiferente a sus necesidades, se trata de que mantengas la calma para pensar claro y dar soluciones. Y que logres disfrutar tu trabajo porque estás haciendo tu mejor esfuerzo por solucionar problemas. Solucionar problemas puede ser divertido.

¿Cuándo lo tengo que terminar?

Me ha pasado que le pido a alguien que me ayude con cierta tarea de desarrollo de software y me pregunta que cuándo lo tiene que terminar. Mi respuesta generalmente es: "lo antes posible"; pero la persona que va a hacer el trabajo es quien debería de decirme cuándo considera que va a estar listo, claro que su respuesta debe estar justificada. Tampoco se trata de que invente un número.

Parece que estamos acostumbrados a que alguien más nos diga para cuándo ocupa lo que nos pide y nosotros ya veremos como le hacemos para cumplir con esa fecha. Quizás sea que esta costumbre la tenemos porque así se nos enseña en la escuela. Se nos pide un proyecto de tarea y se nos da una fecha de entrega. Es curioso; pero generalmente desarrollar el proyecto se toma todo el tiempo que tenemos... ni más, ni menos.

Se nos enseña que la persona que pide el trabajo nos dirá para cuándo lo quiere listo. No nos enseñan que como profesionales, somos nostros, los que debemos dar estimados.

Lo hacemos, también, porque al preguntar en cierta forma estamos evadiendo la responsabilidad de entregar algo completo en la fecha dada. Porque podemos alegar después que no quedó completo por falta de tiempo y sentir que no fue nuestra culpa. Podríamos decir que nos da miedo equivocarnos.

Si hacemos seguido eso que nos da miedo, después ya no nos dará miedo. Podemos intentar hacer estimados seguido.  Al principio es normal equivocarse, puede que seamos muy optimistas y después darnos cuenta que es más trabajo del previsto. Aun así debemos seguir practicado estimar el trabajo que nos piden. Incluso cuando no hay fecha límite, pensemos en: "¿Qué tengo que hacer y cuánto tiempo me tomará cada tarea?". De ese modo vamos practicando y podemos revisar al final del proyecto si tomamos en cuenta (en la estimación original) todo el trabajo que en realidad tuvimos que realizar.

La próxima vez que nos pidan un proyecto, recordaremos esos detalles que se nos pasaron en el proyecto anterior y los tomaremos en cuenta. Así cada vez, la estimación será más apegada a la realidad y en lugar de preguntar para cuándo, ahora nosotros daremos la fecha aproximada en que puede estar listo eso que nos piden, claro que siempre agregando algo de margen para los imprevistos.

Email para el Seguimiento

En varios equipos de desarrollo con los que trabajo se ha dejado de usar el correo electrónico como principal forma de comunicación, para ahora usar herramientas de mensajería instantánea. Herramientas como: Skype, Slack o similares son comunes. Todo esto está bien porque permite una mayor interacción entre el equipo de desarrollo. Hay una retroalimentación rápida sobre el trabajo a realizar.

Esta mayor interacción también provoca que haya muchos mensajes que leer, de ahí surge la necesidad de tener canales o "conversaciones" específicas para cada proyecto. Sirve tener canales específicos porque así podemos ver toda la información relacionada a cierto proyecto en un solo lugar. Esto ha influido para que cada vez se use menos el correo electrónico entre los equipos de desarrollo con los que trabajo.

El problema de los mensajes instantáneos surge cuando se necesita ver el panorama general del proyecto. Es difícil dar seguimiento a grandes bloques o módulos al leer los detalles de la conversación. Herramientas de administración de proyecto ayudan a tener toda la conversación agrupada a una tarea; pero a veces hay muchos lugares dónde buscar el estatus de las tareas. A veces no queda otra que leer los mensajes del chat del día para saber cómo vamos.

El correo electrónico me sirve en esos casos porque no es tan instantáneo. Se puede incluir a varias personas en la conversación y no se necesita una respuesta de cada uno al momento. Solo con que respondan cuando tengan algo que decir y en un solo mensaje te den todas las respuestas que necesitas. A veces en los mensajes se pierde la secuencia porque contestan varios al mismo tiempo y dan una respuesta por mensaje y mandan dos o más mensajes para una sola respuesta, mientras otros hacen los mismo y ya se revolvió todo. Por correo recibes una respuesta por cada miembro del equipo e idealmente viene toda la opinión o informe que requieres de esa persona en un párrafo explicado. A veces por la flojera de pensar y dar un reporte se prefiere escribir varios mensajes de una línea y puede ser más complicado darle sentido a la idea del mensaje completo.

He notado que cada vez es más común que no revisen el correo electrónico, no es raro que tenga que avisar por mensaje que les he enviado un correo electrónico que requiere respuesta. A veces van y lo leen y me contestan por mensaje. Para mi es difícil darle seguimiento a las cosas de ese modo. Porque eso me exige, en cierta manera, estar atento a los mensajes, que pueden ser muchos.

Usando el correo electrónico puedo programar un tiempo para hacer las preguntas que necesito enviar o escribir los reportes que necesito enviar y si la respuesta es por correo entonces puedo dejar que se acumulen en mi buzón mientras sigo trabajando en otras tareas. Una vez que tenga tiempo puedo ir y procesar mi bandeja de entrada. No puedo hacer lo mismo con los mensajes.  Los mensajes distraen más y puede que si me dan los datos que necesito por mensaje, al momento que tengo tiempo de revisarlo ya han enviado muchos mensajes más y es difícil encontrarlo. Por eso prefiero las respuestas a mis correos por correo electrónico, el seguimiento es más fácil.

¿No les pasa lo mismo?

Micromanagement al Rescate

Hace ya un buen tiempo me tocó trabajar con un equipo de desarrollo que tenía problemas a la hora de dar resultados. Siempre había un pretexto o detalle que se les iba y por alguna u otra cosa no se entregaban las características requeridas en el programa. Este era un equipo que lo administraba el cliente directamente. Nuestra empresa solo "rentaba" a los programadores.

Algo que intentó el administrador de proyectos para "rescatar" al equipo, fue realizar lo que se conoce como micromanagement. El micromanagement (o microgestión en español) es cuando la persona encargada de administrar, o dirigir a otra, le da instrucciones al detalle de lo que hay que hacer. Esto es algo que por lo general se busca evitar ya qué es cansado para ambas partes.

Cuando supe que se intentaría "rescatar" al equipo usando micromanagement no me pareció una buena idea. Supuse que eso traería más problemas. Me comentaron que sería una medida temporal en lo que "salíamos del hoyo". Contra mis pronósticos parece que la medida dio algo de resultados. El equipo empezó a entregar tareas y quedaron expuestas las causas de los problemas del equipo, haciendo posible realizar correcciones. Algunas de. estás correcciones no tan agradables; pero fueron necesarias para bien del proyecto.

Una vez realizadas las correcciones necesarias para que el equipo funcionara mejor, se pudo regresar a un ambiente menos controlado y se pudo seguir avanzando en el proyecto.

Esa no ha sido la única vez que la microgestión nos ha ayudado a sacar adelante un proyecto. En otra ocasión me tocó a mi detener un proyecto y volverlo a empezar desde cero. Lo que hicimos para que el proyecto no se saliera nuevamente de control fue que lo iniciamos programando todos juntos en la misma maquina. Éramos un equipo distribuido por lo que todos nos conchabamos a una junta por GoToMeeting y el "chofer" compartía pantalla y empezaba a programar mientras los demás íbamos viendo. Eramos 4 personas en la llamada. Al principio me parecía un desperdicio de recursos estar los cuatro viendo como definir algunas clases; pero ahora que veo hacia atrás, creo que fue una buena decisión porque eso logro sacar al proyecto adelante.

Después de un tiempo dejamos de conectarnos para programar y cada quien trabajaba en cierto módulo; pero no permitía que subieran código fuente al repositorio hasta que lo revisara yo mismo. Al principio había varias observaciones en los commits que me solicitaban; poco a poco fueron disminuyendo. Pasado algún tiempo dejé de revisar todo el código fuente y ahora solo nos preocupábamos porque la funcionalidad estuviera ahí y pudimos trabajar sin micromanagement. Se tenía una junta en las mañanas para tener el plan del día y con eso era suficiente.

El micromanagement es algo que por lo general se ve como malo, yo mismo me he quejado de eso en este blog; pero también puede ser una práctica que puede ayudar al equipo a salir adelante en ciertas ocaciones.

Atención al Detalle

Hay varias cosas que distinguen a los profesionales de los aficionados, una de esas es la atención al detalle. Cuando estás empezando a programar lo que te puede interesar es crear algo, que funcione y quizás eso evite que te fijes en los detalles que le harán la vida fácil a tus usuarios.

Un caso común que he visto que se omite es el de permitir al usuario usar solo el teclado para navegar en tu aplicación. Es algo que me pasó en los primeros programas en los que trabajé, sobre todo cuando el proyecto no era web, cuando era un ejecutable y en esos se debe especificar el "tab order" explícitamente. Y a veces por hacer que el programa funcionara y poder decir que ya estaba listo olvidaba verificar el orden de todos los tabs y definir labels que permitieran navegar fácilmente sin necesidad del ratón.

La atención no es solo al momento de programar, también es importante al realizar todas las  actividades de tu trabajo. La comunicación es una parte importante para el éxito de un equipo de programación. Debes poner atención al detalle de como te expresas, debes ser capaz de dar una explicación tanto técnica, en caso de ser necesaria, como una explicación que personas no técnicas puedan entender el problema y la solución que se está planteando. Debes evitar que los clientes o jefes se sientan ignorados. Contestar rápidamente a peticiones, no necesariamente con la solución, quizás solo informando que vas a investigar, es una atención a la otra persona y ayuda a la comunicación. Nadie está tan ocupado como para no poder contestar que vas a revisar lo que te piden. Y ya que lo revises, avisa. Evita que te tengan que preguntar nuevamente por cosas que ya te pidieron.

De la misma forma cuando se te pide que realices ciertas actividades como documentar es importante que pienses en la persona que va a consumir esos documentos. Dar toda la información posible para que sea de utilidad lo que escribes y que la otra persona no tenga que buscarte para pedir que aclares qué quisiste decir. A veces no te salvas de eso por más explicado que esté; pero por lo menos ya lo aclaraste para ti cuando lo escribiste.

Básicamente estoy hablando de entregar las cosas completas y bien hechas, sin detalles pendientes. Esa es la diferencia entre una persona profesional en la que se puede confiar y una persona aficionada a la que hay que revisarle todo lo que hace porque no tienes la garantía de que: lo que hizo, lo hizo bien.

La experiencia ayuda a poner más atención, cuando eres principiante es fácil pasar por alto los detalles; pero además de la experiencia, la mentalidad para hacer las cosas bien es muy importante. Ten la intensión de hacer las cosas bien terminadas, sin detalles pendientes y así lograras ser una persona profesional y confiable.