Discusión sobre el artículo "Cómo Pedir un Robot de Comercio en MQL5 y MQL4" - página 4
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
De hecho, todos (la Administración, el Desarrollador y el Cliente) estamos en lados diferentes del servicio. Y cada uno ve sus propios matices y dificultades. El cuadro de diálogo que has citado lo acabo de ver: es un avance significativo e importante para hacer llegar al Cliente toda la información necesaria. He enumerado las preguntas que se hacen el 99% de los clientes cuando acuden al servicio por primera vez. Y todos los clientes tienen que dar un enlace a la Guía Paso a Paso y a la sección de Cálculos de Cuenta con una constancia y persistencia envidiables. Este estado de cosas sugiere que la informatividad en los temas clave -Guía Paso a Paso y Cálculos- es claramente insuficiente.
Hola, soy nuevo en mt5.com, he pedido un EA de la sección de trabajos y al pasar por el proceso paso a paso del trabajo me he encontrado con dificultades en el paso'Negociación de requisitos'. Ambos, el desarrollador y yo, confirmamos el paso pero no puedo acceder al siguiente paso Prototipo/Modelo. La columna "Negociación de requisitos" sigue en color verde y no puedo acceder a la siguiente sección. Alguien con experiencia me puede ayudar...
TENGO EL MISMO PROBLEMA, VER IMAGENES ADJUNTAS
¿Tienes idea de lo que está pasando, cómo podríamos resolver esta situación?
Buenas tardes a todos. Tengo una duda sobre este tema. Se repite a menudo la situación de que se toma el trabajo, se empieza a hacer y luego resulta que o bien el indicador proporcionado por el cliente como fuente de señales para abrir operaciones no es correcto y hay que mejorarlo, o bien los deseos del cliente tras pasar la fase de aprobación de los TdR han aumentado, lo que conlleva un incremento del coste del trabajo. El cliente está de acuerdo con esto y está dispuesto a pagar un extra, pero el precio del proyecto es fijo y, según tengo entendido, no se puede cambiar ni siquiera de mutuo acuerdo. Como resultado, el pago extra tiene que pasar por el sitio o hacer algún otro trabajo, que no siempre es conveniente. La pregunta es la siguiente - ¿todavía no hay manera de cambiar el costo del trabajo después de firmar el TOR. En la vida real, todo es simple - emitir un addendum al contrato, en el que. prescribir cambios en los TdR y el precio del contrato - sellos de algodón y firmas en ambos lados y seguir adelante. Pero aquí no encontré nada de eso. ¿O tal vez no busqué lo suficiente? )))
Hasta ahora no hay tal posibilidad, pero vamos a pensar en la aplicación.
Y sólo hacia arriba y sólo si el cliente tiene suficiente dinero.
Aún no tenemos esta posibilidad, pero pensaremos en realizarla.
Y sólo hacia arriba y sólo si el cliente tiene suficiente dinero.
Aún no tenemos esta posibilidad, pero pensaremos en realizarla.
Y sólo hacia arriba y sólo si el cliente tiene suficiente dinero.
Aún no tenemos esta posibilidad, pero pensaremos en realizarla.
Y sólo hacia arriba y sólo si el cliente tiene suficiente dinero.
Justo cuando
1) el ejecutante tenga la posibilidad de rechazar el trabajo
2) el ejecutante tenga la posibilidad de reducir el coste del trabajo
3) el cliente tenga la posibilidad de aumentar el coste del trabajo
Hay un fallo en las fases de ejecución del trabajo:
cláusula 3.2.7. del Reglamento "Tras la confirmación del paso "Aprobación de los TdR" por ambas partes, el importe del Pedido se bloquea en la cuenta del Cliente en el Sistema de Pagos".
Resulta que las partes discuten los TdR - es decir - el Contratista profundiza en los TdR, invierte su tiempo, corrige los TdR del Cliente, realmente consulta al Cliente - y como resultado el Cliente tiene la oportunidad de "escapar" y/o elegir otro. Como resultado, a menudo es necesario aceptar unos TdR superficialmente estudiados con todas las consecuencias en forma de "subestimación de la complejidad/coste/realizabilidad del trabajo".
La fase de "aprobación de los TdR" debería desarrollarse en dos etapas:
1. 1. El cliente confirma los términos de referencia: se bloquea el importe.
2. Hay una discusión de los TdR y ANTES de la confirmación de la etapa "Aprobación de los TdR" el ejecutante debería tener la posibilidad de: rechazar los TdR, cambiar el coste.
O la posibilidad de rechazar los TdR por parte del Contratista y cambiar el coste a realizar en la fase "Prototipo/Mockup".
Correcto cuando:
1) el contratista tiene la capacidad de rechazar la obra
2) el contratista tiene la capacidad de reducir el coste de la obra
3) el cliente tiene la capacidad de aumentar el coste de la obra.
Hay un fallo en los pasos de ejecución de la obra:
cláusula 3.2.7. del Reglamento "Tras la confirmación del paso "Aprobación de los TdR" por ambas partes, el importe del Pedido se bloquea en la cuenta del Cliente en el Sistema de Pagos".
Resulta que las partes discuten los TdR - es decir - el Contratista profundiza en los TdR, invierte su tiempo, corrige los TdR del Cliente, realmente consulta al Cliente - y como resultado el Cliente tiene la oportunidad de "escapar" y/o elegir otro. Como resultado, a menudo es necesario aceptar unos TdR superficialmente estudiados con todas las consecuencias en forma de "subestimación de la complejidad/coste/realizabilidad del trabajo".
La fase de "aprobación de los TdR" debería desarrollarse en dos etapas:
1. 1. El cliente confirma los términos de referencia: se bloquea el importe.
2. Hay una discusión de los TdR y ANTES de la confirmación de la etapa "Aprobación de los TdR" el ejecutante debería tener la posibilidad de: rechazar los TdR, cambiar el coste.
O la posibilidad de rechazar los TdR por parte del Contratista y cambiar el coste a realizar en la etapa "Prototipo/Mockup".
Confirmo, varias veces en tales rastrillos pisado en tales rastrillos, masticar el cliente su propio TOR. Usted pasa 3-4 días en él. Se extiende todo en los estantes, y se va con este TOR ya desplegado, y ordena su ejecución por una cantidad menor.
Hacer un TOR sensata parte del león de la obra, y esta parte resulta que no tienen pago garantizado en el servicio "Trabajo" !!!!.
Estos son sus riesgos como contratista. Al fin y al cabo, cuando eliges un frigorífico, no compras uno que esté muy bien descrito por el encargado. Usted toma nota de la historia del gerente y puede ir a otra tienda y comprar un frigorífico más barato. Y el gerente no recibirá nada por su historia de calidad. Pero es imposible no contar nada. El gerente lo entiende y se arriesga cada vez.
Usted, al igual que otros apologistas del libre uso de la mano de obra cualificada de un programador, confunde constante y persistentemente
a) la venta de productos ya fabricados, cuyo precio ya incluye una penalización en forma de trabajo improductivo de un gestor-consultor, alquiler de la tienda, etc,
b) con la investigación, el desarrollo y los trabajos técnicos - en este caso el objetivo de la fase de "Aprobación" es comprender lo que quiere el Cliente, formalizar su tarea inicialmente vaga, etc. etc. - vale la pena el coste del trabajo profesional, que sin duda debe pagarse.
Si en el primer caso el gestor-consultor no crea un nuevo valor - el producto ya está fabricado y listo para la venta, en el segundo caso el programador que discute con el cliente sus propios TdR crea un nuevo TdR para el cliente - y este trabajo debe pagarse.
Si, en su caso, el gestor cobra un sueldo, en el segundo caso, ¿en qué se basa para pensar que el programador debe seguir sin cobrar? Los RPT revisados y analizados no cuestan menos que el coste de escribir un programa - y que el cliente se vaya a otro programador es natural y está justificado por el deseo de pagar menos.
En realidad, ningún KB se comprometerá siquiera a analizar un problema sin un pago garantizado. Entonces, ¿por qué debería ser norma en el servicio de Trabajo no pagar (o no garantizar) el pago por analizar/revisar/redactar RPT?
La mayoría de las situaciones de arbitraje en el servicio de Trabajo son "TdR poco claros", "subestimación de la complejidad del trabajo". Y la razón es que el desarrollador está completamente desprotegido frente a un cliente sin escrúpulos en la fase de "aprobación de los TdR".
papaklass:
Lo mismo ocurre en su caso. Si se niega a trabajar en los términos de referencia con el cliente, lo perderá definitivamente. Y si ayuda de forma competente al cliente a redactar los términos de referencia, hay muchas probabilidades de que este trabajo le sea encomendado y de que en el futuro el cliente vuelva a trabajar con usted. Tómelo como un coste de trabajar con personas.
Es hora de dejar de ver a un programador como un cierto parado que no tiene nada que hacer, que se sienta a esperar y se contenta con cada cliente y cada pedido. Un programador tiene un trabajo principal, tiene sus propios intereses y tiempo libre. Y es poco probable que un programador se alegre de dedicar su tiempo libre a un pedido que puede tener lugar sólo con cierta probabilidad.