nunca os ha pasado?

Visto 0 veces
Saltar al primer mensaje no leído

Javier Loureiro

no leída,
26 may 2008, 6:53:5526/5/08
a code...@googlegroups.com
hoy comento en el artículo algo que estuvimos hablando este fin de
semana varios colegas, sobre lo dificil que se hace ver los límites de
los programas que hacemos. Y muchas veces nos pasa a todos. Seguro que
podeis contar muchos ejemplos parecidos que os ocurren diariamente.

Manolo Padron Martinez

no leída,
26 may 2008, 6:59:0726/5/08
a code...@googlegroups.com
Mas que no ver los límites de los programas que hacemos, al menos en mi caso, lo que me pasa es que donde yo puse los limites originalmente se va moviendo con el paso del tiempo y al final no acabas la aplicación nunca.

A lo que me refiero en concreto es a eso de los "requisitos cambiantes" que cada vez me mata mas.... "Hemos llegado a acuerdo? es esto? seguro que es esto y no quieres esto otro?", dos meses despues, "Bueno ahora que me gusta como ha quedado todo porque no le añades aquella otra cosa que te dije que no, total a ti no te cuesta nada" (ARGHHHHHH)

Seguro que mas de uno ha pasado por esto y se ha visto al dia siguiente con la escopeta y matando a todo bicho viviente que aparezca por al oficina ;D

Saludos desde las islas

Manuel Padrón Martínez

Javier Loureiro

no leída,
26 may 2008, 7:55:1926/5/08
a code...@googlegroups.com
Totalmente deacuerdo. Otra cosa que no tiene límites: el desarrollo
de aplicaciones. Una casa, sabemos cuando está terminada, un coche,
sabemos cuando está terminado... pero una aplicación? siempre hay que
meter cosas nuevas... y cuando algo funciona, siempre ocurren nuevos
usos que darle a esa nueva característica, que precisa de nuevos
desarrollos. Y después tienes que escuchar "eso no está acabado"... que
hay que tragarse con resignación.

Manolo Padron Martinez escribió:

J.Manuel Marin - gyakoo

no leída,
27 may 2008, 6:21:4927/5/08
a codepixel
Es que es muy difícil cerrar el código. Puedes decir que esto está
acabado, ¿pero cerrado?.
Eso involucra al tema de los pequeños detalles, los cuales son
infravalorados casi siempre al comienzo de los proyectos.
Ni que decir tiene, que son estos pequeños detalles en los que luego
el cliente más se fija. Puedes decirle que el motor de inferencia del
negocio de seguros está funcionando bien (núcleo del proyecto, que ha
llevado el grueso del tiempo y de recursos...), pero el cliente
siempre te dirá, "¿La tabla esa puede tener 3 columnas en lugar de 4?"
ó "quiero que pueda meter los datos desde esta pantalla no desde la
otra"... Y mientras no se acaben estos detalles, el proyecto no estará
acabado.

También me lleva a pensar, que luego los clientes, quieren pequeños
cambios (pequeños para ellos) y no comprenden qué repercusiones puede
tener. O no quieren comprender.

Pero vamos, qué os voy a contar, esto no es solo de libro de
Ingeniería Software, sino que por desgracia es el día a día.

Saludos

Jesús de Santos García

no leída,
27 may 2008, 6:52:1427/5/08
a code...@googlegroups.com
Para mi hay algunas piezas claves que ayudan a solucionar el problema. Un problema que para mi no es inherente al software sino que es un problema de inmadurez de esta ingenieria.

Por un lado de cara al cliente, el cliente siempre lleva la razón, con lo cual no quedan mas narices que decir lo que dice. Eso es asi, pero hay que dar tiempos de verdad y no tiempos que suenen bien al cliente. Por desgracia esto es dificil de conseguir, porque muchas veces la empresa necesita el dinero del cliente.

Por otro lado esta el desarrollo interno de la empresa. Aqui hay dos elementos claves importantes: escribir las especificaciones de lo que se quiere hacer. Y sobre esto hay mucho escrito. Y mucho mas importante aun, algo que es dificil de encontrar en empresas que no sean serias: los tiempos los ponen los programadores o la persona encargada de hacer la parte que se esta midiendo. Cuantas veces habre visto el error de un manager presionando a un programador para que cambie los tiempos. Es muy dificil encontrar buenos jefes de proyectos, esos que te cubren y respetan tus tiempos y que luchan por su verdadero objetivo: conseguir que el producto este a tiempo sin horas extras. :)

