archivo

Archivos Mensuales: agosto 2009

Un error en el que se suele caer muchas veces es la prepotencia de un proveedor de servicios de desarrollo de software o de consultoría respecto a un cliente.

Los clientes quieren que se le resuelvan problemas, eso es cierto, pero no desean que se les ponga siempre en tela de juicio su trabajo ni que venga un iluminado a decirles lo que tienen que hacer o a fiscalizar sus tareas. Si el proveedor opta por la estrategia de yo sé más que tú y además tú eres un inútil (no hace falta decirlo con palabras), por regla general los resultados no serán buenos.

Como decía antes, es cierto que si se contrata a un proveedor es para resolver un problema, pero la solución siempre debe ser consensuada y esto solo es posible escuchando al cliente e informándole siempre de todo (además de explicarle el por qué se recomiendan las diferentes alternativas de solución frente a otras). Si el cliente decide delegar el resultado de todo el trabajo al proveedor, que sea porque el cliente lo ha decidido y no porque el proveedor quiera implantar una solución por encima de todo.

Anuncios

De un tiempo a esta parte en mi departamento, se ha tomado la decisión de comenzar a procedimientar determinados procesos que tenían lugar dentro del mismo, algo que por otra parte era necesario ya que muchas tareas llegaban a los técnicos que las tenían que ejecutar por múltiples medios (correos electrónicos, Service Desk, teléfono, oralmente, etc…), lo que por un lado impide medir la carga real de trabajo, por otro impide priorizar tareas de manera adecuada y por último daba lugar a que se perdiesen determinadas peticiones e incidencias.

De esta manera se han dado los pasos adecuados para centralizar todas las peticiones e incidencias a través del Service Desk, tanto las que procedan de usuarios por diversos motivos (microinformática, aplicaciones, etc…), las de consumo interno dentro del Departamento de Informática, así como las que procedan de proveedores de servicios TIC que tengan contratadas determinadas tareas, como por ejemplo desarrollo de software (el proveedor, con la autorización pertinente de la Dirección del Proyecto, puede también reportar incidencias (por ejemplo, se ha caído tal servidor de aplicaciones) o realizar peticiones (por ejemplo, solicitar la asociación de un determinado usuario a un proyecto en SVN).

Una vez que se ha tomado la decisión de centralizar peticiones e incidencias en el Service Desk, toca delimitar su competencia con otras herramientas que utilizamos dentro del departamento, como por ejemplo Redmine (esto es más sencillo, ya que aunque Redmine gestiona peticiones, son aquellas relacionadas con la actividad interna de un proyecto concreto) y Mantis, que gestionaba peticiones e incidencias para procesos concretos del departamento de desarrollo (generalmente peticiones relacionadas con la solicitud de recursos sobre alguna de las herramientas que componen nuestra infraestructura de desarrollo e incidencias producidas en el proceso de paso a producción de las aplicaciones). En este nuevo marco, Mantis quedará como bugtracker dentro del proceso de desarrollo de software, de uso interno en cada proyecto.

La relación cliente/proveedor en los procesos de desarrollo de software presenta como situación ideal, el equilibrio.

Este equilibrio se basa:

1) En que si el cliente desea en cualquier momento cambiar de proveedor, lo pueda hacer sin poner en riesgo su negocio o lo que es lo mismo, que el tiempo en que tarde el nuevo proveedor en conocer el negocio, el software desarrollado y su tecnología sea inferior a un umbral que se establezca como tiempo límite razonable.

2) En que el proveedor si lo desea, una vez finalizada sus obligaciones contractuales, pueda desligarse del cliente por la circunstacia que sea: no le resulta rentable, no es una línea de negocio que quiera seguir potenciando, etc…

Esa situación de equilibrio, casi nunca existe y de ella tratan de sacar tajada proveedores y clientes:

1) Si un proveedor sabe que el cliente no va a poder encontrar un sustituto que le garantice el éxito o la continuidad del servicio, puede hacerse fuerte exigiendo unas contraprestaciones económicas más elevadas y/o reduciendo la calidad del servicio..

2) Si un cliente sabe que un proveedor tiene una fuerte dependencia económica de él, intentará conseguir condiciones más favorables: mejores precios, acuerdos de nivel de servicio más exigentes, etc…

