Habilidades vs títulos (episodio 2)

dilbert-certification

Si hace poco hablába de la titulitis en el artículo “Habilidades vs títulos” (que ahora deberé renombrar añadiéndole “episodio 1”), ahora va el jefe de Recursos Humanos de Google y suelta la frase: “el expediente académico no sirve para nada“.

Y es que nos pongamos a la defensiva o no, se está demostrando cada día más que la postura de “yo valgo porque mi título es tal o cual”, ha muerto, y debería considerarse una postura conformista y obsoleta.

Por desgracia, todo cambia, y debemos adaptarnos. Ya nunca más el tener un título va a suponer una ventaja absoluta, y debemos mirar con otros ojos (y con el debido respeto profesional), a los que han elegido otras vías de formación. Debemos valorar por capacidades, no por títulos.

Tal y como afirma el jefe de RRHH de Google, lo que se enseña en la universidad es muy distinto de lo que se necesita en el mundo laboral. La paradoja, tal y como desarrolla en el artículo, es que la universidad enseña…a superar la universidad. Del mismo modo que el hacer muchos Test Psicológicos entrena a superarlos (no necesariamente desarrolla el intelecto, aunque aparentemente los resultados de tus test sean exponencialmente mejores). De ahí se deduce que una persona que saca muy buena puntuación en un test…sólo significa eso y nada más. Para resolver problemas reales…hay que enfrentarse a problemas reales.

En el artículo, es curioso como una de las preguntas favoritas del jefe de RRHH de Google es “Dame un ejemplo de cómo resolviste un problema analítico difícil”. Aquí empieza a verse la luz valorando la experiencia, al mismo tiempo que una mente inteligente.

 

Anuncios

DevOps: la palabra de moda

devopsBueno, parece que el concepto de DevOps ha adquirido categoría casi viral. Se habla de él en las redes, y se hace a través de términos relacionados, o de herramientas usadas para llevar a cabo soluciones relacionadas con dicho concepto.

¿Pero qué es esto de DevOps?

Aunque varios conceptos de DevOps son viejos conocidos, se les añadieron algunos nuevos para dar una visión unificada. Ha adquirido especial protagonismo, por la visión de DevOps desde el punto de vista de los programadores. En realidad, la palabra ya incluye la definición. DevOps no es más que Development (Desarrollo) y Operations (Operaciones).

El origen del conflicto…

El concepto, como decía antes, no es nuevo. El objetivo de la “gente de sistemas” (operaciones), es mantener estables los sistemas, y por tanto, establecen controles en el número y forma de los despliegues en producción. Sin embargo, siempre ha existido una corriente opuesta (la de los desarrolladores), de poder tener acceso a producción, de poder desplegar un cambio o un producto con la mayor rapidez posible, y sin todos los controles, validaciones y protocolos que les imponen desde los departamentos de operaciones (recordemos: sistemas).

Ambas corrientes se sienten poseedoras de la razón. Pero como ya ha ocurrido en muchas otras iniciativas…el sentimiento agile habría de venir al rescate para facilitar a los desarrolladores el imponerse sobre la gente de operaciones.

…Y la llegada de la solución

El área de desarrollo apuesta por el cambio, por la facilidad del cambio. Y operaciones…por la estabilidad y el control. Con esto, ya tendríamos la semilla para que aprovechando las tendencias ágiles, la gente de desarrollo se sintiera legitimada para poder imponer su criterio y tener un mayor acceso y control sobre los sistemas de producción. Por otro lado, para apoyar los criterios del personal de operaciones, se usarían diversas técnicas que integraran control y rapidez de puesta en producción: un ejemplo lo tenemos en la adopción de buenas prácticas como ITIL, o los conceptos de Integración Continua.

De esta forma, se adoptarían metodologías ágiles que integrarían por un lado los esfuerzos de los equipos de desarrollo, que dejarían los objetos/código fuente bien probados y convenientemente etiquetados . Por otro, el equipo de operaciones recoge el testigo y se encarga de la puesta en producción del desarrollo/cambio, pero de una manera ágil y al mismo tiempo, segura.

