Encuesta a los lectores

Escrito el 20 de Diciembre de 2007 a las 12:25 

La pregunta es:

Si en vuestra empresa contratasen a Proyectalis, ¿Para qué pensais que sería? “

Venga, hay casi 500 suscritos al blog, no me seais perros y contadme algo en los comentarios. Prometo análisis y conclusiones ;-)

Manda webs…

Escrito el 19 de Diciembre de 2007 a las 10:58 

Hace un par de semanas puse una oferta de empleo en Infojobs. Buscamos gestores de proyectos en el ámbito de las telecomunicaciones y las tecnologías de la información, con al menos tres años de experiencia y manejo del inglés con soltura, aunque las principales características que evaluamos son unas excelentes habilidades interpersonales, una alta capacidad de análisis y síntesis de los problemas y oportunidades observados en el desempeño de sus funciones, un conocimiento tecnológico adecuado a los proyectos en los que vaya a participar y algo de formación específica en las técnicas, metodologías y herramientas de gestión de proyectos. Se trata de un puesto orientado a trabajar en proyectos de nuestros clientes más que a engrosar la estructura interna de la empresa, eso sí, y buscamos titulados en Ingeniería Superior de Telecomunicaciones, Informáticas o con formación/experiencia equivalente. En el fondo, en realidad, lo que buscamos es gente con pasión y con talento, pero claro, eso es dificil de cuantificar en primera instancia.

Entre las cosas que ofrecemos están (cito) “la flexibilidad de horarios, el compromiso de formación interna y externa, las facilidades para el Teletrabajo, una filosofía OpenBusiness y la oportunidad de participar en un proyecto jóven con gran proyección de futuro“. Además de una banda salarial de entre 24.000 y 36.000 euros. Que digo yo que no está nada mal.

A la oferta han respondido 61 candidatos, de los cuales unos diez cumplían muy bien con las expectativas que tengo al respecto (al resto, gracias por el interés, y a los 21 que se han descartado por estar absolutamente fuera de nuestro área de interés…En serio, replanteaos la estrategia de apuntaros a todo lo que se mueva, que quema mucho, a vosotros y a nosotros). A los finalistas se les ha mandado un correo explicando mejor el proceso, el timing que estamos manejando, algunas características del puesto y pidiendo algo más de información sobre su situación actual, lo que les ha gustado de la oferta y de la empresa… No he mandado un correo similar a los 30 restantes más por falta de tiempo y de una utilidad en Infojobs que permita mandar un mensaje-tipo a una selección de perfiles (tendría que ir abriendo uno por uno y cogiendo las direcciones de correo…Señores de Infojobs, tomen nota, que esto es consultoría gratis). De todas maneras nos quedamos con estos perfiles para posibles necesidades en el futuro, ya que en general son interesantes.

Bueno, pues de los seleccionados y contactados el 75% ni siquiera me ha contestado al correo, y de eso hace ya una semana. Dicen algunos amiguetes que Infojobs tiene herramientas que te apuntan automáticamente a las ofertas en función del campo de conocimiento, salario, ubicación… Yo creo recordar que Infojobs te avisa de estas ofertas, pero dudo que te pueda suscribir directamente sin tu aprobación específica, y si es así me parece muy mal, sinceramente.

Volvemos a mis preguntas de siempre:

PD: El proceso sigue abierto, por si algún lector se siente cualificado y con ganas… Hay otro puesto más estructural, peor pagado pero con mayor apego y responsabilidad en la empresa. Lamentablemente para vosotros, ese tiene novia hoy por hoy… ;-)

Responsabilidad Social Corporativa

Escrito el 3 de Diciembre de 2007 a las 19:25 

Micropost: La junta directiva de Proyectalis en pleno, con su Consejera Delegada Ejecutiva al frente, ha decicido donar un 1% de la facturación del año a una ONG o proyecto que merezca nuestra aprobación y solidaridad (no os emocionéis, que son cuatro duros, pero si nosotros podemos con el 1% el estado ya debería poder con el 0,7%, digo yo, más ahora que hay superavit). Hemos estado a un trís de optar por Intermón Oxfam, ya que hasta antes de ayer estabamos muy por la labor del comercio justo y la cooperación para el desarrollo, pero la lectura de El Economista Camuflado ha cambiado ligeramente mi visión al respecto (lo justo para que por lo menos indague y me documente antes de apoyarlo) . Ya colaboramos personalmente con Médicos sin Fronteras, y ando barruntando que a la raza humana le está bien empleado lo que le pasa y que quizás debería tender hacia la causa ecologista, pero sinceramente no los veo muy centrados ultimamente. Así que andamos algo perdidos. Como esto siga así, lo invertimos en árboles y ya veremos dónde los plantamos. Sugerencias bienvenidas. Religiones abstenerse.

Cosas que hacen que Scrum funcione

