archivo

Archivos Mensuales: agosto 2010

Existen proyectos unipersonales pero lo más normal es que en un proyecto de desarrollo de software participen varias personas y para que salga bien es necesario que el equipo funcione bien, no solo basta con tener buenos técnicos en el mismo.

Es importante que el equipo esté cohesionado, motivado, equilibrado y buscando un mismo fin. Si cada uno hace la guerra por su cuenta el resultado del proyecto se verá afectado.

No es fácil formar buenos equipos, ya que hay desarrolladores que funcionan mejor en un tipo de proyectos que otros, hay personalidades que no son compatibles, técnicos que funcionan muy bien trabajando juntos, recursos que pueden ser adecuados para el mismo están en estos momentos asignados a otros, existirán casos donde técnicos tengan que compartir el tiempo entre varios proyectos por lo que el funcionamiento del equipo se podría ver afectado por la marcha de otros proyectos que pueden hacer que no se dedique el tiempo suficiente y/o que distraigan ya sea porque son más interesantes o porque dan más problemas, etc…

Lo comentado en el párrafo anterior hace que en ocasiones el equipo no se seleccione sino que se forme con los recursos que van quedando libres de otros proyectos, en estos casos para que funcione el equipo hay que apelar a la profesionalidad de sus miembros y al trabajo del jefe de equipo que tendrá que intentar sacar el máximo partido de los recursos con los que va a trabajar, como lo haría cualquier entrenador en cualquier deporte de equipo.

Cuando se tenga la posibilidad de seleccionar equipos hay que hacerlo y no dejar que la composición de los mismos se realice sin criterios, ya que se estaría dejando pasar la oportunidad de intervenir para que los equipos sean los mejores posibles. Por supuesto que puede haber errores, como lo tendría también cualquier entrenador cuando hace una alineación, nadie es infalible y de un error en una selección de personas para el equipo seguro que vendrá y multiplicados aciertos en futuras elecciones.

Para poder formar buenos equipos es necesario conocer a todo el personal de la mejor forma posible, en función del tamaño de la empresa esto puede ser más fácil o difícil, pero en cualquier caso no existirán islas desiertas y siempre habrá alguien que conoce a algún recurso que no conocer y que te podrá dar las referencias que se necesitan. Siempre que se pueda, las personas con responsabilidad en la dirección de equipos deben intentar conocer el mayor número de técnicos que le sean posible y no solo en sus virtudes como desarrolladores, sino también en cómo se desenvuelven trabajando en equipo y cómo es su personalidad.

El deporte en equipo no se termina en el equipo de proyecto, sino que es extrapolable al funcionamiento de todo el área de producción (cooperación necesaria entre diferentes equipos) y en general a toda la organización, ya que para que funcionen de manera adecuada necesitarán apoyo y servicio de diferentes áreas de la organización.

En el artículo de ayer comenté, utilizando como ejemplo mi blog, que si determinados sitios web relevantes en lo que a atención se refiere te tienen en cuenta la visibilidad se incrementará y como consecuencia los resultados.

Como esos generadores de atención son externos no se pueden controlar y por tanto corre a criterio de los que los dirigen darte visibilidad o no. Tal vez te den la oportunidad de alquilar esa visibilidad, que se terminará cuando dejes de pagar (será cuestión de hacer números y ver lo que se ingresaba antes y después de esa inversión).

Otra posibilidad es crearte tu propio generador de atención. Supongamos que hemos desarrollado un software de base de datos de calidad, una posibilidad de atraer atención sobre el producto es crear un sitio web que trate de programación o más concretamente de bases de datos (no necesariamente particularizando en nuestro producto) y a través de la información y servicios que se presten generar atención y utilizarla para promocionar el software a través de ese servicio. Lo que propongo es un sitio web más generalista que un sitio web propio del producto, entiendo que de esta forma será más fácil lograr atención ya que mucha gente buscará un servicio o un producto generalista más que el nombre concreto de tu producto, el cual puede que ni conozcan. El grado de generalización dependerá mucho del producto o servicio que se quiera vender, tal vez una solución demasiado generalista no consiga atraer al tipo de personas o empresas que pueden querer contratarte.