Bueno, esa es mi opnión... :)

2008/5/27 J.Manuel Marin - gyakoo <gya...@gmail.com>:

Ramon Boza

no leída,
27 may 2008, 7:53:0927/5/08
a code...@googlegroups.com
Creo que el culpable está en tu mensaje.

"total, a ti no te cuesta nada"

más vale sobreestimar el proyecto, que se queden contentos pero que no acaben pidiendo las mil y una, como si su dinero lo cubriera todo !!!

En mitad de un proyecto, según se van presentando las betas con sus respectivos tests siempre dice el cliente, mmm me podríais implementar esto en un ejecutable que lo vaya utilizando, debería penarse !!!

O subproyectos que para el cliente son tremendamente sencillos y lo podrían realizar ellos pero te contratan a ti no se por que extraña razón.

Donde trabajo tenemos una frase que una vez nos dijo un cliente, estubo llamando a toda la empresa para intentar sacar la información de como realizarlo, un proyecto que normalmente puede costar unos 6000 -> 15000 euros dependiendo de la funcionalidad que se quiera incorporar, pero para el cliente era sota-caballo-rey, fácil y sencillo, pero no sabían por donde empezar.

2008/5/26 Manolo Padron Martinez <mano...@gmail.com>:

Alfonso García

no leída,
27 may 2008, 8:07:1327/5/08
a code...@googlegroups.com
Yo creo que el problema es que hay una clara contradicción entre teoría y práctica, económicamente hablando:

En teoría,  un buen jefe de proyecto como bien dice Jesús debe saber ajustar bien el trabajo para siguiendo unas estimaciones óptimas, satisfacer al cliente, no putear a su equipo, y que el dinero asignado al proyecto termine en los bolsillos.

En la práctica, el buen jefe de proyecto es el que termina su proyecto antes y con menos recursos. Menos recursos implica menos mano de obra, ahorrar más dinero, y por tanto más horas extras.

Se da prioridad al dinero frente al ARTE de la programación.

No es un problema exclusivo de nuestro sector, pero quizá sí que sea donde más se manifiesta.


Un saludo!

javier loureiro

no leída,
28 may 2008, 16:15:4228/5/08
a code...@googlegroups.com

para mi, todo eso de la organización del tiempo me parece algo
realmente complicado. Lo normal es que necesitemos el doble de recursos,
el doble de tiempo, etc.

Pero por otro lado, eso significa el doble de gente, y el doble de
pasta... y yo a veces pienso... de donde sacan el dinero? porque
programas, la mayoria piratillas, las pelis, todos se la bajan del
torrent... juegos... pues para que pages el online, anda que no hay que
tener un juegazo... cree que a la larga se van consiguiendo cosas, pero
me parece tan dificil.... por no decir imposible. Al final, hay que
ajustarse a un presupuesto, a un plan de produccion, e inebitablemente,
surgen errores de calculo, problemas no previstos...

Alfonso García

no leída,
29 may 2008, 2:59:1429/5/08
a code...@googlegroups.com
El problema no es que no se saque dinero para pagar todo el software.
Una cárnica por ejemplo (eh! con cariño a todos los consultores ;)
suele firmar contratos de mucho dinero (más que de sobra) que bien
cubren las necesidades de desarrollo a nivel de equipación,
producción, etc.

El problema es que ese dinero se destina a mejores usos
(bolsillos de pantalón de tela fina, cosidos normalmente a la pierna
de alguien por encima en tu jerarquía profesional) y se usan licencias
de modo turbio para reducir costes.

Es uno de los problemas de no usar software libre. (Bien por
obligación, bien por negligencia)

Y totalmente de acuerdo en que siempre surgirán problemas en un
plan de producción, esto es inevitable y en teoría la experiencia
dirigiendo proyectos similares anteriormente debería tener esto en
cuenta y gestionar el tiempo incluyendo la resolución de los
problemas que te vas encontrando. En Ingeniería del Software
se estudia esto también.
Aunque de ahí a la realidad... qué os voy a contar que no sepáis...

Salu2!


2008/5/28 javier loureiro <dere...@derethor.net>:
Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos