lunes, 8 de octubre de 2007

la cuenta por favor.

Tras un mes fuera del mundo TIC, la verdad es que no dejo de sorprenderme de la capacidad humana para "desaprender", olvidarse de todo y cambiar totalmente de tercio.

Después de casi un mes, me ha llegado una invitación de Antonio Valle, para que continúe con una serie de reflexiones acerca de como valorar un servicio profesional.

Todo empezó aquí, para seguir con la anecdota de la guerra fría en este, para tener más tarde otra buena réplica.

Ahora me toca a mi. La verdad es que en este mes de desconexión, me ha servido para ver las cosas desde fuera, y comprender como se ven las cosas desde el otro lado.

La verdad es que el debate surge porque es complicado. En mi opinión es difícil poner precio a la experiencia, habilidad, y capacidad de una persona. Y si estamos hablando de algo, en ocasiones tan intangible como la consultoría TIC, pues aún más.

Para polemizar un poco con lo anterior, he de decir, que es verdad, en ocasiones el cliente no valora la aportación del profesional en su justa medida, por lo que se dan situaciones de ese tipo, no le vas a cobrar lo que crees que vale, y optas por una solución de compromiso que salve tú orgullo y la amistad.

Pese a esto, he de decir que en mis años de experiencia en TI, he visto facturar por cosas, que si te paras a pensarlas no son más que una tomadura de pelo. Supongo que todos habremos visto, más o menos de cerca facturar unos buenos euros por un mal trabajo de copio/pego/copio/pego.

En resumen, que nos encontramos en una situación difícil por dos motivos. El primero es que el cliente en ocasiones no alcanza a ver el valor de nuestra aportación, si esto sucede ya no es un problema de lo duro que sea negociando, sino que no lo va a ver. El segundo, es el mercado quemado que han dejado muchos por ahí, y que hace que la gente vea la consultoría con recelo.

¿cómo lo arreglamos?
Yo creo que lo fundamental son dos pasos. El primero es conocer al cliente, entender sus necesidades, y ver si de verdad nuestro producto encaja o no.

Eso lo veo claro ahora, estoy al frente de una Pyme, con un volumen de facturación decente, tenemos muchos proyectos abiertos, y se(porque vengo de allí), que habría cosas para hacer en TIC, que resultarían muy interesantes. Sin embargo, por el momento, la cultura, la estrategia no vamos a hacerlos. Por lo tanto, difícilmente voy a pagar un servicio a su justo precio, si creo que no lo necesito.

El segundo paso, es poner en valor el servicio. Creo que el precio de un servicio siempre ha de ser función de su resultado, tendrá mayor o menor correlación, pero creo que un servicio ofertado puntualmente tiene que venderse de ese modo.

Si consigues argumentar y explicar la relación entre tú servicio y un valor creado, lo cuantificas y te asignas un importe, el único tema que queda abierto es la negociación de si te llevas más o menos, y eso se arreglará sin lugar a dudas.

Si esto lo llevas a proyectos TIC, se que es complicado. ¿Como valorar el efecto de tu trabajo en un proyecto con su propio y nebuloso Business Case?.

Pues seguro que es difícil, pero yo desde aquí lanzo mi propuesta. Compromiso con los resultados de negocio.

Si hago un proyecto de BI, para analizar las pautas de consumo, y con ello mejorar las ventas, o aumentar la fidelización. Compromete tú servicio con el resultado, € más de ventas, mejora en la fidelización del XXX €.

Ya se que dependes de muchas cosas, del mercado, de la competencia, del tio de marketing que no tiene ni idea, de que si este invierno llueve menos, que si el Euribor ......

Si quieres cobrar lo que vale, demuestra y compromete lo que vale, y si no, factura horas.

miércoles, 8 de agosto de 2007

Despedida y cierre

Hola a todos, después de unos meses con este blog, con una actividad modesta, llega el momento del cierre.

Más que cierre reorientación, ya que a finales de este mes dejaré de dedicarme profesionalmente al mundo TIC, para asumir la dirección de un negocio mucho más tradicional.

El cambio es grande, pero espero que todo lo que he aprendido durante estos años me sirva para, desde un ámbito distinto aportar lo máximo posible en esa generación de valor de la que habla el título del blog.