Algunos pensaréis: “Lo que has hecho ha sido trasladar el problema de la atención o de la visibilidad del producto al sitio web”, y yo diré que efectivamente, pero tal vez en determinadas ocasiones sea más sencillo obtener la atención de esa manera, es decir, ofrecer un cebo para a partir de él dar visibilidad a lo que quiero vender.

Cuando se tiene un producto o un servicio que vender ser visible es fundamental. De nada vale tener el mejor producto del mercado si no se te llega a conocer. Servicios y productos mediocres se venden más simplemente porque llegan a más gente.

Pongo de caso por ejemplo mi blog (sin decir con esto que sea bueno o malo), si estuviera enlazado en unos cuantos blogs que atraen y preservan la atención de mucha gente, seguro que el número de visitas que recibo se multiplicaría por unos cuántos dígitos, sin tener que modificar un ápice la política de publicación de artículos que aplico.

Para mi resulta fundamental el contenido, ya que pienso que la calidad marca la diferencia, pero lo hace cuando se llega a competir en igualdad de condiciones o casi en igualdad.

Esto provoca que sea absolutamente necesario hacerse visible y eso requiere mucho esfuerzo e incluso la realización de determinadas inversiones económicas. Hacerse visible no es fácil, ya que incluso aunque se consiga ser reina por un día, al día siguiente la red tendrá una infinidad de nuevos contenidos y noticias que probablemente eclipsen lo que lograste el día anterior. La visibilidad exige perseverancia y trabajo, de la misma forma que se requiere esos mismos ingredientes para obtener productos de calidad.

Una de las peores cosas que les puede pasar a una organización es que se sumerja en una situación de desorden o de caos. Hay cosas peores, como por ejemplo que no se venda, pero en muchos casos esto será consecuencia de que la trastienda no funciona bien.

El orden lo establecen los procesos. No hay que confundir proceso con burocracia, ya que ésta es consecuencia de una mala configuración de los procesos.

No solo basta con definir procesos sino que tienen que ser conocidos por los que los tienen que cumplir y deben controlarse y exigirse su cumplimiento. Es importante que se cumplan estas dos premisas para que los procesos se implanten y funcionen, ya que en un papel quedan muy bonitos pero no sirven para nada.

Los procesos pueden abarcar cualquier área de funcionamiento de la organización y deben estar siempre sometidos a un proceso de revisión y mejora continúa.

Cada empresa tiene su propia identidad, pero en demasiadas ocasiones la misma solo se expresa de puertas para adentro. En demasiadas ocasiones los clientes percibimos las empresas como algo plano, como si todas fueran iguales, solo que unos vienen con corbata y otros no, que unos tienen una tarjetas muy guays, otros utilizan modelos más clásicos y otros no utilizan.

Con todas las empresas puede haber tiras y aflojas, resultado de que cada uno busque sus propios intereses, eso es legítimo, por lo que marcar la diferencia no consiste en buscar un remanso de paz sino en conseguir que el cliente se encuentre satisfecho por el trabajo y no solo en el presente, sino en el futuro, es decir, que los resultados logrados en el pasado tengan vigencia en el futuro a través de productos o servicios que puedan ser amortizados y que tengan costes de mantenimiento (si fueran necesarios) razonables.

Si una empresa quiere marcar las diferencias lo debe hacer a partir de la calidad de sus trabajos y productos, eso sí que es una seña de identidad hacia fuera y que el cliente percibe y valora.

Un proveedor me comentó un día que el mayor enemigo para la calidad del software es el tiempo, entendiéndose este en sus dos vertientes: en las existencia de fechas de entrega y que los costes del proyecto están directamente relacionados con el tiempo dedicado al mismo.

Desde luego que no le falta razón, pero estoy seguro que el simple hecho de tener más tiempo o algo de más presupuesto no implica tener un producto de mayor calidad. Muchas veces disponer de más tiempo supone simplemente tener más tiempo que perder.

