Entradas

Mostrando las entradas de marzo, 2014

Mejora de procesos de TI > Documentar

Encuentro todavía muchos lugares donde el área de procesos tiene como misión documentar. "Tenemos el 90% de los procesos documentados" te dicen. Como si el porcentaje de procesos documentados fuera una métrica de éxito. Siento decirles que no lo es y que esa visión estrecha de la disciplina hará que pronto dejen de existir. Ningún CIO sostiene un área de procesos para documentar. Se puede contratar a un externo para venir, relevar y documentar en algunos meses los procesos pero no tener un área para eso. La misión de un área de procesos es proveer la infraestructura necesaria para que el negocio primero y el área de TI después, cumplan sus objetivos. Debe ser un área dinámica, que escucha sistemáticamente a la organización y busca formas de hacerla más eficiente y más eficaz. Seguimos pensando..

Una mañana de lluvia

Una mañana lluviosa, particularmente tranquila en la casa. Es cuestión de poner un poco de música tranquila y ponerse a escribir un rato. Cada tanto los planetas se alinean y eso es posible. Definitivamente este es uno de esos momentos que hay que dejar {consignados | registrados | resaltados } para recordarlos. No todo es a las corridas, lo mejor posible y con el aliento en la nuca. Seguimos pensando..

#weekendvideo 55. Hans Rosling and the magic washing machine (2010)

Gracias al amigo Damián , me crucé con este video de Hans Rosling. Contenido, excelente. slides excelentes, presentación, excelente. Una jollita. Seguimos pensando..

#consultip 177. ¿Quiere ser un PM valorado? Embárrese

Aquellos que creen que gestionar proyectos significa controlar el GANTT están fritos. El verdadero PM (project manager), el que es valorado por el resto del equipo, se embarra y forma parte de él. Es protagonista del proyecto y es responsable directo de que las cosas se hagan. Ese PM no tiene problemas tomar tareas de otros si cree que con eso el proyecto avanza. Tampoco los tiene a la hora de involucrarse técnicamente para entender y hablar el idioma de los demás. Seguimos pensando..

¿Dónde termina un proyecto de desarrollo de software?

Me resulta sumamente difícil de entender por qué tantos equipos de desarrollo consideran que el final de su proyecto es el momento en el que entregan el software para que Operaciones lo instale en producción. Ni hablar de esos equipos que creen que en realidad su proyecto termina cuando entregan el software al Equipo de Testing . El final del proyecto debería ser, para todos, el software funcionando en Producción sin problemas. Por suerte hay dos tendencias positivas que de a poco van aligerando este problema. Por un lado, las metodologías ágiles rompiendo los silos organizacionales (léase las áreas de Desarrollo, Testing, Infraestructura y/o Producción) en las áreas de TI. Por otro DevOps . Seguimos pensando..

Optimizar el tiempo de testing manual vs. Automatizar

¿Se han encontrado con frases parecidas a esta? "Quiero automatizar todas las pruebas de esta aplicación, de esta forma podré achicar el tamaño de mi equipo de testing. El objetivo es apretar un botón y que todo se testee sólo." Yo sí y provienen de un error muy común. Mucha gente cree que la automatización de pruebas tiene por objetivo reemplazar horas de testing realizado en forma manual por tiempo de una máquina. En el extremo, para determinados dominios y tipos de prueba, podríamos llegar a no necesitar tiempo dedicado a ejecutar tareas manuales por parte de un tester. Vamos a tener que trabajar duro para conseguirlo pero sería posible. En la práctica hay muchos estadios previos que resultan muy útiles y hasta con mejor relación costo-beneficio. Mucho más productivo es pensar los temas de automatización en términos de optimización del tiempo del tester . No buscamos reemplazar al tester, sino minimizar los trabajos manuales. Todo trabajo que pudiera ser realizado por un

#weekendvideo 54. Marcus Buckingham: Identify Your Strengths #Wobi

Interesante forma de ver nuestras fortalezas y debilidades, no? Seguimos pensando..

Nos faltan analistas funcionales y no nos damos cuenta

Hace tiempo escribí sobre la escasez de profesionales informáticos . Ahora toca el turno de hacer doble-clic en los analistas funcionales . Empiezo por el final. Mi hipótesis es que faltan personas que realmente tengan las habilidades necesarias para hacer trabajo de análisis funcional y deberíamos hacer algo al respecto. Algunos coinciden conmigo y dicen que es natural: si faltan informáticos en general, faltan analistas en particular. Otros no coinciden conmigo y dicen que no faltan analistas. Mi sensación es que los que dicen eso contabilizan como analistas a personas que en realidad no reúnen las condiciones mínimas para serlo[1]. ¿Qué deberíamos hacer? Primero, trabajar sobre algún tipo de acreditación, certificación o estándar que nos permita dirimir la cuestión de si alguien reúne o no las habilidades para ser analista funcional. Algo he hablado en el pasado sobre esto . Teniendo una vara consensuada para medir podremos discutir si tengo razón en que faltan o no. Luego, si

La informática dejó de ser un cuerpo compacto de conocimiento

Tiempo atrás si querías trabajar en algo relacionado con el software estudiabas informática. El cuerpo de conocimiento era monolítico y sin especialidades. Esto ya no es así. Hoy tenemos personas de las más diversas formaciones ocupando puestos de trabajo relacionados con el desarrollo y el mantenimiento de software. Algunas con éxito y otras si él, obviamente. Algunas con las habilidades mínimas requeridas para desempeñar su rol y otras no. Hasta tenemos informáticos desempeñando roles para los que no estamos preparados[1], en la industria del software. Por ejemplo informáticos escribiendo guiones para juegos, dios mío! Hoy no están claras y consensuadas las habilidades mínimas que cada perfil requiere. El mercado tiene búsquedas distintas para perfiles como Desarrolladores, Testers, Analistas Funcionales, etc. No obstante, los criterios para evaluar la aptitud de los postulantes a dichas búsquedas son subjetivos. De hecho, a la hora de revisar la oferta en educación y capacitación