Me voy justo ahora, con la CMDB integrándose en los procesos, con la gestión finaciera en mente ...
pero bueno, espero que todo esto siga su curso y al final se continúe persiguiendo ese objetivo, el alinear y el conseguir ese entendimiento a veces complicado entre negocio y TI.

Os agradezco a todos vuestras visitas, y lecturas, así como los comentarios que me han llenado de ánimo y de ganas para continuar con esto.

martes, 3 de julio de 2007

Por fin vacaciones


Bueno, este año ya me he quejado de las muchas horas que paso en la oficina. (porque yo quiero, todo sea dicho). Así que también toca anunciar, las buenas nuevas, cuando toca como es el caso.

Estoy de vacaciones, un par de semanitas que me vendrán muy bien. Y para desconectar, pues nada mejor que dejarlo todo e ir hasta los Pirineos en mi moto. Espero volver con las pilas cargadas.

Nuevos horizontes. Kaizen


El pasado lunes asistí a unas jornadas sobre Kaizen, organizadas por la Escuela de Negocios Caixanova.

El entorno, tanto en lo referente a asistentes, como ponentes era muy industrial, con una presencia muy importante del automóvil. Algo normal, si se tiene en cuenta que el organizador era el Cluster de Empresas de Automoción de Galicia.

Lo primero que me llamó la atención, es lo lejos que en principio parece estar un entorno fabril, comparado con el entorno de servicios TIC en el que me muevo habitualmente. Da la impresión, de que es un mundo más maduro, un entorno físico dónde las cosas se ven y se tocan.

Sin embargo, escuché con gusto las palabras del Sr. Masaaki Imai, qué más que experiencias prácticas o tangibles, nos dio una deliciosa charla acerca de la filosofía Kaizen.

Me gusto mucho el hecho de que se centrase, en lo que aporta valor. El valor se aporta en el Gemba, el taller, el lugar dónde suceden las cosas.

Su charla hablaba de cómo este el sitio en el que trabajar para conseguir la mejora, siempre pensando en como eliminar la "muda" (desperdicio), para conseguir mejorar los procesos.

Tras la charla me quedó claro como funciona, pero comencé a dar vueltas en cómo esto se podría adaptar a una organización que desarrolla y presta servicios TIC.

Al llegar a mi oficina, empecé a buscar el gemba. ¿dónde está?. Realmente dónde suceden las cosas, es en los puestos de los programadores, de los analistas, de los agentes del Service Desk, de los técnicos de sistemas, de los DBA's ....

Con todo esto de ITIL, COBIT, Gobierno IT, estamos trabajando en crear una capa de control, y de coordinación entre procesos, pero en ocasiones es preciso levantar la vista, y darse cuenta que no son fines, son medios para, dicho en términos Kaizen, eliminar muda en el gemba.

Una de las historias que más me gustó, es cuando comentaba que hacía él cuando llegaba a una planta. Se iba el gemba, siempre. Y una vez allí, la manera de identificar quien está agregando valor y quien no, es la verdad curiosa y sencilla. Los que mueven los dedos, son los que están aportando valor. Los que hablan, pasean, fuman, toman café no están agregando valor. Se que es otro entorno, pero no deja de ser aplicable.

En resumen, la jornada ha sido muy interesante, porque a veces abrir nuevos horizontes, y mirar en otros contextos ayuda a enriquecer la visión que puedes tener de cómo hacer las cosas.

domingo, 17 de junio de 2007

¿Qué ha sido del propósito del fin del overtime?

Empezaba este 2007, con este post. Totalmente comprometido con la causa de acabar con el tiempo extra en la oficina.

Medio año después, solo puedo decir que recuerdo con cariño las primeras semanas del año, en las que me iba a casa a las 20h.

Cambios organizativos, cambio de proveedor con un servicio importante, nuevas responsabilidades, y un proyecto de lanzamiento han terminado por dinamitar todo esto.

La buena noticia es que mis fines de semana, siguen casi intactos, pero de lunes a viernes, la jornada se vuelve a hacer extra-larga.

Si fuese una situación puntual, pues no me preocuparía, pero empiezo a pensar que esto, en el mundo TIC funciona así.

Mantengo mi idea, acerca de que trabajar así no es bueno. Baja la productividad, pero claro, siendo ya un poco malpensado uno se da cuenta, que asumen más costes el que lo hace que el empleador.

