Jummp’s Blog

Una de las pesadillas de las empresas de desarrollo de software es la confusión (queriendo o sin querer) que existe en muchas casos entre los conceptos de mantenimiento correctivo y evolutivo. ¿Por qué pesadilla? Porque la garantía de los desarrollos afecta sólo a los mantenimientos correctivos y por tanto no se facturan y en muchas ocasiones se “cuelan” evolutivos como mantenimientos correctivos y se convierte en trabajo adicional para las empresas, no previsto y que en muchas ocasiones requiere un notable esfuerzo y que, por supuesto, no se cobra.

Un mantenimiento correctivo es aquel que tiene como objetivo solventar una deficiencia en un componente del sistema de información (puede ser software o documental). Entiéndase deficiencia como algo que debería funcionar o estar correcto y que no lo está.

Un mantenimiento evolutivo es aquel que pretende modificar algo que funcionaba o estaba correcto, con el objeto de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras causas como pueden ser, por ejemplo, cambios normativos.

El problema está en la definición de qué es lo que debería funcionar o estar correcto en el sistema de información, es decir la delimitación clara de la frontera entre el correctivo y evolutivo. Y no es algo que esté nada claro en muchos casos, ya que por ejemplo, eso que esa funcionalidad que dice el cliente que debería estar y no contempla el programa, ¿es algo que se ha sacado ahora de la chistera o realmente se contempló en la definición y análisis del sistema de información?, ¿es algo que no se ha interpretado correctamente en el análisis?, ¿es algo que se suponía que se podía extrapolar del análisis aunque no aparezca explícitamente?.

Es cierto que hay muchos casos que las incidencias son de cajón y son correctivos y en la mayoría de las situaciones no dan problemas ni para el cliente, ni para el proveedor, que será consciente que son fallos suyos y los solucionará. También es cierto que hay evolutivos que son muy complicados de colar como correctivos, ya que una cosa es que la pared tenga que estar pintada de blanco o de color crema, que el pomo de la puerta sea plateado o dorado o que incluso el suelo sea de marmol o porcelánico y otra que te intenten comprar un piso de cuatro dormitorios por el precio de uno de un dormitorio. Sin embargo entre un caso (correctivos claros) y otros (evolutivos claros) hay todo un abanico de posibilidades que la mayoría de las veces dan lugar a conflicto (estos serán menos si el presupuesto del proyecto es holgado, el cliente es bueno, el proyecto se trata de una inversión para intentar conseguir más negocio con el cliente o a través del producto que se ha desarrollado, etc…).

Como ya he comentado en algún artículo en caso de conflicto casi siempre tiene las de perder el proveedor y lo más importante es tener asumida esa circunstancia. Eso no quiere decir que se deba decir a todo que sí, pero es más fácil negociar si no se pierde el tiempo en intentar remar a contracorriente.

Habrá negociación porque en los proyectos de desarrollo de software suelen cometer fallos las dos partes cliente y proveedor. Por esta razón siempre digo que las dos partes deben ser flexibles, ya que todos cometemos errores y además la naturaleza de los procesos de desarrollo de software no es rígida, sino en sí, un proceso evolutivo.

Dicen que en el mundo del deporte sólo se recuerdan a los campeones, pues bien, no es el único caso y los hay hasta peores, ya que en el deporte en muchos casos hay medalla de planta, de bronce, diploma de finalista, etc… En el mundo de la contratación, quedar segundo o tercero en un concurso no tiene ningún premio, el único que gana es quien queda primero y primero solo puede quedar uno.

Con esto no quiero decir que si una empresa no se siente bien posicionada (no tiene mucha experiencia en la materia del concurso, no tiene tiempo o medios para hacer una buena oferta, etc…) no se presente. En mi opinión siempre que sea posible, una empresa debe participar en todos aquellos concursos en los que se vea capacitada para desarrollar el trabajo que se pretende contratar. Los motivos son varios, el primero es el más obvio, si no se participa no se puede ganar, y los otros se basan casi todos en que permiten dar a conocer a la empresa y sus capacidades y también permite conocer un poco mejor al que contrata, si se le pregunta después del concurso qué aspectos de la oferta eran mejorables, seguro que la siguiente sale mucho mejor.

