Lycka Bonita

La Gestión de la Comunicación es siempre complicada porque no depende enteramente de una única persona, sino de dos o más partes. En tu mano está mejorar una comunicación, facilitarla, dejarla registrada por escrito… Pero no puedes obligar a una persona a que te entienda mejor ni a que se explique mejor

Permitidme un ejemplo para ilustrar lo que ha sido la comunicación en este proyecto.

Antes de marcharme de vacaciones realicé una estimación (informada, con todos los requisitos en la mano ya que era realizar prácticamente otro desarrollo igual que ya habíamos hecho) de un nuevo desarrollo con un socio, y di tres cifras en función de las entregas de este socio: 65, 70 ó 90 jornadas. Estas cifras eran conocidas por mi equipo, el comercial, y por el departamento de IT.

A la vuelta me encuentro con que se ha vendido (y comprado) en 30 jornadas cerradas… Como era prácticamente igual (según operaciones e IT) que un desarrollo previo, empezaron a quitar tareas y a dividir por dos el tiempo, achantando a mi backup. Fue francamente desagradable tener que abroncar tanto al cliente como al comercial.

En este proyecto y a pesar de mis muchos esfuerzos, la comunicación ha sido caótica e informal porque al resto de partes implicadas le interesaba. En nuestro equipo al menos he mantenido las entradas lo más centralizada que he podido en mí, para cumplir que únicamente haya una entrada de trabajo y descargar al resto del equipo de este caos y lo que antes era blanco ahora es negro…

Por supuesto, no existe nada parecido a un Plan de Comunicaciones.

Comunicación caótica

Comunicación caótica porque el elevado número de interlocutores, que no ha hecho más que aumentar con el tiempo. Podríamos pensar en que la comunicación en un principio sería simple, únicamente entre dos partes (el cliente y nosotros como proveedores), y que luego simplemente se añadió otra parte (Mutua Madrileña como socio) con la que no deberíamos de tener contacto directo, y más adelante otros productos y socios…

La realidad ha sido diferente. Primero el cliente era el departamento de IT, y el usuario el departamento de operaciones, cada uno con intereses contrapuestos : el cliente quiere pagar lo menos posible y el usuario quiere las máximas funcionalidades y servicios. Esta dualidad ha sido un auténtico lastre en las negociaciones y en toda conversación, siendo la causa de que siempre ha habido más trabajo del que se puede completar, y por tanto uno de los orígenes de los problemas de indefinición del alcance, planificaciones imposibles de cumplir y calidad deficiente.

La comunicación con el departamento de IT comenzó siendo a través de un único interlocutor, pero ante su temprana saturación de trabajo que le convertían en un cuello de botella que nos impidiería cumplir con las fechas previstas, y el hecho de que nosotros como proveedores estábamos físicamente en la misma sala que el departamento de IT, comenzamos a atacar directamente a cada reponsable de nuestras necesidades (SQL Server, Sistemas, Host…) descargando a la persona responsable de estas gestiones. Es decir comenzamos a realizar trabajo que no era nuestro, además de aumentar el número de personas involucradas directamente en el proyecto, complicando la comunicación y llegando a asumir la gestión incluso del trabajo del personal del cliente.

Pronto las excepciones se convirtieron en norma, y yo de Jefe del Proyecto dentro de nuestra empresa en Jefe de Proyecto a secas. Fue surrealista recibir una bronca por no obligar a una persona del cliente a priorizar una tarea nuestra.

Con la irrupción de socios la comunicación también se complicó, ya que la comunicación no se realizaba de una única persona a otra única persona, sino que nuestro departamente de IT conversaba con su departamento de IT, operaciones con su departamento de operaciones…

Finalmente, con la puesta en producción del aplicativo aumentamos la complejidad, ya que duplicamos las conversaciones : ahora tenemos desarrollos nuevos y tenemos mantenimiento de producción. Y también operaciones, que mantenía un único punto de entrada, pasa a tener varios ya que los gestores de cada producto nos atacaban a nostros directamente.

Suficiente caos? Alguna cosilla más había por ahí, ya que nos llamaban a nosotros en lugar de a IT en cada problema de comunicación, nuevos productos…