Tal vez sea preciso comenzar a tratar esto como una externalidad. Realmente se están generando costes (personales, sociales ...) que seguramente a nivel agregado son mayores que los beneficios también agregados de esta práctica, sin embargo mientras no los pague el que puede evitarlos, difícilmente desaparecerán.

sábado, 26 de mayo de 2007

Nuevo esquema de certificación ITIL


Hola a todos, tras un parón en la escritura vuelvo a la carga. La verdad es que los principales motivos para no actualizar más esto, es que lo que cuento es fácilmente identificable por cualquiera que esté trabajando con nosotros, y la verdad es que no quiero que se mezclen opiniones personales, con decisiones que se toman en la compañía.

Dicho esto, contar que de nuevo, pese a ser un "fan" de ITIL, COBIT y demás, he vuelto a entrar en crisis. Creo que ya es un problema personal, les tengo manía a la gente de Delivery de los grandes fabricantes. (en realidad son tios majos, y saben mucho, pero tienen un punto que no).
Ya estoy cansado de sus informes, de su cuestionario sobre procesos ITIL, que con la respuesta que da la gente, ya da un estado de madurez, unas propuestas de mejora, y un comentario muy "molón".

Da miedo, la factoría de industrialización de ITIL está a pleno rendimiento, montones de jovenes salen con sus super excel que generan super informes, han salido a la calle a poner orden en el caos.

Tan receloso estoy, que hasta se me está pasando por la cabeza prohibir citar a ITIL para argumentar cualquier cosa. A veces parece el totem, la piedra filosofal que responde a todo.

Slogan fácil: ITIL si pero no así.

En tono de humor voy a poner una serie de requisitos indispensables, para poder hablar de gestión de servicios TIC:

  • Haber pisado alguna vez un CPD
  • Haber vivido una recuperación de BBDD de ese sistema tan crítico, que cuando de verdad pasa, la gente de negocio ya no grita, ni protesta, te mira en silencio, buscando la confianza en esa gente de TI, que habla raro, que no duerme, que están como locos.
  • Haber pasado una migración a producción, de esas que son necesarias para hacer cualquier cosa que la dirección ha dicho a los cuatro vientos que se va a poder hacer el día xx.
  • Haber discutido de verdad (no en laboratorio), el famoso PIR después de ese cambio de versión, con un responsable de negocio "de verdad".
Se me ocurren unas cuantas más, pero creo que es suficiente.

Los procesos están muy bien, pero si todos estuviesen en los maravillosos niveles optimizados, no haríamos falta las personas. El proceso, o sus deficiencias no son justificación para los resultados. Para eso estamos nosotros, para hacer que las cosas salgan adelante, si los procesos , si ITIL o sin San Pancracio nos ayudan pues mucho mejor.

sábado, 28 de abril de 2007

Buscando fuentes para procesos de negocio

Hola a todos, hasta ahora centraba tanto mi actividad profesional como mi actividad bloguera en el mundo TIC.

Ahora, que me tengo que poner con el tema de Organización y procesos, necesito encontrar fuentes menos TIC, y más generales. Si alguno tiene algunas referencias por ahí, estaría muy agradecido si me las pasa.

De todos modos, espero ir ampliando los horizontes tanto de mi blogroll, como de los post que vaya colgando por aquí.

lunes, 9 de abril de 2007

Empresa 2.0

En estos días en los que me estoy alejando un poco de lo que es la gestión y el gobierno TI, para tratar de hacer algo en lo referente a organización y procesos estoy leyendo todo lo que puedo acerca del uso de herramientas 2.0 en un entorno empresarial.

De hecho, en TI, hace ya casi medio año que hemos montando un blog y una Wiki, para que sirva el primero de canal de comunicación adicional y el segundo de repositorio de información.

Ahora, pensando ya en toda la organización se me plantean un montón de dudas acerca de como enfocar este tema.

Realmente, tanto el blog como la Wiki del departamento no han tenido prácticamente éxito, se publica muy poco. Y yo suelo ser uno de los autores más fecundos, por lo que no deja de ser "mi experimento", en lugar de una plataforma para la colaboración.

