Lycka Bonita

Como comentaba, la primera fase del proyecto ya está en producción. Por tanto actualmente estamos ofreciendo mantenimiento (el correctivo se supone que lo hacía el cliente, el evolutivo no está contratado de momento y es un trabajo significativo, pero lo hacemos también qué cojones) y tenemos pendiente continuar el desarrollo de la siguiente fase.

Al finalizar esta primera fase yo aproveché para sacar mis propias conclusiones. Pero debo de ser muy novato, o estar muy equivocado porque las conclusiones que han sacado otras partes del proyecto van en el sentido contrario a las mías. En concreto, que como hemos ido tan sobrados, que ahora lo hagamos sin manos.

Vamos, para que podamos decir todo orgullosos,

Mira mamá ! Sin manos !

Al menos estamos de acuerdo en que ha sido un éxito (razonable), y que el equipo lo ha dado todo y sus resultados inmejorables.

Ahora a la segunda fase de este proyecto, que estaba planificado que se entregaría un mes después de la primera entrega, se le une el mantenimiento de la primera y una nueva ampliación con otro socio.

El alcance pendiente

• Por un lado tenemos que aún no se ha empezado la segunda fase por la cantidad de trabajo que lleva el evolutivo y que ha tenido más urgencia, unido a mis vacaciones y una semana en blanco por enfermedad.
• Por el otro tenemos pendiente una nueva ampliación sobre esta segunda fase.
• Hay que seguir ofreciendo mantenimiento de la aplicación en producción.
• Hay que disponer de tiempo para el control y seguimiento de los proyectos.
• Además, se facture o no, el mantenimiento correctivo de la aplicación en producción y las nuevas mejoras que estamos hemos estado haciendo, y seguiremos haciendo.

Con la experiencia que ya tenemos, el alcance aumentará a lo largo del proyecto un 20% de lo planificado para la ampliación, e incluso un 10% extra después de la entrega como ocurre en el actual .

El plazo

Por motivos comerciales, se ha fijado el 1 de enero de 2010 como fecha en la que se deberían de empezar aceptar siniestros para este nuevo socio (Acuerdo Marco). El 1 de enero está a la vuelta de la esquina, gran parte del equipo ha disfrutado de pocas vacaciones este año, y están las Navidades de por medio.

El equipo

Qué equipo ? No quiero entrar en detalles de presupuesto, por eso no diré si el equipo es de 1 o 100 personas… Y las siguientes cifras son metafóricas

Baste decir que con el equipo actual ni siquiera se puede considerar una utopía cumplir en plazo y alcance. Duplicando el equipo, es sin lugar a dudas inviable. Triplicándolo no llegamos y cuatriplicándolo nos acercaríamos a entregar una parte a tiempo. Necesitaríamos quintuplicar el equipo actual para siendo optimistas verlo factible y quizás con esfuerzos (sin vacaciones, horas extras), y no me quejaría de manos extras.

O para entendernos, si se estima que se necesitan 100 jornadas laborables, se venden 50 y se nos obliga a realizarlo en 20 jornadas, ya que disponemos de una persona durante un mes… se pide cuadrar el círculo. 

Cómo lo solucionaremos ? Os ha pasado ? Cómo lo solucionásteis ?

Veo que ni siquiera la solución del jefe con los pelos de punta, del genial Dilbert, será buena :

Actualización

Bueno, vamos añadiendo gente al equipo. Vamos a ver si conseguimos tener un hijo utilizando 3 mujeres en un mes

Hemos llegado al final, el proyecto ha sido entregado y puesto en producción. Se ha realizado la campaña de publicidad a nivel nacional (yo no me he enterado, cosas de no ver televisión ni escuchar radio) y las primeras solicitudes ya se han registrado en el sistema.

A toro pasado, estimo que este proyecto ha sido infravalorado (en jornadas) como mínimo un 25%, me hubiese sentido más cómodo incluso con más margen, a pesar de lo cual hemos llegado a tiempo por el buen trabajo de los integrantes y su experiencia previa.

Fueron las circunstancias económicas del cliente el factor determinante para fijar el precio, el precio ha sido el máximo que ellos podían pagar por el mínimo trabajo que nosotros podíamos dedicar para que saliese adelante el proyecto.

Quizás por mala suerte, se han materializado muchos (sino todos) riesgos habituales que escapan a mi control : retrasos de terceros, cambios de requisitos, fallos personales puntuales, cambios de fecha, cambios de alcance.

Será un éxito ?

Llegar aquí no ha sido fácil. Los principales obstáculos que hemos sorteado han sido :

1. Incertidumbre en los requisitos, insospechadamente elevada en un mundo tan constante como se considera este sector. Las dudas de los usuarios mezclada con el gran trato firmado con el socio han sido las principales causas. A pesar de lo cual, ha habido relativamente poco "desarrollo en círculos" y el diseño no ha sido especialmente deficiente.
2. Bajo precio, como digo a toro pasado estimo que el precio ha sido al menos un 25% menor. Esto ha supuesto disponer de menos jornadas para realizar el trabajo, provocando cierto estrés y dificultando el desarrollo (4 ojos ven más que 2, 6 más que 4…), el aseguramiento de la calidad y las entregas.
3. No ! Palabra clave que no he pronunciado lo suficiente, resultando en un over service que se ha comido parte de nuestros escasos recursos. Se ha confundido la colaboración con la obligación, culminada por una reunión a las 15:00 horas del viernes para examinar el estado del proyecto, escena propia de la ficción.
4. Riesgos ! Ha sido un poco increíble, si algo pudo salir mal salió mal : retrasos de 21 días para … empezar a probar las partes del socio, que no estuvieron al 95% hasta la última semana; nos entregaron tarde el entorno de producción : 5 días antes de la puesta en producción tuvimos el servidor, el día antes la parte del socio, la base de datos y la parte de sistemas ok, y aún las comunicaciones no están 100%.
5. Tempo descompensado. En este proyecto he tenido más de 15 interlocutores directos… Demasiados, especialmente porque cada uno de ellos ha ido a su ritmo, en algunos casos había que controlar exceso de velocidad de ejecución (que significaba habitualmente retrasar la velocidadd de producción) y lidiar con retrasos abismales, cambios de ritmos…
6. Sólo dos entornos no son suficientes. Tuvimos a nuestra disposición el entorno de preproducción y el de producción (ejem). Solicité una base de datos de desarrollo, pero debí solicitar un entorno completo.
7. CMMI. CMMI ha estado pulunado por el proyecto, pero no ha aportado nada positivo. Sólo ha significado una sobrecarga de trabajo improductivo y el ausentarme 3 días del proyecto para recibir un curso que se tradujo en un desbarajuste. Esperemos que en próximos proyectos podamos recoger frutos y que este gasto se convierta en una inversión.
8. Sin repositorio común de documentación. Cada parte tenía únicamente sus documentos, y yo los de todos. Los numerosos cambios han hecho la gestión de este repositorio no común una sobrecarga no despreciable y sin llegar a causar problemas de comunicación podría haberse conseguido más fluidez con la gestión y uso compartido.
9. Vacaciones ! Las del resto de participantes me refiero, las mías serán en Noviembre. Han sido un obstáculo, pero menor de lo esperado sobre todo comparado con los anteriores.

Esto ha provocado situaciones no deseadas :

1. Falta tiempo ! El cliente se negó a aceptar mi primera propuesta por considerarla alta. Fue la más realista y en la que incluía márgenes para riesgos y una estimación de los recursos propios que el cliente debería dedicar al proyecto. Al marcar un precio debimos reducir todos los márgenes dedicados a los riesgos, y al materializarse todos nos movimos con la lengua fuera desde hace un par de meses.
2. Vacíos. De requisitos, debido a una imprevista incertidumbre, y de responsabilidades debido a un deficiente kick off.
3. A dónde voy ? Los cambios de requisitos han sido una pesadilla, que unido a la falta de tiempo para gestionarlos y la sobrecarga de trabajo nos han hecho perder un poco el objetivo.
4. Mi perro se comió mis deberes. La escasez de tiempo y el over service han provocado tener que dejar un poco de lado tareas menos esenciales como la calidad y el seguimiento, provocando la pérdida del control de la situación en algunos momentos puntuales y en dar la sensación de un quiero y no puedo presentarte mi trabajo.
5. Débiles pilares para la construcción. Debido a que en el arranque de la construcción estábamos más pendientes de los cambios de requisitos y en la formulación de la nueva propuesta, no senté los pilares con suficiente fuerza. En parte no sabíamos a dónde nos dirigíamos, y no ha sido un gran problema por la competencia de los participantes.
6. Borramos la base de datos de preproducción (que era también nuestro entorno de desarrollo) en mitad de una demo en el cliente.

También hemos disfrutado de aliados vientos alíseos :

1. Experiencia. Creo que ha sido el principal aliado. Por parte del cliente, la experiencia ha supuesto facilitarnos la vida en un entorno tan cambiante y comprender nuestras necesidades. De nuestra parte, sin duda la experiencia en el anterior proyecto, tanto técnicamente como en conocimientos de negocio y del cliente, han sido la clave para sacar adelante este proyecto con un 20% menos.
2. Competencia. La experiencia no sirve de nada si las personas no son competentes, y en este caso lo han sido.

Lecciones aprendidas ?

Bueno, seguro que me dejo cosas en el tintero, pero al menos yo he aprendido un montón de cosas de esta experiencia, que me servirán a corto plazo en la cercana ampliación de este proyecto.

El resto de los participantes… no estoy tan seguro de que hayan aprendido que nuestro mayor problema ha sido la falta de tiempo que sólo se cura con un retraso, disminuir el alcance o aumentar los recursos asignados y por tanto el coste. 

Foto

• Mirando atrás, en cerebro hueco.

Stakeholders es un término reciente utilizado para denominar las personas claves involucradas en un proyecto, y es desde mi punto de vista una medida más de la complejidad de un proyecto.

Un stakeholder por ejemplo ha sido la persona que nos ha dictado los requisitos de negocio.

Todos los stakeholders implicados han tenido al igual que nosotros mucho trabajo a parte del proyecto que nos ocupa (en el cliente está habiendo mucho movimiento). Por esa razón el número de ellos creció, ya que tuve que ser yo directamente quien gestionase los temas de base de datos, cuentas de correo, conectividad, acceso a host… Todas estas gestiones debieron haber sido centralizadas en un único responsable del cliente.

En este proyecto yo he podido identificar más de 15 stakeholders, excesiva a mi modo de ver respecto al presupuesto de nuestro proyecto (que no del proyecto). La disminución de este número debe ser un punto a mejorar en el siguiente proyecto.

La comunicación con ellos es muy importante. Este es un aspecto que creo que ha ido bien, pero que podría haber ido mejor con un repositorio compartido por todos de la documentación relevante del proyecto, ya que cada parte gestionaba sus propios documentos y yo los de todos.

Los tempos han sido muy dispares, lo cual ha sido un auténtico quebradero de cabeza. En general ha habido retrasos notables en las entregas de la mayoría de ellos.. El entorno de producción llegará 5 jornadas antes de la puesta en producción, el socio entregó su parte con 21 días de retraso sin funcionar, y no ha pasado los test de calidad hasta 5 jornadas antes de la puesta en producción, módulos que se dejaron fuera del alcance al principio han sido incluidos ahora, muchos requisitos nos han llegado a última hora…

Foto

• Stakeholders vs Shareholders, en  upwardaction.com.

No voy a descubrir nada del otro mundo. Tomar un requisito implica una reunión y/o documentación clara sobre la que estar de acuerdo con el cliente (firmar)… pero el trabajo continua después : a partir de estos requisitos hay que realizar un análisis de riegos, casos de uso, casos de prueba, modelos de clase, diagramas de estado… y sin empezar a construir ! Un cambio de requisito implica además gestionar el cambio. Estas actividades adquieren mayor relevancia bajo la lupa de CMMI.

Y este proyecto ha estado plagado de requisitos, nuevos requisitos, cambios de requisitos, cambios de cambios, grandes, pequeños, medianos…

Han supuesto picos puntales e importantes, en los que no podía dar más de mí y tenía que dejar de lado otras tareas, como casi todo el análisis, la documentación o la supervisión del proyecto. La mayoría las realizaba, no os vayáis a pensar, pero no tenía tiempo para documentar y sólo las hacía verbalmente.

En estos momentos de saturación (varios) en los que no podía supervisar el estado del proyecto perdía el control del proyecto.

La mayor parte de estas ocasiones no han supuesto un problema, todo iba sobre el plan previsto sin necesidad de mi intervención ni supervisión.

Otras sin embargo sí que han supuesto retrasos en tareas, la construcción a partir de requisitos mal entendidos por mi parte y otros por parte del equipo, porque los usuarios nuncan tienen malentendidos.

