Bienvenido al Mundo Real (TM).

A los electricistas les jode que los llamen para cambiar un enchufe y terminen estando dos días arreglando cosas.

A los fontaneros que los llamen para solucionar un "ligero escape" que requiere cambiar media instalación de tubos.

A los constructores que llege el pavo de turno y le diga que las puertas esas no le gustan.

A los mecánicos de coches que te lo traigo hoy pero me lo llevo reparado ayer.

A los médicos tener que dedicar 1 minuto cuando lo deseable serían 30.

A los astronautas cagar dentro del traje con un tubo metido en el culo.

A los ricos el aburrirse sin tener que hacer nada.

A los tontos porque son tontos y no se enteran de nada.

A los listos porque son listos y se enteran de todo.

Es la vida real tío, eso que te pasa no es nada comparado con lo que les pasa a otros.

Pues si te sirve de consuelo hay muchos en la misma situación, incluso en situaciones mucho peores. En todo grupo de trabajo tiene que haber algo como "el jefe de proyecto" que dice joserra, que no tiene que ser el tio que se toma los cafes con los clientes sino el encargado de gestionar todo lo referente al estado del proyecto, y lo tiene que hacer desde el punto de vista de gestión de proyectos y desde el punto de vista TECNICO, que es lo que se suele olvidar, yo creo firmemente que alguien sin profundos conocimientos tecnicos no puede dirigir proyectos de desarrollo de software. Quizas en grupos de desarrollo muy grandes pueda haber dos figuras, un jefe de proyecto más enfocado a la gestión y otro enfocado a la parte tecnica, pero en proyectos pequeños con uno sólo basta y tiene que saber hacer las dos cosas.

Nosotros seguimos fallando en muchos puntos, pero creo que algo hemos aprendido, algunos consejillos por si te sirven:

- JAMAS y digo JAMAS, desarrolleis herramientas propias para gestionar los proyectos. Usar herramientas existentes que hay muchas y algunas gratuitas, si teneis tiempo libre dedicaros a investigar tecnologías que puedan aportar valor a los programas que haceis para vender a vuestros clientes, pero no inviertais tiempo y esfuerzo en crear herramientas que ya existen y seguro que serán mejores que lo que vosotros podais hacer (no es porque no seais buenos, es por pura lógica, no podeis competir echandole cuatro ratos con herramientas que tienen en muchos casos años de desarrollo y por expertos en la materia). Si no encontrais nada gratuito buscar opciones comerciales, es un dinero bien invertido.

- Usar un control de versiones es simplemente obligatorio en cualquier proyecto, empezar a usar SVN (u otro, eso a gusto del consumidor) YA MISMO. Y no lo useis a lo loco, definir un protocolos de cuando subir el código, como poner los comentarios, cuando hacer un tag, cuando hacer un branch, etc,etc. La herramienta por si sóla no soluciona los problemas si no se usa de forma coherente.

- Usar un bugtracking y tirar a la basura la herramienta que habeis hecho, sonara radical pero con el tiempo os ahorrara dolores de cabeza. A mi despues de probar varios me gusta especialmente JIRA, es de pago si, pero tampoco es muy caro y merece la pena.

- También podeis usar JIRA como herramienta sencilla de gestión de proyectos (para gestionar un grupo de cuartro debería ser más que suficiente). y de nuevo establecer un protocolo, todo el mundo tiene que rellenar al día un comentario con lo que esta haciendo sobre el "ticket" del módulo en el que este trabajando y hay que registrar el tanto por ciento de progreso (podeis empezar con protocolos sencillos y según le cojais el aire irlos mejorando para tener más control).

- Sobre los requisitos, este tema es de lo más delicado y depende mucho del tipo de proyecto y el tipo de cliente que tengais. A mi lo que mejor me funciona para especificar requisitos son definiciones textuales y muchas, muchas capturas de pantalla con prototipos de la aplicación. Los clientes que por lo general no entienden nada de informatica necesitan tener una referencia visual de los requisitos que puedan entender, y para esto los casos de uso NO SIRVEN.

- definir normas de estilo para programar, normas que no se limiten a cuestiones sintacticas sino que queden claras determinadas cosas como:
   - tamaño maximo de los métodos y clases (por ejemplo en java 30 y 1000 lineas respectivamente es lo que yo uso)
   - tratamiento de excepciones (aqui hay muchas opiniones, pero es crucial que el tratamiento de excepciones siga unas normas coherentes en toda la aplicación)
    - que todo el mundo se lea el Code Complete