Razones por las que creo que sucede esto:


  • Interface único. La gente, por la experiencia que yo tengo, quiere una única interface para gestionar su trabajo. El Rey en mi empresa es Outlook. O fuerzas el cambio y obligas a que todo el mundo a utilizar la nueva plataforma, o va a ser muy difícil que trabajen con las dos.

  • Falta de incentivos para aportar contenido. Si seguimos gestionando a la gente con los esquemas tradicionales, y no encuentran incentivos para publicar o compartir su información difícilmente lo van a hacer. De hecho, ya se ha institucionalizado el decir que si alguien escribe cosas de interés en el blog o la wiki, es porque tiene mucho tiempo libre.

  • Resistencia al cambio. Si bien, a algunos nos encanta experimentar con nuevas herramientas, no debemos de olvidar que se debe a que se trata de "jugar" con algo que nos parece entretenido. No todo el mundo comparte esta visión, y realmente trabajar con un ordenador, les parece exactamente eso, "trabajar", y no perciben ningún tipo de satisfacción por probar herramientas nuevas.

  • Falta de compromiso de los gestores. Si nosotros como gestores, y nuestros jefes por un lado trasladamos el mensaje de utilidad de este tipo de herramientas, pero después a la hora de la verdad no las utilizamos (comunicaciones importantes, seguimiento de proyectos de gran calado ....) es prácticamente imposible que funcione.

  • Obsesión por la confidencialidad. En los tramos medios y superiores de la jerarquía, al menos en mi organización, existe una gran concienciación respecto a la confidencialidad. Entendiendo esta como el control de acceso a documentación (no me meto ya en el tema de datos de carácter personal, que ya es otra película). A mi modo de ver es más una obsesión que una amenaza real. Muchas veces se habla de poner a disposición de la gente, únicamente lo estrictamente necesario para que pueda realizar su trabajo, aunque es muy normal que queriendo eso para los demas, para nosotros querramos acceso a múltiples fuentes que nosotros discriminaremos con nuestro criterio. Entiendo que hay mucha documentación, más que confidencial, yo la llamaría sensible, que debe de ser tratada con cautela (temas de organización RRHH, salarios, precios ....), pero el resto, la verdad es que creo que no es necesario censurarla. Es más, si alguién realmente quiere algún documento para hacer algo inadecuado, seguramente lo consiga pese al control que tengamos establecido.

Estas son las principales razones que yo veo para que resulte difícil el difundir el uso de este tipo de plataformas, de todos modos yo creo que cada una de ellas puede ser atacada de manera eficaz. Yo al menos seguiré intentándolo.

jueves, 29 de marzo de 2007

dèjá vu


Me ha vuelto a suceder. Proveedor fabricante de los grandes, se acerca a nosotros.

Comenzamos a hablar, parece que nos entendemos, les contamos cual es nuestro enfoque de corresponsabilidad, y de indicadores globales de proceso para todo.

Va bien, parece que lo entiende.

Llega la propuesta, un tocho importante ITIL por aquí, líneas de servicio de preventivo y optimización, todo muy bonito pero ...... ¿dónde están mis métricas?, ¿dónde tengo mis indicadores cutres, sesgados que no miden todo pero que me sirven para medir por igual a todos mis proveedores y hacer que compartan el buen o mal servicio que prestamos al negocio?

Han desparecido, no están. Son "toscos", no miden realmente lo bueno o malo que puede llegar a ser el servicio, realmente, con unos que me traen recien salidos del horno, muy bonitos, que atomizan cada proceso y nos ponen control en cada fase.

Muy bien, muy bonito, pero no es eso lo que yo quiero:

  • No quiero un servicio con unos tiempos de respuesta de la leche
  • No quiere un servicio con un escalado interno impecable
  • No quiero un servicio que tenga mil métricas con valores casi perfectos
Lo que yo quiero, es un servicio que se comprometa con nosotros, y con el resto de proveedores en hacer la vida más fácil a mi cliente interno. Por eso fijamos esos indicadores tan "toscos", y por eso nos medimos todos por ellos (proveedores con su bonus, y empleados con nuestro sueldo variable).

