como usted mande

[haron]

el cliente siempre tiene la razon.

la mision del programador es hacer lo que el cliente le pida.

es decir, que si el cliente quiere un formulario rojo que cuando pase el raton por encima baile la 'lambada', asi se hara, aunque no tenga ni pies ni cabeza...

he trabajado con personas que piensan que la funcion del programador es esta, hacer lo que el cliente le pida.

crees que es asi?

[Viet]

Estoy totalmente en desacuerdo.

En principio, tienes que aceptar que nosotros hemos estudiado Ingeniería en Informática (por lo menos en mi caso) lo que equivale a realizar una eficiente administración de la información, y una mejora de los procesos en los que intervenimos. Ya sea esto por medio de herramientas informáticas o por mejoras en otro tipo de actividades de un proceso.

Hay que tener bien en claro que la programación es solo una fase de la producción de un sistema(ya sea total o parcialmente informático). Tambien, y a mi parecer, están el análisis, el diseño y otros. Pero el principal objetivo de estos son:

En el Análisis (y especificación de requerimientos): lo mas importante es entender QUE hace el cliente, y QUE necesita. Osea identificar claramente el proceso que realiza y todos los objetos y actividades que se realizan en este.
Aquí nosotros debemos identificar los cuellos de botella que tiene el proceso actual del cliente y ofrecerle una alternativa que mejore esto, ya sea informatizada o no. Siempre teniendo en claro cual es el OBJETIVO que el proceso del cliente tiene.


Luego en el Diseño, procuramos especificar COMO vamos a realizar las actividades del proceso de la manera mas eficiente posible, ya sea para Performance, Seguridad, Robustez, Simpleza y otros.

Conclusión: A mi me pagan por tratar de mejorar los procesos que realizan mis clientes, por eso si me piden que un Form baile lambada les voy a preguntar por QUE o para QUE, y a lo mejor les diga(con una justificación) que les conviene que baile un buen Tango.


Saludos

[__cadetill]

Bueno

Esto es un tema peliagudo y de dificil decisión

Cuando me he encontrado el caso de que un cliente (lease tambien usuario) de que pide algo "raro", le pregunto siempre las razones (antes de meter la pata discutiendo con él) y, si no lo encuentro lógico o veo que de otra manera sería más sencillo para él, se discute la jugada. Pero, al fin y al cabo, el que tiene que trabajar es el cliente y, realmente, a mi me da igual que el programa (visualmente) haga una cosa u otra. Si es lo que el cliente quiere..... que luego no venga reclamando y, si reclama, pues s le cobra la modificación (por capullo )

Osea, que si el cliente, sea como sea quiere un formulario que le baile la "agarrada", pues se le hace

[marcoszorrilla]

Estamos tocando un tema de lo mas interesante, y es si el cliente sabe lo que quiere, si el cliente y nosotros estamos hablando de lo mismo o el lenguaje es totalmente distinto.

Sino hacemos lo que el cliente encarga, mal lo tenemos.

Un truco a veces suele ser decir que ya tenemos todo prácticamente acabado, normalmente sin haber empezado, verás como nos sale con no sé cuantas cosas que se le han ocurrido u omitido.....

Se aprovecha la ocasión para meterle un poco miedo, no hay problema lo que haga falta cambiar se cambia, claro que el precio subiría.....


Casí siempre se vuelve atrás y dice que no que en realidad se mantenga lo acordado.


Otro tema es cuando hablamos de una Empresa Grande, me refiero a la nuestra, con un equipo amplio, con un contrato, con un adelanto exigible ...... entonces lo acordado y no hay más cualquier modificación incrementará el presupuesto.....


Y si nos sobra el trabajo, pues decimos que no hay "Lambada" y tan frescos.

Un Saludo.

[Iván]

Mi punto de vista es q depende un poco de lo que nos pida el usuario y si lo que nos pide le ayuda realmente en su trabajo diario.

Las pautas del desarrollo las ha de marcar el programador ya que para algo es el técnico.

Si nosotros nos hacemos una casa, igual nos gustaría que no hubiera ninguna columna en toda la casa, pero por motivos X el arquitecto nos indica que es necesaria... Y creo q todos estaríamos de acuerdo en poner la columna si nos advierte el arquitecto q sin ella la casa puede caer...

Así q para mi el que debe llevar la voz cantante es el técnico.

Pero por otra parte, no se debe tener siempre un "NO" como respuesta ante cualquier petición del cliente. Se tiene que estudiar el impacto en el desarrollo, así como los beneficios que puede tener en su trabajo.