DevOps trata de integrar así los objetivos de las diversas partes en conflicto con términos más o menos novedosos (al menos en su aplicación):

  • Asegurar la calidad de la entrega mediante métricas de calidad de código y pruebas automatizadas. De esta forma, el área de operaciones (ahora parte de “DevOps”), confía en el producto y corre muchos menos riesgos, lo que facilita realizar despliegues prácticamente inmediatamente después de estar el código disponible.
  • Los procesos (apoyados en conceptos como ITIL e integración continua, automatización de pruebas, etc), facilitan la integración Dev+Ops, al trabajar todos en una misma cadena.
  • Automatización: la clave de una puesta rápida en producción es que se realice al máximo a través de herramientas, no de personas. Las validaciones han de ser objetivas al máximo.

Planificación 3-4-5

Dilbert_BusinessTravel¿Alguna vez os habéis encontrado con un calendario o planificación 3-4-5? ¿No sabéis lo que es?

Bueno, este concepto está relacionado principalmente con la conciliación laboral/personal de personas que viajan habitualmente por motivos de trabajo, normalmente porque trabaja todas las semanas en las instalaciones del cliente. Este calendario o planificación consiste en:

  • 3 noches de hotel, desplazado por motivos de trabajo (normalmente de lunes a miércoles por la noche).
  • 4 días trabajando en las instalaciones del cliente. Eso significa que el jueves, te vuelves a dormir a tu casa.
  • 5 días de trabajo a la semana: esto significa que el viernes, se trabaja en tu propia oficina (o en algún caso afortunado, en tupropia casa). Esto también significa que el sábado y domingo quedan asegurados para conseguir un mínimo de conciliación entre lo profesional y la vida familiar.

Está claro que la vida profesional es dura, y que en muchos trabajos hay que darlo todo día a día. Pero iniciativas como el 3-4-5 forman un mínimo deseable, un ejemplo a seguir incluso en los más exigentes trabajos de dirección.

¿Y vosotros? ¿Habíais oído alguna vez acerca del calendario 3-4-5? ¿Os parece una buena solución?

Un saludo

Modelo RACI – Qué es y para qué se usa

Hola de nuevo. Hoy quiero hablaros de una técnica que es a la vez tan simple como necesaria, y que sin embargo, se tilda de teórica e inútil en muchas ocasiones…incluso cuando nos damos cuenta de que hace falta.

Es una técnica de gestión de proyectos, por lo que efectivamente, aquellos proyectos que carezcan de una adecuada gestión, son los principales candidatos a quejarse de esta técnica.

El modelo RACI es una técnica que permite identificar quién se encarga de qué en el proyecto. Pero va mucho más allá, identificando los principales roles intervinientes en cada tarea. Los roles que identifica esta técnica son cuatro, cuyas iniciales en inglés dan nombre al modelo:

  • Responsible: responsable de ejecutar la tarea. Vamos, quien la hace físicamente, el que se pone manos a la obra, y se “mancha” las manos.
  • Accountable: responsable de que la tarea se ejecute, es quien rinde cuentas. ¿Porqué separar este rol con el anterior? En muchas ocasiones, yo puedo ser el responsable de que algo se haga, pero no lo hago directamente yo. Lo subcontrato, o lo asigno a un tercero. Y es importante diferenciar las tareas que hago yo directamente, de las que encargo a otros.
  • Consulted: este rol tiene información útil o valiosa para la realización de las tareas, aunque no sean responsables de las mismas ni participan activamente en su ejecución. Por ejemplo, grupos de expertos en un tema, grupo de calidad, etc. Es importante destacar, que este rol interacciona bi-direccionalmente, es decir, se le consulta, y él responde, o bien participa de forma espontánea aportando su conocimiento.
  • Informed: informado. En este rol incluiremos a todos los grupos que hay que mantener informados, poner en copia de los correos, etc. La principal diferencia con otros roles es que con éste se tiene comunicación unidireccional.

¿Cómo se hace todo esto?.

Una forma simple es hacer una tabla, donde por cada fila, escribiremos en la primera columna el nombre de las tareas. De esa forma, por cada fila (por cada tarea), rellenaremos a su derecha unas columnas adicionales, una por cada persona o grupo involucrado. En esas columnas adicionales, indicaremos su rol por las iniciales antes mencionadas: R, A, C, I.

A la hora de rellenar con estas letras/roles, tendremos en cuenta una serie de reglas:

  • No es necesario usar todas las letras (R,A,C,I) en cada fila/actividad.
  • Al menos, sí deben aparecer en cada fila/actividad, los roles R y A (es decir, responsable y encargado de ejecución). Los roles C,I, son por tanto opcionales en cada fila.
  • En cada fila/actividad, debe aparecer un único R (responsable de ejecución), y un único A (responsable de la tarea).
  • En cada fila/actividad, los roles C,I pueden repetirse.
  • Una misma persona/grupo, puede asumir varios roles para una misma tarea. En ese caso, se anotaría algo como “R/A” si por ejemplo fuese a la vez responsable de la tarea y de su ejecución.

