Archive for the ‘Requisitos’ Category

Aceptando el reto

Jueves, Marzo 19th, 2015

Recientemente iniciamos un proyecto para un cliente estadounidense. Nuestro cliente quería un sitio web en el que se incluyera un componente de donaciones para una asociación civil sin fines de lucro, por lo que el presupuesto era muy ajustado. Adicional a esto, el cliente necesitaba que el sitio estuviera operando para inicios del año, lo que nos dejaba un calendario muy ajustado para terminar. La fecha de entrega no era negociable porque ya se había publicado la fecha del inicio del concurso que recaudaría los fondos y cada día que fuera entregado tarde el sitio representaba una pérdida en el potencial de recaudación.

shutterstock_7861366.jpg

Previo al proyecto

El cliente en EUA de primera instancia buscó compañías en ese país para que le hicieran el trabajo, pero con el presupuesto reducido y, sobre todo con el calendario tan apretado, tres compañías le rechazaron el proyecto. Posteriormente encontró un par de compañías basadas en India que accedieron a hacer el sitio por el presupuesto ofrecido, pero ninguna de las dos compañías ofrecieron terminarlo a tiempo, de hecho, ambas coincidieron en que lo podrían hacer en el doble del tiempo presupuestado.

Finalmente buscaron en México y siendo nosotros socios comerciales en proyectos pasados nos solicitaron la implementación. Revisamos la factibilidad y decidimos abordar el proyecto pero con una metodología ágil en la cual redujéramos algunos costos. La propuesta fue aceptada e iniciamos el proyecto.

Factores de riesgo

Adicional a la metodología ágil, otra estrategia que implementamos para reducir el costo fue conseguir personal externo a nuestra compañía que hiciera el trabajo con un precio por debajo de nuestro propio costo y buscamos personal en entidades socioeconómicas de menor nivel (fuera de la ciudad de Monterrey) y con los conocimientos técnicos para hacer la tarea.

Entrevistamos a algunos individuos y finalmente contratamos a dos de ellos en una ciudad a más de 2,000 kilómetros de distancia.

shutterstock_98130041.jpg

El proyecto involucraba el desarrollo sobre un Sistema Administrador de Contenido (Content Management System o CMS ó por sus siglas en inglés) que nuestro equipo nunca había utilizado y también involucraba la interacción con una entidad para la recepción de donaciones de manera segura, cosa que tampoco habíamos implementado antes.

Todo esto preparaba una atmósfera de riesgo adicional en el proyecto sin embargo decidimos tomar el reto con el afán de dar el servicio y con la expectativa de hacer algo que otros no habían querido hacer.

Las fiestas decembrinas, el fin de año, el equipo de trabajo a distancia, la metodología ágil, el presupuesto cerrado del proyecto, la fecha agresiva de entrega del proyecto y la tecnología que nuestro equipo no dominaba eran riesgos evaluados pero no poco considerables.

La ejecución del proyecto

En las primeras fases todo parecía ir bien hasta que solicité ver físicamente los entregables, empezamos a notar que no estaba todo lo que los externos decían que iban a completar. El líder de los externos empezó a postergar entregables de un sprint a otros posteriores y lo que fuimos recibiendo eran entregables incompletos.

Hicimos la primer presentación del avance al cliente de manera exitosa indicando que postergaríamos algunos de los entregables para una presentación posterior y el cliente aceptó.

Llegaron las festividades decembrinas y por un tiempo no recibimos avances considerables. El equipo externo estaba localizable, pero los entregables no se completaban. Establecimos una estructura de revisiones más cercanas que el equipo externo no pudo cumplir ya que no tenían siquiera una estructura de trabajo formal.

shutterstock_20302609.jpg

En subsecuentes revisiones con el cliente, éste se mostró preocupado por el escaso avance y empezó a cuestionar nuestra capacidad de entrega del producto a tiempo, por lo que me vi forzado a tomar por completo el control del equipo externo aún cuando su líder se resistía a ser administrado.

Iniciamos juntas diarias con el equipo remoto y establecimos metas claras diariamente para ir concluyendo cada uno de los entregables. También concentré al equipo en pocas actividades de alto valor, esto nos permitió ir acabando lo más importante aún que fueran pocos entregables y evitar tener muchos medios avances.

Agregué un equipo de pruebas que no era de ingenieros de pruebas (QA Testers), sino un equipo de desarrolladores de sistemas que empezaron a probar cada uno de los entregables que a su vez el equipo de externos iba produciendo. Esta decisión tenía tres objetivos: 1) reducir el tiempo del ciclo entrega-testing-documentación-remediación-entrega, 2) involucrar a nuestro personal técnico en la solución desarrollada, para que pudiera hacerse cargo de algunas partes del desarrollo del sitio en un momento dado, y 3) para que nuestro equipo apoyara en la remediación de algunos defectos, de tal forma que redujéramos la cantidad de trabajo enviada a los externos para remediación.

Continuamos con las revisiones diarias que a la vuelta de las semanas se volvieron muy cansadas ya que no permitíamos que el equipo se fuera a descansar sin concluir las metas propuestas por ellos mismos en el día. Debido a algunos problemas de actitud que el equipo de externos tenía, las revisiones se volvieron tortuosas, sin embargo para mediados del mes de enero, muy cerca ya de la fecha de entrega, declaramos como terminado todo el sitio y solo quedaron algunas actividades de pruebas y remediación de errores.

Las pruebas finales

