Mostrando entradas con la etiqueta Comunicación. Mostrar todas las entradas
Mostrando entradas con la etiqueta Comunicación. Mostrar todas las entradas

Primera persona del singular

Llevo un tiempo trabajando con equipos y, pensando retrospectivamente, me doy cuenta que muchas veces me encuentro/nos encontramos dialogando con compañeros o clientes, anteponiendo el pronombre 'yo' o usando verbos en primera persona singular. Este hecho marca el sentido de no pertenencia a nuestro equipo y atenta contra los ambientes colaborativosCreo que una de las maneras de mejorar la comunicación y la colaboración, y que debería ser trabajada en retrospectivas, es la erradicación de este tipo de pronombres y verbos cuando hablamos en nombre del grupo. Potenciará el sentido de equipo, la pertenencia y el compromiso hacia él.

Germán

Tengo un problema (2)

Luego del éxito sin precedentes del post sobre el patito de goma (¿?) y de algunos de los comentarios que me llegaron, quise hacer una remasterización del algoritmo de la técnica con el feedback que obtuve.


Si tenés un problema que no podés resolver y te está bloqueando, entonces:
          Si trabajás remoto:
                1. Buscá un compañero en el chat para contárselo;
          Sino:
                2. Contáselo a un compañero en persona;
Si no tenés más remedio y no tenés un compañero a mano:
                3. Buscá un Patito de Goma y/o cualquier otro;
En otro caso:
                4. Googlealo :)


Germán

No escribirás con errores ortográficos

Recuerdo que cuando estaba en la escuela primaria (6to grado), tenía una maestra que en una de las clases semanales de Lengua, nos tomaba un dictado. La dinámica era la siguiente: te dictaba 20 palabras elegidas al azar y, si tenías menos de 6 o 7 errores ortográficos, aprobabas. A medida que iba pasando el tiempo, la complejidad de las palabras se incrementaba y, para la calificación final de la materia, se ponderaba también cuántos dictados habías aprobado. Si bien era un examen y tenía un cierto nivel de stress, hoy en día, agradezco haber tenido la posibilidad de entrenar mi ortografía desde chico.

Esta anécdota es para introducir un tema que me parece muy importante, por no decir crítico. Digamos que podríamos seguir hablando sobre skills blandas, duras, etc. de un profesional (en este caso, informático, tester, developer, no viene al caso). Sin embargo, pienso que antes de entrenar cualquiera de estas habilidades (que obviamente son también importantes), tenemos que estar seguros de escribir sin errores de ortografía. En resumen, antes de entrenar cualquier otra habilidad, procura escribir sin errores de ortografía.

Les dejo algunos tips que me ayudan a mejorar mi redacción:

- Leer, leer, leer.

- Consultar la RAE o un diccionario físico.

- Tener a mano reglas de ortografía y gramática básicas.

- Usar sinónimos.

- Ejercitar la escritura.

- Seguir en Twitter a @DelCorrector (leer también su blog El Santo de la Pluma)

Por último, no sé si a ustedes les pasa, pero me molesta leer un texto que tiene errores. Además, tiene consecuencias varias. Por ejemplo:

- Si es un informe, pierde toda seriedad al momento de localizar el primer acento mal puesto.
- Si es un bug, tu reputación de buen tester está en duda.
- Si es un chat, sms o mail informal, puede zafar pero, de vez en cuando, una corrección no viene mal.
- Si es un CV, estás out.
- Si es una chica que tiene problemas con su ortografía, pierde inmediatamente todo su encanto.
- Si es este post, por favor, dejar un comentario. Gracias!

¿Es mucho?

Germán

Publicación en el blog de PetroVR

Colaboré como autor, junto a mis compañeros de equipo de Pragma, en una entrada sobre Testing en el blog de PetroVR. En el post, hablamos un poco sobre una propiedad que me parece interesante para desarrollar y que es la "self-testability" de un producto software. Los invito a leerlo How is the Testing of PetroVR done? The self-testability of PetroVR

Gracias Caesar Systems por la invitación a participar y a +Leandro Caniglia y +Carlos Ferro por el feedback.

Germán

Tengo un problema

La técnica del patito de goma [1] (reformulada)

Muchas veces nos pasa que nos bloqueamos cuando tenemos que resolver un problema (en este caso, laboral). No podemos avanzar, nos volvemos menos productivos, incómodos y no disfrutamos de nuestro trabajo. Para evitar esto, lo que la técnica propone es, simplemente, contarle a alguien lo que nos pasa. Luego, en medio del proceso, nos daremos cuenta de lo que está fallando (eventualmente) y nos ayudará a resolver el tema que nos aqueja. Pero tiene un problema, hay que molestar a otra persona para que nos atienda. Es aquí dónde aparece el Patito de Goma. Cuando estés bloqueado usá el patito, contale lo que te ocurre y verás cómo, en muchas ocasiones, te ayudará.

Contado de esta manera, tiene algo que me hace ruido y que contradice el "espíritu" de este blog: atenta contra los ambientes colaborativos. Por lo tanto, mi propuesta es:

- Si tenés un problema que no podés resolver y te está bloqueando:
          1. Buscá un compañero para contárselo.
- Si no tenés más remedio y no tenés un compañero a mano:
          2. Buscá una Patito de Goma.

Talent Pool

Hace unos días, en mi trabajo, estuve presenciando una charla interesante sobre NoSQL. El orador era Cristobal Pedregal Martín. Sinceramente, no conocía mucho sobre el tema y, por lo tanto, no voy a entran mucho en detalle sobre el concepto en este post. Más allá del tema en cuestión (del cuál podemos tener una vaga idea o no saber nada al respecto), estas exposiciones son oportunidades para abrirse a nuevos conocimientos y relacionarlos con otros ya existentes. Personalmente, en estas charlas me fijo mucho en cómo está estructura la presentación, qué ejemplos se usan para explicar los conceptos y cómo el orador se dirige a la audiencia. Cómo hacer una buena presentación no es un tema que esté en condiciones de abordar profundamente, sin embargo, creo que hay que entrenarse al respecto para saber hablar delante de una audiencia.


Volviendo a la charla, y a lo que motivó esta entrada, quería mencionar lo que Pedragal Martín nombró como Talent Pool. La traducción es simple. Sin embargo, me interesó el contexto en el cuál lo comentó. Promediando la presentación, Martín repasaba algunos riesgos asociados a implementar un sistema NoSQL. Decía que es necesario tener en cuenta el costo capital (Capex), el costo operativo (Opex), si el sistema es propietario o si es Open Source y, por último, si existe gente capacitada en esta tecnología o si es necesario atraer a jóvenes promesas para capacitarlas. Inmediatamente, relacioné esto último a un tema actual, complejo y crítico, y que tiene que ver con la poca gente especializada que existe en el ámbito de la Informática. Lo digo en relación a la necesidad actual de profesionales informáticos y cómo de ellos depende el desarrollo de una "identidad tecnológica" como país. Claramente, esto no es algo nuevo y en estos enlaces hay algunas muestras de ello:

Estudiar Computación,
Las posiciones de trabajo más dificiles de cubrir,
La escasez de profesionales, y
Hay que estudiar informática

Como conclusión, está claro que para desarrollar nuevas tecnologías e innovar, es necesario tener este talent pool impulsado por la "profesionalización" de la Informática como disciplina y por la necesidad de definir esta "identidad tecnológica". Es también nuestra responsabilidad promover esta especialización.


Imagen: http://www.insightfororganisations.co.uk/talent-management/

No revisaré mails al inicio del día

Aquí les dejo la justificación científica de por qué es interesante tratar de implementar el lema "Stop Starting, Start Finishing"

El video "La razón sobrevaluada", de Estanislao Bachrach en la TEDxRíoLimay del 2012 (en Septiembre de 2013 es la segunda edición), deja algunas perlitas:

1. Revisar mails al inicio del día consume mucha energía.
2. Dejar las actividades que nos consumen más energía para cuando estamos más descansados.
3. Priorizar
4. Visualizar
5. Escribir nuestros proyectos/ideas/compromisos para no tenerlos en nuestra cabeza constantemente.
6. Querer ser más productivos, nos hace improductivos.




Limitar nuestro WIP en pos de tomar mejores decisiones.