utilizar una herramienta que os garantize que vuestro código cumple las normas de estilo y "cante"cuando alguien no las cumpla, por ejemplo en java teneis checkstyle o pmd ambas más que recomendables.
   
- Compilación de vuestros productos sin usar el boton del IDE. si usais java con ANT, .net con NANT, c++ con make. Vuestros proyectos se tienen que poder bajar del sistema de control de versiones y generar todos los ejecutables, instaladores etc,etc con un sólo comando. Si podeis también es util un sistema de integración continua (tipo cruise control), si no al menos que la integración sea "frecuente", vamos compilar el producto completo una vez al día minimo y pasar los test.

- Hacer test unitarios, y hacerlos bien, es decir probando los métodos de forma aislada usando objetos mock si es necesario (esto requiere investigación y experiencia que es bastante más complejo de lo que parece, pero merece la pena con creces).

Yo hace dos o tres años (llevo 6 en este mundillo) ni sabia que eran la mitad de estas cosas, pero precisamente el estar en un entorno de trabajo desorganizado me hizo replantearme las cosas y buscar herramientas y tecnicas para mejorar nuestra forma de trabajo, en mi caso particular al menos todo lo que te comento nos ha sido de gran utilidad, ahora veo como haciamos las cosas hace dos o tres años y se me ponen los pelos de punta...

Gracias a los tres por vuestras contestaciones, rfog realmente me dio con el salvavidas en la cabeza y me fui hundiendo..... pero también me sirvió para ver que en el fondo había muchos como yo, algo muy importante, por lo menos para mi salud mental.

En cuanto a lo del jefe de proyecto, pues si que lo hay, y ¿a que no sabéis quien es?, pues yo mismamente. Cual es el problema, que también soy uno de los desarrolladores y el tiempo es limitado, y veo que para tener un control férreo sobre los proyectos, que so se vayan de las manos, etc.. se necesita tiempo. En la empresa se planteo la posibilidad de contratar a una persona exclusivamente para este puesto, ser el analista de los proyectos y el jefe de los mismos, pero mi postura fue radical y tajante, no lo creía oportuno, ya que creo que esa figura debe de ser como bien dice rastafari, muy conocedora de muchas cosas, tanto a nivel de gestión, como se hace algo, a nivel de conocimientos de gestión, que es caso del 90% de los clientes o aplicaciones que desarrollamos, como tener un nivel alto de conocimientos de programación, ya que puede ser que lo que te piden sea directamente imposible de desarrollar, y a nivel comercial y de decisión, ya que debe de ser capaz de decidir de forma rápida si una especificación o un cambio de un cliente se hace o no.

Rastafari, tiene toda la razón en lo que dice, realmente estoy dando pasos para que todo se haga de una manera mas formal, con respecto al código es algo que ya hacemos, ya que tenemos un “libro� de estilo, sobre el nombre de las variables, la tabulación o espaciado del código, nombre de procedimientos, etc… para que si cojo el código de un compañero no tenga que pasarme 3 horas para ver y saber lo que quería hacer.