La imagen siguiente ejemplifica lo comentado:

¿Dónde se utiliza esto?

Yo lo he usado principalmente en documentación funcional para definir el “As-Is” o el “To-Be” de los procesos de negocio, o en contratos, o propuestas, donde es fundamental dejar claro el papel de las distintas partes durante el ciclo de vida de una tarea.
Es importante hacer notar, que el rol de las distintas partes puede cambiar en el tiempo. Por ejemplo, en un mantenimiento, el proveedor anterior de mantener la aplicación puede pasar de R/A, a solamente A/C (en la fase de transición) y finalmente solo C en un período de soporte en el que el nuevo proveedor de mantenimiento tiene ya el control total del soporte.

¿Y ya está?
Pues no. Como siempre, hay variantes para todos los gustos. Por ejemplo veremos dos a continuación.

RACI-S

Existe la variante RACI-S, que añade un rol adicional de Soporte (“Support”). Ésta es la variante que he visto en la práctica. EL rol Soporte, se encarga de dar soporte de todo tipo al rol “R” (que es quien hace la tarea), en todo lo que éste necesite. No confundir con el rol “C”, que sería más bien un experto en la materia, y que si bien también da soporte, digamos que dicho soporte sería más “pasivo” que el del rol “S”.

RACI-VS

También existe la variante RACI-VS que añade dos roles:

  • Verify (verificador): este rol se encarga de actividades de verificación, es decir, de comprobar si el producto está conforme con los criterios de aceptación establecidos en su descripción/diseño/calidad.
  • Sign (aprobador o supervisor): este rol aprueba las decisiones del rol Verificador y autoriza el producto. Lo lógico es que el trabajo de un S preceda siempre al de un A.

24h – El complejo de Jack Bauer

Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.

Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.

¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión “24”. Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.

¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de “bombero” o “apagafuegos” en las que nos vemos inmersos.

Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón “apagafuegos”. Os recomiendo leer esa web de antipatrones.

Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota…hasta el siguiente fuego).

Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.

Los cambios los gestionamos nosotros, no al revés.

No borres tus huellas, vaquero

Esta entrada en mi blog la dedico a todos aquellos que borran sus huellas en el trabajo. Los que sólo guardan los ficheros en su última versión. Los que no versionan los documentos. Los que cuando tienen un fichero incompleto lo destruyen al comenzar uno nuevo.

Son los amigos de lo imperfecto. Tal vez sea la obsesión de aparentar perfección, o no mostrar debilidad, tan habitual en algunas empresas.

No se trata de guardar un registro de todo lo que hacemos, sino más bien de protegernos de nosotros mismos. Después de todo, la mayoría de herramientas de versionado de código nos protegen de nuestras ganas de cambiar el código en exceso, permitiéndonos recuperar una versión previa que funcionaba o que simplemente queremos revisar. Si estamos de acuerdo en el caso del código fuente…¿qué pasa con la documentación?

La documentación es parte del proyecto.

Debemos cuidar la documentación, tal y como hacemos con el código. De nada servirá esto a los que entienden que la documentación se hace “después del código”.
Cómo me duele ver en los diseños técnicos o funcionales, código fuente o pantallas que se han obtenido de la versión final.
Los documentos  hay que versionarlos y cuidarlos como cualquier otro resultado de nuestro trabajo.

La necesidad del versionado.

Algunas ventajas de tener la documentación versionada en un repositorio:

  • Documentación alineada con cada versión del código.
  • Es fácil identificar los cambios en los objetivos, del mismo modo que el versionado del código permite identificar los cambios en los resultados.
  • Acceso centralizado. Al estar la documentación versionada y centralizada, todo el mundo accede a la última versión.
  • Notificaciones de versionado. Muchos repositorios de documentos avisan de nuevas versiones. Esto es útil porque el equipo de desarrollo puede estar informado de cualquier cambio en una Historia de Usuario, un Requisito (o como lo queráis llamar).
  • Permite escalar proyectos. Es muy sencillo trabajar con post-its para documentar requisitos, pero escalarlo a un equipo de 50 personas en 10 países, no es sencillo. En un repositorio documental, incorporar a un nuevo equipo en otro país es tan simple como darles acceso.
  • Utilizar un repositorio permite ahorrar reuniones: todo el mundo puede estar al tanto de que se está cociendo una nueva versión de los requisitos, o de que se han modificado 5 de las 10 historias de usuario de nuestro producto. Esto no significa que no sean útiles las reuniones. Simplemente se trata de que las herramientas hagan el trabajo más simple.

¿Y qué hacemos en un proyecto pequeño?

Si tu proyecto es muy pequeño, puedes hacer el versionado de forma manual. Guarda el archivo como “requisitos_v02” y ya está. También puedes integrar la documentación como parte del código, y que tu herramienta (Subversion, Git, etc), se encargue del resto.
De todas formas, es útil seguir con la documentación, las mismas técnicas que un repositorio de código:

  • Check-out: Avisa de que el documento lo vas a modificar. Que la gente tenga claro que hay una nueva versión en curso. Eso les hará organizarse mejor y centrarse en las áreas que menos cambios vayan a tener. Pocas cosas molestan más que ver cómo llega un gran cambio sobre algo en lo que hemos dedicado varias semanas con sus larguísimas jornadas. Y más cuando hay otras tareas que podríamos haber avanzado en su lugar. Avisa de la fecha prevista para terminar la nueva versión.
  • Check-in: Avisa de cada nueva versión. Que la herramienta (o tú mismo mediante un correo), notifique al equipo de una nueva versión de lo que sea (requisitos, análisis, etc). Hazlo ágil y simple. Tanto para el que lo lee, como para tí que lo escribes y que lo vas a tener que actualizar.

Actitud y respeto, fuentes del problema.

Al final, es una cuestión de respeto profesional, de velar por que nuestras acciones ayuden en lugar de interferir al resto del equipo. De intentar prever las consecuencias de nuestros actos, no limitarnos a soltar nuestro (llámalo código, documento o lo que sea), y darnos la vuelta para no ver los resultados.

Muchas veces oigo a la gente quejarse de lo mismo repetidas veces: “para qué documentar si nunca voy a tener la documentación actualizada”. Es deprimente, ya que muestra un grave problema de actitud. Hazlo o no lo hagas, pero no lo intentes. Deja ya esa actitud derrotista, por favor. ¿Somos ágiles y por tanto capaces de abrazar los cambios en el código? ¿Y sin embargo no somos capaces de hacer lo propio con la documentación? Claro que van a llegar cambios, es algo inherente en el software. El problema está en que no documentamos, sino que escribimos novelas.

Yo no sé si hay falta de programadores, pero de lo que estoy seguro de que sobran novelistas, y faltan buenos analistas o arquitectos que documenten los objetivos técnicos y funcionales. Menos verborrea, y más UML, casos de uso, historias de usuario.

Trucos para un buen informe de seguimiento

Leía hace poco un artículo en el excelente blog de Javier Garzás, sobre lo que nunca debería faltar en un informe de seguimiento. Y me he quedado con una sensación de que me faltaba algo. En primer lugar, los informes de seguimiento no son algo estándar y cerrado válido para cualquier proyecto. Empezaremos por pensar en los objetivos del informe.

Objetivos del informe de seguimiento.

Este tipo de informes, se realizan periódicamente con el cliente en un proyecto (de software o de cualquier tipo). El informe de seguimiento software pretende:

  • Identificar brevemente el proyecto. Un par de frases, un resumen del plan o del proyecto en cuestión. Esto es útil en clientes para los que trabajan múltiples proveedores. Hay que tener en cuenta que estas reuniones las sufren constantemente, y el cliente necesita que “les hagamos una introducción”. No podemos llegar y empezar a soltar nuestro rollo. Recordad: adaptar el mensaje a lo que necesita el cliente, no a lo que queremos contar nosotros.
  • Mostrar los objetivos del proyecto. ¿Qué se quería hacer? ¿Cuáles son los objetivos?
  • Mostrar de forma resumida el estado del proyecto (precisamente respecto a esos objetivos). El estado incluye cosas como revisión de posibles desviaciones en la fecha de fin, esfuerzos dedicados, o costes. Seguimiento de hitos y entregables. Cumplimiento del contrato, y los distintos acuerdos alcanzados. El estado supone comparar la situación actual respecto al global del proyecto: el coste total, el esfuerzo total en horas estimado, y la fecha final de entrega (entre otros). Presupone una planificación y un seguimiento respecto a la misma.
  • Mostrar los riesgos y su estado. Siempre hay riesgos. No gestionarlos, no dedicar tiempo de gestión, planificación y seguimiento no hace que desaparezcan.
  • Mostrar los problemas y su estado. Los problemas, se refieren aquí a problemas de gestión. No a incidentes o fallos del software. Los problemas surgen en cualquier momento (un entorno no disponible, una tecnología que no funciona, un profesional que se va de la empresa…). Los problemas han podido ser detectados previamente (como riesgos), o surgir de imprevisto.
  • Hitos clave y su estado. En todo proyecto suele haber fechas clave, que incluso pueden determinar el poder facturar o no todo o parte del proyecto.
  • Entregables clave y su estado. Los proyectos no son solo código. Suelen llevar otros entregables (documentos, hardware,…), y que estarán recogidos en el contrato u objetivos iniciales.

Otros posibles contenidos el informe de seguimiento.

Vamos a ver otras cosas que pueden incluirse en un informe de seguimiento, pero que hay que pensarse bien si encajan en el tipo de seguimiento que pretendemos presentar:

  • Avance del proyecto. No es lo mismo avance que estado. Al hablar de avance, nos referimos a lo incorporado desde la reunión de seguimiento anterior. Este tipo de reunión sería incremental, y trata de mostrar la diferencia respecto a lo anterior. De nuevo, este tipo de información suele darse en proyectos ágiles. Cuidado con esto, porque estamos mostrando la situación relativa respecto a un estado anterior, pero no respecto al proyecto total (eso sería un estado del proyecto). En proyectos ágiles, habría que dar también un estado, es decir, informar de cómo nos encontramos respecto al total del proyecto, informando de un coste estimado, fecha estimada de finalización, etc, etc.
  • Estado de la calidad. Soy defensor de la calidad, y creo que hay que planificarla, establecerla muy al principio, y utilizar para ello indicadores lo más objetivos posibles. Sin embargo, en el tipo de clientes que he visto en mis bastantes años de vida profesional, no metería gráficas ni un análisis semanal de métricas (pocos clientes los entenderían). Eso sí, esos análisis los haría “de puertas para adentro”, y lo convertiría en un semáforo donde se indicara si dichos indicadores están bien, o si por el contrario alguno de ellos no se está cumpliendo. Este tipo de indicadores, por ejemplo, lo trataría en un informe de seguimiento técnico, no en un comité ejecutivo. Por desgracia, los indicadores de calidad no son entendibles, y pueden dar lugar a falsos equívocos, preocupaciones innecesarias. Lo que hay que hacer es evidenciar que se trabaja con calidad dentro de un margen, y que se trata no de dar un producto perfecto, sino un producto con un buen balance entre coste y calidad. Por supuesto, siempre es posible que un sistema automatizado, u otra empresa certificadora, sea quien presente el estado de la calidad.
  • Demo del software. Una demo del software, no siempre podrá realizarse con los clientes en todas las reuniones del seguimiento. Básicamente, porque una reunión de seguimiento ha de ser algo muy concreto, muy enfocado, y una revisión funcional del software puede llevarnos mucho tiempo. Por otro lado, una demo no se hace cada 1, 2, o 3 semanas. Tal vez sí en proyectos ágiles que lleven asociado un cliente deseoso de ver ese software avanzar. Pero no siempre. Una última cosa. Las demos son caras. Se dedica tiempo y recursos en preparar una demo. Y no sólo por el software: están las personas que asisten (cuyo tiempo es caro, y hay que respetar), están los datos, que han de estar listos para presentar el software (la gente no quiere ver el software, quiere ver las cosas que es capaz de hacer, y eso requiere de una preparación de datos previa).

Al final, no existe un informe perfecto. El informe debe servir al cliente y a los propósitos del proyecto. Todo lo aquí comentado suele incluir se en informes, pero hemos de recordar que no todas las reuniones de seguimiento son iguales.

Antes de presentarnos a una reunión, deberemos: establecer qué necesita el cliente, cuál es el ámbito del proyecto… De todas formas, yo recomendaría siempre al principio del proyecto establecer claramente:

  • Modelo de relación: tipos de reunión, quiénes asistirán, decisiones a revisar, periodicidad…
  • En cada tipo reunión, definir qué informe se revisará, contenido, roles (quién lo presenta, quién lo aprueba, etc).