No obstante, si ya se ha conseguido que te conozcan e incluso tienes ya negocio con el cliente, quedar segundo sirve de bien poco, mientras que en el deporte conseguir muchas medallas de plata puede permitir que dentro de tu especialidad seas reconocido e incluso si el deporte es de masas permite ganar mucho dinero, una buena colección de segundos puestos en concursos, puede poner a una empresa en una situación complicada.

Todos los clientes y todos los proveedores no son iguales, esto implica que sea complicado encontrar una fórmula que funcione en todos los casos. No obstante, lo que voy a indicar a continuación es mi visión ante una circunstancia que pasa muy a menudo y que desde mi punto de vista se puede resolver de forma muy sencilla.

Pasa muchas veces que el cliente solicita al proveedor la realización de una serie de tareas ya sea de manera verbal o a través de un correo electrónico y el proveedor queda “indefinidamente” en silencio mientras realiza la tarea (o mientras no la realiza). Al no recibir respuesta o comunicación por parte del proveedor, el cliente (como por otra parte resulta lógico) tiende a mosquearse, ya que piensa que están pasando de lo que ha solicitado, cuando lo mismo el proveedor está totalmente implicado en la realización de la tarea. Es decir, a los clientes nos gusta saber, ¿cómo va lo mío?.

Este posible malentendido se soluciona si el proveedor, mientras realiza la tarea (y sobre todo si la misma dura más de una semana) se pone en contacto con el cliente ya sea verbalmente o por escrito indicando cómo lleva la realización de la misma. Con eso, el cliente se sentirá tranquilo en cuanto a que sabe que lo que ha pedido se está atendiendo. Otra cosa será si se retrasa sistemáticamente la tarea, si esta se entrega incorrectamente, etc…, pero eso son otros problemas y no el que estoy analizando en el presente artículo.

Para responder a esta pregunta me voy a basar en que por regla general existen dos niveles de calidad, uno el que marca el proveedor del servicio y otro el que marca el cliente.

En el caso de que alguno de los dos o los dos (cliente y proveedor) tengan un nivel de calidad, el nivel de calidad que debe tener el proyecto es aquel que tenga un umbral más alto. Una empresa de desarrollo de software podría aprovechar que el cliente tenga un listón por debajo del suyo para entregar un producto con menos calidad que la media que pretende alcanzar, pero esto aunque permite ganar algunos euros más, al final resulta contraproducente, ya que la calidad es un factor diferencial en el proceso de desarrollo de software (empresas de desarrollo hay muchas, pero que normalmente desarrollen productos con calidad, no tantas) y si se quiere tener la calidad como llave para mantener o incrementar el nivel de negocio, es necesario por un lado que la calidad sea siempre mayor o igual que la que espera el cliente y mayor o igual que el nivel de calidad establecido en la empresa y por otro crear un hábito en los procesos de desarrollo, ya que el establecimiento, seguimiento y exigencia de una calidad determinada en los mismos, hace más sencillo el cumplimiento de la misma en la mayoría de los proyectos. Sin la existencia de ese hábito, el esfuerzo por alcanzar el objetivo en cuanto a calidad se incrementa de manera considerable.

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.

Hace poco tuve una charla con algunos amigos sobre el error que cometen algunas empresas de ofrecer un servicio sin preocuparse por intentar adaptarlo a las circunstancias, madurez y estado del cliente, ya que un servicio implementado de una determinada forma puede resultar excelente para una organización y nefasto para otra.

Es decir, ofrecer un servicio, como un appliance: aqui venimos, con esta metodología, con estas personas y con estas herramientas y lo arreglamos todo, independientemente de todo lo demás a mi juicio no funciona o al menos (concediendo el beneficio de la duda) tiene una menor probabilidad de funcionar que una solución que se preocupa por adaptarse al entorno en donde se va a aplicar.

Esta muy bien que una empresa que tenga experiencia en un servicio determinado y que haya tenido diversos casos de éxito aplicando una determinada metodología o forma de trabajar intente aplicarlos, yo eso no lo discuto, lo que sí estoy totalmente en contra es en suponer que sin adaptarlo al nuevo entorno vaya a funcionar correctamente.

Hace tiempo escribí un post sobre el uso, en el plano personal, más que necesario del quién no llora no mama, para intentar en determinados entornos y circunstancias, determinados objetivos.