Por tanto, el tiempo puede ser un factor importante pero más lo es la existencia de unos procesos internos de revisión funcional y de código de las aplicaciones. Ahí sí que se marca la diferencia. Cuesta dinero, claro que sí, pero ¿más que tener que dedicar tiempo al proyecto una vez entregado teniendo en cuenta que probablemente interrumpirá otras actividades en otros proyectos?, ¿más que los beneficios que se obtienen por tener una imagen de empresa asociada a la calidad de los desarrollos?.

Como he comentado en otros artículos, la calidad del software no empieza por el final, es decir, por retocar lo ya construido porque eso es costoso, sino que parte desde la realización de un buen análisis funcional (el principio de todo), pasando por la seleccion de una arquitectura y framework que sienten las bases para un desarrollo posterior de calidad, no asegura nada, pero mejor partir de una buena base que carecer de ella.

Desde que comienza a codificarse tomando como base el framework empezarán las desviaciones en cuanto a la calidad del producto final desde el punto de vista de la programación, como es lógico si el análisis no es bueno, las deficiencias empiezan desde antes, pero si a un análisis mejorable le sucede un diseño o una codificación mala, serán mayores los problemas a los que tengan que enfrentarse cliente y proveedor en un futuro debido a que cuando se tenga que tocar la aplicación para ajustar los requisitos funcionales costará muchísimo más trabajo si el código no facilita el mantenimiento.

Por ese motivo las revisiones funcionales y de código deben empezar desde el principio ya que cuanto más tiempo pase hasta que se detecten los defectos más costoso será tomar soluciones, tanto, que determinados tipos de problemas se obviaran debido al coste que tendría solucionarlos. ¿Tiene esto un coste? Desde luego, ya que las revisiones además deberían hacerlas personas ajenas al equipo de desarrollo, pero realmente la clave está en pensar que la entrega de un mal producto implica que ese coste (probablemente mayor que la inversión a realizar por aplicar estas revisiones) repercute tras la entrega en lugar de repartirse a lo largo del proyecto.

Tengo muy claro que la mayoría de los proveedores de desarrollo de software estarán en desacuerdo con este artículo por la sencilla razón de que habla de un “mundo ideal” en el que el cliente es un comprensivo corderito y desde ese punto de vista tengo que dar la razón, ya que el cliente va a ser exigente y además de eso va a tratar de meter evoluciones del producto dentro de la garantía y eso va a pasar independientemente de si el trabajo ha sido bueno o malo o si la calidad del software ha sido óptima o regular. Llegado a ese punto toca negociar y mejor hacerlo siempre con un producto en las mejores condiciones ya que será más fácil hacerlo teniendo el as en la manga de una buena ejecución y también porque las modificaciones que haya que hacer se realizarán con mayor facilidad.

Sé que esta estrategia de revisión continua se ve como ciencia ficción en el mundo real, lo cual no quita que piense que puede traer buenos resultados e incluso haciendo media, una reducción de costes en los proyectos tanto para el cliente como para el proveedor.

Uno de los aspectos que más valoro de mi trabajo es el tiempo que me permite tener fuera de él ofreciéndome la posibilidad de desarrollar otras facetas de mi vida.

Tal vez podría estar ganando más dinero si no hubiera optado por el tipo de trabajo que desarrollo, pero hay otros aspectos que no se miden por el rasero estrictamente económico como es la capacidad de tener tiempo para poder hacer lo que queramos dentro de nuestras posibilidades y contexto.

Todo depende de dónde pongamos el corte sobre la cantidad de dinero que necesitamos para llevar el tipo de vida que queramos llevar. Si el listón está muy alto tal vez necesitemos trabajar más horas para poder superarlo, si no es así, tal vez el hecho de que se pueda prescindir de determinados lujos nos permita tener más tiempo para disfrutar de otros placeres que no se compran con dinero pero sí se consiguen teniendo el suficiente tiempo libre, además hay que tener en cuenta que no hay muchos lujos que no se puedan adquirir ahorrando un tiempo.

