El super poder del mail

Es increíble la creencia de algunos en los superpoderes de un mail. Claro, basta con enviarlo para pasarle a otro la responsabilidad de algo o "cumplir" con haber solicitado, derivado o entregado una tarea. Total, "lo pedí por mail".

Puedo derivar o atender muchos requerimientos desde la comodidad de mi escritorio, ¿pero cuantos realmente puedo cerrar? No muchos. Vaciar un inbox sólo con responder sin verificar la real ejecución de algo, es sólo una ilusión de tener el trabajo hecho.

Si queremos que las cosas pasen, debemos dejar la postura cómoda de el carteo eterno por correo. ¡Es mucho más fácil llamar por teléfono y concretar!

Me he topado con gente que cree, que como te envió una cita por mail, estás informado y obligado a asistir. Así de fácil. Mail y ¡paf! reunión agendada. Es mucho más simple llamar, validar la disponibilidad de las partes involucradas y acordar cita. Te gastas a lo más 10 minutos. Si lo haces por mail, desperdicias mucho tiempo, porque cada vez tendrás que ir saliendo de lo que estás, contextualizarte en el mail que debes responder( lo cual implica muchas veces leer el hilo de correos ) y claramente es más costoso que 10 minutos de una llamada telefónica. Obvio, es puro sentido común. Y ahora, si con quien debes acordar cita, trabaja a dos pisos de tí o unos escritorios más allá, camina. Hace bien para la salud hacer un poco de cardio extra.  ¡Puros beneficios!

¿Por qué la gente prefiere la burocracia de un mail a la comunicación por teléfono o incluso directa cara a cara? Creo que la respuesta es simple. El contacto directo implica involucrarse.

El mail debería ser para formalizar, pero núnca el canal para que las cosas pasen. Y con esto vuelvo a mi post de algunos años "Cuestión de actitud", el cual aunque añejito ya, lamentablemente, continua MUY vigente.

¿Usuarios tontos o tontos que no explican?

En una conversación con mis compañeros de trabajo, vimos que en muchas oportunidades se escucha la frase "los usuarios son tontos" para referirse a usuarios de sistemas informáticos. Nos cuestionamos la frase. Concluimos que efectivamente está hace rato en la mente muchos TI, quienes tenemos complejo de superioridad( claro, porque como nosotros escribimos en este o tal lenguaje, o como sabemos de fierros entonces somos superiores).

Y pensando en el adjetivo "tonto", no podemos generalizar. Personas poco astutas, las vamos a encontrar en todos lados... y como informáticos no somos la excepción.

Por ejemplo ¿a cuántos nos ha pasado que otro TI nos hace una pregunta absurda, o pregunta algo que perfectamente pudo responder, o al menos pre-validar( o sea, pensar un poquito) antes de preguntar? Uff, sí.  Y más de una vez.
Pero recordemos que somos personas, no todos los días son iguales, no todos los días andamos pillos y no todos los días tenemos nuestra mente libre de distracciones. Nos equivocamos. Podríamos decir que hay días donde andamos bastante lentos( por decirlo de una forma sutil y no con el chilenismo que se viene a mi mente).

Actualmente, los usuarios están buscando y probando formas de abordar sus requerimientos hacia las áreas de sistemas, dado que se enfrentan a los siguientes problemas:

• no existen SLA y si los hay son pésimos,
• poco entendimiento de sus necesidades,
• excesiva burocracia,
• dificultades de comunicación. ¡Obvio!, porque hablamos en un lenguaje muy técnico y en muchas oportunidades los hacemos sentir tontos, dado lo complicado de nuestros conceptos y explicaciones aún peores. 

Esto empuja a que los usuarios:

• Usen intermediarios para que las cosas fluyan: PMO's. ¡Claro! ellos hacen el trabajo de perseguir a los TI y de "comunicarse" con ellos,
• Busquen soluciones SaS. ¡Qué mejor! Software que funciona, y sin la necesidad de pasar por largos y tortuosos procesos de desarrollo, pruebas y puestas en producción de software.