Lógicamente para conseguirlo seguro que tenemos que trabajar en mejorar los tiempos de respuesta, escalados, monitorización, prevención, gestión proactiva de problemas, mejorar la gestión de cambios ..... pero todo esto son medios para un FIN. Dar buen servicio al cliente, eso y solo eso. De nada me vale tener un CPD en perfecto estado de revista, si mi cliente, si la unidad de negocio a la que doy servicio no está contenta, si no le ayudo y le apoyo para que consiga sus objetivos. Porque al final, nuestro objetivo es conseguir clientes e ingresos, y no lo es el tener un CPD y unos sistemas dignos de aparecer en un documental.

Buff ya me he deshaogado, pero me da rabia el contar las cosas tomar mi tiempo en explicar mi visión, para que la entiendan y si dedicen trabajar con nosotros que sepan cuales son las normas del juego, para que después de todo, me lleguen con una propuesta "del manual de delivery".

Los servicios de TI, por mucho que nos cuenten y nos digan, por mucha arquitectura de servicios, virtualización, remotización, gestión dinámica de cargas ..... lo que sea aún no es un commodity. Puede que le falte poco para serlo, pero aún no lo es.

Foto realizad por Dailysnap.

miércoles, 28 de marzo de 2007

Más notas sobre PRINCE2


Después del comentario que he recibido, en el anterior post en el que hablo sobre los proyectos, me animo a escribir un poco más sobre esta metodología que por lo que he visto, aún no tiene demasiado tirón en España.

PRINCE2 Projects in Controlled Enviroment.
Se trata de una metodología de gestión de proyectos, que en mi opinión es muy consistente.

¿Cómo funciona?

Básicamente todo se inicia si desde la dirección ya sea Ad Hoc, o a través del desarrollo de un programa, un ejecutivo tiene una necesidad y busca el montar un proyecto para darle respuesta.

Lo primero que tiene que hacer es buscar un Jefe de Proyecto, que será el que se responsabilice de llevar a buen puerto el mismo. Con esto nace el proyecto, con lo que se denomina "mandato de proyecto". A partir de ahí entramos en el primer proceso de PRINCE2, Starting Up a Project (SU).

  • En SU, hay una serie de subprocesos con los que tenemos que poner en marcha el proyecto. Básicamente se trata de cerrar el equipo de proyecto (resto de miembros de la junta de proyecto), y de trabajar el Business Case y el Project Brief. EL Business Case, es el corazón de la metodología, en este documento debemos reflejar la justificación del proyecto en términos de negocio, los enfoques que manejamos, riesgos, y una estimación previa de costes y beneficios. A lo largo de la vida del proyecto, este documento estará vivo, y se irá actualizando. De hecho, será lo que nos permita en cualquier momento de la vida del proyecto ser justificado por parte del Ejecutivo que ha generado el mismo con su "mandato de proyecto". De SU, se sale invocando al proceso de Dirección del Proyecto (DP), enviando toda la información Business Case, Project Brief con lo que tiene información sobre la justificación, costes estimados (a muy alto nivel), enfoque del proyecto (in house, externalizado, compra, alquiler lo que sea). Con esto, la dirección de proyecto puede o cancelar, o autorizar el inicio del proyecto. De ser así, pasamos al siguiente proceso Initiating a Project (IP).
Me está quedando un post, muy largo, por hoy lo dejo pero en los próximos días continuaré hasta hacer una explicación breve de cada proceso.


martes, 27 de marzo de 2007

Teoría vs Práctica

Ayer mientras leía este post, me daba cuenta de que realmente estaba contando algo muy cercano a lo que se puede vivir en un departamento de TI. Tras pensar esto, reflexioné acerca de si realmente el resto de inquietudes y enfoques que planteamos aquí, son capaces de dar respuesta a este tipo de reflexiones.

Puede ITIL, o COBIT o PRINCE2 o lo que sea dar respuesta a situaciones como esta. Pues la verdad es que por si solos no. Este tipo de problemática hay que atacarla con la capacidad que tenga cada uno para llevar este tipo de situaciones, de todos modos, y esto ya si es mi experiencia personal. Tener unos procesos finos, unas métricas definidas, una gestión de proyectos ponga el acento en la justificación de negocio, pensar en servicios en términos de soporte a procesos de negocio, no soluciona, pero si que nos da muchas armas (tanto ofensivas como defensivas), que pueden ser realmente útiles cuando se presentan estas "batallas internas".

lunes, 19 de marzo de 2007

buscando herramientas