Precisamente la conciencia del valor de mi tiempo libre me ha hecho valorar mucho más mi trabajo y mi capacidad para intentar ofrecer en el mismo el mayor rendimiento posible ya que gracias a eso consigo reducir el número de horas extralaborales que tengo que dedicar al trabajo. También me permite que cuando tengo que trabajar esas horas fuera de jornada lo haga tomándomelo con mayor filosofía ya que precisamente la disponibilidad de tiempo permite ser consciente que detrás de la tormenta siempre vendrá la calma.

No se consiguen necesariamente mejores resultados trabajando más horas sino intentando sacar el mayor provecho del tiempo que dedicamos al trabajo, de esta forma se pueden conseguir iguales o mejores resultados trabajando siete horas que diez. El problema está en que la mayor parte de las organizaciones no valoran el trabajo por la productividad sino por el calor del asiento, mientras esto siga así será el reloj el que determine la capacidad de producción de la empresa y no la productividad de cada individuo. Como lo importante es el tiempo y no los resultados se traduce en overtime, falta de productividad y falta de motivación. Siempre habrá personas que hasta en las condiciones más adversas serán altamente productivas y ofrecerán grandes resultados a la organización, por ese motivo cuando hablo de falta de productividad y motivación lo hago en términos generales sin indicar que todos puedan tener ese problema.

Personalmente cada vez veo más clara la utilidad del software como servicio como medio para conseguir un ahorro real de costes para cualquier organización (digo cualquiera, incluso las que se dedican a los servicios relacionados con el desarrollo de software) y todavía veo con más nitidez su utilidad para las PYMES pese a que haya estudios que indican que su grado penetración en las mismas está siendo peor que en empresas de mayor tamaño.

El software como servicio no pretende “sacar” de la empresa todo lo que son los servicios informáticos, habrá casos donde eso sea más factible que en otros, dependiendo de a lo que se dedique la empresa, su infraestructura, presupuestos, etc…, sino que plantea que la gestión de algunos servicios (correo electrónico, servidores, software ofimático, aplicaciones, etc…) se haga desde fuera (incluso en la nube, ¿por qué no?), es decir, la empresa paga por recibir el servicio y el proveedor lo proporciona, pudiendo establecerse acuerdos de nivel de servicio que garanticen para el cliente una calidad acorde a la inversión que se está realizando.

¿Por qué gastar en infraestructura informática cuando ese no es el objetivo principal de mi negocio?, ¿por qué invertir tiempo y esfuerzo en algo que no me va a reportar ningún valor añadido a si lo tengo contratado por fuera?, ¿por qué no estudiar cuánto puedo ahorrarme?, ¿por qué no invertir lo que ahorro en marketing, en mejorar mis productos o en I+D?.

El principal problema que se plantea al apostar por el software como servicio es la pérdida de control directo en el servicio que se contrata, es decir, en los datos, en su disponibilidad, etc…, se tiende a pensar que ese pérdida de control puede ser negativa, cuando en realidad es todo lo contrario, ya que no se pierde el control de nada (con la firma de los acuerdos de confidencialidad de la información y con el establecimiento de cláusulas que establezcan contraprestaciones en el caso de que se determinados riesgos, como por ejemplo, la pérdida de datos o accesos no permitidos a los mismos, terminen sucediendo) y sabremos qué servicio nos tienen que proporcionar (mediante el establecimiento de los acuerdos de nivel de servicio apropiados).

Que nosotros gestionemos directamente la información y el software no garantiza que esté mejor tratado que si esa gestión la realiza una empresa especializada en ello (es más, lo más probable es que al ser ellos especialistas lo hagan mejor que nosotros, ya que su negocio dependerá de lo bien que lo hagan y además, problemas de pérdidas o de seguridad de los datos o de un mal servicio, pueden acabar perfectamente con ellos). Comprender y asimilar esto puede proporcionar una ventaja significativa respecto a la competencia.

