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.

Anuncios

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.