Como ya he comentado en anteriores post, parece que este año nos ha tocado llevar temas de Organización y Procesos desde TI, el tema es apasionante, y si bien tengo bastante claro como enfocarlo.

En lo que si que estoy buscando (y agradezco cualquier sugerencia), es qué herramienta utilizar para toda la gestión de contenidos referente a estos temas.

El otro día leía este post, y ya comencé a echar un ojo a esas herramientas.

Os comento lo que estoy buscando, algo flexible, sencillo de usar, con buenas funcionalidades de búsqueda y de control de versiones. Me gusta mucho Mediawiki, pero lo que no me gusta tanto es que no puedes llevar una gestión de usuarios que permita bloquear la edición para un usuario, un grupo ....

sábado, 17 de marzo de 2007

Gestión de Configuración

Hola a todos, estamos ya a las puertas de acabar el primer trimestre de 2007, y ya tenemos muy avanzada la parametrización de nuestra CMDB.

La verdad es que da una satisfacción el ver como una vez con el esqueleto ya listo, a través de bastantes reuniones se va poblando cada vez más con múltiples CI's y sus relaciones.

Por ahora, lo tenemos montado en Remedy sin integración con los formularios de gestión de cambios, incidencias y problemas. Estamos un poco en fase Beta, alimentando la BBDD con el inventario de servicios, y con estos hacia abajo identificando y relacionando todos los CI's necesarios para dar soporte al servicio, así como sus relaciones.

En cuanto a la interacción del proceso de Gestión de Configuración con el resto de procesos, también estamos en pruebas. Seleccionamos algunos cambios, para desde el análisis identificar los CI's que se van a modificar, para finalmente cuando se lanza el cambio a producción, proceder a actualizar los cambios en la CMDB identificando los CI's modificados, su versión, el cambio con el que están relacionados.

Las búsquedas para identificar servicios afectados cuando se cae un CI olvidado, ya las hemos usado y la verdad es que con unos resultados muy buenos. Ahora nos toca trabajar en montar indicadores sobre el proceso, y buscar consultas para ayudar a la operativa en otros procesos. He encontrado una buena fuente, para apoyarme en esto en Evergreen.

viernes, 16 de marzo de 2007

Si TI construyese aviones

En muchas entradas de este blog, cuando se comentan temas relativos a ITIL, PRINCE2, COBIT... realmente de lo que hablamos es de cómo con estos frameworks, podemos dar a TI esa capa de gestión operativa, y control, necesaria para que nos parezcámos más a otras "disciplinas" más maduras.

Tras ver esta aproximación, a lo que de verdad hacemos en TI, a parte de reirme un poco, me doy cuenta que por muchas capas que pongamos, nuestro trabajo siempre va a estar un poco en el filo de la navaja.



Nota: Tiene gracia que el anuncio sea de EDS, no me imagino yo una versión hispana con Indra, Everis, Accenture o alguna más haciendo una anuncio de este tipo

miércoles, 14 de marzo de 2007

cerrado por derribo

La verdad es que tengo esto bastante abandonado. Hace mucho que no escribo, y la verdad es que tampoco tengo demasiadas ganas de hacerlo.

El motivo principal es que los cambios organizativos que comentaba en un post anterior, han provocado que me pueda centrar mucho menos en estos temas de lo que hacía unos meses atrás.

Se nos avecina un proyecto muy grande, que va a tener mucho impacto en nuestros sistemas, y además como departamento de TI asumimos la responsabilidad de Organización para toda la compañía.

Todo esto va a hacer que probablemente durante 2007 quite el foco a la organización en TI, para ponerlo en la Organización de los procesos de la compañía y como ligarlos consistentemente con los servicios de TI.

Al menos ya tenemos una CMDB casi totalmente parametrizada, por lo cual presiento que será un buen año para hacer experimentos asociando servicios de TI con procesos de negocio.

Como esto coincide con el superproyecto, y vamos a tener aquí un par de consultoras de las grandes grandes, tendré la oportunidad de ver como está esta gente con estos temas, y como enfoca estos proyectos.

Yo de todos modos seguiré manteniendo mi postura de comunicación, transparencia, información a todo el mundo, y construir los procesos colaborativamente con la gente que trabaja en ellos.

viernes, 2 de febrero de 2007

Nota sobre las fotos