En este caso lo voy a enfocar al ámbito de las empresas y la consecución de negocios. En muchos artículos he comentado lo interesante que resulta cuando no se consigue un determinado contrato ir al cliente y preguntar en qué aspectos se ha fallado en la oferta, con el objetivo de mejorar en las próximas. Pues bien, esto además de resultar más que útil por la posibilidad de conocer un poco mejor al cliente y a los que toman las decisiones, (lo que provocará que las ofertas sean cada vez más adaptadas a los que ellos quieren y buscan), es una herramienta psicológica muy importante (si se aplica en condiciones, es decir, si se va de buenas y no en plan borde), que como es lógico no afecta a todos por igual, ya que hace ver al cliente que lo intentas una y otra vez y que no consigues negocio con él, pese a que cada vez inviertes más esfuerzo en la realización de las ofertas y estas cada vez son mejores y que se merecen una oportunidad para demostrar que lo pueden hacer muy bien. Si se hace correctamente (y hay auténticos especialistas en el mundo de los negocios), el quién no llora no mama puede ser un instrumento muy eficaz.

En el anterior artículo, hablaba de las ventajas que tenía desde el punto de vista del cliente los contratos grandes (concentración de tareas en un solo expediente o en varios de gran alcance), en lugar de múltiples contratos. En este voy a hablar de las ventajas que también proporciona este tipo de estrategia para los proveedores, que en cierto modo son bastante parecidas a las de los clientes. Algunas de ellas pueden ser:

- Reducción del esfuerzo comercial. Mantener una empresa grande, a base de muchos contratos pequeños exige, sin duda, un gran esfuerzo comercial, ya que hay que estar continuamente vendiendo (y mucho) para poder mantener el negocio.

- Reducción del esfuerzo administrativo (en la misma línea que lo que sucede con los clientes, se reduce el número de proyectos sobre los que hay que controlar la solicitud de certificaciones y facturación).

- Mejora en la planificación y reducción del riesgo. Los contratos grandes dan estabilidad, se sabe que durante un tiempo se va a tener a un conjunto de personas con carga de trabajo facturable, lo cual puede hacer que la empresa pueda planificar a más largo plazo su política de personal e incluso su política de negocio. Los contratos pequeños dan la inseguridad de que si se tiene una mala racha de ventas, esta afecte de forma directa a la plantilla y por tanto, complique las políticas de personal, estrategias de crecimiento, inversiones, etc…

Por tanto, de igual forma que las organizaciones están tendiendo a sacar expedientes cada vez más grandes, las empresas TICs están haciendo grandes esfuerzos (reduciendo considerablemente el margen de beneficio) por hacerse con ellos, ya que les otorga una estabilidad muy necesaria para la continuidad del negocio.

Es muy importante visitar a clientes y potenciales clientes. Que sepan que sigues existiendo aunque haga tiempo que no trabajas con ellos, que sepan que sigues evolucionando, ganando proyectos y consiguiendo casos de éxito.

Estas visitas tienen por regla general la característica de que en poco tiempo tienes que intentar que tu empresa se luzca, en aspectos que le resulten de interés al cliente (si no hay un orden del día marcado o una temática concreta hay que saber adaptarse o interpretar a lo que el interlocutor o interlocutores están interesados) y además sin parecer prepotente o pedante (casi mejor marcharte sin nada, que dejando al cliente o posible cliente con una mala sensación).

Un aspecto muy importante es intentar que la reunión sea para intentar cubrir una necesidad que no tiene cubierta el cliente, si vas por ejemplo a vender al cliente un sistema que resuelve una determinada problemática de negocio y el cliente ya tiene uno que resuelve dicha problemática y está contento, lo mejor es que te ahorres la visita. Por eso a veces es mejor, si se puede, conseguir una primera reunión sin más objetivo que conocer al posible cliente y a partir de ahí plantear una nueva reunión (si realmente interesa) sabiendo por donde se puede intentar conseguir algo.

Si el objetivo no es conseguir una venta a corto y medio plazo y lo que quieres es simplemente mantener el contacto con el cliente o el posible cliente, sí que se puede enfocar una reunión más generalista y de marketing.