Por cierto, en el tema de colores del formulario, lo más fácil es dejar que los pueda configurar.... Eso da pie a ver unas combinaciones de colores de lo más "interesentes"

Un saludo

[haron]

yo estoy totalmente deacuerdo con Viet.

la funcion del equipo de programacion es resolver problemas al cliente, no hacer lo que el cliente les manda.

me imagino algo asi como la consulta de un sicologo.
el paciente va al sicologo porque sabe que tiene un problema (tiene ciertos indicativos que asi se lo confirman).

la funcion del sicologo en este caso es la de administrar un tratamiento que permita a su paciente resolver sus problemas, el paciente no tiene porque decirle como hacer su trabajo, solo puede exponer sus problemas.

muchas veces el paciente tiene dificultades para describir lo que le pasa, por eso a veces insinua al tecnico ciertos metodos que unicamente pretenden ilustrar su verdadero problema.

bueno, pues la cosa es asi y si al cliente no le gusta, que se busque a otro programador.

[andres1569]

Hola:

Como ya se ha comentado, el tema admite cierta flexibilidad.

Estamos hablando, por supuesto, de programación a medida, en la que el cliente recurre a los servicios de un programador autónomo /empresa de software para que le haga una aplicación a su gusto. En los programas estandard, el cliente busca / compara y elige el producto que más le satiasfaga. Pero ese a su gusto significa que la aplicación debe tratar de conseguir los objetivos que el cliente desea (siempre que no vayan contra ciertos códigos deontológicos, léase programas con fines sospechosos, que un programador puede negarse a hacer), pero no afecta a la manera de hacerlo.

Donde el cliente no debería intervenir es en el cómo se realiza ese programa, esa es la parte técnica que se le supone al programador. Sólo faltaba que nos pidieran cómo tenemos que enfocar el esquema relacional de la BD, por poner un ejemplo. Y digo esto porque si luego el programa falla o tiene algún tipo de limitación derivada de un mal diseño, es al programador / empresa soft a quien corresponde la responsabilidad de los posibles errores, ahí no vale decir "es que usted me pidió hacer esto de esta manera". El profesional debe imponerse en lo que es su parcela. Esto incluye también el asesorar e incluso advertir al cliente de las inconveniencias de algunos de sus requisitos.

Si uno se encuentra con un cliente "listillo", de esos que saben más que tú, pues se le invita a que haga él el programa, a la vez que ahorra costes a su empresa. Si no es así, se usa la diplomacia, frases como "esto es informáticamente imposible" (lo siento, ya sé que casi todo es posible), o sencillamente "esto aumentará considerablemente el presupuesto".

De paso decir que lo más fastidia es cuando a uno le piden una modificación, por nimia que parezca, cuando el programa está acabado/semiacabado. Los clientes no suelen entender el enorme trastorno que eso provoca, a veces piensan que eso lo tienes hecho en un periquete y resulta que te desmonta el programa entero.

[chutipascal]

Llevo más de 20 años en esto y las frustraciones que ha tenido viet y muchos otros las he pasado tambien y de vez en cuando las paso de nuevo.
Es inherente a este tipo de trabajo, algunos clientes son tontos rematados del culo (o es lo que nos parece), pero son los que pagan.
Por eso es muy importante definir lo que hara el programa en un papel y rematar diciendo que la presentación, elección de colores etc.. es de nuestra discreción si luego quiere que el informe baile la lambada podras cobrarle el cambio o no combrarselo como compensación por algún fallo tuyo.
El problema principal de todo esto es que en el momento de hablar con el cliente para plasmar las especificaciones o presentar tu trabajo tienes que tener con el una relación igualitaria y esa es la clave del problema, más aún que tus conocimientos tecnicos.
En psicologia, cuando dos personas mantienen una conversación se puede dar el caso de que una domine a la otra y se estable una relacion de mayor<->menor, el empresario o directivo, faltaria más, esta acostumbrado a que todos sus empleados le complazcan y tiene un Audi aparcado en la puerta y ya que te contrata usa la función imperativa del lenguage en las comunicaciones contigo. Tu te siente como un gusano que se arrastra por la tierra mientras el te imparte ordenes (además apenas conoces al tio y te falta sangre en la cara porque a fallado una de las cosas que acabas de instalar) ademas tu tienes un Ford Fiesta oxidado del 81' aparcado en la ORA y te falta 30 minutos para ir a tener que cambiar el ticket.
Ese es el problema no se trata de ir a verlo con sentimientos de superioridad (¡que los tendras cuando salgas de casa del cliente!) sino de mantener un equilibrio de confianza en el cual el cliente pueda expresar sus opiniones y ambos admitir sus errores. Consejo: dejalo hablar primero hasta que se canse, luego toma punto por punto lo que ha dicho para rebatirlo o confirmarlo en tono amistoso (seguro que tiene buenas ideas y conceptos originales) y sobre todo tienes que dejar una salida a tu cliente si le niegas una cosa accepta otra a cambio.
A pesar de que la experiencia te cura de todo esto tengo que reconocer que me sigue pasando (en menor medida) pero ya no encuentro al cliente tonto rematado del culo y que es increible que haya hecho dinero, me consuelo en saber que soy más selectivo con la elección de clientes y que a un buen puñado de 'impresentables empresarios' no he querido hacerles una linea de codigo, pero claro vivo en un pueblo y aqui sabes muy bien quien es serio y quien no.

