Discusión sobre el artículo "Cómo crear una Tarea Técnica al encargar un indicador" - página 3
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
Alucinante. ¿Podemos ver lo que se quería decir al final? ¿Proporcionó el cliente imágenes al principio o sólo fueron palabras?
Rashid, hay muchas páginas de discusión - es superfluo aquí, y todavía no he hecho el indicador - el plazo todavía no se acerca, y otras cosas son más importantes.
En mi opinión, hay demasiados detalles técnicos en el artículo, que el cliente nunca entenderá.
Hagamos enlaces para el artículo, como es nuestra costumbre. Podrá ver inmediatamente la sección necesaria y saltar a ella - sin siquiera leer todo el artículo
Ejemplo - MQL5.community - Guía del usuario
1. Configuración del perfil
2. Editor d e mensajes
3. Favoritos
4. Mensajes privados Mensajes privados
5. Escritorio de servicio
6. Trabajo y cálculos
7. Mercado
8. Señales
9. RSS
10. Calificación
11 Almacenamiento MQL5
Lo principal para el cliente es tener una idea clara de lo que realmente quiere. Para tener esta idea, antes de ir a freelance, sería bueno que el cliente intente hacer un esquema simplificado del indicador/experto en Excel y proporcione su esquema con capturas de pantalla: cómo se ve tal o cual señal en el gráfico.
Un buen deseo. Aunque me parece que ninguno de los clientes lo hace.
Es una buena observación. Aunque no creo que ninguno de los clientes lo haga.
Ése es el problema.
Ninguno de ellos piensa en la lógica de las funciones, las formalizaciones y qué se llama para qué. Como se suele decir, si la abuela tuviera abuelo, sería un abuelo.....
El cliente percibe el gráfico de forma 100% visual. Incluso el concepto de buffer es un bosque oscuro para ellos.
El cliente mira el gráfico y quiere que se dibuje una línea aquí, esta altura, esta anchura. Los enfoques y las explicaciones son muy específicos
Esta es la base sobre la que Rashid debe permanecer. Ni siquiera intentes ampliar sus horizontes, porque se cargará y no hará nada de lo que intentas hacer de él, porque necesita revisar sus puntos de vista sobre la vida, y esto es mucho tiempo, y necesitas un indicador para ayer.
---
Es necesario dejar al cliente estrictamente en el marco de sus conceptos (que ya ha inventado cuando se aplica a trabajar por cuenta propia).
Y justo no al cliente, pero al codificador para dar esta plantilla cuestionario, en el que se le pedirá al cliente los datos sobre los puntos y escribirlos de acuerdo a su estándar.
Y todo lo demás es pura comunicación, que (a diferencia de los expertos en el oficio de escribir) no se puede formalizar de ninguna manera.
He aquí una sugerencia.
- Cambiar el enfoque del concepto de TdR.
Ahora no es una correspondencia o txt o doc con imágenes, sino un atributo inamovible de la propia aplicación. No es un documento adjunto, sino un componente del servicio (en forma de un documento xml generado).
Es el TdR en la aplicación, elaborado con la ayuda de su asistente y firmado por ambas partes será un documento.
Actitud del cliente
- si realmente desea cargar al cliente con información sobre las capacidades de MT, no debería exigirle que rellene todos los campos al crear una solicitud. Basta con obtener de él lo que ha sido capaz de identificar en su cabeza en el marco de los conceptos algorítmicos y de MQL. Marque algunas opciones de estilos, gráficos, etc.
Actitud del codificador
- el codificador se encarga de elaborar el TOR completo y de formalizar todas las funciones del cliente.
Se comunica con el cliente, rellena detalladamente el componente TOR, prescribe algoritmos y conceptos precisos para que sean percibidos por el cliente y aprobados. Es decir, la creación de TOR es un proceso de comunicación y aprobación. El TK forma parte del pedido.
Incluso si el codificador se niega a trabajar, el TK trabajado permanece en el pedido y otro ejecutor puede seguir trabajando con él. El nuevo ejecutor no verá la correspondencia, pero verá su resultado - TOR.
---
Es entonces cuando las ovejas están intactas y el cerebro del cliente no está roto.
El cliente está satisfecho - el codificador le entendió e hizo los TOR para él.
El codificador está satisfecho - hizo los TOR aprobados con la ayuda del asistente, y es abierto, no apretado.
El árbitro está satisfecho - no necesita leer documentos de terceros, sino sólo ver el documento TOR completado en la solicitud.
En el futuro será posible recopilar estadísticas sobre estos documentos, ya que los propios términos de referencia son ahora un documento formal.
---
Es necesario dejar al cliente estrictamente dentro del marco de sus conceptos (que ya se ha formado él mismo al solicitar ser autónomo).
Y no sólo para el cliente, sino también para el codificador para dar este cuestionario plantilla, según la cual se le pedirá al cliente los datos sobre los artículos y escribirlos de acuerdo a su estándar.
Y todo lo demás es pura comunicación, que (a diferencia de los expertos en el oficio de escribir) no se puede formalizar de ninguna manera.
Deberíamos intentarlo. En el proceso de discusión de este hilo, creo que estoy empezando a cambiar un poco el concepto del artículo. Se hará más hincapié en dibujar figuras explicativas, se pondrán algunos ejemplos de RPT y luego seguirá el contenido actual. Para los que puedan pasar los dos primeros párrafos.
Quiero decir, propongo esto
- cambiar el enfoque del concepto de TdR.
Ahora no es una correspondencia o txt o doc con imágenes, sino un atributo no matable de la propia aplicación. No es un documento adjunto, sino un componente del servicio (en forma de un documento xml generado).
Es el TdR en la aplicación, elaborado con la ayuda de su asistente y firmado por ambas partes será un documento.
Dudo que esta sea la forma de conducir a la humanidad al paraíso. Para reinterpretar un clásico:
Dudo que esa sea la forma de llevar a la humanidad al cielo. Reinterpretando un clásico:
No importa que excusemos a un codificador de escribir la RPT, pero al final es el codificador quien la verifica, y la complejidad de su verificación está incluida en el presupuesto.
Es decir, al final lo paga el cliente (paga el tiempo del codificador), pensando que es una programación tan cara, y no la formalización de sus TdR).
Se hará más hincapié en hacer dibujos explicativos, se darán algunos ejemplos de TOR, y luego se irá al contenido actual. Para los que puedan con los dos primeros puntos.
sí, más capturas de pantalla o micro gifs.
Sobre todo en el asistente para tomar una decisión por parte del cliente: qué tipo de indicador especificar en los TdR, o qué tipo de líneas. No sólo palabras, sino cómo se verá. Porque así es como razonó - lo que veré al final y si corresponde a su idea.
especialmente en el asistente para tomar una decisión por parte del cliente: qué tipo de indicador especificar en los TdR, o qué tipo de líneas. No sólo palabras, sino cómo se verá. Porque así es como razonó - lo que veré al final y si corresponde a su visión
Master TK no está planeado todavía. Aquí sería primero artículo útil para hacer y evaluar el resultado de su aparición
Master TK aún no está previsto. Aquí sería primero hacer un artículo útil y evaluar el resultado de su aparición
Sí, por ahora me refería a un artículo de sugerencia bajo el máster.