¿Cuándo dejaremos atrás la creencia de que los usuarios son tontos?

• Cuando recordemos que TI apoya al negocio y no debería funcionar como si fuera una empresa externa( con excesiva burocracia y trabas hacia los proyectos, incluso entre TI's), 
• Cuando entendamos que los usuarios ya están mirando hacia otros países, donde existen proveedores con más experiencia y soluciones listas,
• Cuando por fin entendamos que somos nosotros quienes debemos acercarnos al cliente( pues estamos en falta) y si no lo hacemos, esta relación va directo a su fin. Porque si el cliente externaliza todo, compra todo listo y se quita el "problema" de lidiar con nosotros, entonces cada vez tendremos proyectos menos interesantes, ya que para los proyectos entretenidos considerarán a "otros". Un ejemplo: El metro de Santiago. Lo usamos porque necesitamos llegar a nuestro trabajo a tiempo( porque las micros se enfrentan a tacos enormes). Pero en el metro nos empujan, nos aprietan, siempre está lleno sin importar hora. Soportamos olores indeseados y realmente nos sentimos humillados. Pero lo necesitamos, entonces, lo usamos. (Estamos condenados :/ ). Sin embargo, si apareciera un medio de transporte alternativo, el cual nos permitiera cumplir con nuestro objetivo de llegar al trabajo a tiempo, y la experiencia fuera mucho más digna, ¿Acaso no pensaríamos en dejar el metro, aunque incluso este otro medio de transporte fuera un poco más caro? ¡Sí!. Y esto es precisamente lo que están pensando nuestros usuarios acerca de TI.

Siempre es más fácil culpar a otros de nuestros propios errores. Pero, supongamos por un momento que el problema no son los usuarios, somos nosotros, TI. Veamos como mejorar. Tenemos que acercarnos al usuario y ser capaces de tratarlo con dignidad. Y ello incluye buscar formas de expresarnos mejor para transmitir nuestras ideas y crecer. 

Sólo con este ejercicio estaremos creando un mejor entorno, comenzaremos a revertir el daño y retomaremos el sentido de apoyo al negocio, que hoy por hoy, tan perdido está.

Y tú, ¿malcrias a tus clientes?

Hace un tiempo, me toco reemplazar a un jefe de proyecto en una empresa cliente nuestra. Como tal, debí aprender los procedimientos y códigos de equipo que existían en dicha empresa.

Como parte de mi trabajo y para mejorar la visión que tenía un área de negocio con respecto a su área de informática, comencé a enviar semanalmente el estado de avance de todos los proyectos, incluía un resumen con estado e hitos importantes cumplidos y fechas comprometidas vs fechas reales. Esto gustó mucho, porque los mantenía informados de en qué estaba cada uno de los temas de su interés, además de ayudarme a destrabar aquellos que estaban a la espera de algo que no dependía de nosotros como informática( el cliente hacia lobby para destrabar, ayudándonos).

Fué así, que se generó una excelente relación con esta área de negocio y no sólo los ayudé a ver los temas puntuales que tenía encomendados, si no también que los apoyé en reuniones como asesor, lluvia de ideas y en temas que permitían mejorar el funcionamiento del área. Cuando había problemas, les decía la verdad y les explicaba los pasos que la gente de soporte debía realizar para poder solucionar el impaz. Pero llegó el período de vacaciones y tuve que dejar a mi cliente encargado con un Jefe de proyecto local, uno de la casa, uno contratado y que era parte de la empresa para la cual prestábamos servicios.

Le entregué mis pautas para resolver problemas( estaban migrando un sistema antiguo, el cual tenía problemas que serían solucionados por el software de clase mundial), le expliqué el reporte de avance semanal( un simple mail), qué hacer en caso de, en fin. Todo aquello que creí le sería útil. 

Durante mis vacaciones ví pasar mails donde el gerente del área, pedía cosas y mi reemplazo daba respuestas escuetas o simplemente no respondía. 
 Cuando volví, la jefa de desarrollo me llamó y me dijo que había recibido la solicitud expresa de trabajar conmigo en dicha área, pero que ellos sabían que en realidad yo los tenía mal acostumbrados. ¿Pero cómo? dije. 
Sí, tu reemplazo nos ha indicado que has mal acostumbrado al cliente con eso de reportarle semanalmente y este trato tan cercano, con grupos whatsapp para comunicación inmediata, no, no es bueno.
 
¡Obviamente me quejé! ¿Es malo informar a tu cliente los avances y retrasos a tiempo, para transparentar las complicaciones reales en el curso de un proyecto? ¿Es malo decir la verdad? ¿Es malo preocuparte de que sientan que informática si es de apoyo y no una traba?

Es triste ver que incluso gente de tu área cree que aquello que muchos consideramos simplemente ser profesional, sea malcriar al cliente. ¿No se supone que informática es de apoyo al negocio? y más triste confirmar que profesionales recién salidos de institutos y universidades piensen de esta manera. Si son el futuro, ¡qué  queda para después!

Si ser transparente, correcto y dar la información oportunamente, es mal acostumbrar a los clientes. Soy culpable. Sí, los malcrio. Me gustan las relaciones de confianza mutua y considero clave estos aspectos para formar este tipo de lazos.

La importancia de saber y de aprender

Cuando se aborda un nuevo proyecto, es importante que quien tome el rol de líder en el equipo, tenga conocimiento no sólo del problema y de la solución, sino que sepa cómo ésta será implementada, con un grado mayor de detalle.

Bajo las antiguas metodologías, el conocer un lenguaje, o haber desarrollado alguna vez en tu vida, servía de herramienta para poder estimar junto al equipo, para que la planificación fuera certera (o al menos lo intentara ser), pero principalmente, para que no pudieran "engrupirte" fácilmente.

¿Pero qué pasa, cuando estás trabajando con un equipo nuevo, con un nuevo lenguaje o arquitectura que no dominas y debes liderar un proyecto?

Dos opciones:

• Cierras los ojos... y diriges el proyecto, sin la visión clara de las herramientas que tienes, para llegar al objetivo, o
• Te reinventas y vuelves a aprender.

Está claro que la segunda opción no es la más fácil. Pero cuando quieres aportar y realmente quieres entender las limitaciones o virtudes de un lenguaje/arquitectura, ¿no es mejor saber?

Cuando desarrollaba, me esforzaba por hacerlo bien. Tenía compañeros mucho más talentosos, pero siempre me empeciné en mejorar. Incluso recuerdo, las entretenidas competencias que haciamos con mi jefe (quien amaba y aún ama con toda su alma programar ) para ver quien lograba "botar" la aplicación del otro. Haciamos control de calidad cruzado y como ambos desarrollábamos, sabiamos qué exactamente un usuario común y silvestre no haría y aplícabamos lo que cualquier desarrollador motivado por la competencia haría: ocupábamos las combinaciones de teclas rebuscadas, condiciones de borde y cualquier artimaña que permitiese ganar.

Ahora que lidero proyectos, ¿por qué no iba a aplicar el mismo espíritu?

Una vez que comienzas a aprender, todo cambia. Entiendes los problemas a los que se enfrenta tu equipo, entiendes qué no es posible hacer; que es tanto o más poderoso que saber lo que si se puede hacer. Puedes aportar valor, no sólo realizando el trabajo de negociación con el cliente, que es parte de tu trabajo, sino que también aportas tu visión de los problemas y soluciones. Entiendes de qué se habla, frenas al cliente cuando se arranca con deseos no realizables. Haces mejor tu trabajo.

Tu compromiso e interés por aprender hará que mejores como profesional, no precisamente porque vayas a aportar con líneas de código, si no que con ello demuestras interés y respeto por el trabajo de tu equipo. Te hace parte. No que te vean, ni los hagas sentir como en las empresas convencionales, donde los jefe de proyecto están en un pedestal y los desarrolladores "bajo" ellos.

Lamentablemente aún en muchos lugares a los desarrolladores se les dice que para crecer profesionalmente, deben ser Jefes de proyecto. ¿Pero que pasa, si realmente aman desarrollar? Deberían poder optar a crecer en esa dirección y que se les valore por ello, no por intentar ser algo que no quieren. Pastelero a tus pasteles. Que tu talento y pasión guien tu camino profesional.

A mi me gusta liderar proyectos, armar equipos de trabajo, descubrir y orientar el talento de nuevos profesionales. No me interesa tener un cargo rimbombante. Y no es por falta de aspiración, es porque ésto es lo que me hace feliz.

Mi primer jefe, se ganó el respeto y admiración de su equipo, no porque hablara más alto ni por su cargo de "gerente de desarrollo", sino porque él, sabía. Entendía la implicancia de un desarrollo u otro, él era uno más del equipo. Con él podías hablar y él entendía de lo que hablabas.

Por ello, creo firmemente que un líder de proyectos, debe:

• Mostrar respeto por el trabajo de su equipo
• Aprender de sus errores
• Aprender con su equipo
• Conocer a los miembros de su equipo, interesarse realmente por ellos, preocuparse.

Pero también, ser firme cuando se requiera y un compañero cuando sea necesario.

Y sobre todo, debe estar dispuesto a ayudar a sacar adelante el proyecto, haciendo lo que se deba hacer.

Tengo la suerte de estar en un lugar donde hay excelentes desarrolladores, de los cuales puedo aprender día a día. Gente dispuesta a invertir su tiempo libre codificando, porque ama lo que hace. Y yo estoy allí, donde día a día, puedo aprender de y con ellos. Puedo ser mejor.

Cuestión de actitud

Hace unos días lancé una pregunta a Twitter/Facebook a la cual no obtuve respuesta. La pregunta era "Dejar pasar la responsabilidad ¿Es un tema de idiosincracia de los chilenos?

La verdad no sé si es precisamente un tema de idiosincracia; tendría que conocer otras culturas para aumentar mi muestra. No obstante, creo que es un tema de "actitud". Sí, tal como lo dice un comercial de una tienda "La belleza es cuestión de actitud", creo que es posible reutilizar la frase, para convertirla en "El profesionalismo es cuestión de actitud".

Día a día, veo como Jefes de proyecto dejan pasar la responsabilidad de involucrarse. Como programadores dejan pasar la responsabilidad de revisar que lo que estan entregando funcione de acuerdo a lo que se les solicitó, que sus implementaciones no generen bugs que rompan el desarrollo ya entregado. Como otros, ante las llamadas de atención responden con una risita o simplemente, se hacen los "lesos".

¿Tomamos la postura fácil?

Lamentablemente creo que en muchos ámbitos, Si. Es más fácil callar y esconder los problemas, que levantar la voz para decir que algo está mal. Es más fácil esperar que otro haga el trabajo, a hacerse cargo y tomar la responsabilidad de tomarlo, involucrarse y sacarlo adelante.

Es más fácil que "otro" haga de policía y sea siempre el que llame la atención. Es más fácil culpar a otros, por nuestra propia responsabilidad.

¿Cuestión de actitud?
Con mi hermana vemos una serie gringa, de una modelo que tiene un reality. En uno de sus capítulos, una de las postulantes a "modelo" era licenciada en literatura inglesa. Al momento de enfrentar la entrevista, no supo qué responder ante la pregunta, "mencione 3 escritoras inglesas que consideres relevantes". Simplemente, quedó muda, sin saber qué decir.
La modelo que hizo la pregunta, al no obteber respuesta, mencionó a 3 escritoras. Y agregó: ¿Cómo yo, que soy modelo y que no soy licenciada en literatura, puedo responder a esta pregunta? Y finalmente sentenció: Sea lo que sea que hagas, ¡hazlo con pasión! ¡Pasión! ¡Éso es lo que marca la diferencia!

Me quedó dando vueltas la frase.

En cualquier área, aquellas personas que se destacan, son aquellas que tienen la actitud. Las que hacen su trabajo con pasión. Las que toman la responsabilidad sin verla pasar. Son esas personas las que ascienden en sus trabajos, las que brillan en sus áreas.


Por ésto, es que el apoyo entre los miembros de un equipo es importantísimo. Que la responsabilidad fluya para que en ocasiones seamos apoyo, y en otras, seamos quienes lideren y llevemos la responsabilidad.

En una conversación con mi esposo, quien también es Ingeniero informático, afirmó: "Scrum es un sueño en Chile. Van a tener que pasar varias generaciones para que funcione, porque nuestra idiosincracia es así. Es más fácil que otro haga la pega".

Quiero ver funcionar esto. Y creo que podemos hacer que funcione. Todos debemos poner de nuestra parte. En donde sea que trabajemos, sea cual sea el rubro, donde estemos, que lo que hagamos sea con pasión. Los colegios, las Universidades, deben transmitir ésto a los niños. Si desde pequeños nos mentalizan a decir lo que pensamos, a luchar por lo que creemos justo, a entender que nuestras acciones tienen consecuencias y sentirnos responsables de ellas, en un futuro no muy lejano, contaremos con excelentes profesionales y excelentes personas.

Apuesto por un futuro donde poner pasión en lo que hacemos, no sea la excepción, sino la regla.

Para reirse un rato:
http://www.youtube.com/watch?v=BozeR4WX7jI
http://www.youtube.com/watch?v=kAFX1DsGsog ( desde el minuto 1:50)

Los dineros de la empresa, ¿deben ser conocidos por el equipo?

Quizás para muchos, la respuesta a esta pregunta es un rotundo NO. Sé que es posible enumerar un montón de argumentos completamente válidos para justificar tal respuesta, pero creo que es posible resumir todos ellos en una sola palabra: Confianza.

Durante mi vida laboral, he tenido la oportunidad de trabajar en empresas donde la respuesta a la pregunta siempre fue NO.

En algunos casos, porque ésa información podría generar incertidumbre, ante lo cual los simples mortales podrían entrar en pánico. En otros, porque ésa información es confidencial y sólo debe estar reservada a ciertas personas.

Pero siempre en todas ellas la causa es la misma, Confianza.

¿Por qué no pensar, en que el equipo de trabajo podría tomar positivamente el hecho de que la empresa, confíe en ellos para mostrarles los flujos de dinero?

Hoy, he tenido la posibilidad de comprobar que es posible responder SI a la pregunta título de este post.

Abrir las cuentas de la empresa y ver en qué nos gastamos nuestros ingresos, tiene muchísimos beneficios, entre ellos:

• Crear conciencia de cómo nos financiamos

• Resultado de lo anterior, sabemos de qué prescindir en una eventual crisis, vemos si estamos siendo rentables y más aún, creamos conciencia de lo que cuestan las comodidades que la empresa nos dá.

• Entendemos que para optar a un aumento, debemos aumentar la rentabilidad( en realidad siempre lo sabemos, pero ahora es explícito)
  

• Cuando te dán la confianza, realmente te sientes parte de la empresa, te involucras. Es tu empresa.

• Se produce la magia. El equipo empieza a buscar formas de mejorar, para volver más eficientes los procesos internos y analiza en conjunto, cuáles serían las acciones a seguir. Por ejemplo:
  

1. Analizar muy bien los requerimientos.
2. Discutir las historias de negocio en Equipo y, delegar su escritura al mismo equipo.
3. Programar individualmente o Juntarse en pares según necesidades
4. Utilizar pruebas unitarias para poder saber qué se rompió al implementar la nueva funcionalidad. Tender hacia TDD.
5. Hacerse cargo de los errores.
6. Educar al cliente para que entienda el impacto de sus demoras.
7. Educar al usuario para que use nuestro Kanban y acepte junto a uno de los integrantes del equipo las historias de negocio.
   
8. Revisar si es posible diversificar las lineas de negocio de la empresa.

Sé que hay muchos beneficios más, pero quería reflejar acá que la confianza, sólo puede traer consigo cosas buenas para el Equipo. Al menos debemos intentarlo. ¿Por qué perder la fé sin al menos intentar creer?

De esta manera, el equipo entiende por qué muchas veces aquellos con rol de Coordinadores les pedimos apurar más la producción, revisar más las entregas, probar probar y reprobar. Es una forma muy gráfica que todos tomemos conciencia que nuestras acciones tienen concecuencias, ¿y acaso ésto no implica crecer?



Hoy, tuvimos una reunión de empresa en nuestro "Lectura y Cerveza", donde hicimos este ejercicio. Y además de encontrar muy entretenida la forma en que mi partner explicó los flujos( utilizó imágenes en su presentación muy simpáticas), vi fluir la magia.

Para aquellos que no crean en ella, les digo que la magia existe. Sólo deben confiar, está allí esperando a que la descubran. Brinden la oportunidad a sus equipos, Confien.

Los verdaderos equipos

Últimamente me he interiorizado en la metodología Scrum y he tenido la oportunidad de poner en práctica algunos de sus principios en mi trabajo diario.

La base para un buen equipo Scrum, es precisamente ésa, el equipo. Pero no un grupo cualquiera, si no, un verdadero equipo. Aquel donde cada integrante tiene una habilidad y la pone a disposición de sus pares, donde existe apoyo, donde es posible compartir las tareas.

He visto lo que genera. Basta con algunas prácticas como las reuniones stand up, para comenzar el día informado, motivado y con la visión de los objetivos.

Sin embargo, Scrum nos pone en aprietos. Lograr formar equipos autogestionados y con profesionales de alta calidad es difícil...pero no imposible.

La actitud de los profesionales marca la gran diferencia.

Personas proactivas, que no esperan a que "otro" haga el trabajo, que respetan a sus pares( XP) , que programan pensando en las pruebas y en el próximo que mantendrá su código. Ésas personas son las que se necesitan y no sólo en Scrum!.

Pero aquí surge la contradicción. Llegar a contar con este tipo de equipos, es el ideal, pero en la vida real, en muy pocos lugares se dá esta situación.

Luego, ¿puede haber equipo si sus miembros son sólo estrellas? Basta pensar en el equipo de futbol del real Madrid, para que sepamos que no.

Porque en un equipo existan muchos delanteros, no necesariamente se harán más goles o se ganarán todos los partidos. El grupo debe tener sentido y actitud de equipo. Reconocer sus posiciones, probar formaciones, compartir éxitos y derrotas, aprender.


Se viene a mi mente una frase que me dijo un jefe tiempo atrás:
No siempre se tiene a los mejores recursos, la gracia es, con lo que tienes, sacar tus proyectos.

Creo, que al gestionar un equipo y jugar en la posición de JP, es un deber apoyar a los compañeros, involucrarse en el juego, jugar. Trabajar para y con el equipo. No puede haber gestión sin acción.

Todos los equipos son diferentes, y ésa es la gracia! Su magia está en:
"cuando dos o más elementos se unen sinérgicamente crean un resultado que aprovecha y maximiza las cualidades de cada uno de los elementos "( Sinergía). Aunque suene cliché, es la pura y santa verdad.