En la realización de proyectos existen muchos mitos que, por muy expertos que seamos en nuestra área, a veces creemos. Estos generan experiencias tormentosas cuando nos enfrentamos a la realidad. En otras ocasiones no somos nosotros, sino nuestros clientes los que se apoyan en ellos. Trataré de explicar acerca de los mitos del cliente enfocado hacia el desarrollo de software, web y proyectos de tecnología.
Mito del Cliente
Una reunión inicial en la que se exprese el objetivo general de un proyecto, junto a un análisis breve de los detalles importantes, bastará para que mi equipo de trabajo empiece a planificar, estimar y desarrollar el trabajo.
Realidad del Programador
Al no tener una clara definición de los requerimientos del cliente, empezar a desarrollar sus exigencias en la mayoría de casos será una pérdida de tiempo. Antes de cualquier planificación, debemos comprender cada parte, parámetro, componente, etc. del objetivo final. Al comenzar con una lista de requerimientos ambigua, el cambio de algunos de ellos podría destrozar la planificación y afectar las estimaciones de costo o esfuerzo que habíamos previsto.
Fundamentos (enfocado al software):
En el desarrollo de software, la definición de requerimientos es el punto más importante. El éxito del producto dependerá de la comprensión cada uno de ellos por parte del equipo de trabajo. Así es posible planificar una buena estructura de datos, definición de interfaces, comportamiento, validaciones necesarias, etc.
La inclusión de algún requerimiento es crucial, pues algunos de los escenarios en que puede influir son:
- Diseño: Hay que agregar a la interfaz un espacio para la entrada de un dato nuevo que afectará la presentación de la información; afectando también la interfaz de salida.
- Validaciones: La validación de un dato requiere un esfuerzo mayor para cualquier desarrollador de software, pues la fase de pruebas se incrementa, al tener que probar los posibles caminos por los que pasarán los datos. El esfuerzo se incrementa progresivamente dependiendo de las dependencias de los valores.
- Estructura de datos: El diseño de las estructura de datos es algo vital. El ejemplo más claro es el diseño de una Base de Datos. Un nuevo dato puede requerir un rediseño completo en muchos casos, añadiendo incluso más complejidad a la administración desde la aplicación.
- Comportamiento: El cambio puede ser sea tan crucial que provoque la redefinición de una tarea para que se cumpla algún requerimiento en específico. Un nuevo cálculo matemático, por ejemplo, podría necesitarse para generar la información correctamente.
Los clientes se apoyarán de estas creencias si los desarrolladores/trabajadores se los permiten, y esto estará afectado por la comunicación que tienen con ellos, siempre dicen: "No ignores al cliente", pero también hay razones para NO dejar que el cliente te ignore y use esta clase de técnicas y "mitos" a su favor.
Una lectura que puede ampliar este tema está en el libro "Ingeniería de Software. Un Enfoque Práctico", 5ta Edición, del reconocido autor Roger Pressman.
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
Por santos el 03 de Agosto de 2006
Por hernan el 03 de Agosto de 2006
Porque lo haces ver como que cada uno tiene que tener una posición, defenderse y evitar problemas. Cuando lo que uno debería intentar hacer en un proyecto es entender al cliente.
La primera base que no estoy de acuerdo es la siguiente:
Maikel :
El cliente llama a la primera reunión porque no es el experto, y no pretende que eso baste, sino que los guíemos. No sabe calcular ni estimar las bases ni alcances del proyecto, y ciertamente no podrá hacer mucho más que decirnos su problematica y que elementos dispone para solucionarla.
He aquí donde entra la experiencia y dedicación que demos al planeamiento, para ofrecer antes que nada en papel una solución lógica a sus problemas, una guía efectiva, los pasos a seguir. Sino proponemos pasos a seguir, quién lo hará si nosotros somos los expertos. Si quieres más información pidela, si necesitas otra reunión vé a ella. Pero no esperes ellos "solucionen" tus problemas de logistica, porque ciertamente no es su trabajo.
Otra cosa que no estoy muy de acuerdo:
Maikel :
Justamente el plan se hace para diagramar el proyecto, y en él estimarás componentes, parametros, etc. Aunque quizá enfoques a otro lado me gustaría ahondar en este tema.
Siguiendo lo que te comentaba, creo que sería mejor partir al revés, tener un objetivo Final (el cliente te lo pedirá en la reunión, quiero tal cosa). Con ese objetivo, plantear el desarrollo desde un punto de vista lógico y viable, presentar la planificación estratégica al cliente ahorrará tiempo. Porque, sólo un experto puede armar un plan lógico.
Con plan no me refiero a complejos diagramas de datos, y planteos de posibles escenarios. Sino de la interacción de los componentes entre sí para lograr la meta propuesta.
Otra cosa también me parece un poco incompleta es la siguiente:
Maikel :
Esta bien has dado los escenarios que pueden "corromper" tú tiempo, pero sin preocuparte por tú cliente. No has planteado un escenario lógico, sólo tácticos.
O sea algo muy importante a plantear es el porque de cada cosa hacemos, cuando estan los porques, es más equivocar la Estructura de los Datos, o Validaciones Lógicas. Porque la estrategia asegura los elementos, la táctica solo se encarga de llevarlos a la practica.
En fin, el artículo realmente me parece interesante, pero desde un punto de vista táctico pero no para negociar ó tratar el proyecto con el cliente, sino para que otro trate con este y uno sólo programe.
La verdad no quiero extenderme más y ser tan pesado, pero sólo quería darte mi opinión.
Buen aporte
Salu2, Hernán . -
Hernan :
Muchas veces piden presupuestos solo al dar una idea de lo que quiere, y tu muy bien lo sabes
Hernan :
Eso es lo que digo, no podemos estimar con una idea vaga del proyecto, pues lo que realmente saben planificar, estimar costo y esfuerzo es el desarrollador o desarrolladores.
Hernan :
Aqui me das la razon, debemos reunir todos los requerimientos para poder establecer el alcance, hacer planificaciones y estimaciones. Y lo hacemos nosotros, nunca dije que fuera el cliente, lo que enfatizo es que a veces los clientes quieren que uno empiece a planificar y/o estimar con solo una idea del proyecto.
Hernan :
Maikel :
Antes de cualquier planificación, debemos comprender cada parte, parámetro, componente, etc. del objetivo final.
Justamente el plan se hace para diagramar el proyecto, y en él estimarás componentes, parametros, etc. Aunque quizá enfoques a otro lado me gustaría ahondar en este tema.
Siguiendo lo que te comentaba, creo que sería mejor partir al revés, tener un objetivo Final (el cliente te lo pedirá en la reunión, quiero tal cosa). Con ese objetivo, plantear el desarrollo desde un punto de vista lógico y viable, presentar la planificación estratégica al cliente ahorrará tiempo. Porque, sólo un experto puede armar un plan lógico.
Con plan no me refiero a complejos diagramas de datos, y planteos de posibles escenarios. Sino de la interacción de los componentes entre sí para lograr la meta propuesta.
Alli me refiero a comprender todos los requerimientos, antes de hacer cualquier planificacion, por ejemplo como se hara la recuperacion de una contraseña en un sistema de usuarios, si por mail, o del mismo formulario, etc.
Hernan :
Maikel :
Esta bien has dado los escenarios que pueden "corromper" tú tiempo, pero sin preocuparte por tú cliente.
Lo estas viendo como si estuviera en contra del cliente, NO, hernan no es asi! insisto con la compresión de todos los requerimientos podemos sastisfacer todas las necesidades del cliente, y entregarle un proyecto de calidad, que al final es lo que él espera. La inclusión de un nuevo requerimiento corrompe la planificacion, y como digo puede afectar en muchas cosas, que de acuerdo al tiempo estimado que se tenia previsto no sea cumplido, y con eso comenzar de nuevo, perdida de tiempo para el cliente y el desarrollador.
Ojo contadas veces no se puede comprender todos los requerimientos, ejemplo proyectos que implique agentes expertos
Hernan :
mmm, por eso digo debemos crear estrategias para que el cliente no nos ignore
Maikel :
Una reunión inicial en la que se exprese el objetivo general de un proyecto, junto a un análisis breve de los detalles importantes, bastará para que mi equipo de trabajo empiece a planificar, estimar y desarrollar el trabajo.
...dice claramente Mito, y es que, realmente existen clientes que así lo créen.
Tu dices....
hernan :
Aquí creo que estás pre-suponiéndo algo que no se puede generalizar, en el caso de Maikel, según yo (o al menos así lo entiendo) está tratando de explicar los mitos de parte del cliente, como bien lo señala al inicio del artículo.
Maikel :
En lo demás estoy completamente de acuerdo contigo.
Muchas veces piden presupuestos solo al dar una idea de lo que quiere, y tu muy bien lo sabes << Si por eso armó el plan como lo acabo de explicar. No doy un número, sino un plan con un costo.
Eso es lo que digo, no podemos estimar con una idea vaga del proyecto, pues lo que realmente saben planificar, estimar costo y esfuerzo es el desarrollador o desarrolladores. << Idem, para eso es importante armar el plan.
Para hacerla corta y no responder renglón a renglon jejeje, lo que te planteo lo voy a decir con un ejemplo:
Cliente-> QUiero vender en la Web
Yo-> Ok, que productos vende usted?
Cliente-> Vendo Juguetes
Yo-> Ok, en 2 días tiene el plan que estimo necesario
A los dos días entregó un plan de Ecommerce perfectamente diagramado sin estimaciones raras porque las hice yo. El cliente no tiene porque pedirme quiero modulos de programación de este estilo y que valide aca, y tener esto aquí. Generalmente dicen Necesito esto para hacer lo otro.
Ojo, generalmente tardó 1 a 3 horas en una reunión. De hecho para proyectos grandes he estado hasta 12 horas seguidas reunido para comprender los alcances reales del proyecto. Y tardado 2 semanas en armar la planificación correcta. Pero la planificación no falla si uno es el que arma el plan técnico en vez de dejar al cliente eso.
Además tenes que estimar que el cliente salgo igual que tú beneficiado, todo lo que dices la verdad lo estimo como una linda táctica para no andar perdiendo horas en programación pero sin importarme el proyecto ó elcliente. Una estrategia se ocupa del cliente, de la técnica y del futuro del proyecto.
A menos claro, estemos hablando que el mito es de los programadores y no de los clientes. Porque el cliente te reune para que lo GUIES, o sea te sientes y le digas "Señor XXXXXX, por lo que me dice creo que l ocorrecto es seguir así..."
Reitero cambiar el título entonces, porque es el mito de los programadores, no del cliente. El cliente es un ser humano que llama a otro ser vivo para pedir un servicio del cual él no es experto ni le interesa ser, pero que requiere para solventar una problematica.
Si fuera así realmente que los clientes piensan así, sería un caos! Negociar imposible! Simplemente sería dar precios y ya!
No te parece?
Por el 03 de Agosto de 2006
Hernan :
Eso de programacion, estilo y demas, me refiero es al plan de trabajo de los desarrolladores, luego de saber los requerimientos, no es el mismo plan que se le entrega al cliente, NO lo es.
El plan al que tu refieres es otra cosa que aparte tambien va incluido la recoleccion de requerimientos, ejemplo cuando se trabaja enseñandoles prototipos o avances, este plan es al que tu llamas "estrategias".
Por el 03 de Agosto de 2006
Hernan :
Sabes MUY BIEN que algunos si lo creen.
Hernan :
Los programadores tienen otros mitos y no son esos. Estos son del cliente que afectan al programador
Hernan :
Juas!
Bueno, has corrido con mejor suerte, pero éso no es regla general, como te decía hace rato.
Tambien te voy a citar un ejemplo:
Cliente-> Quiero poner una página en la Web
Yo-> Ok, de venta de cosméticos, verdad?
Cliente-> No, quiero vender horóscopos y consultas a guías espirituales, como ésos que te aconsejan como conseguir novio(a), y que me puedan pagar con TC y que se genere automáticamente la respuesta (me dijo que ya tenía alrededor de 200 respuestas diferentes)
Yo-> Ok, en unos días le mando la cotización por escrito.
Cliente->Ok, pero... ¿Cómo cuanto me vá a costar?
Yo-> Pongo cara como de que estoy haciéndo cuentas
Cliente-> Mi presupuesto es de 100 dólares
Yo->Ah ok, entonces le mando el teléfono de varios muchachos que le pueden ayudar mejor que yo
Afirmo: Si hay clientes Idiotas
saludos
Por khafra el 03 de Agosto de 2006
Ya contaban con uno hecho en VB 6.0,
Equipo: recitamos un servidor,
cliente: ya tenemos uno (equipo de escritorio con 1Mb de memoria, con cables salidos por todos lados, y sin )
Equipo: eso no sirve, necesitamos algo más robusto.
cliente: me costo $ 30,000.°°
Equipo: (jajajajajaj!!!!)
DEPUES TERMINAMOS DISCUTIENDO, Y EL PROYECTO AL CAÑO
Por Aoyama el 03 de Agosto de 2006
Aoyama :
Ok, de acuerdo, pero no te limites a solo paginas web´s
Por Aoyama el 03 de Agosto de 2006
Maikel :
Aoyama :
Ok, de acuerdo, pero no te limites a solo paginas web´s
De hecho en ningún momento hablé sólo de páginas web...
Si bien no le agrado (se encerro en su oficina y se dedico a exigir reportes éxoticos que nuca uso, y hasta la fecha no usa) al final nos dejo trabajar con ellos y entregarle un sistema eficaz, hecho a medida de cada puesto.
1.- Sí hay clientes idiotas
2.- No todos son idiotas
3.- A veces yo soy el idiota
Maikel, en gran parte estoy de acuerdo contigo, y recalco, en gran parte. También estoy de acuerdo con Hernan, es evidente que su experiencia es considerable en este punto.
En muchos casos, empresas como agencias de publicidad (que no saben ni un céntimo de desarrollo Web) me sub-contratan para desarrollar sitios. Ellos le venden el proyecto al cliente final (bancos, embotelladoras de refrescos, etc...), el cliente final les dice -en grandes rasgos- lo que necesita (vender en internet por ejemplo).
El caso se complica -si lo vemos desde la óptica de Maikel- porque el cliente PEPSI -por ejemplo- contrata a BBDO (agencia de publicidad) para desarrollar su sitio. BBDO le dice a pedro: "El cliente quiere un sitio para promover sus refrescos y la participación de éste en la película Superman". Entonces pedro pregunta: "¿Y qué necesitan exactamente?". El cliente de pedro (la agencia), lo ve con ojos de "no seas pendejo, te estoy contratando porque no lo puedo/quiero hacer yo..."; así que pedro, al ver la mirada del cliente (la agencia), le dice: "OK, haremos una propuesta y la revisamos mañana".
El cliente (la agencia), NO espera que pedro le lleve una serie de detalles técnicos, le interesa que le diga: "su sitio tendrá estas secciones a,b,c,d y e". La agencia dice OK, me parece bien. Entonces pedro, hace el sitio con las secciones a,b,c,d y e; según su plan y sin pedirle al cliente la bendita definición de requerimientos. Te aseguro que si yo le salgo a la agencia con que quiero una "definición de requerimientos", me mandan a pelar naranjas, se buscan alguien que no les "complique" la vida y siguen haciendo negocios "a lo grande". El cliente NO me contrata para ocasionarle problemas, sino para solucionarselos.
Imagina que esto se puede poner peor. PEPSI contrata a la agencia, la agencia me contrata a mi, yo tengo desarrolladores a mi cargo. PEPSI dice que quiere algo, la agencia me dice que PEPSI quiere algo y yo le digo al desarrollador a mi cargo que PEPSI quiere algo... pues al desarrollador le digo lo que PEPSI quiere, el desarrollador, entonces, hace ese trabajo de planificación, una vez que lo hace -mientras yo sigo haciendo negocios con más clientes para poder hacer que la empresa subsista y se desarrolle- me lo plantea, se lo planteo a la agencia, la agencia al cliente (a veces la agencia lo rebota antes que el cliente y se reprocesa la cosa) y una vez con el visto bueno, pues se hace la cosa.
A veces, nosotros complicamos la cosa más de lo que realmente amerita. Es importante no ponernos tan drásticos con los clientes. Otra vez, no nos contratan para que les compliquemos la cosa, sino para que se la descompliquemos.
Este es un tema importante y cada quien tiene su opinión, pues cada quien sabe cómo prefiere tratar a los clientes según el mercado.
HOY justamente le entregué la propuesta al presidente de una Fundación que está por empezar una universidad. Él me dijo, "mirá, me gusta tu propuesta y la asesoría que me has dado. En nuestra plática he aprendido mucho y me has ayudado a tener una mejor perspectiva del proyecto. Ahora podré pedirle lo mismo que me estás proponiendo a las otras empresas que participan en la licitación".
Al escuchar eso, cualquiera pensaría: "que pendejo soy, le dije a este fulano, lo que necesita para que los demás oferentes puedan competir y ganarme el proyecto". Pero en realidad, yo creo que ya me gané el respeto del tipo (que me aclaró que la decisión la tomaraán por precio, más que por cualquier otro factor) y eso, en el mediano y largo plazo (sino es que en el corto) vale mucho y suman a la imagen de tu marca, te creas un prestigio.
Pero bueno, ese es otro tema.
En general, MUY BUEN TEMA MAIKEL, muy bueno. De acuerdo contigo y de acuerdo con Hernan.
Por jomajudo Pro el 04 de Agosto de 2006
Lo que quiero decir es, extraer toda la información posible a los clientes de lo quieren, muchas veces ni ellos mismo estan claros, asi que no puede hacerse todo en la primera reunión, pues como ustedes dicen en la practica se le presentan propuestas, avances, etcétera. Dependiendo de que tan claro él este con lo que quiere, se toma una serie de pasos (estrategia como le dice hernan) a seguir para poder definir bien que es lo quiere, que para nosotros al final estariamos definiendo los requerimientos que debemos sastisfacer.
Seria ideal poder planificar, estimar costo y esfuerzo con una lista de requerimientos bien definida, pero desgraciadamente no siempre es posible, pues hay proyectos que ninguno sabe bien que es lo que se quiere hacer, asi que una estrategia posible es que la comunicación cliente-desarrollador(o persona encargada) deba ser continua y desarrollando el proyecto concurrentemente, quizás hasta el final del proyecto. Hay otros en que si podemos definir bien una lista de requerimientos desde el principio, antes de empezar a desarrollar.
Dependiendo del tipo de proyecto se debe eligir/plantear una estrategia para definir esa lista de requerimientos, entre otra cosas.
- ¿"servibar" o no servibar en la oficina?
Realmente la cerveza, alcohol y diversión, son necesarios para programar...
No en serio, parece que nunca te hubieras encontrado el caso de un cliente que no sabe lo que quiere, o peor aun, que cree que sabe mas que uno como ha de hacerse algo porque"alguien" se lo dijo. Incluso he tenido algunos que me han dicho que ellos lo quieren de cierta forma y que no les importa el usuario final, que eso es de ellos y asi lo quieren (lease caso intros en flash).
Insisto, has tenido mucha suerte...
Hey!, se me acaba de ocurrir algo.
Ya regreso, voy a invertir 100 dólares (a manera de práctica para ayudar a ése pobre cliente)
Y no estamos criticando al cliente, ni lo insultamos ni nada, solo estamos diciendo que NO debemos dejar que pase, para que poderle entregar lo que el exactamente quiere, como y cuando el lo quiera.
saludos
La100mails :
Hey!, se me acaba de ocurrir algo.
Ya regreso, voy a invertir 100 dólares (a manera de práctica para ayudar a ése pobre cliente)
la100ra en el caso me planteas yo salgo conduciendo un bonito auto
Maikel :
Dejar que pase que ?
[/quote]
Hernan :
La100mails :
Por Coyr el 04 de Agosto de 2006
...heee Bate(tm)
Coyr :
es lo de siempre
Por Aoyama el 05 de Agosto de 2006
Pedro :
Hernan :
Es cierto, el cliente no es nuestro enemigo, pero a veces abusa un poco de esa relación, en fin, coincido en una cosa, y creo que todos los que estamos aquí lo hacemos, nuestro trabajo es brindarle soluciones, se supone que nosotros somos los especialistas y que lo que le decimos al cliente no es sacado de nuestra imaginación sino producto de mucho esfuerzo, estudio y trabajo, el detalle es cuando el cliente es necio y se aferra a una idea, a mi me ha tocado que le planteo a un cliente una solución, la que considero correcta y que le puede ayudar a que su problema sea resuelto, pero el cliente se aferra a otra idea porque lo vío en Internet y le gusto o un amigo le dijo que esa idea era mejor o más productiva.
Muchos clientes son fácilmente influenciables por factores externos, sobre todo porque la mayoría de ellos, piensa en el proyecto en cuestiones económicas, si le ofresco una solución a su problema, pero el costo es algo elevado, igual viene un incircunciso y le ofrece a un costo más bajo una solución que a veces puede no ser muy adecuada, luego entonces, ahí es donde viene nuestro poder de convencimiento y negociación, con todo yo estoy seguro que no soy el único al que le han tocdo clientes que te dicen "verde lo quiero, y verde lo debes hacer" y aunque tu le diga que no puede ser verde por X o Y razones tanto técnica, operativas y a veces hasta económicas, simplemente se las pasan olimpicamente por el arco del triunfo y acabas haciendo lo que pide porque al final, como bien dijo pedro, es el que paga...
Aclaro que no soy enemigo del cliente, me he hallado clientes totalmente opuestos que son muy cooperativos y considerados (y esos son los que atesoras) que te dan todas las facilidades y se toman la molestía de leer y analizar cada cosa que tu les digas o les propongas, incluso he tenido algunos que confían ciegamente en mí, y hasta ahora creo que no los he defraudado, de lo que si soy enemigo es de ese famoso dicho de "el cliente siempre tiene la razón", porque todos sabemos que en la realidad no es que siempre tenga la razón, es que al final es el que paga.
Por Bovino el 05 de Agosto de 2006
He seguido con atención esta interesante discusión, y creo que, en primer lugar, y a pesar de ser abogado —lo que hace pesar sobre mí una fuerte sospecha de oligofrenia—, creo que hay clientes imbéciles, abogados imbéciles y diseñadores imbéciles. Además de abogado soy gerente editorial de una pequeña editorial jurídica en la que nos preocupamos por el diseño de nuestros libros. Más allá de mis gustos personales, es una regla absolutamente indestructible el hecho de que los abogados no compran libros con fotos en la tapa, y que sólo podés jugar con un diseño que utilice —no sé nada de diseño, pero sí tengo sentido estético— tipografías, símbolos geométricos y combinación de colores.
En el estudio jurídico en el que trabajo, un estudio concheto, a la diseñadora que tenía que armar toda la nueva imagen del estudio, incluyendo el brochure, se le ocurrió elegir de un banco de imágenes de miles de fotografías el retrato de un espermatozoide picando en punta para llegar al óvulo, para expresar que siempre estábamos por delante de los demás. Me llevó 45 minutos explicarle a esta señora, que finalmente hizo un buen trabajo, que la imagen no resultaba muy apropiada para nuestro estudio, y que con la fama que tenemos los abogados —además de oligofrénicos, piratas—, si yo entraba como cliente a un estudio de abogados y veía esa imagen lo más probable sería que en lugar de pensar que los leguleyos picaran en punta probablemente sintiera que pronto me dolería por debajo de la espalda.
Si tratan con un cliente que aun sin saber nada de diseño tiene claras ciertas cuestiones —además de lo que desea— que ustedes no tienen por qué saber —por ej., lo de las fotos en las tapas de los libros para abogados—, lo mejor es establecer un buen diálogo y no imponerle soluciones "lógicas" —a lo sumo serán más o menos apropiadas o razonables, pero no entiendo qué tiene que ver la lógica en todo esto—. Es lo que en medicina se llama "consentimiento informado", y que tanto los abogados, los editores, como los diseñadores debemos utilizar como criterio rector de nuestro trabajo.
Saludos oligofrénicos,
Aoyama :
Aoyama :
F :
Sé a que te refieres pero me gustaría aclarar para todos el concepto que dices no es precisamente convencer. Figuren esto, una charla con un amigo, o una persona a la que no quieres hacer daño. Cuando esa persona dice algo equivocado, uno no le convence, le aconseja en puntos bien fundamentados, no intenta blandir sus defensas, sino convertir sus defensas en positivo.
Esto es lo mismo, en orden para lograr hacer entender ciertos puntos a un cliente, hay que guíarle, lograr que entienda el punto. Y en el proceso, mi recomendación personal es entender su punto. Si lo hacen, luego de un tiempo, de miles de conversaciones con clientes, tendrán los puntos de vistas de los capitanes de industria, a tal punto que tendrán sus visiones de negocio. No es eso c00l?
Por Bovino el 05 de Agosto de 2006
ABovino
Bovino :
ABovino
A veces el silencio corresponde más que un comentario vacio. Pero sí has de necesitarlo; de hecho me parecio un comentario muy acertado el tuyo. Nada que objetar.
En especial tú conclusión final "consentimiento informado", esta muy bien orientado.
En fin, un buen aporte. Pero no busques "gloria" por tus aportes, sino compartir el conocimiento tienes, así puedes seguir aprendiendo como todos aquí. Es el objeto de una buena discusión eso.
Atentamente. Hernán.
Bovino :
¿A cuál definición de oligofrenia te refieres con ésto?
Según la R.A.E.
Según psicopedagogia.com
Según discapnet
Bovino :
Freddie® :
Alli responde Freddie, a lo que agrego, es como tú dices Bovino, no se gana nada imponiendole algo - a nadie le gusta que le impongan las cosas - la cuestión es llegar a un acuerdo segun lo que plantea el cliente y la soluciones que le brindan (el contratado), y se hace como ha comentado hernan al cliente hay que hacerle propuestas, dialogar con él, y que vaya decidiendo en una "mezcla" entre lo correcto(del contratado) y lo deseado(por él [cliente]).
Ahora algo que quiero dejar en claro, la estrategias que uno use para conseguir esa lista de requerimientos debe ser creada y mejorada por las experiencia anteriores, y pueden ser tan formales(encerrados en una oficina, discutiendo) o informales(en un cafe, criticando a la mesonera) como sean posibles, depende del proyecto deben tener varias estrategias, algunos requeriran que sean muy formales, otros que sean informales, o por qué no una mezcla de ambas.
saludos
Por Aoyama el 09 de Agosto de 2006
Freddie® :
Ok, veamos, en realidad no es por "miedo a perderlos", si así fuera, ni siquiera me metería a hacer estás cosas, mi punto es, que en aquellas ocasiones en que no es posible llegar a un acuerdo (porque aceptemóslo, no todos tenemos el mismo poder de convencimiento) con el cliente, yo considero lo más prudente acceder a su petición, haciendole ver que no es lo correcto, pero que se hará de cualquier forma.
Me han tocado clientes del tipo "me valen $&%&$/ tus estándares yo lo quiero verde y punto." en esos casos en que el cliente es "especial" como dicen aquí en mi tierra, yo prefiero no seguir haciendole bola, hago lo que él me pide, pero le advierto de los riesgos que conlleva hacer el trabajo como él lo desea y de las posibles soluciones (todo en un lindo y bien decorado documento) y se lo entrego al final junto con el trabajo terminado, después, prefiero no volver a trabajar con ellos, lo curioso es que esos clientes "especiales" acaban recomendandome con otros, por lo que no veo mi postura como "inseguridad", ¿qué sucede al final? mi cliente queda complacido con el trabajo, yo me lavo las manos por el trabajo e incluso gano buenas recomendaciones que me proporcionan trabajos a futuro.
Por FANY el 24 de Septiembre de 2006
Por adriana el 24 de Abril de 2007
Por jenifer el 10 de Septiembre de 2007
Decir que el cliente es oligofrénico es la mejor manera de demostrar que eres un oligofrénico.
Por Juan Pablo el 23 de Marzo de 2009
Y al iniciarse cualquiera de estos tres navegadores que aparezca un mensaje que diga "IE es malo, muy malo."
Entonces el usuario de querer deshacerse del virus e instalar nuevamente Windows KK, ese mensaje rondará por sus cabezas e inconcientemente se bajarán un navegador que cumple los estándares y lo instalen.
PD. Mi novia ya automáticamente abre siempre el Firefox sin pensarlo en lugar del IE!
Por yo el 01 de Septiembre de 2009