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.

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.

Según comenta el blog Genbeta, Twitter prevé la comercialización de cuentas Premium a final de año.

Como es lógico Twitter tenía que dejar de vivir del aire (una vez que no se ha dejado comprar por los gigantes del sector) y necesitaba un modelo a partir del cual obtener ingresos de forma constante. Según comenta Genbeta, los servicios Premium se centrarían en tres servicios: estadísticas avanzadas, seguimiento de la marca y un API comercial. Según el cofundador de Twitter, Biz Stone, estos servicios ya venían siendo demandados por las empresas.

¿Tendrá éxito? Es complicado decirlo. La base para que pueda interesar a las empresas o personas que utilizan Twitter con una finalidad de comercial o de promoción la tiene, que es la atención de millones de usuarios, no obstante, dependerá bastante del precio final y de las características exactas de los servicios. No obstante, de ser cierto lo que comenta Biz Stone y no hay por qué dudarlo, partirían de unas necesidades ya existentes y demandadas, por lo que la base, desde luego, es buena.

En cualquier caso, para los usuarios “normales” de Twitter, estas medidas no supondrán ningún cambio, ya que el servicio seguirá siendo gratuito y sin variaciones (de igual forma sucederá con la API pública). No obstante Twitter deberá aclarar qué posible impacto podría tener (si es que hay alguno) de los nuevos servicios sobre las cuentas de carácter privado.

Si el modelo funciona, estoy seguro que Twitter seguirá incrementando la gama de servicios premium, tal vez orientándola más a la autenticación, integridad y no repudio de las comunicaciones y al comercio electrónico.

Otra máxima importante que he podido comprobar en los últimos años es lo importante que resulta para las empresas de servicios TIC contar con buenos socios, de hecho conozco muchas que sobreviven (y me consta que muy bien) gracias a tener uno o dos buenos socios (generalmente socios tipo “primo de Zumosol”), que les proporcionan carga de trabajo prácticamente de manera continua, es decir, forman parte casi, del tejido de producción del socio fuerte. Es evidente, que este tipo de alianzas tiene sus riesgos, porque si mañana el primo de Zumosol decide repartir carga de trabajo entre más socios, sufre una reducción de su volumen de negocio o bien decide prescindir de los servicios del socio débil, o se tiene una manera alternativa de conseguir negocio o los problemas de subsistencia de la empresa pueden ser muy grandes. En cualquier caso, entiendo que muchas empresas se encuentren cómodas por este tipo de sociedad.

En el mundo de las TICs soy de los que piensan que la unión hace la fuerza, tener buenos socios, partners, etc… pueden proporcionar en el mercado una buena posición estratégica. Las relaciones entre los socios pueden ser de lo más variopintas y con un mayor nivel de fidelización o no, es decir, puede haber acuerdos para que una empresa pueda asumir carga de trabajo excedente de otra (cómo lo que vimos en el párrafo anterior), participar de forma conjunta una serie de servicios concretos, cooperar tecnológicamente, participar en proyectos donde los servicios que se presten sean muy diversos y puedan ser asumidos por los socios, cada uno de los cuales domina un aspecto concreto del servicio (un ejemplo de este tipo de proyectos, son las denominadas secretarías técnicas de eventos, en donde una parte importante es la organización, gestión y promoción del evento y otra parte, tal vez más pequeña, pero no por ello despreciable, puede dar lugar al desarrollo de determinadas soluciones informáticas, como por ejemplo un sitio web del evento, etc…), una combinación de parte o de todas las casuísticas que acabo de comentar, además de existir otras muchas formas posibles de cooperación entre empresas.

Andar solo en un mundo tan competitivo como el de los servicios TICs, es posible, no digo que no, pero evidentemente es mucho más complicado que sin tener socios y/o aliados.

El hoax es otro de los orígenes que tiene nuestro correo electrónico no deseado. En ocasiones está íntimamente relacionado con el spam, ya que puede tener como objetivo captar direcciones de correo electrónico o hacer propaganda contra algún producto o concepto (lo cual es otra forma de hacer una comunicación comercial no deseada), no obstante y por regla general a diferencia del spam el objetivo directo que suelen tener los hoaxes no es el beneficio económico.

Un hoax es un bulo, una mentira, una exageración, una media verdad, que se propaga a través del correo electrónico generalmente en modo de cadenas de correo, donde algunos usuarios que los reciben son los que los van propagando a otros. ¿Quién no ha recibido en infinidad de ocasiones un correo en cadena de alguien que conoce o que medio conoce y lo ha reenviado a su vez a más personas? Más que nada porque siempre piensa uno, ¿y si es verdad?, al fin y al cabo reenviar un correo electrónico no cuesta nada.

El problema es que como sucede con el spam el impacto económico que supone el hoax también es muy importante y por ese motivo es necesario que esta práctica se reduzca o elimine dado el daño que hace a Internet y a las organizaciones (empresas, instituciones, administraciones, etc…). También como sucede con el caso del spam, su erradicación es muy complicada y solo mediante la adquisición de cultura y conciencia de lo que es la red en sí se podrá reducir progresivamente su proporción. Mientras tanto, leyendas urbanas, cadenas de la suerte, etc… seguirán haciendo acto de presencia en nuestras bandejas de entrada.