#50 Si, es cierto todo lo que dices, los problemas con el soft de la admon no son sólo un problema de mala programación, ni muchísimo menos, la forma de gestionar estos proyectos, la forma de definir los requisitos, la mala comunicación etc,etc tienen mucho que ver con el resultado final.
Pero esto, la comunicación con el cliente (en este caso la admon), el como se transmitan las necesidades etc,etc lo considero parte del trabajo del equipo de desarrollo y de la empresa que ayude tecnologicamente a la admon. Me explico, esto de "me dieron estos requisitos yo los implemento y mi trabajo esta bien echo" no sirve, hay que ir un paso más alla y ser capaz de ayudar al cliente, que es evidente que no sabe hacerlo, a describir sus necesidades. Esto con la admon es cuasi imposible porque piden desarrollos a costo, plazo y alacance fijado, lo que hace que los proveedores de software se laven las manos intenten cumplir con lo que pone en los pliegos y a correr, y los resultados de estas politicas saltan a la vista. La única forma de construir esto decentemente es mediante iteraciones y comunicación cercana entre cliente y equipo de desarrollo, de modo que se hagan entregas cortas (una o dos semanas) y se vayan validando los resultados y cambiando todo lo que sea necesario para al final tener un producto decente, teniendo en cuenta la dificultad (no tecnica, más bien funcional) de estos proyectos pretender que un pliego (que además son para verlos...) se pueda definir los requisitos con exactitud meridiana del proyecto es una absoluta locura que no funciona. Conozco algunas iniciativas y personas dentro de la admon que han intentado una aproximación más ágil a la hora de contratar proyectos con proveedores, pero son pocas y además suelen ser de gente que tiene que luchar contra viento y marea dentro de la propia admon para intentar hacer las cosas bien, que aunque parezca que no, algunos hay que de verdad lo intentan.
En resumen, decia un tio muy listo, en software no hay que hacer lo que el cliente pide, hay que hacer lo que el cliente NECESITA, y casi nunca coincide.
Pero esto, la comunicación con el cliente (en este caso la admon), el como se transmitan las necesidades etc,etc lo considero parte del trabajo del equipo de desarrollo y de la empresa que ayude tecnologicamente a la admon. Me explico, esto de "me dieron estos requisitos yo los implemento y mi trabajo esta bien echo" no sirve, hay que ir un paso más alla y ser capaz de ayudar al cliente, que es evidente que no sabe hacerlo, a describir sus necesidades. Esto con la admon es cuasi imposible porque piden desarrollos a costo, plazo y alacance fijado, lo que hace que los proveedores de software se laven las manos intenten cumplir con lo que pone en los pliegos y a correr, y los resultados de estas politicas saltan a la vista. La única forma de construir esto decentemente es mediante iteraciones y comunicación cercana entre cliente y equipo de desarrollo, de modo que se hagan entregas cortas (una o dos semanas) y se vayan validando los resultados y cambiando todo lo que sea necesario para al final tener un producto decente, teniendo en cuenta la dificultad (no tecnica, más bien funcional) de estos proyectos pretender que un pliego (que además son para verlos...) se pueda definir los requisitos con exactitud meridiana del proyecto es una absoluta locura que no funciona. Conozco algunas iniciativas y personas dentro de la admon que han intentado una aproximación más ágil a la hora de contratar proyectos con proveedores, pero son pocas y además suelen ser de gente que tiene que luchar contra viento y marea dentro de la propia admon para intentar hacer las cosas bien, que aunque parezca que no, algunos hay que de verdad lo intentan.
En resumen, decia un tio muy listo, en software no hay que hacer lo que el cliente pide, hay que hacer lo que el cliente NECESITA, y casi nunca coincide.