#consultip 176. Convencemos contando historias

La era en la cual convencíamos a otras personas usando la retórica convencional ha terminado. Según el artículo de HBR Storytelling that moves people usar este método tiene dos problemas: "But there are two problems with rhetoric. First, the people you're talking to have their own set of authorities, statistics, and experiences. While you're trying to persuade them, they are arguing with you in their heads. Second, if you do succeed in persuading them, you've done so only on an intellectual basis. That's not good enough, because people are not inspired to act by reason alone." Los autores del artículo sugieren usar otro método: contar una historia . Ellos dicen que “In a story, you not only weave a lot of information into the telling but you also arouse your listener's emotions and energy.”. Obviamente esto no es sencillo. “Persuading with a story is hard. Any intelligent person can sit down and make lists. It takes rationality but little creativity t

#weekendvideo 53. Pasión.. de la película “El secreto de tus ojos”

Gran escena! Lástima que hablan de Racing y no de River. Seguimos pensando..

Espejitos de colores

Llevo tiempo trabajando en consultoría y he visto de todo. Sin embargo, todavía me indigno al ver cómo ciertas personas/empresas creen en los espejitos de colores que algunos venden. Inclusive, diría que me enojo más con el que los compra, que con el que los vende. Seguimos pensando.. Firma: El Campeón Moral

No existe el éxito fácil en calidad de software

Para tener resultados debemos tener "políticas de estado" que se mantienen a lo largo de años . Es necesario desarrollar que nos lleven a hacer las cosas con el nivel de calidad que queremos. Dan gracia esos lugares donde creen que "en unos meses" se puede generar una cultura de calidad . Seguimos pensando..

Increíble pero real: Todavía hay empresas que no tienen #DevOps en su agenda

El otro día un cliente me comentaba sobre los problemas que estaba teniendo para poder poner en producción un desarrollo que habíamos terminado. Me decía que el servidor que Operaciones “le había prometido” ya no estaba disponible y que entonces no sabía donde lo iba a poder instalar, y que estaba viendo si “le prestaban una máquina”, etc., etc.. Estos problemas estiraban los tiempos del proyecto y -como corolario- también nos complicaba un poco a nosotros de modo que, con una mezcla de alarma y diversión, le pregunté sobre la forma en la que su empresa se organizaba (tienen un área de TI muy grande). No había dicho ni tres oraciones cuando recordé “the wall of confusion” de este post y el concepto de DevOps. Me describía torres verticales, castillos, quintas, política, etc., etc.. Quiero creer que el CIO de esa empresa sí tiene el tema en carpeta y que esta es sólo otra de las pequeñas rencillas que ocurren más abajo en el organigrama de TI. Quiero creerlo porque sería raro que un

#consultip 175. Sea coherente con sus tarifas

La consistencia y la previsibilidad son valores que considero importantes en los consultores. Lo mencioné cuando hablaba de la vestimenta y lo traigo ahora también respecto a los precios. Es importante mantener una política de precios coherente . Esto permitirá que nuestros clientes puedan proyectar de antemano sus costos y tenernos en cuenta en sus presupuestos. Dicho esto es necesario aclarar que coherente no significa fija y menos en contextos inflacionarios como el de la Argentina de hoy. Seguimos pensando..

#weekendvideo 52. David Puttnam: Does the media have a "duty of care"? #ted

Un tema interesantísimo presentado en forma excelente. Son 10 minutitos, véanlo y van a entender mejor lo que nos pasa aquí en Argentina también. Seguimos pensando.. PD: Por las dudas dejo el link .

#consultip 174. Tenemos que pensar nuestra carrera como una maratón

Tal vez es un pensamiento muy generación X pero la verdad es que creo que es importante pensar la carrera como algo que dura más que los próximos 6 meses o el próximo año: como una maratón. Podemos ganar carreras de 100 metros, es decir pegarla con algún laburo que hoy sirve y mañana no. Eso nos dará nuestro minuto de fama, sin dudas. Pero ¿cuánto dura eso?  Una maratón es equivalente a años de carrera con pendiente positiva , con una red profesional armada , con conocimiento adquirido y con una reputación ganada. Seguimos pensando..

#quote “Management is the most noble of professions if it’s practiced well”–Clayton Christensen

Clayton Christensen, en How Will You Measure Your Life , escribió lo siguiente: “Management is the most noble of professions if it’s practiced well. No other occupation offers as many ways to help others learn and grow, take responsibility and be recognized for achievement, and contribute to the success of a team.” Seguimos pensando..

Monumentos

Extraído de The Monuments of Tech: “When companies feel that they are changing the world as much as these tech enterprises do, they don’t need just offices. They need monuments.” Yo, en lo personal, no creo en este tipo de cosas. Seguimos pensando..

Especialización vs. Visión Amplia y de Conjunto

En su post La innovación corporativa y la gestión de la información , Enrique Dans dice: “En la era post-industrial, el mejor trabajador no es el que se especializa hasta el límite y únicamente es eficiente en una tarea muy específica, sino el que mantiene una visión amplia y de conjunto que le permite aportar cosas que, en muchas ocasiones, no tienen una relación directa con su trabajo.” Seguimos pensando..

#weekendvideo 51. Greg McKeown: Essentialism - The Disciplined Pursuit of Less

Como decía en mi post del lunes, se trata muchas veces de hacerse el tiempo para pensar. Les dejo un video de 5min relacionado con este tema. Interesante lo que dice, aunque todavía no leí el libro. Seguimos pensando..