Un saludo.

[andres1569]

Como apunta Chutipascal, la psicología es muy importante, en todas las facetas por supuesto, pero sobretodo a la hora de tratar con esos clientes que creen que llevan la voz cantante porque ellos pagan.

En efecto, hay que entablar relaciones en términos de igualdad, si no te comen vivo. Ellos aportan el dinero, y tú a cambio les haces un trabajo, y en la mayoría de los casos ese dinero seguro que no les ha costado tanto de conseguir como las horas que a tí te lleva hacerles una aplicación (esto no es matemático pero se aproxima bastante). Además, es común que exigan que el programa funcione a la perfección, cosa que no exigen al MS Word, Windows, ...etc, les queda tan lejos llamar a una de estas empresas (como MS) para exponer sus quejas .... Incluso a veces te comes los marrones de dichas herramientas, porque tú se las instalaste.

A veces, plantarle cara a un cliente es lo mejor que podemos hacer, ya habrá tiempo de disculparse si uno se sale de tono, pero ayuda a dejar las cosas claras.

[chutipascal]

No no se trata de plantarle cara y liarse a chillar o a hostias.
El truco es dejar que hable el primero y que te chille si quiere, acepta automaticamente sus frustraciones con; si, si señor, tiene uds razón, su satisfacción es lo primero etc...si has cometido algún fallo no trates de juestificarlo en ese momento dile: tiene Ud. razón es imperdonable. Si te es necesario toma apuntes en ese momento...
Luego cuando ha dicho todo lo que tenia que largarte bajara la guardia y es cuando empiezas a rebatirle punto por punto cada cosa que te dijo, pero siempre sin perder la calma y explicandolo desde tu punto de vista y haciendole ver las implicaciones de cada punto, tienes que hacerle comprender con mucho tacto de que no tiene que ahogarte para poder dejar las puertas abiertas, porque en definitiva tu no quieres traicionar la confianza que el deposita en ti.
Recuerda la ultima posición es la que prevalece no la primera, por eso es importante que no salgas pidando despues de la broca o te lies a chillar como un poseso contra el que es precisamente lo que el piensa que haras: largarte a solucionar el problema o ponerte a chillar (y como juega en casa o peor en la tuya...más cuando otro cliente esta esperando) el se sentira gratificado por la bronca, aguanta el chaparrón y tanto tu como el descubrireis que ambos estais equivocados o que vuestros puntos de vista son distintas pero que se puede llegar a una posición intermedia y eso es beneficioso para ambos y el saldra gratificado porque ha asistido a una reunión donde se solucionan los problemas.

Un saludo.

[Iván]

Una de las mejores formas de aguantar el chaparron de un cliente "no satisfecho" con el resultado del programa, es como dices, aguantando la bronca y luego rebatiendo punto por punto cuando baja la guardia.

Si encima se consigue hacer sin perder en ningún momento la sonrisa y el animo cuando nos critican, y sabiendo aceptar nuestros errores, entonces los tendremos comiendo de nuestra mano en menos que canta un gallo (siempre hay la excepción del cliente borde por naturaleza y q es mas ..... bueno no sigo...).

Pero os lo aconsejo... tened siempre una sonrisa y buen animo en esas situaciones y veréis como es mucho mejor.

Un saludo.

PD: Támpoco hay q pasarse y reirse en la cara del cliente.... támpoco es eso.

[Viet]

