Blogia
softinspain

Desarrollando "in situ" (I)

Este es un primer artículo de una serie en los que quiero contar mis experiencias desarrollando en casa del cliente, "in situ".

Los proyectos que desarrollé lo hice como autónomo, no como miembro de una empresa.

Durante unos años trabajé para una empresa, tras lo cual, al ver que el rumbo que tomaba la misma no era el que yo creía como adecuado, decidí dejarla y continuar por mi cuenta, ya tenía experiencia al respecto porque en un periodo anterior ya había estado como "freelance".

Tras dejar la empresa se presentó la posibilidad de trabajar para un antiguo cliente, desarrollándole la versión Windows de una aplicación de MS-DOS que hice. Al mismo tiempo, otro cliente me llamó para que le realizara una gestión, un mini ERP, a medida.

Enseguida me vi en dos proyectos, a la vez, y totalmente diferentes. Uno de ellos era una gestión de documentos, realmente una gestión de los trámites de documentos (una gestoría administrativa) y el otro una gestión de una empresa comercial (un mayorista de informática).

El de la gestoría era (y es) mucho más complejo, porque se pretendía no solamente registrar datos sino hacer un "workflow" para controlar el proceso e ir mejorándolo progresivamente, de hecho gracias a la aplicación la empresa tiene la ISO 9002 sin problemas.

En el del mayorista, la complejidad residía en la cantidad de datos que se trataban y en el tiempo disponible para desarrollarlo, empecé en Agosto de 1.999 y estuvo en funcionamiento en Diciembre... (Aún alucino con lo rápido que se fue) Para diciembre no estuvo terminado al 100%, pero se puso en producción a falta de cosas adicionales, lo que era la actividad diaria estaba cubierta en un 70% y durante los primeros días de enero de 2000 estuvo plenamente funcional el trabajo diario. Respecto a la cantidad de datos, en aquellos tiempos se realizaban alrededor de 300 albaranes diarios, introducidos por un grupo de 10/12 televendedoras.

En el proyecto de la gestoría, al principio trabajaba desde casa, pero las cosas no funcionaban, no avanzaban lo suficiente. Con el mayorista, desde el primer día se trabajo "in situ", con reuniones casi diarias para estudiar la evolución, a poco de empezar se agregó una persona al proyecto, una persona del propio mayorista.

En el tema de la gestoría no funcionaba por culpa mía, por diversos motivos me embarque en soluciones técnicas que al final no sirvieron para nada y sólo fue una pérdida de tiempo para el cliente. Una lección que aprendí.

Tengo que destacar que para que un proyecto de este tipo funcione perfectamente, tiene que haber una implicación al 100% por parte del cliente, tiene que estar supervisando y probando constantemente el producto.

Sin saberlo, en 1999, en el proyecto del mayorista, estuve utilizando una pseudo programación extrema, ya que prácticamente a diario se entregaba al cliente una nueva compilación del programa que se testeaba inmediatamente y se corregía "ipso facto". Con la documentación justa, trabajando con el código. Utilizámos el FreeVCS que se integraba con Delphi para controlar las versiones del código y no "chafarnos" el trabajo. De esa forma conseguimos avanzar mucho, y en la dirección adecuada, lo único que nos faltó fue un set de pruebas, las "unit test", porque compilaciones diarias hacíamos, pruebas en casa del cliente se hacían, y un cliente en el equipo... Pues mas bien al reves, yo formaba parte del cliente. Como dice Joel Spolsky, no hay nada como comerse uno su propia comida.

Trabajar en casa del cliente, tiene sus inconvenientes, pero según mi experiencia, tiene muchas ventajas, sobre todo para el cliente. Todo depende de varios factores:
1) Que el cliente esté dispuesto a "ceder" parte del personal/tiempo para las pruebas.
2) De la "actitud" del desarrollador, debe estar abierto a las sugerencias del cliente.
3) Deben establecerse unos mecanismos de "aprobación" de sugerencias, no todo lo que diga el cliente se va ha hacer, al menos no inmediatamente. Hay que hacerle ver que es mejor utilizar un método para ello. Ya contaré como lo hicimos.
4) Hacer partícipe al cliente de los problemas que surgen, si optamos por ocultarselos, al final se vuelve en nuestra contra.

Fin de la parte 1, continuará ...

1 comentario

rido -

Totalmente de acuerdo, de hecho, estar en contacto con el cliente es una de las mejores prácticas recomedadas de eXtreme Programming !!