En este blog, de post en post, suelo acompañar el mismo de alguna foto. Como muchos habréis ya supuesto las fotos no son mías, las busco en Internet y solo las posteo si el contenido está bajo licencia Creative Commons. Sin embargo, pese a no modificar el trabajo inicial, y no tener este blog fines comerciales, he fallado en el reconocimiento.

Debería de haber identificado a los autores de cada foto, y sin embargo no lo he hecho. Ahora es complicado ya que en el enlace a Flickr no nos lleva al autor. Intentare ver si es posible obtener a los autores de una manera sencilla, y corrijo este error.

Aprovecho, y acompaño este post con una foto, de la que, en este caso si soy yo el autor. Se trata de una playa en un pequeño pueblo, el primero si no me equivoco de la "Costa da Morte", un lugar tranquilo y altamente recomendable si lo que quieres es pasear y alejarte del mundanal ruido por unos momentos.

jueves, 1 de febrero de 2007

¿y los proyectos?


Desde que comencé a examinar lo que es ITIL, me di cuenta que uno de los puntos flojos que tenía era todo lo referente a desarrollo de nuevas funcionalidades/sistemas.

Todos los procesos de ITIL, están orientados a mantener la maquinaria funcionando con los niveles de servicio establecidos. Después, tienes algún proceso como gestión de cambios, que podría hacer de puente con la parte de desarrollo, pero que se queda corto para gestionar un flujo de modificaciones en los servicios que se pueda derivar de la actividad normal del negocio.

Para la parte de desarrollo, tenemos CMMi, pero el hecho de que nosotros no desarrollemos sino que gestionamos a equipos de desarrollo de proveedores externos, hace que muy probablemente nos quede un poco grande.

Con este panorama, al final nos fuimos a por algo para gestionar proyectos. Y el ese "algo", finalmente fue PRINCE2.

Los motivos de elegir PRINCE2 y no otra metodología como PMBOk o similar, fueron básicamente la cercanía en nacimiento de PRINCE2 con ITIL, ya que ambas fueron alumbradas en el seno de la oficina de comercio británica (OCG).
Junto con esto, la otra razón era que podríamos repetir la buena experiencia que tuvimos con el proveedor que nos formó en ITIL, ya que en su cartera de cursos también tenían PRINCE2, que por lo que he visto todavía no es muy popular en España.

Una vez realizada la formación a todo el grupo, la verdad es que el sabor de boca que nos ha dejado es bueno.
Estamos en lo de siempre, se trata de una herramienta, y por tanto, ella por si misma no va a solucionar todos esos problemas que nos encontramos durante la ejecución de los proyectos. Pero en lo que si creo que nos va a ayudar es en el de establecer unas reglas de juego, unos criterios transparentes sobre los cuales vamos a evaluar el progreso del proyecto.

En PRINCE2, todo el modelo gira entorno al business case, que define como aquel documento en el que él que solicita el proyecto (normalmente alguien de negocio), justifica la necesidad del mismo. Este documento se debe de mantener vivo a lo largo de todo el proyecto, y es la herramienta básica para la dirección del mismo.

Lo que me ha gustado es que pone especial incapié en el arranque/inicio de proyecto, y después plantea un modelo de dirección por excepción.

Otra cosa que me ha encantado, pero eso ya es debilidad personal que tengo hacia la gente que piensa estas cosas, es su robustez. Es increíble lo coherente que resulta ese conjunto de subprocesos enlazados unos con otros, y que dan salida a todos los "y si ....?, y si ....?" que planteamos durante las jornadas de formación.

Eso si, es enorme por lo que para evitar el convertirse en esclavos de la burocracia será preciso hacer una adaptación, (eliminar documentación y algún subproceso), y emplearlo solo en proyectos de entidad suficiente.

Ya lo hemos puesto en marcha, el primer proyecto que vamos a realizar siguiendo PRINCE2, ya ha sido lanzado. Así que ya iré contando si va bien, o si como se suele decir "del dicho al hecho hay mucho trecho".

martes, 30 de enero de 2007

parte de Enero

Pues eso, que ya estamos de lleno en el 2007.

Ha sido un mes complicado, ya que este año estrenábamos con los proveedores la liquidación de variables con cargo a consecución de SLA's. Al final, el resultado general si no excelente, si que se puede calificar de bueno.