Hay muchas personas, entre las que me encuentro, que las interrupciones controladas (la lectura de correos electrónicos recibidos, por ejemplo), ayudan en determinadas circunstancias a mantener la concentración (también es cierto que en mi caso, hay ciertas tareas que para poder ejecutarlas bien, necesito desconectarme de todo y dedicarme exclusivamente a esa tarea).

Sin embargo, las interrupciones constantes, sobre temas diversos, en muchos casos que no tienen absolutamente nada que ver con lo que estás haciendo en ese momento, son las pueden terminar por arruinar una mañana de trabajo, ya que al tiempo de la interrupción, hay que añadir el tiempo necesario para volver a retomar lo que estás haciendo, ya que volver a enfocar la atención en un tema no es inmediato.

El problema de las interrupciones está en que todos nosotros pensamos que lo nuestro es lo más urgente y no puede esperar y claro cuando surge una consulta con alguien, si tenemos la posibilidad le hacemos una visita a su mesa o le hacemos una llamada telefónica.

Existen diversas formas de reducir las interrupciones que van desde hacerte totalmente inaccesible (es decir, se establecen pocas vías de contacto, la mayoría asíncronas) a planificar las interrupciones (solo recibo llamadas en tal rango de horas, solo recibo visitas tal día y a tales horas, tales tipo de consultas o peticiones las recibo por este medio, estas otras por este otro, etc…). Ambos casos tienen un problema y es la falta de flexibilidad, ya que sí que hay ocasiones, donde las consultas son algo urgente y no pueden estar sometidas a ese corsé.

En resumidas cuentas, las interrupciones pueden suponer un problema y su solución no es nada sencilla: hay que evitar la barra libre de interrupciones y tampoco meterse en un búnker. Lo importante es el equilibrio, y para conseguirlo se necesita disciplina personal y que la organización o departamento en el que trabajas ponga una serie de normas. En mi caso me tengo que aplicar el cuento de la disciplina personal (a lo que tengo que sumar aprender a decir más veces no) y que en mi departamento se hagan efectivas una serie de políticas.

Hace unos días recibí un par de correos electrónicos de usuarios que por diversas razones abandonaban su puesto de trabajo e iban a iniciar nuevas trayectorias profesionales.

Se trataba de usuarios que llevaban trabajando conmigo seis años, desde que entré a trabajar en mi organización, por lo que la relación con ellos ha sido intensa y han vivido conmigo la evolución del sistema de información que utilizaban.

Agradezco enormemente las palabras de cariño que me han trasladado, las cuales me dan unas fuerzas enormes para seguir una vez que vuelva de mis vacaciones. Como he dicho muchas veces hay usuarios y usuarios, en este caso son usuarios con un conocimiento e implicación muy importante en el uso del sistema de información, por eso le doy un gran valor a su opinión y a su valoración de la trayectoria profesional conjunta que hemos tenido.

Como es lógico, nunca llueve a gusto de todos y evidentemente no todos los usuarios piensan igual que estos (y esto no es algo que me imagine, lo sé), pero para mi ha sido muy importante su opinión sobre el trabajo realizado en estos últimos años, ya que todo el trabajo que realizo (y no es algo que me suceda exclusivamente a mi, sino a todos los departamentos TIC) está orientado exclusivamente al usuario. No hay que olvidar que los sistemas de información que se desarrollan y mantienen lo utilizan usuarios (está muy bien innovar, pero siempre si eso favorece al usuario). El usuario es nuestro cliente, sin ellos no existirían los departamentos TIC en las organizaciones.

Es cierto que mi experiencia en el mundo laboral es relativamente corta y que el desarrollo de software es todo un universo por descubrir, pero todavía no he descubierto el secreto del framework de la corbata, esa alquimia que utilizan muchas empresas para producir software y que debe proceder de incunables que van de mano en mano y que contienen los secretos que hacen que se programe mejor haciendo que los empleados piquen código con chaqueta y corbata.

Fuera de ironías, ni entiendo, ni conseguiré entender por qué determinadas empresas hacen ir a los programadores (incluso siendo becarios o similares) a ir en traje y corbata a programar (quítese programar, por otros servicios TIC similares), incluso cuando no están en cliente y trabajan en las dependencias de su organización. Puedo incluso llegar a entenderlo si tienen que trabajar en cliente (aunque no compartirlo), sobre todo si en el cliente todo el mundo va en traje y corbata, también puedo entender incluso que los analistas, cuando vayan al cliente vayan también trajeados y también lo puedo entender en jefes de proyecto, gerentes, etc… ya que ellos pisan mucho cliente, pero por favor, que les hagan programar en la sede de la empresa vestidos así, no lo entiendo.