Bien... por lo que veo y lo que han dicho ustedes hay dos temas aqui. Uno es negociar con el cliente los requerimientos del sistema, y sus modificaciones o correcciones. Y otro es aconsejar al cliente que es lo que mas le conviene.

Obviamente yo, al igual que todos ustedes, entiendo que el que va a usar el sistema, el que entiende para que lo necesita y sobre todo el que paga es el cliente. Por eso no soy tonto y se que conseguir la satisfaccion de este es lo mas importante. Pero a lo que yo apuntaba era a que no siempre tenemos que tomar a rajatablas lo que el cliente nos indica, sino que debemos, como profecionales de la informatica, acesorarlo para que el tenga la mejor solucion a su problema(el proceso del cual hablaba antes).

Por otro lado, y siguiendo con el tema de la "negociacion" de lo que hemos hecho o estamos por hacer.... en mi caso, siempre me muestro seguro de lo que el cliente me plantea con confirmaciones y luego de confirmar haber entendido lo que necesita(ya sea antes de hacer el producto o bien para hacer alguna correccion) trato de ver con el las complicaciones(tiempo/costo) de realizar cada funcionalidad en el sistema.

De todos modos quiero reafirmar lo que pienso: "no se olviden que sistema no es necesariamente programa, en la mayoria de los casos es mucho mas". He aqui nuestra diferencia

(haron.... es solo una opinion... no lo tomes a mal )

[[gatosoft]]

Yo pienso que se esta enfocando el tema en una solo tipo de persona: el cliente o usuario de la aplicación. y en los diferentes tipos de exigencias que este pueda hacer.

Pero para mi el "problema" o la cuestion es otra:

¿Que significa ser programador?... por lo general en las empresas de desarrollo organizadas, se manejan ciertas estructuras y funciones sugeridas por las metodologías de desarrollo tradicionales, en las que se sugiere que un programador es el último eslabon en una gran cadena, al cual se le entregan los planos de un sistema y este solo se debe limitar a seguirlo, como lo haría un arquitecto con un obrero de construcción.

¿quien le entrega estos planos al programador? No es el cliente que paga por hacer el software o el usuario final... es un grupo de personas que decidieron que este era el camino a segiuir (Analista, diseñador, director de proyecto, etc).

Pero nosotros sabemos que esto asi no funciona, un programador como tal no existe, no existe una persona que reciba unos planos y simplemente los transcriba sin hacer sus propias observaciones.... Nosotros vivimos a diario la situación en la que nosotros somos los analista, diseñadores programadores y hasta directores del proyecto por que sencillamente nos fué asignado solo a nosotros o no existe alguine mas a nuestro alrededor que sepa lo que es construir un sistema.

Aqui en Colombia, a muchos se les vende esa idea....

"Ud. puede ser ing. de sistemas o ing. informático, ud. puede ser Master o Doctor en Computación o lo que sea y no necesita saber programar, por que para eso estan los programadores... usted solo necesita apoartar la idea... y ellos plasman las ideas del genio en el codigo. (je, je)."

Bueno.... esto es imposible, por que aunque el desarrollo de software se compare con la arquitectura o la ing. civil, no es ni medianamente parecido.... se necesita saber construir para poder hacer estimaciones y poder definir un rumbo basados en la tecnología con la que disponemos. si no hemos programado nunca como podemos saber que nos ofrece cierto lenguaje o motor de BD, o metodología de desarrollo?

No quiero decir que para ser director de proyecto o gerente o analista diseñador se necesite ser un duro en programación, pero si se necesita que el programador se un buen analista y buen diseñador, para poder frenar el impetu de esos "visionarios", que creen que todo es "soplar y hacer botellas"

Por lo tanto, esa visión de programador que obedece todo lo que les impongan por que es simplemente un tecnico no es correcta. Quien no este metido de cabeza en el desarrollo, no puede mas que hacer comentarios, sugerencias o exigencias pero para modificaciones mínimas, como un cambio de entorno a apariencia.

Saludos a Todos.

[chutipascal]

Posteado originalmente por gatosoft
¿Que significa ser programador?... por lo general en las empresas de desarrollo organizadas, se manejan ciertas estructuras y funciones sugeridas por las metodologías de desarrollo tradicionales, en las que se sugiere que un programador es el último eslabon en una gran cadena, al cual se le entregan los planos de un sistema y este solo se debe limitar a seguirlo, como lo haría un arquitecto con un obrero de construcción.