shutterstock_56950768.jpgHacia el fin del proyecto invitamos al cliente a entrar al sitio para que validara toda la funcionalidad, el accedió e invitó a tres integrantes de su empresa para probar el sistema. Nosotros les compartimos el acceso a una herramienta para el reporte y seguimiento de los errores encontrados y en ese sistema ellos fueron capturando cada problema encontrado. Nuestro equipo revisaba la lista de problemas encontrados y priorizaba  su atención, asignaba cada problema a un responsable de desarrollo e iba remediando cada problema y probando que hubiera quedando resuelto. De esta manera proporcionamos un entorno muy visual y transparente del avance en la resolución de problemas encontrados.

La entrega

El sitio lo terminamos dos semanas antes de la fecha final de entrega y esas dos últimas semanas el cliente estuvo revisando y reportando problemas mientras nuestro equipo los resolvía. El día previo a la fecha final de entrega, alrededor de las 7:30pm terminamos de corregir todos los problemas y el sitio pudo ser anunciado en la prensa local y las donaciones empezaron a entrar al día siguiente.

Hubo algunos cambios que nos solicitó el cliente conforme iba probando el sistema y conforme veía su desempeño, pero gracias a que involucramos a nuestro equipo pudimos hacer internamente lo solicitado sin recurrir a los externos, a quienes ya habíamos liberado con la intención de no volver a contratarlos más.

Conclusión

Nos quedamos con muchas lecciones aprendidas de este proyecto, pero una de las principales es que necesitamos tomar los retos que se nos presentan, pero con una evaluación adecuada de los riesgos y de nuestra capacidad para afrontarlos. Desde luego aprendimos que debemos combinar el menor número de riesgos, por ejemplo, pudimos experimentar con un grupo de externos con los que no habíamos trabajado antes, pero en un proyecto más holgado.

Nuestro cliente quedó sorprendido por nuestra entrega a tiempo con fechas tan agresivas y un presupuesto tan recortado y gracias a eso ya estamos firmando nuevos proyectos con ellos, pero más holgados y en mejores condiciones presupuestales.

Creo que podemos hablar mucho de lo que hacemos, pero cuando nos dan la oportunidad de demostrarlo eso se convierte en el mejor argumento de ventas para nuestro equipo de trabajo. 

shutterstock_76411899.jpg

Una de valor, astucia y coraje

Martes, Enero 20th, 2009

imagen-para-blog-astucia-y-coraje.jpg

Para ser un buen líder de proyecto no basta con hacer las cosas según el manual, también hace falta tener… actitud (”tamaños desos” diría mi abuelita).

Érase una vez un proyecto donde teníamos un líder de proyecto de los que hasta en el kinder sacaban estrellita a diario, todo lo hacía al pie de la letra, en las primera auditorías si hubieran tenido mención honorífica se la daban, todo pintaba color de rosa.

Debo reconocer que las cosas marchaban tan bien que hasta me daban escalofríos. Los primeros síntomas de que las cosas no eran tan ideales, se dieron cuando a la primera semana de retraso para la entrega de requisitos, los responsables de esa entrega convencieron al líder de proyecto de que no era posible cumplir con esas fechas y que necesitaban una semana más, por supuesto que me quede pasmado cuando ante ese movimiento en tiempo no planteó ningún ajuste en alcance o recursos.

La situación comenzó a ponerse preocupante cuando al término de esa semana los responsables de los requisitos se cobijaron bajo la influencia del director de la empresa para argumentar que todavía necesitaban dos semanas más para terminar los requisitos, y el líder de proyecto se achicó ante el director y sólo dijo “Sí señor, la fecha de entrega tampoco se mueve”.

El descontento general comenzó cuando pidieron otras dos semanas para terminar los requisitos, ya eran seis semanas de retraso y el líder de proyecto ¡¡¡no hacía nada!!!.

Los responsables de los requisitos seguían tan campantes como si todo marchara sobre ruedas, llegaban a su hora y se iban a su hora, iban por sus 15 minutos de café mañanero, otros 15 minutos de cigarro, otros 15 más para departir con los compañeros de pasillo y alguno hasta aplicó sus dos semanas de vacaciones a pesar del retraso en su entrega.

Vamos, no estoy en contra de algún tiempo para despejarse durante el trabajo, pero el punto es que todos veíamos como se iba acabando el tiempo del proyecto en ese mes y medio de retraso y ellos tan campantes como si las cosas marcharan sobre ruedas.

La cosa estalló cuando notificaron que a pesar del nuevo retraso en la entrega de los requisitos la fecha de liberación del proyecto no se movía, los reclamos por parte del equipo de desarrollo no se hicieron esperar, plantearon que era ilógico, ingenuo e imprudente (claro que con palabras altisonantes) esperar terminar el proyecto en el mismo tiempo y con los mismos recursos pero ahora con ocho semanas de retraso, es decir, se recortó el tiempo y el líder de proyecto nunca planteó ajustes de alcance o recursos. Todo mundo inició negociaciones agresivas para cubrir su espalda, a partir de ahí el ambiente del proyecto no fue el mismo, todas las desveladas posteriores fueron un “regalo especial” del equipo de los requisitos.

Moraleja…

En este caso le faltaron liderazgo, valor y astucia al líder de proyecto para hablar franca y honestamente con el director de la empresa y plantearle que ante cualquier movimiento en una de las tres variables más importantes del proyecto (tiempo, recursos y alcance) se deben ajustar una o las dos restantes. También le faltó tomar las medidas necesarias para lograr que el equipo de requisitos cumpliera con su objetivo en la fecha necesaria. Lograr esto es todo un arte y la forma en que se logra tiene que ver con los distintos tipos de liderazgo que adoptamos.

Como decía al inicio, este fue un ejemplo más donde quedó demostrado que para ser un buen líder de proyecto, no basta con saberse el PMBOK al derecho y al revés, también son necesarios valor, astucia y por supuesto liderazgo.

Por Mentat