Se ha liberado la primera versión oficial de Redmine 1.0. Personalmente me alegro mucho de que este proyecto siga evolucionando ya que es la opción de gestión de proyectos que hemos implantado en mi organización y con bastante éxito y satisfacción entre el resto de responsables de proyecto.

No fue idea mía implantar esta herramienta ya que fue una recomendación, pero lo importante, como he repetido en tantas ocasiones no es que a uno se le ocurra la idea sino que aunque sea de otro, el rendimiento que se le pueda sacar a la misma sea positivo.

Yo recomiendo el uso de este software ya que es tremendamente sencillo y potente y sobre todo por la capacidad de evolución que tiene que lo irá dotando progresivamente de cada vez más utilidades y además permite personalizar determinadas funcionalidades a través de plugins ya sean propios o desarrollados por terceros (los más significativos se van implementando dentro del núcleo del producto, como por ejemplo la posibilidad de definir subtareas que ya no requiere la utilización de plugins).

Para ver las novedades de esta versión os dejo un par de enlaces (de la página oficial de Redmine), uno referido a la última release candidate y otro a las novedades de la 1.0.1 respecto a la versión candidata:

Redmine 1.0.0 Release Candidate

Redmine 1.0.1

Mark Gibbs es un importante empresario, divulgador en el terreno de las TIC y consultor de importantes compañías, teniendo una experiencia de más de 25 años en este negocio.

En febrero de 2006 publicó la siguiente cita como parte de un artículo en la revista Network World en el que hablaba sobre una presentación no del todo exitosa de Microsoft en el Consumer Electronics Show en Las Vegas:

“No importa lo estupendamente que haya ido la demo en los ensayos, cuando lo haces frente a tu audiencia la probabilidad de que sea una presentación existosa es inversamente proporcional al número de personas mirando, elevado a la cantidad de dinero que hay en juego”

Mark Gibbs como bien comenta en su artículo hace una cita que perfectamente podría pasar a formar parte del compendio de la Ley de Murphy y detrás de esa frase y de lo que le pasó al gigante de Redmond podemos sacar dos mensajes claros:

– Que a todos nos puede suceder ese problema.

– Que como es posible que pase hay que tomar las debidas precauciones para reducir o mitigar el impacto.

A mi, en el contexto de mi trabajo, me ha pasado y no solo una vez y me volverá a pasar. Me gusta hacer demos de los productos en directo ya sea en el entorno de pruebas o de producción porque tengo interés en que los usuarios y los directores usuarios vean que lo que les estoy enseñando no es cartón piedra, me gusta que vean que se está trabajando ya que el proceso de desarrollo una vez finalizado el análisis se vuelve demasiado opaco para ellos y prefiero que si salen deficiencias lo hagan antes que el producto esté entregado (por supuesto que si se hubieran detectado o tenido en cuenta en el análisis, mejor, pero hay siempre que tener un resquicio de flexibilidad). Por supuesto, cuando el producto no está terminado o si está terminado pero todavía está en fase de pruebas les recalco el estado en el que se encuentra y que es posible que nos encontremos con incidencias en la presentación que se está realizando.

El peligro de enseñar el programa en funcionamiento es que pueden existir diversas contingencias que te puedan fastidiar la presentación, por eso siempre hay que llevar un plan B si no es posible continuar o realizar la presentación en línea. Ese plan suele ser tenerla preparada en diapositivas (pero bien preparada, no unas cuantas capturas de pantallas para salir del paso).

Evidentemente no me juego lo que se jugaba Microsoft en aquella presentación, pero supongo que salvando las enormes y kilómetricas diferencias buscaban con ese tipo de demostraciones llamar la atención de la audiencia y enseñar que detrás del producto no solo hay palabras sino también hechos.

No siempre hago presentaciones enseñando el programa directamente, depende de la audiencia y del propósito de la reunión, a veces es mucho más productivo trabajar directamente con diapositivas ya que te permite ir más al grano y no tener que pasar por funcionalidades del programa que no tienen por qué interesarles a tus interlocutores.