A partir de aquí quisiera abrir un hilo de conversación diferente que creare en otro post, pero lo anticipo. Tengo otro problema, y en un blog vi el cielo al ver que hablaban de ello, y es como decir que no a los clientes. ( http://www.kilex.org/blog/2006/02/18/qu … -decir-no/  ) Tengo ese problema y me doy cuenta de que tras hacer análisis, hablar, requetehablar y volver a hablar una vez echa una parte de la aplicación, montarla y decirte el cliente: “Ya pero y esto como lo hacemos ahora, porque claro, si esto no podemos hacer tal cosa, etc…..â€?, ¡¡¡ PERO QUE ME ESTAS CONTANDO !!!, la primera vez que oigo algo parecido pero si eso no lo hace y mira las especificaciones, mira tal, mira esto otro, y contestar el muy jodio, “pues entonces no me vale nadaâ€?, Ahhhhh, que hacer en ese caso?????

Por si no lo he dicho muchas gracias por los comentarios, me han servido de mucho.

Giskard dijo:

En cuanto a lo del jefe de proyecto, pues si que lo hay, y ¿a que no sabéis quien es?, pues yo mismamente. Cual es el problema, que también soy uno de los desarrolladores y el tiempo es limitado, y veo que para tener un control férreo sobre los proyectos, que so se vayan de las manos, etc.. se necesita tiempo. En la empresa se planteo la posibilidad de contratar a una persona exclusivamente para este puesto,

Entonces a lo mejor la solución no es que se contrate a un jefe de proyecto, sino que tú asumas realmente esa función y lo que se contrate sea un programador para descargarte a tí de trabajo.

Giskard dijo:

Tengo ese problema y me doy cuenta de que tras hacer análisis, hablar, requetehablar y volver a hablar una vez echa una parte de la aplicación, montarla y decirte el cliente: “Ya pero y esto como lo hacemos ahora, porque claro, si esto no podemos hacer tal cosa, etc…..�?, ¡¡¡ PERO QUE ME ESTAS CONTANDO !!!, la primera vez que oigo algo parecido pero si eso no lo hace y mira las especificaciones, mira tal, mira esto otro, y contestar el muy jodio, “pues entonces no me vale nada�?, Ahhhhh, que hacer en ese caso?????

La solución a eso es el desarrollo iterativo.

Un saludo.

El desarrollo iterativo se puede hacer igualmente independientemente de como factures al clente. En tu caso empiezas cerrando una serie de requisitos y pactando un precio, posteriormente en tu analisis lo que haces es dividir el desarrollo en iteraciones, genralmente colocando los requisitos con más riesgo primero, o bien aquellos requisitos que sean bloqueantes para otros desarrollos (si no hago el insertar en la bd no puedo empezar con el borrar). Lo que ocurre es que tampoco merece la pena planificar veinte iteraciones porque a la tercera como mucho tardar ya estará descuadrado todo el planning, mi consejo es que hagas una valoración global del tiempo que llevaría el proyecto y luego planees las 3 o 4 primeras iteraciones ya de forma más exahustiva, el resto ya se ira viendo, si cuando vas por la tercera todo sigue según el plan (que sería cosa rara) planteate ir planeando nuevas iteraciones, y si te han cambiado ya la mitad de los requisitos (lo normal) pues por lo menos no has perdido tantas horas planeando iteraciones a las que nunca llegaras. Hay que tener claro que tratar de cumplir un plazo firmado sobre unos requisitos que varian a cada paso es sencillamente imposible, como mucho puedes buscar la forma de desperdiciar el menor tiempo posible, pero el problema es el propio plantemiento de lo que se esta vendiendo, y eso no hay metodología que lo arregle.

Una cosa importante es marcarse las etapas más cortas posibles (un par de semanas suele estar bien) y ir enseñandole al cliente el proyecto, de este modo ganas margen de reacción cuando te pidan cambios. Es fundamental que el cliente se implique en este proceso y le dedique tiempo a ir verificando el desarrollo. La realidad es que los clientes quieren firmar un presupuesto y olvidarse hasta el día de la entrega final, cierto, pera la realidad también es que cuando esto pasa los proyectos por lo general son un desastre. Al final el tiempo inicial se dispara, el cliente esta descontento y la empresa desarrolladora a invertido mucho más tiempo del deseable en el desarrollo, y eso sin mencionar al pobre desarrollador que acaba quemado y preguntandose porque no se dedico a prepararse las oposiciones de controlador aereo, a la cria del champiñon o a cualquier otra actividad menos frustrante.

El módelo de vender productos cerrados cuando lo que en realidad se necesita es un proyecto que se vaya adaptando a las circunstancias del cliente es algo que espero que el tiempo y las malas experiencias de los clientes terminen por enterrar algún día. Hay otros módelos mucho mejores, por ejemplo cobrar por el valor que tu producto aporta al cliente, te pongo un ejemplo, tenemos un proyecto con un banco para procesar una serie de expedientes (digitalizarlos, enviarlos a la central donde pasan por un worflow con varios revisores etc,etc), en este caso se cobro un precio por la instalación y puesta en marcha inicial y posteriormente se acordo un precio por expediente procesado, cuanto mejor sea nuestro producto más expedientes decidira el banco procesar con nuestro sistema y más dinero ganará mi empresa, en este caso cliente y proveedor están alineados en los objetivos, y esto es lo mejor que le puede pasar a un proyecto.

Otro ejemplo más muy tipico en las empresas que desarrollan OCR's, lo que hacen es cobrarte por documento procesado dandote unos niveles de fiabilidad, de modo que tu les compras un "paquete" de digamos un millon de documentos y cuando se te acaba les compras otro, y si el producto no cumple las expectativas pues te vas a otro proveedor. De este modo la empresa proveedora se preocupara por entregar el mejor producto posible, ya que en ello le va su exito o fracaso.