Esto es valido en 1% de los casos la gran mayoria de empresas de soft no tienen más de 3 programadores (al menos es lo que hay por aqui). Esa estructura rigida no se da en la practica núnca porque entre otras cosas cargas el trabajo abajo, los directores, analistas etc... solo tienen trabajo al principio del desarrollo por lo que o se les da otra funcion (ventas, prospección, formación, programación) o son personas que tendran una utilidad limitada para la empresa. En cuanto a los planos hay que hacerlos uno mismo, cuando comienzas es una gran desventaja porque solo los haces bien cuando tienes experiencia, de nada sirven los libros sobre metodologia y analisis porque su enfoque es para organizaciones muy grandes. El cliente es la fuente de información más fiable (a pesar de los pesares) porque realmente es el experto en su trabajo y lo que tienes que solucionar es que pueda 'mecanizar' el maximo de tareas posibles que lleva haciendo a mano o con otro programa más tiempo del que tu le has dedicado a pensar en el problema.

Un saludo.

[Delphi Man]

Bueno, yo voy a ser escueto.

Siendo orgulloso, hare lo que crea conveniente dentro de la aplicacion, ahora, siendo objetivo y mirando mi bolsillo, si el cliente quiere que se baile la lambada y lo paga, se baila la lambada. Hasta si paga bien la bailo yo mismo. No hablo de que el cliente tenga la razon sino que el es el que te paga. Si yo voy a una cafeteria y pido una coca cola y me ponen un te porque dicen que la coca cola no me conviene, me importa una m.....a yo voy a pagar mi coca cola y yo quiero mi coca cola.

Un saludo.

[haron]

Bueno, la cuestion de si el cliente siempre tiene la razon, en el fondo surgio de una situacion que se dio en mi empresa y me cabreo mucho, mucho, mucho.

mi empresa estaba estructurada jerarquicamente... bueno, lo mas seguro es que siga estructurada, pero no me importa porque gracias a dios ya no formo parte de ella.

las ordenes vienen de arriba y se trasladan de forma incuestionable hacia abajo.

la cosa surgio porque mi jefe de equipo me dijo que tenia que hacer un formulario con unas formulas determinadas.

habia una formula que no tenia ningun sentido, y pense... "seguro que se han equivocado al darme esta formula, porque no tiene ni pies ni cabeza".

pues todabia no se para que sirve esa formula (de hecho ni siquiera me acuerdo de la formula).

la cuestion es que el jefe tecnico estaba siguiendo a rajatabla lo que el usuario le pedia sin preguntarse para que lo queria.

el problema no era en este caso el usuario, que hara todo lo posible para que le entreguen un software de calidad. el problema era el jefe de proyecto que era un incompetente y que el equipo de trabajo estaba estructurado jerarquicamente.

quizas esta otra pregunta habria sido mas interesante:

¿son efectivas las estructuras de equipo jerarquizadas?

en mi opinion NO.

[guillotmarc]

Hola.

Yo diria que la estructura jerárquica es inevitable. Alguien tiene que responsabilizarse de que se haga el trabajo. A mayor responsabilidad asumida, más alta debe ser su situación en la estructura.

Saludos.

[[gatosoft]]

Es cierto, son inevitables las jerarquias, pero creo que no es del todo correcta tu apreciacion:

"a mayor responsabilidad asumida mas alta su situacion en la estructura"

Hay unos factores intermedios, que llevan a lo mismo, pero son los detonantes...

"a mayor envergadura del trabajo.....mayor número de procesos y personas y por ende a mayor responsabilidad."

Sin embargo, el problema de la jerarquiano no esta en si el "cliente tiene o no la razon", o si "quiere que bailemos lambada" y todo eso... sencillamente esta en la injerencia que tiene cada miembro de la jerarquia sobre la construcción del producto.

¿Hasta que punto un miembro de cualquier lugar superior de la jerarquia puede decidir sobre la forma como se hace el producto?.

Hay que tener en cuenta que desde el punto de vista del programador, todos los sujetos de la piramide, son sus clientes, pero en la mayoria de los casos actuan como creadroes y cleintes al mismo tiempo.

Todo esto es para tener en cuenta....

Saludos.

[haron]

ok

posiblemente cuando el grupo es muy amplio o hay una diferencia entre habilidades o conocimientos en el mismo, de forma natural se establece una jerarquia de trabajo.

quizas el problema no sea la jerarquia en si, sino la aptitud de los responsable.

gracias a todos por vuestras valiosas opiniones.