Escrito el 30 de Noviembre de 2007 a las 13:11 

Que sí, que sí: que scrum es muy sencillo. Que se explica en cinco minutos. Que se lo puedo explicar hasta a mi abuela. Pero que algo más tendrá Scrum cuando en el último curso hemos estado dieciséis horas analizándolo (sin contar almuerzos) e incluso nos ha faltado tiempo.

Scrum es indudablemente más sencillo que los frameworks pesados para la gestión de proyectos como puedan ser el PMBOK o Métrica V3 (¡ergs!), e incluso más sencillo que las versiones “lite” que se han diseñado de los frameworks pesados, como puede ser Prince2. Pero eso no quiere decir que si echamos a andar los famosos tres procesos, tres artefactos y tres roles ya lo tengamos todo hecho. Hay muchos aspectos que son los que hacen que Scrum funcione, y la atención a estos aspectos marca la diferencia entre el 66% de empresas que consiguen implantar Scrum efectivamente y el 33% que abandona por el camino (datos de la Scrum Alliance).

Ahora que empieza el iweekend (que rabia habérmelo perdido) y sabiendo que Raúl está mirando metodologías ágiles para aplicarlas, me he decidido a escribir este post. En base a mi experiencia y a literatura existente (que la hay como para enterrar a un gran danés en papeles), las cosas que hacen que Scrum funcione son las siguiente:

  1. Scrum es sencillo, pero muy duro. Como un canto rodado, vaya. Si pensamos que Scrum no nos va a requerir un esfuerzo, es más que probable que la gente abandone cuando se de cuenta de que exige una importante dedicación, un proceso de gestión del cambio que puede llegar a ser muy complicado y un nivel de foco superior al que se habitualmente se tiene en las organizaciones. Aun así, los resultados que Scrum proporciona en términos de productividad, calidad, satisfacción, éxito y rentabilidad de los proyectos hacen que el esfuerzo merezca la pena.
  2. Scrum no es una bala de plata. Esto, junto con lo de las gallinas y los cerdos, es uno de los principios más citados de Scrum. Cuando la gente se sumerge en el mundo de las metodologías ágiles y ven lo que pueden llegar a conseguir siente la tentación de recetar “café para todos” (en palabras de Mario). Y eso no es así. Scrum tiene su territorio: proyectos complejos, con un requisitos cambiantes, organizaciones flexibles, implicación del cliente… En otros entornos es mejor usar otras cosas. Por otra parte, Scrum no va a solucionar todos los problemas de la organización. Si falta compromiso de la gerencia, si hay compañeros obstruccionistas., si el cliente es un explotador…Bueno, Scrum no va a solucionar todo eso. Si pensamos que sí y fallamos, sentiremos la tentación de abandonar Scrum. Por eso es importante recordar constantemente que Scrum no es una bala de plata.
  3. Scrum es iterativo e incremental. Repetid conmigo: iterativo e incremental. Iterativo e incremental. Eso quiere decir que liberamos código (o producto) frecuentemente, y cada liberación representa un incremento sobre la anterior. Pensad más en “Casa 0.1″, “Casa 0.2″ hasta “Casa 1.0″ que en “cimientos” seguido de “paredes” seguido de “techo”. No podemos liberar una casa sin techo, pero a lo mejor sí una casa con paredes de chapa y techo de uralita (version “chabola”… Todo tiene un mercado).
  4. El producto que funciona es la única medida del avance del proyecto. Si me tuviera que tatuar una frase sobre Scrum, sería esta. No cuántas horas hemos echado. No cuántos recursos llevamos consumidos. No cuántas tareas llevamos hechas. Producto que funciona. Si no hay producto que funciona, no avanzamos. Lease el punto anterior.
  5. Todo en Scrum tiene un límite de tiempo. Para esto me gusta mucho la expersion inglesa time-boxed, que lo expresa mejor. Nada de “alargamos la reunión un poco más”. Nada de “El lunes, tal vez el martes”. La reunión acaba a las cuatro, y trabajaremos con lo que tengamos al final de la misma. La entrega es el lunes, y entregaremos lo que tengamos el lunes. Scrum cambia el enfoque tradicional del PMBOK de recursos+funcionalidades deseadas = fecha de entrega y lo convierte en recursos + fecha de entrega = funcionalidades que podremos entregar. Si se nos cae una funcionalidad de la lista, vaya por Diox. Pero entregamos.
  6. Las entregas son productos potencialmente utilizables y/o comercializables. Shippable, que dicen los ingleses. Eso significa que nada de power point y nada de planos o documentos describiendo lo que hará la aplicación: queremos tocar, ver y usar algo, aunque sea un prototipo de la funcion de login.
  7. Definir qué significa terminado. Terminado puede querer decir “rula” o puede querer decir “rula, ha pasado los tes de calidad, se ha documentado, se ha añadido al repositorio y hemos formado a soporte técnico”. No es lo mismo. El trabajo no se acaba hasta que se acaba.
  8. Mantener Sprints de duración fija. Al principio es muy tentador andar tocando la longituds de los sprints para adecuarlos al producto, en vez de adecuar el producto a los sprints. Pero si hacemos lo primero nunca seremos capaces de obtener una sensación correcta en el equipo de cuánto trabajo podemos abarcar en un Sprint. Scrum es disciplina: quien piense que las metodologías ágiles on una especie de hacking institucionalizado, se equivoca.
  9. Realizar los Scrums diarios. Es una de la sprimeras cosas que se abandona, como decían en su día en el blog de chuidiang. Pero el Scrum diario es la unidad atómica de Scrum, y si empezamoscargándonos esto, no podemos esperar que los ladrillos se mantengan unidos. El Scrum diario es lo que consigue que podamos controlar a tiempo, que tengamos visibilidad efectiva, que el equipo sincronice sus tareas… Hay que protegerlo a capa y espada, y ser muy estricto con su celebración. Por eso lo de “todos los días en el mismo sitio, a la misma hora”. Si empezamos a cambiar las horas todos los días, acabaremos por no celebrearlo un día. Entonces pensaremos “anda, no ha pasado nada” y empezaremos a saltárnoslo cada dos por tres. Y entonces estaremos en la situación sobre la que nos previene el ScrumMaster Miyagi: haremos “Scrum supongo”.
  10. Hacer retrospectivas. Lo más importante de las retrospectivas es asegurarse de que se celebran. Las retrospectivas son lo que nos permite detectar impedimentos de alto nivel en el proceso y mejorar constantemente. Si nos enfocamos demasiado en los sprints y en producir y no nos paramos de vez en cuando a reflexionar, todo el enfoque empírico y adaptativo de Scrum se nos viene abajo. Como decían por ahi, “si siempre estás sprintando, en realidad acabarás haciendo jogging”.
  11. Respetar los roles: Sólo el Dueño de Producto puede tocar la pila de producto. Solo el euipo puede tocar la pila de Sprint. Permitid que los Jefes manoseen la pila de producto o que el dueño de producto trastee con la pila de sprint y acabaréis con unos equipos que mandarán Scrum a hacer gárgaras hartos de que no se les deje trabajar ni se confíe en ellos. Scrum es adaptativo, pero eso no quiere decir que todos los días peguemos volantazos: es más bien hacer pequeños movimientos de volante constantemente para mantener al coche en la carretera. Aquí es donde viene bien la historia de las gallinas y los cerdos: distingamos también entre miembros del proyecto y stakeholders.
  12. El Scrum Master no es un jefe. Es un “siervo-lider”. No le dice a la gente lo que debe hacer. No divide las tareas entre los miembros del equipo. No acepta o rechaza las funcionaldiades. El equipo es quien decide, y el dueño de producto el que evalua. El Scrum Master sólo debe preocuparse de que el proceso Scrum siga en marcha y de eliminar los impedimentos en el camino del equipo. Tiene más de Coach que de Project Manager.
  13. No interrumpir constantemente a los equipos durante los Sprints. Si no confiamos en los equipos y les dejamos trabajar, ¿qué estáis esperando que ocurra? Una terminación anormal de Sprint debería significar que algo muy gordo está pasando en la empresa o en el proyecto. Y si hay que hacer re-priorizaciones, que afecten al próximo sprint en la medida de lo posible, no al que está ahora mismo en marcha.

En fin, probablemente no estén todos los que son, pero son todos los que están. Espero que esta lista os sea de utilidad implantando Scrum, y vigilaré ansioso los twitter del iweekend este fin de semana. ¡Animo tíos! ;-)

PD: Para los supersiticiosos, cogéis el punto 11 y lo dividís en “solo el dueño de producto toca la pila de producto” y “solo el equipo toca la pila de sprint”…¡Voila! 14 puntos. :twisted:

Certificación PMP

Escrito el 15 de Noviembre de 2007 a las 18:30 

Recibo cierta cantidad de mensajes preguntando por los pasos necesarios y recursos disponibles para obtener la certificación PMP (os recuerdo que estoy en ello). Recuerdo que en su día ya me resultó algo confuso obtener información sobre la forma en la que solicitar el exámen, dónde hacerlo, el coste del mismo o cómo prepararlo. Ervin me ayudó en su momento a solucionar varias de estas dudas, así que os resumo a continuación lo que conozco al respecto:

Una vez obtenido el PMP hay que mantenerlo a lo largo del tiempo obteniendo PDU’s (Personal Development Units) a razón de unos 60 al trienio… Pero eso, amigos míos, es otra historia ;-)

Buscar:

Suscriptores:

Pastafari!

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter

    Fotos

    www.flickr.com
    angel.medinilla fotos Más fotos de angel.medinilla
    Cerrar
    Enviar por Correo