Mercado: ¿Cómo se gestionarán las situaciones de fallo del producto tras una actualización de la compilación?
...
Hasta ahora, la buena noticia es que la empresa se está desarrollando, y organiza y apoya el mercado y la venta de productos MQL5. Por lo tanto, habrá una lucha por la calidad, pero ¿quién la pagará con su reputación y su dinero?
Las preguntas son muy relevantes. Y hay que encontrar una solución. Ya tengo una sugerencia.
Por ejemplo, puede hacer lo siguiente. Para instalar la siguiente actualización (build) para el terminal de comercio, el propio usuario decide si la instala o no. En otras palabras, hay que hacer que conozca la nueva construcción pero que pueda decidir por sí mismo cuándo puede instalarla. Los desarrolladores de aplicaciones deben entonces tener dos versiones del terminal instalado. Una versión con la compilación anterior, y una segunda versión con la compilación más reciente. Si no se encuentran errores en la nueva compilación cuando se utiliza el producto, el vendedor hace una nota en el mercado que el producto es compatible con la última compilación. Si el producto empieza a tener fallos en la última compilación, no se pondrá la marca y el usuario sabrá que es demasiado pronto para instalar la nueva compilación.
Esta es una opción. Más cosas en las que pensar...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
De hecho, esta cuestión se viene gestando desde hace mucho tiempo.
¿Qué deben hacer ahora los tres partidos?
Dos. El programador no tiene nada que ver. El comprador sólo tiene que ser capaz de descargar el nuevo mercado ex. Sin correos electrónicos, solicitudes, captchas, mensajes de confirmación, etc.
Por supuesto, sólo en el hardware, donde ya está encendido.
Los productos tienen una función de versionado interna, puede leer sobre ella en el artículo https://www.mql5.com/ru/articles/385.
Cuando se publique una nueva versión, habrá un aviso automático para actualizar el software. Esto es bueno para actualizar versiones menores como la 2.xx
Cuando se lancen versiones mayores, será necesario registrar un nuevo producto para poder revenderlo o seguir lanzando nuevas versiones bajo el registro anterior con una actualización automática gratuita para los clientes existentes.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
Los productos tienen un versionado interno, puede leerlo en el artículo https://www.mql5.com/ru/articles/385
Cuando se publique una nueva versión, habrá un aviso automático para actualizar el software. Esto es bueno para actualizar versiones menores como la 2.xx
Cuando se lancen versiones mayores, será necesario registrar el nuevo producto para poder revenderlo o seguir lanzando nuevas versiones bajo el registro anterior con una actualización automática gratuita para los clientes existentes.
Sí, esto es lo que se aplica a las nuevas versiones de los productos.
Pero eso es un poco diferente a lo que trata la pregunta del hilo.
¿Y si la nueva construcción del terminal bloquea el funcionamiento normal del software?
Si lo piensas, las builds salen unas dos veces al mes. Resulta que al actualizar el terminal, el cliente perderá la capacidad de utilizar el producto durante un par de semanas. De eso estamos hablando.
Y no sólo eso, el programador debería dejar su trabajo actual y ponerse a trabajar en la captura del bicho. ¿Y si tiene varios productos en el mercado?
Así que todos ellos se llevan las manos a la cabeza.
¿Pero cuál es la solución?
pero ¿cuál podría ser la solución?
no hay solución.
Hasta que no haya una nueva versión con las correcciones, el producto permanecerá inactivo (o perderá dinero para el cliente, o tal vez incluso beneficios, ¿quién sabe? - entonces, después de arreglar el fallo del terminal, una multitud de usuarios exigirá indignada que el fallo vuelva al terminal...)
Si no se encuentran errores en la nueva versión mientras se utiliza el producto, el vendedor marcará el producto en el Mercado como compatible con la última versión. Si el producto empieza a "fallar" en la última compilación, no se marca y el usuario sabrá que es demasiado pronto para instalar la nueva compilación.
¿Así que el proveedor también es responsable de detectar los errores en las nuevas versiones? De hecho, el producto es utilizado por el comprador (y detecta un error), el problema se produce por culpa de MQ (dentro del tema indicado), ¿y el vendedor tiene que asumir la culpa?
...
Es una opción. Más cosas en las que pensar...
Idealmente, vemos la siguiente solución (la pregunta es cuán factible es):
1- Desactivar la opción de instalación de actualizaciones automáticas en el terminal, sólo el mensaje de disponibilidad y la decisión por parte del usuario (esto se ha sugerido en algún lugar antes);
2- Función "rollback to build #..." en el terminal.
Entonces, en el caso de un fallo de EA causado por un nuevo fallo de construcción, se pueden tomar fácilmente medidas temporales hasta que se resuelva la situación de construcción. Los más precavidos pueden, como precaución adicional, instalar las actualizaciones en un día libre y ejecutar su EA en el probador. Por la adecuación o inadecuación del historial en comparación con la construcción anterior, tome la decisión final de actualizar-cancelar.
Cuando desarrolle (venda) un Asesor Experto, debe especificar la compilación en la que se ha probado su rendimiento.
Lo ideal es que veamos la siguiente solución (la cuestión es cuán realista es):
1- Desactivar la opción de instalar automáticamente las actualizaciones en el terminal, informando únicamente de la disponibilidad y tomando la decisión el usuario (ya se ha sugerido en alguna parte);
2- Función "rollback to build #..." en el terminal.
Entonces, en el caso de un fallo de EA causado por un nuevo fallo de construcción, se pueden tomar fácilmente medidas temporales hasta que se resuelva la situación de construcción. Los más precavidos pueden, como precaución adicional, instalar las actualizaciones en un día libre y ejecutar su EA en el probador. Por la adecuación o inadecuación del historial en comparación con la construcción anterior, tome la decisión final de actualizar-cancelar.
Cuando desarrolle (venda) un Asesor Experto, debe especificar la compilación en la que se ha probado su rendimiento.
sí, a mí también me parece una sugerencia razonable, (como otra similar que sugirió tol64 inmediatamente).
Instalar una construcción bajo demanda es la salida lógica. Protegerá al vendedor y al comprador de los promotores. :)
El vendedor podrá probar más tranquilamente el producto en la nueva compilación y exponer las modificaciones y la nueva versión, si es necesario.
Pido a los desarrolladores de la plataforma que piensen en este tema y en esta propuesta en particular.
¿Quizás la empresa tiene su propia visión del problema y su solución?
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
En realidad, esta es una cuestión que se plantea desde hace mucho tiempo.
La situación es la siguiente, bastante real.El programador y el control del mercado, tras probar el software, lo ponen en el mercado.
Por supuesto, lo más estresante de esta situación es que la reputación del programador sufrirá más que la de la empresa. Porque todavía hay que identificar y probar los problemas de la construcción.El cliente, después de pagar una determinada cantidad de dinero por él, descubre tiempo después que el producto ya no funciona en la nueva construcción.
DE ACUERDO. El programador comprueba y encuentra que el problema está en la nueva compilación, pero no hay forma de encontrar y localizar el fallo.
¿Qué hacen ahora los tres partidos?
¿Devolver al comprador los fondos que ya haya invertido en la nueva promoción?
¿Mandar al comprador a los desarrolladores del terminal diciendo que el problema está en la compilación y que no es culpa del programador?
¿O de otra manera?
El producto recibirá muchos comentarios negativos durante este tiempo y puede que tenga que ser retirado de la estantería.
Así que resulta que los programadores de MQL dependen de los desarrolladores de la plataforma. Y son tan dependientes que cualquier truco en la construcción puede arruinar su reputación en las raíces, o interrumpir futuros pedidos u otros planes.
En general, ¿qué salida se prevé para esta situación y cómo puede resolverla la empresa?
ZS. Hasta ahora la buena noticia es que la empresa está desarrollando y ella misma organiza y apoya el Mercado y la venta de los productos MQL5. Por lo tanto, habrá una lucha por la calidad, pero ¿quién la pagará con su reputación y su dinero?