Así que respiro aliviado por haber dejado a un lado un pico de trabajo provocado por los requisitos, para pasar a abrazar un pico de trabajo de hacer el pino con las orejas para recobrar el equilibrio y volver al plan previsto.

Lo bueno es el haber mantenido bien engrasada la cadena global y el equilibrio : el resto de implicados en el proyecto han estado satisfechos y a su temperatura ideal (un poco más fríos creo).

Mientras más aprietes tu puño, más sistemas se escaparán entre tus dedos

(Princesa Leia)

La peor consecuencia negativa de estos momentos de descontrol es que se comieron nuestro escaso margen de jornadas para imprevistos y materialización de riesgos en una temprana fase, por lo que el resto del proyecto hemos andado en una cuerda floja y sin red ! 

Pero bueno, aquí seguimos adelante como buenos profesionales. Parafraseando a mi querido pero abandonado Gnon,

… menos mal que somos la polla

Off the record, 

os recomiendo la lectura de esta entrada de Presión Blogosférica. La cita de la princesa Leia está sacada de otra entrada de Presión Blogosférica. Por si no lo he recomendado, os lo recomiendo ahora.

Más horas, más productividad ?

Creo que a nadie se les escapa que salvo muy escasísimas excepciones, trabajando 60 horas semanales de media no se puede producir con la misma calidad que trabajando 40 horas; es decir, se entregarán trabajos que haya que repetir.

Usain Bolt no puede correr una maratón (42 km) haciendo una media de 10 segundos cada 100 metros.

Y ni que decir tiene que si se rema en círculos no se avanza, o en una dirección equivocada no se llega al destino esperado.

Más servicio significa ofrecer mejor servicio ?

Pero hoy me quería referir a dar más servicios de lo que se ha firmado, lo que he oído por ahí que se llama overservice.

Como había dicho, este proyecto venía precedido por otro no exitoso para el cliente y asfixiante para nuestro equipo. Además se trata de un proyecto a presupuesto cerrado, y se ha vendido objetivamente barato y muy ajustado en fechas, con el agravente del periodo vacacional no ya nuestro sino del resto de participantes del proyecto.

Por estas razones, he intentado dar a todo el mundo un poco más. Mi equipo ha tenido más libertad (han trabajado prácticamente 4 de cada 5 días en casa) sin ninguna presión de fechas, viendo pocos cambios de rumbo a pesar de los bandazos que ha pegado el barco. He sido muy paciente con la falta de comunicación y sobre todo de "este error no es mío, lo debes de estar haciendo tú mal" y las pruebas.

Pero también he asumido responsabilidades que caían en el lado del cliente, como el seguimiento de todo el proyecto y no exclusivamente de nuestra parte, como asistir a reuniones, apoyo técnico. Incluso responsabilidades en el lado del socio del cliente, como asumir sus retrasos, la comunicación o participar en el diseño del futuro CAU.

Todo esto ha estado suponiendo más pelotas en el tejado de mi empresa, al fin y al cabo el tiempo que dedico a estas tareas no pagadas es tiempo que no dedico a mis tareas sí pagadas. Y evidentemente también ha estado suponiendo más pelotas en mi tejado, más carga de trabajo para mí, que se ha visto traducida en más presión y más horas realizadas.

Sí, ha sido un efecto negativo previsto y voluntariamente aceptado, que me ha ayudado a ver nuevas cosas, a organizarme mejor, a dar más de mí mismo… pero llegó un momento en el que literal y físicamente no podía más.

Así que llegado el momento límite, o explotas, o corriges los desajustes, de la única forma posible : haciendo únicamente tus tareas en el tiempo del que dispones. Y es cuando pasa lo que le decía a Toñi : pareces un ogro vago.

La libertad se confunde con libertinaje, los favores con obligaciones, las facilidades con derechos, las sobrecargas de trabajo del pasado se toman como mínimo para el futuro, ocurriendo lo mismo con los costes (literalmente he oído "si este proyecto costó X, pues una ampliación del 10% debería costar el 10% de X"; pasa igual con el trabajo, convoca la reunión como hiciste la semana pasada, habla con esta persona que ya le conoces…).

A partir de ahora tendré más en cuenta estas frases tan oportunas :

Favor olvidado, ni agradecido ni pagado.

Involucrarse y ayudar sí. Nunca convertir los problemas de nuestros clientes en nuestros problemas.

Más errores nuevos cometidos, más errores sobre los que mejorar.

Foto

• Too much work makes Andy a dull boy