Ser un buen comercial es muy complicado, supongo que como todo, habrá parte que lo dará el rodaje y el aprendizaje, pero creo que gran parte del éxito de un comercial viene de serie con él, es decir, se tiene esa cualidad o no se tiene, es cuestión de instinto. Por este motivo, porque los buenos comerciales no se fabrican en serie, están tan bien cotizados en el mercado.

En un proyecto de desarrollo de software, es complejo cumplir una planificación inicial debido a la gran cantidad de contingencias que pueden ocurrir a lo largo del mismo.

No obstante, eso no quiere decir, que ni el cliente ni el proveedor deban resignarse, es decir, hay que intentar cumplir la planificación inicial y sólo variarla cuando se vea que no se puede cumplir o cuando sea contraproducente intentar cumplirla. ¿Qué quiero decir con esto último? Pues que si el equipo de programadores y analistas están muy presionados y tienen que trabajar de forma sostenida un número de horas superior o muy superior a su jornada laboral, el producto resultante no será bueno en cuanto a calidad se refiere (ya sea en cuanto a las características funcionales y no funcionales del software, la documentación, etc…).

Como el presupuesto de los proyectos se realiza en base a la planificación, es decir, tantas horas de cada perfil en un marco de tiempo, es por eso por lo que interesa a los proveedores cumplir la planificación, si no existe planificación o si no se tiene en cuenta la planificación el proyecto entrará en pérdidas y lo que es peor, para intentar reducirlas bajará la calidad del producto, por lo que al final se perderá dinero y además el cliente no tendrá un producto con calidad, por lo que probablemente se pierda al cliente o su confianza.

Por todo lo anterior, siempre recomiendo que la planificación se realice con criterio y no pensando en una ejecución ideal del proyecto, ya que las situaciones de ejecución ideal no existen, es decir, que se aplique un porcentaje de desfase, sobre esa base ideal, que dependerá en gran medida del cliente (si se conoce), de las características del proyecto, de su alcance y de las características del equipo que se va a asignar el mismo.

Es posible hacer ajustes en el equipo de proyecto, pero si se hacen con planificación y no con prisas, es decir, es posible sustituir un miembro del equipo por otro, aumentar el equipo, etc… Lo que no se debe hacer es cambiar el equipo, por ejemplo, meter cuatro programadores nuevos para intentar cumplir una planificación, si ese ajuste no se realiza de forma ordenada y planificada, si no se hace así, probablemente los resultados sean contraproducentes, ya que personas que son altamente productivas en el proyecto, tendrán que dedicar una parte de su tiempo a formar a las nuevas personas del equipo y esto puede provocar más retrasos.

Ante el incumplimiento de una planificación debe imperar el sentido común, por parte de todos, cliente y proveedor, ya que sin sentido común ambas partes verán perjudicados, todavía más sus intereses. El cliente debe pensar que el objetivo debe ser obtener un producto software con la mayor calidad posible y si para ello hay que esperar un poco más, esperar. El proveedor, debe comunicar cuanto antes al cliente, las posibles desviaciones en la planificación y explicar los motivos. El grado de enfado del cliente es directamente proporcional al tiempo que se le tarda en comunicar dichas desviaciones. Si el proveedor, no ha gestionado internamente bien el proyecto o ha errado en la planificación, debe asumirlo e intentar tomar medidas para que la desviación sea la menor posible sin que el resultado final pierda calidad.

Es evidente que hasta el más paciente de los clientes tiene un límite y la ejecución de un proyecto no se puede demorar indefinidamente, por lo que tampoco se debe abusar de eso, aunque el producto que se entregue sea impecable.

También hay que tener en cuenta que existen proyectos que no se pueden retrasar, ya que se tienen que poner en producción en una fecha concreta por la razón que sea. En estos casos, los retrasos son críticos y tanto cliente y proveedor deben poner los medios para el cumplimiento de la planificación, aunque suponga una merma de otros aspectos, incluida la calidad (eso sí, la pérdida de calidad también tiene un límite, que será aquel a partir de la cual la pérdida de calidad del producto supone un mayor perjuicio que un retraso en la fecha de puesta en producción del mismo. No obstante, aunque ese sea el límite, el cliente y el proveedor deben procurar no acercarse al mismo en la medida de lo posible).