Hemos además terminado de ajustar la batería de indicadores con los que vamos a evaluar en 2007.

A todo esto se ha unido el revuelo provocado por un cambio organizativo, mi jefe se va, y ha habido un movimiento bastante grande, tanto en número de personas afectadas como en impacto. Ahora toca esperar como se asienta esto, la verdad es que a mi me ha dejado un poco desconcertado, pero bueno tengo confianza en la dirección, y espero que hayan tomado una decisión acertada.

Todo este conjunto de temas me ha tenido bastante entretenido, y la verdad es que no he podido escribir todo lo que desearía.

retomando la escritura

La verdad es que cuando comencé a escribir este blog, me preguntaba si tendría cuerda para mucho rato o no. Inicialmente me parecía que tenía muchas cosas que contar, después conforme vas contando algunas ves que cada vez quedan menos.

Sin embargo, lo bueno que tiene esto de los blogs, es que encuentras a gente fantástica que con lo cuentan y dicen te dan gasolina infinita para seguir opinando.

Así que tras un parón que coincide con la cuesta de Enero, espero mantener un discreto ritmo de publicación.

sábado, 6 de enero de 2007

Propósito para 2007. Fin del Overtime


Overtime, anglicismo que por lo menos en mi experiencia, es algo común, yo diría muy común en el mundo de TI.

Por mi observación personal, creo que por lo general, al menos en mi organización el echar horas de más en la oficina, es algo para lo que la gente de TI podría optar a pelear por el título de mayor tiempo de permanencia en la oficina.

Supongo que es algo que también viene heredado del pasado en consultoría de la mayor parte de nosotros. De hecho, analizando conversaciones, actuaciones, omisiones ... uno se da cuenta de que el tiempo extra es algo bien visto, cuando tal vez debería de ser un gran pecado.

Comentarios como los de, "fulano vive como un rey todos los día se va a la hora", o preguntar por alguién a las 20:30, y decir sorprendido, "pero ¿ya se ha ido?", son cosas que se escuchan todos los días, y que contribuyen a crear y mantener esa ley no escrita, de que profesionalidad y compromiso se demuestran saliendo tarde.

Mi opinión respecto al overtime, pues supongo que será la de la mayoría de vosotros. Es improductivo, hace que no valores tú tiempo de oficina ni el de los demás, ya que la presencia de la gente hasta altas horas, es algo que se da por supuesto.

Favorece un entorno de interrupciones, de trabajo poco intenso ... y sobre todo de queme en la gente que quiere tener vida fuera del trabajo.

En las razones de que exista, yo estoy muy de acuerdo con los autores de Peopleware, sirve para quitarnos sentimiento de culpa. No he cumplido, pero me quedo todos los días hasta las 11.

Dicho todo esto, yo en 2007 he decidido dar un paso más para acabar o por lo menos mitigar este fenómeno en mi organización.

Me he puesto como norma salir todos los días a mi hora. Si algún día salgo más tarde, tendré que anotarlo en una excel en la que indicar el motivo concreto por el que me quedo. (y no valen genéricos como revisar correo, adelantar un informe ...)

Esa norma la aplico a mi equipo, todos tienen la orden de salir a la hora. El que no lo haga, me tiene que justificar por qué se ha quedado más tiempo. (en los mismos términos en los que lo hago yo conmigo mismo).

¿que espero conseguir con esto?, pues que se contagie y que el resto de la gente me copie.

Creo que este tipo de inciciativas tenemos que moverlas desde la gente que tenemos algún nivel de responsabilidad, para que por lo menos arranque con un poco de suerte.

Es posible que en un primer momento cause algún tipo de tensión con compañeros o con mi jefe, (espero que no). Pero creo que la transparencia es siempre lo mejor, y el hecho de que yo haya hecho público mis nuevas normas de comportamiento espero que ayude.

Al final como todo en la vida, no hay soluciones mágicas, yo creo que en ocasiones en 2007 me quedaré más tiempo de lo debido, pero al menos seré consciente de ello, y de que se trata de algo excepcional.

Bueno, ya os iré comentando como va mi propósito. Otra cosa, animo a todo el que lea esto a que haga algo parecido. A ver si conseguimos salir de la lista de país europeo menos productivo, y que más horas "trabaja" o más bien, que más horas está en la oficina.