En mi opinión cuanto más cómodo esté la persona que realiza tareas de programación (y análisis) mejor va a realizar su trabajo y por mucho que se esté acostumbrado al traje y la corbata no es lo mismo que una camisa o una camiseta con unos vaqueros (además del ahorro de tiempo que supone cada mañana al levantarse). Soy consciente de que muchas empresas intentan trasladar de esta manera una imagen y que ese es el motivo, y eso puedo respetarlo, pero bien podrían intentar ser más flexibles en según que casos y no mostrar una inflexibilidad fuera de toda lógica.

Tengo una espinita clavada y es que me gustaría saber qué se siente cuando se gana un proyecto. Prácticamente toda mi vida laboral la llevo en mi organización y dado el camino laboral que he elegido, me da la impresión de que nunca estaré en la tesitura de presentar una oferta y ganar un concurso.

En cierto modo siempre he tenido un espíritu comercial (con esto no quiero decir ni que sea ni buen ni mal comercial, ya que aunque parte de mi trabajo sea llegar a acuerdos, consensos y negociar, no es a lo que me dedico ni a lo que me vaya a dedicar, en cualquier caso estoy muy lejos del nivel de algunos de los comerciales con los que me ha tocado tratar) y gran culpa de ello lo tienen los seis meses que estuve de becario en una importante empresa de desarrollo de software.

En dicha empresa, tuve como jefe de proyectos a alguien de quien tuve la oportunidad de aprender mucho, en cierto modo fueron él y mi primer jefe en mi actual organización los que más han influido a lo largo de mi trayectoria profesional, es curioso porque entre los dos sumé como año y medio aproximadamente y desde entonces hasta ahora (cinco años después) pese a que he seguido aprendiendo de mucha gente (y espero seguir haciéndolo), han sido ellos dos realmente los que me han marcado.

En este post me voy a centrar en mi primer jefe de proyectos, del otro jefe tal vez hable en otro post más adelante, como también lo haré de otra vertiente muy importante de mi primer jefe de proyectos que era un auténtico firewall entre el cliente y el equipo de proyecto, defendiendo al equipo siempre con uñas y dientes (otro aspecto muy valorable).

Independientemente de que siempre me trató muy bien y me hizo sentir importante pese a ser el último mono del equipo de proyecto (y no solo por llegar el último y tener nula experiencia, sino por el nivel tan importante que existía en ese equipo de trabajo, no hay más que ver la evolución que han tenido las carreras de los que fueron mis compañeros para ver que son personas de una gran valía), hubo una cosa que me llamó la atención mucho y es que siempre nos orientaba mucho al negocio y cada vez que había que hacer una oferta, hablaba con los analistas, compartían opiniones, les asignaba tareas relacionadas con la misma y en algún caso (en desayunos o en reuniones) también escuchaba la voz de los demás, incluida la mía. Es decir, a un equipo muy técnico les fue metiendo en la cabeza poco a poco que el negocio de las empresas de desarrollo de software ni empieza ni termina en la programación, sino que hay mucho más y que los proyectos deben salir rentables para la empresa y que para que haya trabajo hay que seguir ganando proyectos. Por tanto complementó la valía profesional y técnica del equipo de proyecto con una visión orientada al negocio, algo que como he repetido muchas veces en mi blog no hay que olvidar.

Basado en la experiencia personal que he tenido, recomiendo a los jefes de proyecto que den la posibilidad de participar en la redacción de la oferta a analistas y por qué no, consultar a otros perfiles de la organización si fuera necesario. Evidentemente al principio saldrán peor, pero cuando realmente vayan adquiriendo destreza, empezarán a entender qué estrategias se deben seguir para intentar ganar un contrato y qué consecuencias trae después en la ejecución del proyecto, es decir, empezarán a entender un poco más de qué va el negocio y de lo importante que resulta para la empresa vender proyectos (lo mejor posible, si pudiera ser) y ejecutarlos en tiempo y forma.