Comunicación informal en un sentido, formal en otro.

La informalidad ha sido otra gran carga de profundidad, y lo que más me ha molestado a mi en lo personal por el doble juego : el cliente tiene carta blanca para decir y desdecirse, y a nosotros se nos busca una cifra optimista con sólo el 10% de los requisitos definidos para luego exiguirnos compromiso sobre ella sin un mínimo análisis de riesgos y aumentando el alcance constantemente.

Dentro del equipo esta falta de comunicación única provocaba que las soluciones no se reutilizasen, diseños diferentes, estilos heterogéneos…

Almacenaje

Los documentos de requisitos eran diferentes en el cliente y en nuestro equipo, almacenados en diferentes sistemas, con diferentes versiones y desactualizados con el tiempo. Costó meses poner fin a esto y unificar la documentación. Imposible hacer análisis ni diseños en un ambiente tan cambiante. Respecto a los casos de pruebas, peticiones que caen en el olvido al llegar a los usuarios.

Reuniones de seguimiento

Esto ha sido lo más parecido a un Plan de Comunicaciones, reuniones semanales (semanas sí, semanas no) para evaluar el estado del proyecto. A nivel personal, han sido lo más desagradable del proyecto.

Cada reunión se planificaba el trabajo para el desarrollo de la siguiente semana, y constantemente esta programación se incumplía (como todas las planificaciones de todos los proyectos que gestiona este cliente). Las causas, más que identificadas:

• Por supuesto ha habido retrasos achacables a mí y a mi equipo, sin lugar a dudas. Pero echando la vista atrás, suponen una inmensa minoría.
• En otras ocasiones se retrasaba el desarrollo por la entrada prioritaria de trabajo sin planificar, principalmente mantenimiento de producción, que al ser tan inestable la aplicación es impredecible estimar la entrada de la semana siguiente.
• Pero la gran mayoría de los retrasos se debían a retrasos en las entregas del propio cliente. Pero claro, yo no puedo escudarme en un retraso de IT para justificar que una tarea no está completada, porque se enfadan si les saco los colores delante de operaciones (las mayores broncas que he recibido han sido por esto); y viceversa. Baste decir que llevamos 8 meses, OCHO, esperando a que nos definan una tabla, UNA. Y a día de hoy seguimos esperando.
• Y por supuesto, una planificación en la que no se hace ningún análisis de riesgos no puede llamarse planificación. Ya sabéis que todos los días son buenos, nadie enferma, nadie se va de vacaciones, nadie deja la empresa, nadie se retrasa, no nos topamos con problemas al desarrollar sobre una aplicación inestable…

De paso comentar que estoy plenamente convencido en que utilizar los Test como métrica de progreso de un proyecto es lo más realista, además de las ventajas que aporta ya de por sí una adecuada gestión de la Calidad. En este proyecto, sin Test unitarios ni de integración durante gran parte de su vida, ha sido imposible llevar TDD a la práctica.

Las actas de reunión una utopía inútil ya que sólo servían para recordarnos nuestros compromisos que se nos exigía cumplir a rajatabla y los compromisos del cliente casi inexistentes y rompibles (antes de llegar aquí me parecía un buen chiste, ahora es que me parto el pecho).

Éxitos

• Arroz para todos. Al arrancar el proyecto, el resto de partes implicadas disfrutaban las ventajas de una comunicación caótica e informal mientras mi equipo era el único que sufría las consecuencias. 

Oportunidades de mejora

• Formalizar la comunicación en momentos clave, aún retrasando o parando el proyecto. 

Imprescindible para el futuro

• Retrospective, o cierres de proyecto. Sacar las lecciones aprendidas individualmente es bueno, pero en grupo es mejor. 

Un aspecto clave del éxito de un proyecto son las personas que participan en él, especialmente cuando los procesos son inexistentes y las herramientas escasean. En este escenario, la Gestión de los Recursos Humanos es crítica para convertir una idea en realidad.

La principal dificultad en la Gestión de los Recursos Humanos en este proyecto ha sido como podéis la falta de un plan realista y fiable, por lo cual es imposible anticiparse, difícil dimensionar correctamente un equipo y complicado asignar roles fijos a cada persona, generando inestabilidad y obligándonos a contar con los recursos disponibles en lugar de los recursos necesarios.

A la hora de seleccionar personas he intentado ser lo más sincero y transparente posible, reflejando la difícil situación fielmente, y advirtiendo de la inestabilidad a la que se nos obliga a vivir. Si te piden a una persona para mañana para que esté un mes con nosotros, pues no puedes elegir : coges lo que haya que esté dispuesto a este tipo de trabajo. El resultado, un grupo heterogéneo de supervivientes curtido en mil batallas convertido en un buen grupo, mientras el grano se ha ido llendo con el viento.

La formación del equipo ha sido insuficiente, tanto a nivel técnico como a nivel de negocio, debido a que en este cliente nunca ha habido tiempo reservado a este fin. En la medida de mis posibilidades, para mis proyectos he dedicado tiempo a tener un mínimo de documentació útil, y he apartado tiempo de cada persona para que pudiese formarse en las áreas necesitadas, ya sea un framework nuevo, ya sea en el negocio.

Conflictos ha habido, sin llegar la sangre al río, menos de los que se podrían esperar en este difícil ambiente debido a que la profesionalidad de la mayoría de los implicados. Han tenido un impacto globalmente positivo, ya que ha llevado a un grupo más unido y maduro. El hecho de tener un equipo notablemente infradimensionado hace difícil gestionar los conflictos, ya que castigar o prescindir de alguien puede tener un tan impacto negativo a corto plazo (al poder perder un 25% de la productividad del próximo mes pej) como no castigar o prescindir (el resto del equipo se molesta por la ausencia de consecuencias). Solución, bastante mano izquierda a la hora de resolver los problemas.

No se ha impuesto un estilo de liderazgo inamovible, se ha ido adaptando según las necesidades del cliente y del propio equipo, pero manteniendo una orientación a la persona. Se comenzó intentando utilizar metodologías tradicionales, documentar, planificar… y se tuvo que ir abandonando. Nos hemos visto obligados a aparcar soluciones win-win debido a que el cliente no se ha dejado ayudar. Se ha intentado dar a todos el protagonismo y responsabilidad que pedían (y que podían cumplir) para poder ser

• efectivos (hacer las cosas correctas)
• eficientes (hacer las cosas correctamente).

Ha sido difícil mantener la motivación de los mejores porque yo no controlaba todos los factores : no puedo hacer que el cliente haga bien su trabajo por ejemplo. El mayor problema ha venido por hacer un trabajo más participativo y no agobiar con controles : los responsables responden, los irresponsables no y surgen tensiones. Los objetivos trasladados al equipo eran lo más realistas posibles 

He puesto todos los medios para que la comunicación sea lo más transparente y horizontal posible, siempre ofreciendo una oreja para escuchar y poder mejorar, mordiéndome la lengua en alguna ocasión, siempre positivo, buscando soluciones y no culpables…

Ha habido mucho estrés, estrés puntual por entregas o fechas pero sobre todo estrés "institucional" por la forma de trabajar del cliente. Quizás el exceso de positivismo y buen ambiente es un lastre para que el cliente solucione este grave problema. He intentado aislar al grupo para que se quedase únicamente en mí.

La delegación de responsabilidad ha supuesto decepciones puntuales, al fin y al cabo es un hecho que no todo el mundo es responsable. Se comunicaba claramente las expectativas, la medida del rendimiento (performance) era por funcionalidad o tareas cumplidas, el control era insuficiente por la dificultad para resolver un conflicto mencionada antes, y el feedback era casi siempre positivo en los responsables y negativo en los no responsables.

Éxitos

• Adaptación, a las necesidades del cliente, al grupo, y a cada persona. Por supuesto no es una adaptación al 100%

Imprescindible para el futuro

• Mayor supervisión : debí dedicar mayor cantidad de tiempo a la supervisión del trabajo para verificar que realmente somos efectivos y eficientes. A las personas responsables les molesta, pero cuatro ojos ven más que dos y todos podemos mejorar. A las personas irresponsables mejor no tenerlas cerca, pero si se tienen hay que controlarlas más de cerca.
• La confianza se gana, no se da. Es una pena pero en un proyecto con una considerable cantidad de beneficios (libertad de horario, jornada intensiva, buen ambiente, alto grado de libertad y responsabilidad…) las respuestas no han sido todo lo agradecidas que se pueden esperar.

Para asegurar la calidad en un producto/servicio se precisa :

• Una clara especificación y uso de estándares. Las buenas prácticas aquí eran conocidas pero ignoradas.
• Experiencia y recursos cualificados. De esto no ha faltado, pero simplemente nos ha librado del fracaso para caer en el caos absoluto.
• Revisiones de diseño imparciales. También hemos tenido revisiones por terceras partes imparciales tanto en el cliente como en nuestra propia empresa.
• Control de cambios. Imposible de implementar, la vida es cambio en este proyecto, todos los días hay cambios.

En la etapa de Planificación se debe planificar la calidad del proyecto a partir de

• Política de calidad. Inexistente en este caso
• Alcance establecido. Incertidumbre total.
• Descripción del producto. A día de hoy aún no está disponible.
• Estándares y regulaciones. Prefiero no escribir nada sobre esto.

Utilizando como herramientas

• Análisis de coste/beneficio.
• Benchmarking, es la comparación con otros proyectos para mejorarlos y obtener normas

LLegamos a los siguientes entregables

• Plan de Gestión de Calidad, cómo implementar la Política de calidad.
• Definiciones operativas y métricas de calidad
• Checklist específica para cada actividad que se utiliza para verificar que un conjunto de pasos necesarios han sido llevados a cabo.

En la etapa de Ejecución a partir del Plan y los resultados de las métricas de calidad podremos realizar auditorías de calidad que nos ayuden a seguir mejorando.

La calidad es el conjunto de propiedades y caracterísiticas de un producto, servicio o proceso que le confiere su aptitud para satisfacer las necesidades establecidas o implícitas.

Una vez entregado el producto, se debe seguir dedicando recursos a la calidad para conseguir una Mejora Continua, es decir mejorando las características del producto, servicio o procesos de forma continua y con ello la percepción del cliente y su satisfacción.

La Gestión de la Calidad son las tareas encaminadas a que el producto a entregar como resultado del proyecto cumpla dichas especificaciones, así como a mejorarlas con el tiempo.

Qué bonito! Pero cómo conseguirlo ? Hay toda una batería de tareas relacionadas con calidad que deberíamos de llevar a cabo, procesos, documentación, reuniones… Pero una forma muy fácil de elevar la calidad de tu trabajo es aplicar a todo lo que hagas estos 2 principios, que retrasarán su entrega pero lo harán más duradero y fiable :

• Mantenlo simple (Keep it simple), es paradójico lo complicado que es hacer que las cosas sean y parezcan simples.
• Verifica cuando lo termines que efectivamente es correcto. Es sorprendente la gran cantidad de personasque no verifican que su trabajo es correcto, es un gran medidor de la profesionalidad.

 En este proyecto en concreto…

… como ya he comentado, la calidad no es ni alta ni es baja : simplemente ha sido inexistente en las primeras fases ya que no se han definido las propiedades a cumplir por el producto.

• Ha sido la gran sacrificada para "abaratar" el proyecto, y sin embargo como todos podéis suponer lo único que se consiguió es abaratar un poco el desarrollo y encarecer un mucho el mantenimiento.
• En mi opinión este problema ha sido ahondado por mí, suponiendo mi mayor demérito, ya que no he conseguido un producto simple ni verificado correctamente por razones ajenas a mí, pero también por errores propios.

El impacto de abandonar la calidad en las primeras fases del desarrollo se ha visto amplificado ya que como he comentdo anteriormente las especificaciones del producto han sido incompletas e inestables, dando como resultado que:

• El cliente no tenga claro a dónde quiera llegar, y por tanto el equipo tampocoo : se abandona el camino recto para pasar a un camino más espiral, constantemente se añade, quita y modifica código, el código no es claro ni está documentado, siendo el origen de numerosos bugs y errores, y dificultando el posterior mantenimiento.
• Se crea una diferencia entre los resultados esperados por el cliente y los resultados entregados por el equipo.
• Es imposible poder definir e implementar un juego de pruebas. Tengo que mencionar las ventajas de tener un juego de pruebas y validarlo en cada subida a test o producción? Implica dedicar un tiempo a tareas "improductivas" que no hacen avanzar el proyecto, pero a medio plazo ese tiempo y coste han sido sobradamente rentabilizados. Además soy partidario de  desarrollar primero las pruebas y luego desarrollar el negocio, ya que así se tiene más claro qué se necesita para no caer en los errores anteriormente mencionados.
• La ausencia de un diseño único e invariable : se partió de otro existente para una aplicación similar, que unido al alto grado de independencia concedido a los integrantes del equipo el resultado es una elevada heterogeneidad de diseños.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

Antoine de Saint-Expury

Por qué abandonar las buenas prácticas?

Sólo hay dos respuestas posibles a esta pregunta : quieres perder dinero o aunque sabes que te va a costar más en el futuro, hoy no tienes más dinero (cómo pedir un préstamo).

En el mundo ideal de las buenas prácticas nos deberíamos de haber levantado de la mesa, desmontado el equipo recoloncando a unos y despidiendo a otros, esperar al día en que esa documentación aumentase en volumen y concreción, y si ese día llegase intentar montar otro equipo, formarlo y arrancar el proyecto bien.

En el mundo real, el cliente realmente necesitaba completar ese proyecto en el plazo estipulado por razones estratégicas y de mercado, y nosotros (empresa pequeña) no podemos permitirnos abandonar el cliente que supone un % notable de la facturación de la empresa y perder parte de los activos más importantes que tenemos : personas probadas a fuego.

Los beneficios de abandonar las buenas prácticas eran superiores que los costes para todos los involucrados, así que se tomó la opción más mundana, que debería de ser temporal hasta que dispusiésemos de tiempo (y presupuesto) para arreglar los desaguisados causados.

Consecuencias del abandono de las buenas prácticas

Con el tiempo el proyecto fue mutando hacia un monstruo descontrolado que aún hoy estamos domando, en el que hay funcionalidades entregadas sin código que las implemente, errores detectados en producción tras más de 9 meses, código que nunca se utiliza… Pero seguíamos sin ser capaces de convencer al cliente de que el proyecto necesitaba más recursos, volver a la senda de las buenas prácticas y rebajar la indefinición.

El colmo llegó al final de un desarrollo, cuando deberíamos de optar por desmontar el equipo con la problemática de encontrar más adelnate tan buena gente como la que teníamos y además con los conocimientos técnicos y de negocio. En ese moento se nos pidió una ampliación de cientos de jornadas para ayer… partiendo de 14 páginas de documentación de las cuales 5 eran modelos de cartas a enviar, que por supuesto cambiaron y se hicieron multiidioma.

Y durante todo este tiempo me he sentido como un demente predicador del fin del mundo, avisando de que esta forma de trabajar no es sostenible, que entendía que las circunstancias obligaban pero que era necesario buscar un momento para parar y hacer bien lo que simplemente estábamos haciendo como podíamos…

El apocalipsis va a llegar

Y el mañana inexorablemente se convertirá en presente.

Retomando el control

Poco a poco comprendí que no había más remedio como ya comenté que ir colando tareas de calidad entre las tareas de desarrollo, desarrollar más despacio y entregar bien cada tarea para tener que hacerla únicamente una vez, quedándose en mi toda la responsabilidad y presión con la que he aguantado. 

Además quería eliminar de mis tareas los dos extremos de la cadena, requisitos+análisis+diseño por un lado y calidad por el otro, para poder dedicar más tiempo a gestión, propuestas, control… Cada uno de los dos extremos de la cadena fue asignado a una persona distinta, quienes en aras de fomentar la participación de todo el equipo y mantener una comunicación fluida y horizontal, disfrutaron de un alto nivel de libertad y autogobierno, limitando mis tareas en estas áreas a dar soporte a estas tareas.

Probablemente mi mayor error ha sido delegar la supervisión de estas tareas, nunca debí hacerlo. En su momento no tuve más remedio que confiar y aligerame de trabajo ya que estaba siendo un cuello de botella importante. Por qué un error? Quizás era una buena idea y las personas no eran las apropiadas, quizás no supimos llevarlo a la práctica correctamente, pero los resultados no fueron los esperados, casi podríamos decir que fueron negativos. En el futuro prefiero aumentar la burocracia y poner escalones a menos que previamente me demuestren que no es necesario.

Después de un par de meses pude evaluar los resultados, y fueron decepcionantes. Sí, las incidencias (medida objetiva de la calidad del producto) bajaron sobre todo gracias al esfuerzo del equipo de desarrollo en corregir errores previos pero aún eran insostenibles e inaceptables y sobre todo no había seguridad y confianza (media subjetiva, pero basada en la experiencia) en el funcionamiento de cada nueva entrega.

Me he visto obligado a incorporar estas tareas a mi listado de responsabilidades, y cambiar de dirección es una de las cosas que más me disgustan. El resultado, he recuperado la confianza en los nuevos desarrollos (la del cliente…), no tenemos nuevas incidencias en producción desde hace un par de meses, únicamente estamos dando soporte a los gestores (que consumen más tiempo del que me imaginé) por lo cual el cliente está más tranquilo y contento, y nosotros disponemos de más tiempo para desarrollar… y para calidad

Oportunidades de mejora para el futuro

• Antes de escribir el código, se escriben las pruebas. Después de obtener la confirmación de los requisitos, obtener la confirmación de los casos de prueba por parte del cliente.

Imprescindible para el futuro

• Bajo ningún concepto abandonar la calidad, aunque el cliente lo quiera. Se puede dedicar menos tiempo, pero hay tareas innegociables como la automatización de pruebas.
• Poner límite a la gestión del proyecto por parte del cliente : los profesionales somos nosotros, y nosotros sabemos mejor cómo hacer un producto eficaz y eficiente. Si no, no nos contratarían.
• No delegar la supervisión de la etapa inicial (toma de requisitos, análisis y diseño) ni de la etapa final (calidad) de un desarrollo.

La Gestión de los Costes es a priori una de las más importantes, no? Trabajamos por dinero, y los clientes nos contratarán porque hacemos un buen trabajo a un precio razonable, así que más nos vale no descuidar este aspecto!

De manera análoga a como comentaba anteriormente respecto a la gestión de tiempo, un buen coste es más una consecuencia de un buen trabajo que una consecuencia de una buena gestión de costes para que las estimaciones iniciales se cumplan. Yo de hecho es lo que he hecho durante el proyecto, centrándome en un conseguir el mejor trabajo posible (que no un buen trabajo) y achicar agua en otras áreas.

Como os habréis imaginado si habéis leído la sección, surgieron las primeras desviaciones en costes pronto, y ya sabíamos cuáles eran las causas

• Indefinición en el alcance, comprendida y asumida por parte del cliente como un problema propio, razón por la cual se ha podido contrarrestar en buena medida. Se intentó minimizar pero no se hicieron grandes avances por la naturaleza del cliente y del negocio anticíclico (que ahora está en la cresta).
• Fechas poco realistas y cambiantes, es decir facturar menos jornadas de las necesarias y dificultad para estimar correctamente. Ante este problema se pusieron menos recursos a disposición del equipo para minimizar riesgos y pérdidas, y yo comencé a desligar jornadas de facturación y jornadas de trabajo. Sí, ser realista es más fácil y barato, pero no tengo tanto poder como para cambiar a la gente

En estas circunstacias cada propuesta presentada llevaba un significativo y alto porcentaje de incertidumbre : lo que nos pides nos costará 100 +- un 40%. Puede que un margen tan alto dé una imagen poco profesional, pero os aseguro que a toro pasado los márgenes consumidos siempre eran mayores que los estimados.

Después surgieron más problemas con la puesta en producción del aplicativo, ya que fue prematura y temprana, a sus 4 mesecitos de vida ya estaba sirviendo al público, sin cumplir los mínimos aceptables para ello. Y como todo bebé, se tambaleaba en sus primeros pasos : los días se iban de sol a sol resolviendo incidencias. 

El cliente fue comprensivo y asumió como suya cierta responsabilidad del estado tambaleante de la criatura, por las prisas, la sobrecarga de trabajo de sus propios recursos y sobre todo por la bomba de Mutua Madrileña que cambió radicalmente todo el plan, así que esos dudativos primeros pasos fueron cubiertos en modo de bolsa de horas y asumida las desviación en coste.

El problema vino al agotarse esa bolsa de horas, ya que nos vimos obligados a cumplir con la garantía en un proyecto que nunca tuvo que ver la luz tan pronto. Baste decir que no se detectó ni por el cliente ni por nosotros que una de las funcionalidades no estaba ni siquiera implementada hasta 4 meses después de su puesta en producción, es decir al 8º mes de vida.

Estuvimos barajando a proposición mía otras formas de facturar. Yo en concreto veía como adecuado una gestión ad-hoc para los costes : eliminar las estimaciones, centrarnos en hacer un buen trabajo (que sería lo más barato) y cuando esté estará y costará lo que haya costado. No seas purista amigo lector, no es una aberración… al menos no en nuestras circustancias. Pero es imposible de aceptar por el cliente dada su necesidad de que estuviese para una fecha determinada, y porque estaba consiguiendo no pagar por todo el trabajo al convertir los días posteriores a a una entrega en días de desarrollo gratuito al estar resolviendo incidencias. 

La Gestión de Riesgos vendrá en otra entrega, pero como ya he adelantado ha sido inexistente, y hemos pagado las consecuencias elevando los costes del proyecto y la dificultad su gestión. Sólo conseguí que el cliente actuase proactivamente ante un riesgo catastrófico a punto de materializarse con un coste brutal, y me supuso una semana de desvelo y preocupaciones.

La Gestión de la Calidad, también para otra entrega y también inexistente, nos hubiera ayudado y mucho a controlar los costes.

• En esta industria el buen trabajo es mucho más barato que un mal trabajo : una vez que una funcionalidad funciona, funciona para toda la vida a no ser que cambien los requisitos. Funcionalidades mal implementadas (por ejemplo, por no conocer 100% de los requisitos) nos ha significado semanas de trabajo de sobrecoste (y no sólo para el proveedor) entre incidencias de producción, ñapear, y arreglarlo.
• En ocasiones es más costoso además arreglar algo mal hecho que hacer bien de cero.
• Un buen trabajador, formado, experto y conocedor del negocio es sin ninguna exageranción 50 veces más productivo que el mismo trabajador sin estar formado, sin tener experiencia y sin conocimientos del negocio. Y sin embargo, su coste no es 50 veces mayor.

Éxitos

Pues no me voy a apuntar tantos en esta ocasión que no me corresponden, mi idea de hacer una gestión de costes ad-hoc no llegó a convertirse en realidad así que nunca sabremos si hubiera sido un éxito o un fracaso. Aquí tiene más culpa el propio cliente y el comercial al conseguir reconducir la situación, aunque en la solución también viene la penitencia.

Oportunidades de mejora para el futuro

• Anticiparse a las desviaciones analizando previamente posibles causas de desviación y actuando sobre ellas.
• Reflejar antes el coste de una baja calidad, prisas y un mantenimiento excesivo de producción.
• Mejor y menos costoso es reducir el coste de la jornada y aceptar una planificación realista.

Imprescindible para el futuro

• Las entregas al cliente deben ser aceptadas por el cliente y por nosotros, o renunciar a la garantía. El cliente decidió subir a producción un proyecto inestable y asumir él las consecuencias, pero también trae consecuencias para nosotros como proveedores que ofrecemos garantía del producto.
• Hacer que el coste de una baja calidad y tiempos imposibles recaiga únicamente sobre el cliente.